SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Disabling Indexes


Disabling Indexes

Author
Message
Andy Warren
Andy Warren
SSChampion
SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)

Group: Moderators
Points: 11955 Visits: 2730
Have to find the tipping point. Drop/create may or may not be faster, for example if you are adding 1 million rows to a 100 million row table. The other portion of the trade off is fragmentation, by rebuilding at the end you correct any fragmentation created during load. Either way you should update column based stats (those that dont match to an index) post load.

Andy
SQLAndy - My Blog!
Connect with me on LinkedIn
Follow me on Twitter
Jeffrey Williams 3188
Jeffrey Williams 3188
SSCertifiable
SSCertifiable (7.9K reputation)SSCertifiable (7.9K reputation)SSCertifiable (7.9K reputation)SSCertifiable (7.9K reputation)SSCertifiable (7.9K reputation)SSCertifiable (7.9K reputation)SSCertifiable (7.9K reputation)SSCertifiable (7.9K reputation)

Group: General Forum Members
Points: 7923 Visits: 9971
Andy Warren (7/22/2008)
Have to find the tipping point. Drop/create may or may not be faster, for example if you are adding 1 million rows to a 100 million row table. The other portion of the trade off is fragmentation, by rebuilding at the end you correct any fragmentation created during load. Either way you should update column based stats (those that dont match to an index) post load.


Definitely have to find the tipping point - and determine what is best for your process. However, dropping and recreating the indexes is actually a lot more work than disabling/rebuilding.

As another poster pointed out - it is very easy to build a procedure that loops through all non-clustered indexes and disable them. This allows for adding new indexes, dropping existing indexes, etc... as you need them without having to modify your code at all.

To rebuild the indexes at the end of the process, you issue a single command for the table:

ALTER INDEX ALL ON table REBUILD;

This rebuilds all indexes for the table, including the clustered index. I have a table on my report server with well over 120 million rows and multiple indexes. The rebuild of all indexes on this one table takes no more than 30 minutes, which is far less time than the increased processing time if I leave the indexes enabled.

Jeffrey Williams
Problems are opportunities brilliantly disguised as insurmountable obstacles.

How to post questions to get better answers faster
Managing Transaction Logs

hdillow
hdillow
Valued Member
Valued Member (63 reputation)Valued Member (63 reputation)Valued Member (63 reputation)Valued Member (63 reputation)Valued Member (63 reputation)Valued Member (63 reputation)Valued Member (63 reputation)Valued Member (63 reputation)

Group: General Forum Members
Points: 63 Visits: 234
I have tested and used this feature a lot. Some advantages to me were, I did not have to script out every index on a table before dropping it. This made database maintenance much easier. If during monitoring missing indexes, I deemed it necessary to add a new index, It would not be lost because index creation were stored in other processes. In testing, I found that disabling all non clustered indexes and leaving the cluster index enabled, then bulk loading data (100's of millions of rows), then re-enabling to rebuild the index, took approx. the same about of time to script and save all indexes, drop all indexes, bulk load data, reapply the indexes. So, for me, this allowed for reduced scripts to maintain.

I also created a stored procedure that would accept a table name and an option to enable\disable indexes. I also added an option to truncate\delete rows.
Kangana Beri
Kangana Beri
SSC Eights!
SSC Eights! (924 reputation)SSC Eights! (924 reputation)SSC Eights! (924 reputation)SSC Eights! (924 reputation)SSC Eights! (924 reputation)SSC Eights! (924 reputation)SSC Eights! (924 reputation)SSC Eights! (924 reputation)

Group: General Forum Members
Points: 924 Visits: 954
Andy Warren (7/22/2008)
Have to find the tipping point. Drop/create may or may not be faster, for example if you are adding 1 million rows to a 100 million row table. The other portion of the trade off is fragmentation, by rebuilding at the end you correct any fragmentation created during load. Either way you should update column based stats (those that dont match to an index) post load.


I agree, you have to find tipping point for your system.

What I have seen in our Data Warehouse is that the Fact tables with few indexes and thus having index space smaller than data space load faster with drop/recreate during the ETL.

On the other hand for Fact tables with lot of indexes and thus having index space greater than data space, ETL is faster if indexes are not dropped. We do rebuild these indexes monthly though to take care of fragmentation.

So sometimes you have to use both strategies in your system; drop/recreate and leaving the indexes alone during ETL. Keeping track of it does adds to maintenance list though!
Nicole Bowman
Nicole Bowman
SSC Veteran
SSC Veteran (279 reputation)SSC Veteran (279 reputation)SSC Veteran (279 reputation)SSC Veteran (279 reputation)SSC Veteran (279 reputation)SSC Veteran (279 reputation)SSC Veteran (279 reputation)SSC Veteran (279 reputation)

Group: General Forum Members
Points: 279 Visits: 1615
Very interesting article and discussion. Thank you!

Nicole Bowman

Nothing is forever.
christopher.dorch
christopher.dorch
SSC Veteran
SSC Veteran (269 reputation)SSC Veteran (269 reputation)SSC Veteran (269 reputation)SSC Veteran (269 reputation)SSC Veteran (269 reputation)SSC Veteran (269 reputation)SSC Veteran (269 reputation)SSC Veteran (269 reputation)

Group: General Forum Members
Points: 269 Visits: 184
I know this is an old article, but I figured I'd give a reason why you should disable indexes.

Not all organizations have the ability to have dbs for applications and others for reporting. So, for EOM or EOY reporting, transactional indicies might cause these reports to take forever especially if there are rollups or aggregations. It's best practice to not have indexes that you don't need, but rather than drop and recreate for EOM or EOY reporting, you can disable. That way, the maintenance hit is not a constant.

Yes, I know.. This is not best practice period . But sometimes, the customer has their limitations.
curious_sqldba
curious_sqldba
SSCrazy
SSCrazy (3K reputation)SSCrazy (3K reputation)SSCrazy (3K reputation)SSCrazy (3K reputation)SSCrazy (3K reputation)SSCrazy (3K reputation)SSCrazy (3K reputation)SSCrazy (3K reputation)

Group: General Forum Members
Points: 2968 Visits: 3637
hello,

the article is really interesting. We have log shipping set up on one of the dbs and there is also huge bulk inserts gng on, bcoz of that the size of log backups is increasing. We were following the process of dropping the indices, bulk-insert the data and then recreate the indices. if i go the other way around by disabling the indices, bulk-insert data and then re-enable, will this decrese the size of log backups? I think so yes bcoz then there is less activity than re-created the indices from scratch. Please suggest me . thanks in advance
Dave Mason
Dave Mason
Mr or Mrs. 500
Mr or Mrs. 500 (538 reputation)Mr or Mrs. 500 (538 reputation)Mr or Mrs. 500 (538 reputation)Mr or Mrs. 500 (538 reputation)Mr or Mrs. 500 (538 reputation)Mr or Mrs. 500 (538 reputation)Mr or Mrs. 500 (538 reputation)Mr or Mrs. 500 (538 reputation)

Group: General Forum Members
Points: 538 Visits: 901
I guess you could say I'm a little late to the party. :-) But thanks, Andy! And thanks to those who have commented.

You all helped me find a solution to a problem I had with bulk inserts, the bulk-logged recovery model, and minimal logging.

Dave MasonSeminole County, FL
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search