Excellent link, Jason. The problem is that even if you just disable and index, it must still go through the throws of a rebuild when you re-enable it. You can't simply make an index "invisible to the optimizer" without disabling it. Brent also failed to mention that Unique NCIs are also prime candidates as a target for Foreign Keys. If you disable such an NCI, you also disable the FK and it will need to be rebuilt after you rebuild the index to re-enable it.
Exactly... The only "advantage" disabling dives you, is the fact that the original index definition is maintained.
For someone like me, who focuses too much in some ares and not enough in other, that's not nothing...
It makes it easy to keep up with the original definition and... I have had more than one , "oh crap... which one is the original?" moment...
Retaining the definition isn't the problem here and I don't consider it an advantage or disadvantage because we have mechanisms in place for version controlling code such as this. I could drop the index but then I loose the statistics for it. On a very large table this means that a rollback in production becomes very expensive because the whole index needs to be rebuilt.
If I disable the index however, the statistics are not dropped but then also not maintained. The critical evaluation period in production is one calendar month before it is considered safe to drop the index and on an index that is disabled means rebuilding the whole structure.