Why does DBCC shrinkfile run for a long time?

After the data compression function is enabled today, it takes a long time to compress the database using DBCC shrinkfile. I believe many friends who use SQL server have encountered this problem. Why is it so time-consuming for SQL Server to shrink files?

 

From msdn, we can see that "DBCC shrinkfile is single-threaded and may take a long time ToComplete" (http://msdn.microsoft.com/en-us/library/dd894051 (V = SQL .100). aspx) that is, SQL
Server is a single-thread running file shrinking, even if you have multiple CPU performance does not help.

 

Here I did a test to open two queries and run the shrinkfile command at the same time. The second statement will report an error:

File ID 1 of Database ID 17 cannot be shrunk as it is eitherbeing shrunk by another process or is empty.

Dbccexecution completed. If DBCC printed error messages, contact your systemadministrator.

 

Three steps for file contraction (you can see in the SYS. dm_exec_request command column)

Step	Command	Description
1	Dbccspacereclaim	Clean up deferred allocations and purge empty extents preparing for data moves.
2	Dbccfilescompact	Moves pages beyond the target to before the target and truncate file as required.
3	Dbcclobcompact	Compacting the lob data.

 

SQL Server executes DBCC shrinkfile and uses 32 pages as a transcation. When the page being processed in the transaction is moved to the targe space, the transcation is commit and a new transcation starts. This avoids excessive Log File growth due to a long time of transcation. After the current transcation is rollback/cancel, the shrink operation only rolls back the current transaction (up to 32 pages ). In this way, if the shrink operation cannot be completed within the maintenance period, it can be divided into multiple batches and processed in part each time.

 

I found an article on how to quickly shrink database files from the Internet:

Http://www.sqlservercentral.com/articles/SHRINKFILE/71414/

How it works: SQL Server 2005 DBCC shrink * may take longer than SQL Server 2000: http://blogs.msdn.com/ B /psssql/archive/2008/03/28/how-it-works-sql-server-2005-dbcc-shrink-may-take-longer-than-sql-server-2000.aspx