如何恢复 SQL Server 数据库并同时缩小其文件？

Question

假设我有一个 SQL Server 数据库，其数据文件的初始大小为 100 GB，但其中只包含 10 GB 的数据。那么数据库备份的大小就只有 10 GB。

我想将此备份恢复到不同的服务器（或同一服务器上的不同数据库），但我不想让它占用与原始备份相同的磁盘空间（100 GB），而这是默认发生的情况。

在备份之前我无法缩小原始数据库（这是一个生产数据库，它需求那么多的预分配空间）；我可以恢复完成后缩小恢复的数据库，但我真的希望不是执行此操作时会占用 100 GB；此外，在这种特定情况下，我没有那么多可用磁盘空间，因此还原不会有任何进展。

有什么方法可以恢复数据库并使其仅占用与其所包含的实际数据相同的空间？

Answer 1

不，抱歉 - 没办法。恢复会将文件恢复到备份时的状态。必须在备份之后或备份之前进行 Schinking。

Answer 2

一般来说，不是。以下几个想法可能对你有帮助，也可能没用：

• 除非你绝对需要那个特定的备份，那么您可以创建一个目标大小的新（空）数据库，并使用批量复制（或 SSIS）将当前（实时）数据库中的所有表推送到您的副本中。
• 如果这不是一次性操作，那么有第三方工具（例如 Redgate Compare）可以帮助自动化此类操作。
• 某些第三方备份软件（例如 Quest Litespeed）能够执行“对象级恢复“，它可以将单个表或其他对象恢复到新的（空）数据库。即使备份不是使用 Litespeed 创建的，我相信该产品应该可以在 Native SQL 备份上运行。

最后，我也希望我的生产数据库有一定的“活动空间”，但总共 100GB 中剩余 90GB 听起来有点极端。以下步骤可能会满足您的需求，并且不会影响生产：

1. 在生产数据文件上运行DBCC SHRINKFILE ('myfile.MDF', TRUNCATEONLY)以临时释放文件末尾的任何可用空间（TRUNCATEONLY 不是 IO 密集型的，并且不会碎片索引）
2. 如果日志文件也很大，DBCC SHRINKFILE请在进行日志备份后，在活动较少的时候对生产日志文件运行。
3. 运行备份
4. 执行操作ALTER DATABASE MODIFY FILE将生产数据文件重新增长到原始大小。

使用这些步骤不会对生产造成任何影响。唯一的风险是，如果某些数据恰好位于 100gb 数据文件的末尾，则步骤 (1) 不会释放太多空间（如果有的话）。

Answer 3

如果磁盘空间紧张，那么您可以将 .bak 文件放在网络共享上并从那里恢复。如果您使用域帐户运行 SQL Server 并授予共享足够的权限来读取文件，则应该可以工作。

另一个选项之前在“你疯了吗”篮子里（但只有在运行 sql server 2008 r2 时才有用）是 SQL Server 支持直接在共享中创建数据库文件，而无需使用跟踪标志，而且我可以从个人经验中告诉你它有效！因此，你可以将 MOVE 还原到共享。