Moon's questions

我有一个生产 SQL Server 2008，其中 8 TB 分布在多个数据库上。我已经删除了每个数据库中大约 85% 的数据，并且必须恢复磁盘空间。所有 USED_SPACE 的最终 SUM 将为 1.2 TB。

此 SHRINKFILE 进程必须适合每个数据库的 7 小时维护窗口。

但是，每个上的 DBCC SHRINKFILE 都需要很多小时才能运行。例如，将 800 GB 的数据库缩小到 120 GB 需要 15 多个小时。

不幸的是，这超出了我的维护窗口，我被迫终止进程，希望数据库不会损坏（随后的 DBCC CHECKDB 显示它们很好）。

我可以看到 DBCC SHRINKFILE 没有充分利用可用的磁盘 I/O 和 CPU 资源。

例如，可以在几个小时内将完整大小的数据库文件从一个磁盘复制到另一个磁盘，但 SHRINKFILE 过程需要相当长的时间。

注意：数据库都设置为 SIMPLE 恢复模式并且 AUTO_SHRINK 关闭。

是的，我看到很多人说永远不要这样做，因为它会破坏索引——我确实计划在 SHRINKFILE 完成时重建索引。

有什么方法可以提高 SHRINKFILE 命令的优先级或任何替代解决方案？以下是我正在考虑的一些选项：

• 在运行 SHRINKFILE 之前，在同一会话中将 DEADLOCK_PRIORITY 设置为高。
  （但我怀疑这会有所帮助。）
• 创建一个新数据库并逐表复制所有数据。

由于硬盘空间不足，我无法恢复 Microsoft SQL Server 数据库。原始数据库为1.6TB，从中删除了大约1.4TB ，并在不缩小数据库的情况下进行了备份。

备份文件只有168GB，是通过快递用硬盘寄给我的。当我尝试还原 168GB 的​​备份文件时，它会尝试创建原始的 1.6TB.mdf数据文件，但出现错误，因为我所有可用的服务器都只有不到 1TB 的可用磁盘空间。

首先，我尝试将数据文件还原到 NTFS 压缩文件夹，但出现错误，指出目标文件可能未设置压缩位。

然后，根据此链接：在还原期间收缩 SQL 数据库

我尝试将恢复的.mdf文件放入指向压缩文件夹的符号链接文件夹中，但它出错了：

System.Data.SqlClient.SqlError：磁盘卷“C:\”上的可用空间不足，无法创建数据库。数据库需要 1541063704576 个额外的可用字节，而只有 748261179392 个字节可用。(微软.SqlServer.SmoExtended)

然后，由于这是在 HYPER-V VM 中运行，我尝试将新的虚拟磁盘添加到压缩文件夹中，但 VM 不会开始抱怨驻留在压缩文件夹中的驱动器之一。

然后，我尝试将新的 HYPER-V 虚拟磁盘添加到指向压缩文件夹的符号链接文件夹中。这工作正常，除了文件在恢复时没有压缩并且在我杀死它之前空间即将用完（我猜资源管理器可能会在写入过程“SQL”关闭文件后压缩文件）

恢复后的数据库应该只有 168GB 的​​实际数据。

有人有解决办法吗？