This is very puzzling:- Same server (SQL 2014 Standard Edition, 64GB RAM, 32 cores, SSD storage attached via iSCSI).- Same database (upwards of 300GB).- Same table (very large, many millions of rows, all columns are either INT or DATETIME).- Same index (non-clustered, 2 INT columns).- Same fragmentation (about 23-25%, give or take).- Same concurrent workload - that is to say, none. During index optimization, nothing accesses the server other than Red Gate SQL Monitor.The script for the index itself:[code]ALTER TABLE [dbo].[MyHugeTable] ADD CONSTRAINT [MyHugeTable_pk] PRIMARY KEY NONCLUSTERED ( [IntColumn1] ASC, [IntColumn2] ASC)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)GO[/code]ALTER INDEX REORGANIZE takes 3 hours and change. I tried different options, but it always takes just about that long. Not compacting large objects, just straight reorg.ALTER INDEX REBUILD takes 1.5 hours. Again, tried different options and no significant change in performance.Why is this happening? I feel like an idiot asking this question, because "REORGANIZE is faster than REBUILD" is something that you learn in MSSQL DBA 101. I feel like I'm looking at some sort of odd outlier case, but it shouldn't be - the index looks very straightforward, and neither it nor the table it is defined on has any unusual data types.Any ideas?
↧