DBCC SHRINKDATABASE TRUNCATEONLY - 2008R2 与 2012

Question

我有点困惑。TRUNCATEONLYSQL 2012 中的参数是否已更改，或者 SQL 2008 R2 中的文档是否有误？

2008 R2

将文件末尾的所有可用空间释放给操作系统，但不会在文件内执行任何页面移动。数据文件仅收缩到最后分配的范围。如果使用 TRUNCATEONLY 指定，则忽略 target_percent。

TRUNCATEONLY 仅适用于数据文件。日志文件不受影响。

最后一条语句让我觉得这对日志文件根本没有影响？

2012年

将文件末尾的所有可用空间释放给操作系统，但不会在文件内执行任何页面移动。数据文件仅收缩到最后分配的范围。如果使用 TRUNCATEONLY 指定，则忽略 target_percent。

TRUNCATEONLY 影响日志文件。要仅截断数据文件，请使用 DBCC SHRINKFILE。

最后一条语句现在告诉我它只影响日志文件？

那么是功能改变了，还是文档中有错误，或者我的解释有误？

Answer 1

TRUNCATEONLY 会影响 2008 年的 LOG 和 DATA 文件。在 SQL Server 2012 的 BOL 上，该消息仅表明如果您只想收缩数据库文件，那么您应该使用 DBCC SHRINKFILE，这将允许您收缩数据或日志文件。

对于 2008 年，明确指出 TRUNCATEONLY 仅影响 DATA 文件。

让我们测试。为了可视化使用TRUNCATEONLYwith会发生什么SHRINKDATABASE，这里是performance我在本地安装的名为的数据库发生的事情的简要说明。

SELECT @@VERSION;
Microsoft SQL Server 2008 R2 (SP2) - 10.50.4000.0 (X64)
   Jun 28 2012 08:36:30
   Copyright (c) Microsoft Corporation
   Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) 

USE performance;

我跑DBCC LOGINFO只是为了在事务日志中看到一个峰值，发现大约 200 个之后的所有虚拟日志文件都处于非活动状态，状态 = 0。在我的性能数据库中，所有这些非活动 VLF 都可以被截断，并且可以将空间还给操作系统。

以下是 LOGINFO 的一些示例输出。

FileId FileSize StartOffset FSeqNo Status Parity CreateLSN
------ -------- ----------- ------ ------ ------ -----------------
2      253952   8192        23     2      64     0
2      253952   262144      24     2      64     0
2      270336   516096      25     2      64     24000000013400005

然后我运行DBCC SQLPERF(LOGSPACE)并得到以下输出

DBCC SQLPERF(LOGSPACE)
/*
Database Name   Log Size (MB)   Log Space Used (%)  Status
Performance          9870,867             3,395626  0
*/

然后我跑了

DBCC SHRINKDATABASE(PERFORMANCE, truncateonly) 

并得到以下结果

/*
DbId    FileId  CurrentSize MinimumSize UsedPages   EstimatedPages
8       1       66464       288         44944       44944
8       2       116584      72          116584      72
*/

接下来，我重新跑

DBCC SQLPERF(LOGSPACE) 

并得到

/*
Database Name   Log Size (MB)   Log Space Used (%)  Status
Performance     910,8047        37,08699            0
*/

SHRINKDATABASE与TRUNCATEONLY还给了9 GB从事务日志文件恢复到操作系统的可用空间。

我用另一个名为的数据库尝试了相同的实验 performance2

sp_spaceused

/*
Performance2 52.19 MB   22.81 MB
*/

DBCC SHRINKDATABASE(Performance2, truncateonly)

sp_spaceused

/*
database_name   database_size   unallocated space
Performance2 31.13 MB   21.13 MB
*/

这给了操作系统20 MB。使用 SQL Server 2008，SHRINKDATABASE TRUNCATEONLY收缩数据和事务日志文件。