Hi guys,
We have an index maintenance issue on large tables recently.
Basically, there is a job running to do the index maintenance daily: do the index scan via sys.dm_db_index_physical_stats, and then reorganize indexes with fragment % between 10 and 30.
We find some large tables (default fill factor is 100%) with quite low pay density, avg_page_space_used_in_percent = 18.91039041, which is expected to have a high index fragment % for reorganization to increase the pay density. However, the index fragment avg_fragmentation_in_percent is 7.130605409%, which means NO need for reorganization.
Total size = 128.12 GB; Actual data size =128.12 *18.91039041%= 24.23 GB;Free size = 128.12 GB- 24.23 GB=124 GB
I then do a manual reorganization on this index. The fragment percent avg_fragmentation_in_percent is 1.423850519%, and page density avg_page_space_used_in_percent is 98.49016555%.
Total size = 24.62 GB; Actual data size =24.62 *98.49016555%= 24.25 GB; Free size = 24.62 GB- 24.25 GB =0 GB
Based on our business, we delete data in this large table periodically, which should lead to low page density. But according to the result, we do need an reorganization to save disk space and optimize memory/IO usage. Why the index fragment doesn't give me an appropriate percent for maintenance?
Reference: index fragmentation includes logical fragmentation and low page density from Pual's explanation - How record DELETEs can cause index fragmentation.
Any thoughts?
Thanks in advance!
MCSE:Data Platform