相关疑难解决方法(0)

这个问题在这里以各种形式提出，但问题归结为：

我知道缩小数据库是有风险的。在这种情况下，我已经删除了这么多数据，我再也不会使用它了。

• 如何缩小我的数据库？我缩小了哪些文件？
• 这样做时我应该考虑什么？
• 之后我应该做些什么吗？
• 如果是大数据库呢？我可以以较小的增量缩小它吗？

在 SQL Server 2017 (CU3) 上，每当我在我的一个 TDE 数据库上启用备份压缩时，备份过程总是会损坏数据库中的特定页面。如果我在不压缩的情况下运行备份，它不会被损坏。以下是我为验证和重现此问题而采取的步骤：

1. 在数据库“TDE_DB1”上运行 DBCC CheckDB；一切都很好，没有错误；
2. 成功备份数据库，无需压缩；RESTORE VERIFYONLY 表示一切正常；
3. 成功将数据库恢复为“TDE_DB2”；一切都很好，DBCC CheckDB 没有显示错误；
4. 成功备份“TDE_DB1”数据库WITH压缩；RESTORE VERIFYONLY 错误，提示“检测到备份集损坏”；
5. 尝试将数据库恢复为“TDE_DB2”；错误，说“RESTORE 在数据库中的页面 (1:92454) 上检测到错误”
6. 重复步骤1-3；一切都很好;
7. 删除“TDE_DB1”和“TDE_DB2”；从备份中恢复“TDE_DB1”；一切都很好;
8. 重复步骤1-5；得到相同的结果；

总结一下：数据库和常规备份看起来不错，在数据库上运行 CHECKDB 并在备份上运行 VERIFYONLY 不会报告任何错误。使用压缩备份数据库似乎会导致损坏。

下面是有错误的代码示例。（注意：在 TDE 数据库中使用压缩需要 MAXTRANSFERSIZE）

-- Good, completes with no corruption;
BACKUP DATABASE [TDE_DB1] TO DISK = N'E:\MSSQL\Backup\TDE_DB1a.bak' WITH CHECKSUM;
RESTORE VERIFYONLY FROM DISK = N'E:\MSSQL\Backup\TDE_DB1a.bak' WITH CHECKSUM;

RESTORE DATABASE [TDE_DB2]
FROM DISK = 'E:\MSSQL\Backup\TDE_DB1a.bak'
WITH MOVE 'DataFileName' to 'E:\MSSQL\Data\TDE_DB2.mdf'
,MOVE 'LogFileName' to 'F:\MSSQL\Log\TDE_DB2_log.ldf';


-- Bad, I …

我正在尝试针对 95% 的数据已存档和删除的数据库以 1GB 的块运行 dbcc 收缩文件。我有一个 235GB 的文件，其中 9GB 是数据/索引。我想把它缩小到 50GB。我知道收缩数据库文件是不好的，它会导致碎片等。作为数据清除/收缩的一部分，我们还有一个重建 idnex 脚本。

当我在自己的工作站（四核、12GB RAM、2 个 SATA 驱动器）上针对数据库运行 dbcc 收缩文件脚本时，收缩需要大约 8-10 分钟。

在数据清除后针对数据库的相同副本运行相同的代码时，在我们的测试环境中（80 多个内核、128GB RAM、SSD SAN），需要 70 分钟。请注意，在运行收缩文件时，此服务器上几乎没有活动。它已运行 4 次，结果相同。

然后我采用了不同的方法，将剩余的 9GB 移动到不同的文件组和物理文件。在我自己的工作站上对空的 230GB 文件运行 dbcc shrinkfile 以将其缩小到 50GB 需要 < 1 分钟。

使用相同的方法，在测试环境中，再次需要 70 分钟以上。

在测试环境的 70 分钟运行期间，我根据 Brent Ozar 的脚本拍摄了前后的 waitstats 快照，并且返回的 waittypes 没有显示任何值得关注的内容。下面的前 3 行：

第二采样时间 采样持续时间（以秒为单位） wait_type 等待时间（秒） 每次等待平均等待毫秒数
2013-05-28 11:24:22.893 3600 写日志 160.8 143066 1.1
2013-05-28 11:24:22.893 3600 CXPACKET 20.9 13915 1.5
2013-05-28 11:24:22.893 …

我已经问过一些关于自动增长和收缩的问题。但我对此有一些疑问。

1. 我有一个每月增长约 300 MB 的数据库。那么最好将 Autogrowth 设置为 300 MB 吗？现在设置了 10 MB。

2. 我有很多小型数据库，它们确实有大约 50 MB 的数据。但它的物理大小约为 900 MB。（所以 850 是可用空间）。我没有缩小这个数据库。好像我在添加数据时再次缩小它会发生自动增长。但是向这个数据库添加数据是很少见的。所以我认为未来一年它不会增长超过 200MB。

   那么我应该缩小数据库吗？如果我保持原样？这会导致任何性能问题吗？或者在数据库中有更多的可用空间（超过 90%）会导致任何问题？我认为大多数人认为大的物理尺寸会导致性能问题。那么这是真的还是假的？

3. SQL Server 2008 R2 Express 数据库大小限制为 10 GB。那么它是 mdf 和 ldf 文件的物理大小吗？因为如果我应该在任何时候缩小数据库，我需要考虑这一点。