Consider the following information when you plan to shrink a file:
A shrink operation is most effective after an operation that creates lots of unused space, such as a truncate table or a drop table operation.
Most databases require some free space to be available for regular day-to-day operations. If you shrink a database repeatedly and notice that the database size grows again, this indicates that the space that was shrunk is required for regular operations. In these cases, repeatedly shrinking the database is a wasted operation.
A shrink operation does not preserve the fragmentation state of indexes in the database, and generally increases fragmentation to a degree. This is another reason not to repeatedly shrink the database.
Shrink multiple files in the same database sequentially instead of concurrently. Contention on system tables can cause delays due to blocking.
DBCC SHRINKFILEoperations can be stopped at any point in the process, and any completed work is retained.
这样做肯定有一些事情需要考虑,我建议你看看Paul Randal’s blog post,当你做这个操作时会发生什么.
use AdventureWorks2012; go ;with db_file_cte as ( select name, type_desc, physical_name, size_mb = convert(decimal(11, 2), size * 8.0 / 1024), space_used_mb = convert(decimal(11, 2), fileproperty(name, 'spaceused') * 8.0 / 1024) from sys.database_files ) select name, type_desc, physical_name, size_mb, space_used_mb, space_used_percent = case size_mb when 0 then 0 else convert(decimal(5, 2), space_used_mb / size_mb * 100) end from db_file_cte;