DBCC SHOWCONTIG - Please Help

How Do i read this DBCC SHOWCONTIG
DBCC SHOWCONTIG scanning 'SAP_ITEM_XXX_SF' table...
Table: 'SAP_ITEM_XXX_SF' (1341194707); index ID: 1, database ID: 11
TABLE level scan performed.
- Pages Scanned........................: 168623
- Extents Scanned.......................: 21288
- Extent Switches.......................: 38573
- Avg. Pages per Extent..................: 7.9
- Scan Density [Best Count:Actual Count]......: 54.64% [21078:38574]
- Logical Scan Fragmentation ..............: 6.83%
- Extent Scan Fragmentation ...............: 29.76%
- Avg. Bytes Free per Page................: 1009.8
- Avg. Page Density (full)................: 87.52%
Scan Density And Avg. Page Density kinda concerns me !! How should i Fix it
?
Thanks A Bunchlots of good data here.
The three that I really focus on are "Pages Scanned", Scan Density, and Avg
Page Density.
The # of Pages Scanned basically indicates how many pages on disk it takes
to store the data for the table in question.
Anything under 1,000 pages is considered small and will have little impact
on index performance.
Scan Density indicates the percentage of contiguous space is used to store
your data. 100% means ALL of the data is in contiguous space (Ideal).
Anything below 80%, I would start to consider an indication of
"Fragmentation" which indicates excessive page splits, resulting in poor IO.
Avg Page Density indicates the percentage that each page used is filled. If
pages are 100% full, that means that in order to add new data to your table,
a Page Split will be required. A High number here, indicates that page
splits are likely, and for Write Intensive tables, this would suggest a need
for modifying the indexes "Fill Factor" settings.
There is much more to these numbers than what I mentioned above, but that is
a "Nutshell" view.
Cheers
Greg Jackson
PDX, Oregon
"Girish" <anonymous@.discussions.microsoft.com> wrote in message
news:769774C6-426F-4181-BEE5-70A5F71D4D08@.microsoft.com...
> How Do i read this DBCC SHOWCONTIG
> DBCC SHOWCONTIG scanning 'SAP_ITEM_XXX_SF' table...
> Table: 'SAP_ITEM_XXX_SF' (1341194707); index ID: 1, database ID: 11
> TABLE level scan performed.
> - Pages Scanned........................: 168623
> - Extents Scanned.......................: 21288
> - Extent Switches.......................: 38573
> - Avg. Pages per Extent..................: 7.9
> - Scan Density [Best Count:Actual Count]......: 54.64% [21078:38574]
> - Logical Scan Fragmentation ..............: 6.83%
> - Extent Scan Fragmentation ...............: 29.76%
> - Avg. Bytes Free per Page................: 1009.8
> - Avg. Page Density (full)................: 87.52%
>
> Scan Density And Avg. Page Density kinda concerns me !! How should i Fix
it ?
> Thanks A Bunch|||I agree with Jaxon, but I like to add one thing:
If the table (index) span several (mdf/ndf) files, then jump between files
will be considered fragmentation in Scan Density. So, in these cases, use
Logical Scan Fragmentation instead. The value you have seems fine. Look up
how to interpret that value in Books Online.
Tibor Karaszi, SQL Server MVP
Archive at:
http://groups.google.com/groups?oi=...ublic.sqlserver
"Jaxon" <GregoryAJackson@.hotmail.com> wrote in message
news:O1jBUFY9DHA.3176@.TK2MSFTNGP11.phx.gbl...
> lots of good data here.
> The three that I really focus on are "Pages Scanned", Scan Density, and
Avg
> Page Density.
> The # of Pages Scanned basically indicates how many pages on disk it takes
> to store the data for the table in question.
> Anything under 1,000 pages is considered small and will have little impact
> on index performance.
> Scan Density indicates the percentage of contiguous space is used to store
> your data. 100% means ALL of the data is in contiguous space (Ideal).
> Anything below 80%, I would start to consider an indication of
> "Fragmentation" which indicates excessive page splits, resulting in poor
IO.
> Avg Page Density indicates the percentage that each page used is filled.
If
> pages are 100% full, that means that in order to add new data to your
table,
> a Page Split will be required. A High number here, indicates that page
> splits are likely, and for Write Intensive tables, this would suggest a
need
> for modifying the indexes "Fill Factor" settings.
>
> There is much more to these numbers than what I mentioned above, but that
is
> a "Nutshell" view.
>
> Cheers
> Greg Jackson
> PDX, Oregon
>
> "Girish" <anonymous@.discussions.microsoft.com> wrote in message
> news:769774C6-426F-4181-BEE5-70A5F71D4D08@.microsoft.com...
Fix
> it ?
>|||You should read the whitepaper bleow which explains how to interpret the
numbers, what to do about them, and whether you should even be worried by
them in the first place.
http://www.microsoft.com/technet/tr...ze/ss2kidbp.asp
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:elW1RLa9DHA.3444@.TK2MSFTNGP09.phx.gbl...
> I agree with Jaxon, but I like to add one thing:
> If the table (index) span several (mdf/ndf) files, then jump between files
> will be considered fragmentation in Scan Density. So, in these cases, use
> Logical Scan Fragmentation instead. The value you have seems fine. Look up
> how to interpret that value in Books Online.
> --
> Tibor Karaszi, SQL Server MVP
> Archive at:
>
http://groups.google.com/groups?oi=...ublic.sqlserver
>
> "Jaxon" <GregoryAJackson@.hotmail.com> wrote in message
> news:O1jBUFY9DHA.3176@.TK2MSFTNGP11.phx.gbl...
> Avg
takes
impact
store
> IO.
> If
> table,
> need
that
> is
> Fix
>