简体   繁体   中英

SQL Server 2005 Clustered Index Drop running long with no non-clustered indexes present

I'm dropping a clustered index from a table in a SQL Server 2005 database and it's taking a very long time to run.

I did some research and determined that dropping a clustered index can take a long time because it's updating pointers in non-clustered indexes to instead reference the RowID of the table itself, however in this particular scenario there are no non-clustered indexes present on the table.

There are a lot of foreign keys in the database, so it's possible that one of them might be referencing the clustered index ID.

Is there any way to determine what objects are using clustered index references as opposed to RowID?

If there's a clustered index, everything uses that instead of a RowID - the clustered index key IS the row identifier.

So the answer is, anything that references that table.

An easy, visual way to see your foreign key constraints is to add the tables into a Diagram. Then you can see the relationships and check if any are pointing to the clustered index.

However, what is the reason that you are dropping the clustered index, which is most likely the primary key?

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM