收缩当前数据库的指定数据或日志文件的大小,或通过将数据从指定的文件移动到相同文件组中的其他文件来清空文件,以允许从数据库中删除该文件。文件大小可以收缩到比创建该文件时所指定的大小更小。这样会将最小文件大小重置为新值。
DBCC SHRINKFILE
(
{ file_name | file_id }
{ [ , EMPTYFILE ]
| [ [ , target_size ] [ , { NOTRUNCATE | TRUNCATEONLY } ] ]
}
)
[ WITH NO_INFOMSGS ]
下表对结果集中的列进行了说明。
列名 |
说明 |
---|---|
DbId |
数据库引擎试图收缩的文件的数据库标识号。 |
FileId |
数据库引擎试图收缩的文件的文件标识号。 |
CurrentSize |
文件当前占用的 8 KB 页数。 |
MinimumSize |
文件最低可以占用的 8 KB 页数。这与文件的最小大小或最初创建时的大小相对应。 |
UsedPages |
文件当前使用的 8 KB 页数。 |
EstimatedPages |
数据库引擎估计文件能够收缩到的 8 KB 页数。 |
DBCC SHRINKFILE 适用于当前数据库中的文件。有关如何更改当前数据库的详细信息,请参阅 USE (Transact-SQL)。
可在进程中的任一点停止 DBCC SHRINKFILE 操作,任何已完成的工作都将保留。
当 DBCC SHRINKFILE 操作失败时,将引发错误。
要收缩的数据库不必在单用户模式下;收缩文件时,其他用户也可使用该数据库。不必在单用户模式下运行 SQL Server 实例以对系统数据库进行收缩。
收缩日志文件
对于日志文件,数据库引擎使用 target_size 来计算整个日志的目标大小;因此,target_size 是收缩操作后日志中的可用空间大小。之后,整个日志的目标大小转换为每个日志文件的目标大小。DBCC SHRINKFILE 尝试立即将每个物理日志文件收缩到其目标大小。但是,如果部分逻辑日志位于超出目标大小的虚拟日志中,则数据库引擎将释放尽可能多的空间,并发出一条信息性消息。该消息说明需要执行哪些操作来将逻辑日志移出位于文件末尾的虚拟日志。执行这些操作以后,DBCC SHRINKFILE 可用于释放剩余空间。有关详细信息,请参阅收缩事务日志。
因为日志文件只能收缩到虚拟日志文件边界,所以不可能将日志文件收缩到比虚拟日志文件更小(即使现在没有使用该文件)。虚拟日志文件的大小在创建或扩展这些日志文件时由数据库引擎动态选择。有关虚拟日志文件的详细信息,请参阅事务日志物理体系结构。
最佳做法
在计划收缩文件时,请考虑以下信息:
在执行会产生许多未使用空间的操作(如截断表或删除表操作)后,执行收缩操作最有效。
大多数数据库都需要一些可用空间,以供常规日常操作使用。如果反复收缩数据库并注意到数据库大小变大,则表明收缩的空间是常规操作所必需的。在这种情况下,反复收缩数据库是一种无谓的操作。
收缩操作不会保留数据库中索引的碎片状态,通常还会在一定程度上增加碎片。这是不要反复收缩数据库的另一个原因。
故障排除
本部分介绍如何诊断和更正在运行 DBCC SHRINKFILE 命令时可能发生的问题。
文件不收缩
如果收缩操作运行时未出现错误,但文件大小看起来没有发生更改,则请执行下列操作之一以验证文件是否有足够的可用空间可供删除:
-
运行以下查询。
SELECT name ,size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0 AS AvailableSpaceInMB
FROM sys.database_files; 运行 DBCC SQLPERF 命令以返回事务日志中使用的空间。
如果可用空间不足,则收缩操作无法进一步减小文件大小。
通常,日志文件看起来不收缩。这通常是由于未截断日志文件的原因造成的。可以通过将数据库恢复模式设置为 SIMPLE 或者通过备份日志然后再次运行 DBCC SHRINKFILE 操作来截断日志。有关详细信息,请参阅事务日志截断和收缩事务日志。
收缩操作被阻塞
在基于行版本控制的隔离级别下运行的事务可能会阻塞收缩操作。例如,执行 DBCC SHRINK DATABASE 操作时,如果在基于行版本控制的隔离级别下运行的大型删除操作正在进行中,则收缩操作将等到删除操作完成才会收缩文件。出现这种情况时,DBCC SHRINKFILE 和 DBCC SHRINKDATABASE 操作会在第一个小时每五分钟将信息性消息(对于 SHRINKDATABASE 为 5202,对于 SHRINKFILE 为 5203)输出到 SQL Server 错误日志,之后每一个小时输出一次。例如,如果错误日志包含以下错误消息:
DBCC SHRINKFILE for file ID 1 is waiting for the snapshot
transaction with timestamp 15 and other snapshot transactions linked to
timestamp 15 or with timestamps older than 109 to finish.
这意味着收缩操作被时间戳早于 109 的快照事务阻塞,它是收缩操作所完成的上一事务。它还说明 sys.dm_tran_active_snapshot_database_transactions 动态管理视图中的 transaction_sequence_num 或 first_snapshot_sequence_num 列包含值 15。如果该视图中的 transaction_sequence_num 或first_snapshot_sequence_num 列包含的数字小于收缩操作完成的上一事务 (109),则收缩操作将等待这些事务完成。
若要解决此问题,请执行下列任务之一:
终止阻塞收缩操作的事务。
终止收缩操作。如果终止收缩操作,则会保留任何已完成的工作。
不执行任何操作,并允许收缩操作等到阻塞事务完成。
有关 SQL Server 错误日志的详细信息,请参阅查看 SQL Server 错误日志。
要求具有 sysadmin 固定服务器角色或 db_owner 固定数据库角色的成员身份。
A. 将数据文件收缩到指定的目标大小
以下示例将 UserDB 用户数据库中名为 DataFile1 的数据文件的大小收缩到 7 MB。
Transact-SQLUSE UserDB;
GO
DBCC SHRINKFILE (DataFile1, 7);
GO
B. 将日志文件收缩到指定的目标大小
以下示例将 AdventureWorks2008R2 数据库中的日志文件收缩到 1 MB。若要允许 DBCC SHRINKFILE 命令收缩文件,首先需要通过将数据库恢复模式设置为 SIMPLE 来截断该文件。
Transact-SQLUSE AdventureWorks2008R2;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE AdventureWorks2008R2
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (AdventureWorks2008R2_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE AdventureWorks2008R2
SET RECOVERY FULL;
GO
C. 截断数据文件
以下示例将截断 AdventureWorks2008R2 数据库中的主数据文件。需要查询 sys.database_files 目录视图以获得数据文件的 file_id。
Transact-SQLUSE AdventureWorks2008R2;
GO
SELECT file_id, name
FROM sys.database_files;
GO
DBCC SHRINKFILE (1, TRUNCATEONLY);
D. 清空文件
以下示例演示了清空文件以便从数据库中将其删除的步骤。针对此示例,首先创建一个数据文件,并假设该文件包含数据。
Transact-SQLUSE AdventureWorks2008R2;
GO
-- Create a data file and assume it contains data.
ALTER DATABASE AdventureWorks2008R2
ADD FILE (
NAME = Test1data,
FILENAME = 'C:\t1data.ndf',
SIZE = 5MB
);
GO
-- Empty the data file.
DBCC SHRINKFILE (Test1data, EMPTYFILE);
GO
-- Remove the data file from the database.
ALTER DATABASE AdventureWorks2008R2
REMOVE FILE Test1data;
GO