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

more administrator oriented and usually used on an ad hoc basis to deal with very specific problems.
The core elements here should, however, be part of your regular maintenance planning.
We’ll start by looking at a couple of top parameters and then look at the options that are part of your
larger maintenance-planning needs.
Index Name
We can name a specific index if you want to maintain one specific index, or use ALL to indicate that you
want to perform this maintenance on every index associated with the named table.
Table or View Name
Pretty much just what it sounds like — the name of the specific object (table or view) that you want to
perform the maintenance on. Note that it needs to be one specific table (you can feed it a list and say “do
all of these please!”).
REBUILD
This is the “industrial-strength” approach to fixing an index. If you run ALTER INDEX with this option,
the old index is completely thrown away and a new one reconstructed from scratch. The result is a truly
optimized index, where every page in both the leaf and non-leaf levels of the index has been reconstructed
as you have defined it (either with defaults or using switches to change things like the fillfactor). If
the index in question is a clustered index, then the physical data is also reorganized.
By default, the pages will be reconstituted to be full, minus two records. Just as with the CREATE TABLE
syntax, you can set the FILLFACTOR to be any value between 0 and 100. This number will be the percent
that your pages are full once the database reorganization is complete. Remember, though, that as your
pages split, your data will still be distributed 50-50 between the two pages — you cannot control the fill
percentage on an ongoing basis unless you regularly rebuild the indexes.
Careful on this one. 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 rely 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).
This one can have major side effects while it runs, and thus it falls squarely in the domain of the database
administrator in my not so humble opinion.
DISABLE
Chapter 9: SQL Server Storage and Index Structures
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 further what you wanted 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 an SQL Server upgrade or some other oddball situation.
289