Question

We currently have a SQL Agent Job that runs once a week to identify highly fragment indexes and rebuild them. For certain large indexes on large tables, this ends up causing the system to timeout, as the index is unavailable during the rebuild.

We have identified a strategy that should significantly reduce the fragmentation that occurs, but that won’t be implemented for some time, and it doesn’t cover everything.

We checked in to upgrading to the Enterprise edition, which allows for online index rebuilding. However, the cost is prohibitive for us at this point.

The indexes don’t really change that much, so we can assume that they are static, at least for the most part.

I did envision a way that we could perhaps simulate the online index rebuilding. It could work as follows

For each of the large indexes identified, run a script to:

• Check the fragmentation and proceed if it exceeds a certain threshold.
• Create a new index, entitled CurrentIndex_TEMP.
• Initiate a rebuild on the index.
• Remove the temporary index.

It seems that once the temporary index has been built, it would be possible to rebuild the other index without causing any downtime, since SQL Server would have another index that would then be available to use on queries that would have otherwise used the other query.

Iterating through this for each index would hopefully minimize the increase in overall index size, as each temporary index would be removed before any other temporary indexes were created.

This strategy would also retain the historical data on the indexes. I had originally considered a strategy of first renaming the current index, then creating it again with the original name, and then removing the index that had been renamed. This, however, would result in a loss of history.

So, my question…

Is this a feasible strategy? Are there any significant problems I may run into? I understand that this will take some manual oversight from time to time, but I’m willing to accept that at this point.

Thanks for the help.

Answer 1

Any offline index rebuild with lock the table so you don’t gain anything by creating a duplicated index.

With great effort your can simulate online index rebuilds. You have to rebuild all indexes on the table at once.

1. Create a copy of the table T with identical schema (“T_new“)
2. Rename T to T_old
3. Create a view T defined as select * from T_old and set up INSTEAD OF DML triggers which perform all DML on both T_old and T_new
4. In a background job copy over batches from T_old to T_new using the MERGE statement
5. Finally, after the copy is completed, perform some renaming and dropping to make T_new the new T

This requires insanely high effort and good testing. But you can realize pretty much arbitrary schema changes with this online.