Page History

...

You can mouse over any icon to display a tip that identifies what that icon represents. The fragmentation statistics include:

Average FragmentationFragmentation Image Added

Displays the total fragmentation of all indexes on the associated object and the objects contained divided by the total number of indexes on those objects. This calculation is weighted based on the size of each index. For example, if you have three similar-sized indexes with 10%, 10%, and 70% fragmentation levels respectively, this value is 90% divided by three, which is 30%. The logical fragmentation level for each index is the percentage of out-of-order pages in that index when the index was last analyzed.

The Average Fragmentation value can help identify critical fragmentation levels as you drill-down to details on individual tables and indexes. You can compare logical fragmentation levels across indexes to identify hot spots. You may see performance gains after defragmenting indexes with as little as 10% fragmentation. In general, consider defragmenting indexes with 20% or more fragmentation.

Pages ReadRead Image Added

Displays the total number of pages used by the associated object and the objects it contains. For example, when you view this value for a database, it displays the total number of pages used by the database, including all pages used by all the tables and indexes in that database.

Fragmentation impacts disk I/O. Since larger indexes are less likely to be cached by SQL Server, fragmentation impacts the performance of large indexes more than small indexes. In general, focus on indexes with 1,000 pages or more.

Pages Per FragmentsFragments Image Added

Displays the average number of pages per fragment. This value is the total number of pages identified by the Pages Read value divided by the number of those pages that are not in logical order.

Page DensityDensity Image Added

Displays how much data is stored in the pages, identified by the Pages Read value, compared to the maximum amount of data that can be stored in those pages. Only a thorough analysis collects or updates this information. If no page density information has been collected for these pages, this value is set to N/A (not available).

Low page density can cause SQL Server to read more pages than necessary when using an index, such as when performing a query. When data is initially stored on the pages, SQL Server uses the fillfactor value to determine how much data to store on each page. At this point, page density is relatively high, but the page density becomes lower as data is inserted and pages are split to make room for the additional data. SQL Defrag Manager can reorganize or rebuild indexes to increase page density and reduce the number of reads when using the index.

IndexesIndexes Image Added

Displays the total number of indexes on the associated object and the objects it contains.

...