I follow the TechNet article Reorganizing and Rebuilding Indexes to check for Index fragmentation. The T-SQL I use:
USE ABOM; GO -- Find the average fragmentation percentage of all indexes -- in the dbo.tblProduct table. SELECT a.index_id, name, avg_fragmentation_in_percent FROM sys.dm_db_index_physical_stats (DB_ID(N'ABOM'), OBJECT_ID(N'dbo.tblProduct'), NULL, NULL, NULL) AS a JOIN sys.indexes AS b ON a.object_id = b.object_id AND a.index_id = b.index_id; GO
and the result is:
Note the 2 entries for Index 1. Testing various T-SQLs, the 2 entries come from sys.dm_db_index_physical_stats, not sys.indexes which has only 1 entry for Index 1.
Questions:
1.(a). Do the duplicate entries represent some kind of corruption?
The client side experiences some delay with this particular Table since I changed this Index/PK Constraint from ASCending to DESCendingly about 2 weeks ago. Old products are often inactive and we are more interested in the current products which have higher values for ProductID (int, Identity Field) so I thought Descending sort would be more appropriate.
I have rebuilt the Indices and well as refreshed the client side (Microsoft Access) to pick up the change but still some delay when access data in this Table compared with before the change.
I do not know if the 2 entries existed before the change or not.
1.(b) If yes, how do I fix it? (besides deleting/re-creating the Index/PK Constraint since there are about 10 FK Constraints which need to be deleted and re-created in conj. with deleting/re-creating the PK Constraint)
2. Why the last Index IX_P_APLNG_CN has ID 32 and not 10? This is the last Index added to the Table and no other Indices have been deleted so I am not sure why SQL Server decides to give the ID 32 and not 10?
Appreciate any answers, help, insights you can offer...
Van Dinh