Question

I am currently running a script which performs a DBCC INDEXDEFRAG on every table in a SQL Server 2005 database, one table at a time. Using DBCC DBREINDEX instead of INDEXDEFRAG is not an option, due to space constraints and uptime requirements.

I have noticed that it takes a long time for certain tables to be defragmented. For instance if I examine the "sys.dm_exec_requests" dynamic management view, I can see that the following INDEXDEFRAG is currently churning away on the clustered index of a table that has a table_id of 829610394:

DBCC INDEXDEFRAG (0, 829610394, 1)

I know that it will be a long time before the defragmentation process completes. Leaving aside the fact that the script currently running will eventually defragment all the tables, is there any harm in me manually running another DBCC INDEXDEFRAG on the clustered index of another table while the current command executes? Will both tables actually be defragmented at the same time if I do this?

Was it helpful?

Solution

Yes, you can do it for multiple tables. You can't do it for multiple indexes on the same table - I invented a new index lock subresource to prevent it. Same behavior in ALTER INDEX ... REORGANIZE that I replaced it with in 2005.

Thanks

OTHER TIPS

Note that DBCC INDEXDEFRAG & DBREINDEX are deprecated and replaced by ALTER INDEX:

Important

This feature will be removed in a future version of Microsoft SQL Server. Do not use this feature in new development work, and modify applications that currently use this feature as soon as possible. Use ALTER INDEX instead. --http://msdn.microsoft.com/en-us/library/ms177571(v=SQL.90).aspx

As for running two simultaneously, it depends on your file layout. If they're all on the same disk(s), you would likely slow each down as they would be fighting against each other for I/O. You would be best to only REORG or REBUILD when necessary. Check out Michelle Ufford's script here for an automated solution: http://sqlfool.com/2010/04/index-defrag-script-v4-0/

Licensed under: CC-BY-SA with attribution
Not affiliated with dba.stackexchange
scroll top