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

FILLFACTOR
When SQL Server first creates an index, the pages are, by default, filled as full as they can be, minus two
records. You can set the FILLFACTOR to be any value between 1 and 100. This number will determine
how full your pages are as a percentage, once index construction is completed. Keep in mind, however,
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 other than regularly rebuilding the indexes (something
you should do).
We use a FILLFACTOR when we need to adjust the page densities. Think about things this way:
❑ If it’s an OLTP system, you want the FILLFACTOR to be low.
❑ If it’s an OLAP or other very stable (in terms of changes — very few additions and deletions)
system, you want the FILLFACTOR to be as high as possible.
❑ If you have something that has a medium transaction rate and a lot of report-type queries
against it, then you probably want something in the middle (not too low, not too high).
If you don’t provide a value, then SQL Server will fill your pages to two rows short of full, with a minimum
of one row per page (for example, if your row is 8,000 characters wide, you can fit only one row
per page, so leaving things two rows short wouldn’t work).
IGNORE_DUP_KEY
The IGNORE_DUP_KEY option is a way of doing little more than circumventing the system. In short, it
causes a unique constraint to have a slightly different action from that which it would otherwise have.
Normally, a unique constraint, or unique index, does not allow any duplicates of any kind — if a transaction
tried to create a duplicate based on a column that is defined as unique, then that transaction would
be rolled back and rejected. After you set the IGNORE_DUP_KEY option, however, you’ll get mixed behavior.
You will still receive an error message, but the error will only be of a warning level. The record is still not
inserted.
This last line — the record is still not inserted — is a critical concept from an IGNORE_DUP_KEY
standpoint. A rollback isn’t issued for the transaction (the error is a warning error rather than a critical
error), but the duplicate row will have been rejected.
Why would you do this? Well, it’s a way of storing unique values without disturbing a transaction that
tries to insert a duplicate. For whatever process is inserting the would-be duplicate, it may not matter at
all that it’s a duplicate row (no logical error from it). Instead, that process may have an attitude that’s
more along the lines of, “Well, as long as I know there’s one row like that in there, I’m happy — I don’t
care whether it’s the specific row that I tried to insert or not.”
DROP_EXISTING
Chapter 9: SQL Server Storage and Index Structures
If you specify the DROP_EXISTING option, any existing index with the name in question will be dropped
prior to construction of the new index. This option is much more efficient than simply dropping and
re-creating an existing index when you use it with a clustered index. If you rebuild an exact match of the
existing index, SQL Server knows that it need not touch the non-clustered indexes, while an explicit
drop and create would involve rebuilding all non-clustered indexes twice in order to accommodate
279