Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Chapter 19: Playing Administrator
index, where every page in both the leaf and non-leaf levels of the index have been reconstructed as you
have defined them, either the defaults, or using switches to change things like the fill factor.
Careful on this one. By default, as soon as you kick off a REBUILD, the index you are working on is
essentially gone until the rebuild is complete. Any queries that relied on that index may become exceptionally
slow (potentially by orders of magnitude). This is the sort of thing you want to test on an
offline system first to have an idea how long it’s going to take, and then schedule to run in off hours,
preferably with someone monitoring it to be sure it’s back online when peak hours come along.
The Enterprise version of SQL Server does include a special ONLINE version of this option that will keep
the index alive and build the new one parallel to the old, but realize that non-Enterprise versions are not
going to have that option available, and, even if it is, the creation of the index is going to be a significant
load on the system; tread carefully when rebuilding. In general, treat this one as though it can have
major side effects while it runs, and leave its use squarely in the domain of the database administrator.
DISABLE
This one does what it says, only in somewhat drastic fashion. It would be nice if all this command did
was take your index offline until you decided what you want to do, but instead it essentially marks the
index as unusable. Once an index has been disabled, it must be rebuilt (not reorganized, but rebuilt)
before it will be active again.
This is one you’re very, very rarely going to do yourself. (You would more likely just drop the index.) It
is far more likely to happen during a SQL Server upgrade or some other oddball situation.
Yet another BE CAREFUL!!! warning on this one. If you disable the clustered index for your table, it
has the effect of disabling the table. The data will remain, but will be inaccessible by all indexes, since
they all depend on the clustered index — the entire table is effectively offline until you rebuild the clustered
index.
REORGANIZE
BINGO!!! from the developer perspective. With REORGANIZE we hit a happy medium in life. When you
reorganize your index, you get a slightly less complete optimization than you get with a full rebuild, but
one that occurs online. (Users can still utilize the index.)
This should, if you’re paying attention, bring about the question “What exactly do you mean by ‘slightly
less complete’?” Well, REORGANIZE works only on the leaf level of your index; non-leaf levels of the
index go untouched. This means that we’re not quite getting a full optimization, but, for the lion’s share
of indexes, that is not where your real cost of fragmentation is, although it can happen and your mileage
may vary.
Given its much lower impact on users, this is usually the tool you’ll want to use as part of your regular
maintenance plan; let’s take a look at running a index reorganization command.
Try It Out Index Reorganization
582
To run this through its paces, we’re going to do a reorg on a table in the AdventureWorks2008 database.
The Production.TransactionHistory table is an excellent example of a table that is likely to have