Index Drop/Create modified to Drop_Existing = ON #963
Conversation
|
Thanks for investigating and creating the PR. I see quite a lot of added complexity. Out of curiosity, what kind of row counts are you running when you decided to find a faster way to rebuild? And more importantly, which versions of SQL Server support this feature? |
|
I was going to leave two areas, one being commented out for supported SQL versions. But I was trying to figure out when DROP_Existing was introduced, but it looks like it goes all the way back to SQL 2000. So I just left it in. The main reason I made these changes as it our CI/CD pipeline runs AliaSQL for versioning. Our INDEX scripts are in the EVERYTIME folder that gets run anytime there is a change in the file. This needs the existing check because We don't want to just run drops and creates manually in production. These changes will be in a branched and committed. |
| --CREATE INDEX [IDX_QRTZ_T_G_J] ON [dbo].[QRTZ_TRIGGERS](SCHED_NAME, JOB_GROUP, JOB_NAME); | ||
| --CREATE INDEX [IDX_QRTZ_T_C] ON [dbo].[QRTZ_TRIGGERS](SCHED_NAME, CALENDAR_NAME); | ||
| --CREATE INDEX [IDX_QRTZ_T_N_G_STATE] ON [dbo].[QRTZ_TRIGGERS](SCHED_NAME, TRIGGER_GROUP, TRIGGER_STATE); | ||
| --CREATE INDEX [IDX_QRTZ_T_STATE] ON [dbo].[QRTZ_TRIGGERS](SCHED_NAME, TRIGGER_STATE); | ||
| --CREATE INDEX [IDX_QRTZ_T_N_STATE] ON [dbo].[QRTZ_TRIGGERS](SCHED_NAME, TRIGGER_NAME, TRIGGER_GROUP, TRIGGER_STATE); | ||
| ---CREATE INDEX [IDX_QRTZ_T_NEXT_FIRE_TIME] ON [dbo].[QRTZ_TRIGGERS](SCHED_NAME, NEXT_FIRE_TIME); | ||
| --CREATE INDEX [IDX_QRTZ_T_NFT_ST] ON [dbo].[QRTZ_TRIGGERS](SCHED_NAME, TRIGGER_STATE, NEXT_FIRE_TIME); | ||
| --CREATE INDEX [IDX_QRTZ_T_NFT_ST_MISFIRE] ON [dbo].[QRTZ_TRIGGERS](SCHED_NAME, MISFIRE_INSTR, NEXT_FIRE_TIME, TRIGGER_STATE); | ||
| --CREATE INDEX [IDX_QRTZ_T_NFT_ST_MISFIRE_GRP] ON [dbo].[QRTZ_TRIGGERS](SCHED_NAME, MISFIRE_INSTR, NEXT_FIRE_TIME, TRIGGER_GROUP, TRIGGER_STATE); | ||
| --CREATE INDEX [IDX_QRTZ_FT_INST_JOB_REQ_RCVRY] ON [dbo].[QRTZ_FIRED_TRIGGERS](SCHED_NAME, INSTANCE_NAME, REQUESTS_RECOVERY); | ||
| --CREATE INDEX [IDX_QRTZ_FT_G_J] ON [dbo].[QRTZ_FIRED_TRIGGERS](SCHED_NAME, JOB_GROUP, JOB_NAME); | ||
| --CREATE INDEX [IDX_QRTZ_FT_G_T] ON [dbo].[QRTZ_FIRED_TRIGGERS](SCHED_NAME, TRIGGER_GROUP, TRIGGER_NAME); | ||
| --GO |
There was a problem hiding this comment.
Oops this can be deleted. I've split out the original block of drops, to be "ones we are discarding" and "ones we can rebuild our index" in one of two ways.
|
SonarCloud Quality Gate failed.
|
FROM:
https://www.tech-recipes.com/rx/60642/creating-index-drop_existing-sql-server/
If we are re-creating a clustered index on a table, which already has a non-clustered index, using DROP_EXISTING = ON in SQL Server while re-creating a clustered index has the following benefits:
• Non-clustered indexes are not re-built again. If we are re-creating a clustered index with DROP_EXISTING = ON in SQL Server, it knows the clustering key has not been changed in the Non-clustered index. This saves a significant amount of time. Every Non-clustered index has a clustering key which refers to the Clustered index. If a clustered index is rebuilt, then SQL Server has to modify the Non-Clustered index as well. However, using DROP_EXISTING = ON is beneficial because we do not need to rebuild the Non-clustered indexes again.
• If we use the old method to drop and re-create a clustered index, it causes all non-clustered index on that table to be rebuilt again to match the clustering key. This can be saved using DROP_EXISTING = ON with clustered index.