planning use DROP_EXISTING like this:
CREATE
CLUSTERED INDEX [idx-clusteredindex]
ON
[dbo].[TABLE_NAME]([COLOUMN_NANE])
WITH
DROP_EXISTING,
FILLFACTOR = 90
ON
[PRIMARY]
As I understand this will also cause all non-clustered index
on the table to be rebuilt/recalculated as well.
Is this infact the case of do I have to
do i have to do it explicitly afterwards like:
DBCC DBREINDEX ([dbo].[TABLE_NAME],[idx-nonclustered],90)Sort of, but this would happen anyway if you rebuilt the clustered
index. Using the DROP_EXISTING clause makes it more efficient ...
If you have NC indexes on a table without a CL index, each row in each
NC index has a pointer to the corresponding record in the main table.
Every time a new record is inserted into the main table, or an existing
record is modified in such a way that its RecordID changes, the NC
indexes also have to be updated.
If you have NC indexes on a table with a CL index, all the NC indexes
contain the CL key as well as their own key columns. This is because
the clustered key points to individual pages in the main table, rather
than individual records, and so the NC indexes do not have to be
updated unless a record actually has its PK value updated which greatly
reduces the NC index maintenance overhead.
If you drop the CL index, there is now no longer a CL key for the NC
indexes to use, so they also have to be rebuilt in order to replace
the CL keys with RecordID pointers. When you rebuild the CL index,
the reverse happens again. So , rebuilding a CL index in the simplest
manner causes all NC indexes to be rebuilt twice.
If you use the DROP_EXISTING clause, the initial drop of the NC
indexes is not done, because the re-creation of the CL index is assumed
to be imminent. Furthermore, assuming the CL index name and key
column list stays the same, the data is NOT re-sorted, which also
saves a good deal of time on large tables.sql
No comments:
Post a Comment