November 9, 2009 at 1:09 pm
I would like to know the percentage at which you would have to defragment your indexes?
November 9, 2009 at 1:37 pm
Per Books Online:
Fragmentation alone is not a sufficient reason to reorganize or rebuild an index. The main effect of fragmentation is that it slows down page read-ahead throughput during index scans. This causes slower response times. If the query workload on a fragmented table or index does not involve scans, because the workload is primarily singleton lookups, removing fragmentation may have no effect.
I recommend doing an online search on the subject. There are a number of good, informative articles on the subject.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
November 10, 2009 at 2:30 am
Nice quote G2. There is a lot of over-excitement surrounding fragmentation. Maybe it's because people 'know' that it is important to keep disk files defragmented?
The situation in SQL Server is quite different. Sure, if the majority of your queries involve big (range) scans on covering or clustered indexes, which invoke SQL Server's read-ahead mechanism, then yes, fragmentation can be important (much less so if your I/O system is RAM- or SSD- based!)
Read-ahead is only invoked on large scans where the data pages required are not already in cache. So, for many systems which either do mostly repetitive single-row operations, or which have enough buffer pool to keep the vast majority of the working set of data in memory, defragmenting offers little benefit, other than perhaps making the DBA feel better.
Paul
Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
November 10, 2009 at 6:47 am
I have an automatic defragmentation routine for indexes that checks number of pages (> 1000), fragmentation level, and check sys.dm_db_index_usage_stats (taking uptime into account). If the index has very few scans, it won't automatically defrag it. Will add it to an automated weekly report to let the DBA know that it may need to be manually defragged, or added to an override list that forces a defrag regardless of use.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
November 11, 2009 at 8:07 am
klineandking (11/9/2009)
I would like to know the percentage at which you would have to defragment your indexes?
The percentage at which you have an issue with performance related to index fragmentation?? 😀
This really is one of those "it depends" scenarios.
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
November 13, 2009 at 7:55 am
Hi,
See the following: http://www.sqlmag.com/Article/ArticleID/96059/sql_server_96059.html
This is a useful tool for those of us that need the comfort level:-)
Happy Weekend!
November 13, 2009 at 8:28 am
The microsoft recommendation is
<= 5% - Do nothing
>5 and <= 30% - Reorganize (defrag)
>30% - Rebuild
But as you can see from the all the posts....it depends! And is worth remebering that fragmentation in OLTP is not as costly as fragmentation in OLAP. You can use the following sql to identify fragmentation on a given tables index'
SELECT
a.index_id,
name,
avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats (DB_ID(' [database name] '),OBJECT_ID('
'),NULL, NULL, NULL) AS a
JOIN sys.indexes AS b ON
a.object_id = b.object_id AND
a.index_id = b.index_id;
November 13, 2009 at 1:51 pm
Thanks guys i really appreciate all your info on this
November 13, 2009 at 1:51 pm
Thanks really appreaciate all your help
November 13, 2009 at 2:01 pm
thank you so much i appreciate it
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply