若要查看文件中的备份内容，可以使用 SSMS 创建引用该文件的新备份设备。创建引用后，可以显示该备份设备中的内容的备份详细信息。也可以使用 RESTORE HEADERONLY 命令。这两种方法都会检查备份设备，并提供一行输出，用于描述文件中的每个备份。SSMS 使用友好名称标识备份类型。若要使用正确的语法，需要按照 SQL Server 联机丛书中有关该命令的条目(有关 SQL Server 2008 版本，请参阅此处)所提供的信息，确定每个备份的备份类型，从而可以使用适当的 RESTORE 命令还原备份。
您还需要确定要还原的备份。这有一点棘手，因为所需要的 RESTORE HEADERONLY 的输出列名称与您必须用于还原的选项不匹配。文件中的备份从 1 开始编号(1 表示最旧)，在名为“Position”的列中可以找到编号。若要还原备份，必须在 RESTORE 命令的 WITH FILE=<编号> 部分中使用相应编号。下面是一个示例：
WITH FILE = 2, NORECOVERY;
其他在此就不一一列举了。您必须从某个数据库备份开始还原序列，然后还原零个或多个差异数据库和/或事务日志备份。更详细的信息不在本专栏的讨论范围之内，不过，在我为 2009 年 11 月刊撰写的文章利用备份进行灾难恢复中，详细介绍了有关可能需要的还原序列和其他 RESTORE 选项。
使用 SSMS 时，可在还原数据库向导中指定备份文件，该向导会自动显示文件中的所有备份，并允许您选择需要的备份。图 1 显示了一个示例。
图 1 使用 SSMS 还原数据库向导显示文件中的多个备份。
无论选择哪个选项，在进行灾难恢复时，在正式执行还原之前，必须试还原到另一个位置，这一点至关重要。我始终遵循的原则之一是“没有成功还原，就没有备份。”
问题：我有一个很大的数据库，每隔几周就需要将它复制到开发环境中。我的问题是，最近数据库因要容纳更多数据增大了，现在将它还原到开发环境中时，它显得太大了。如何在还原该数据库时使它缩小一些?
解答：这是一个相当普遍的问题，遗憾的是，没有什么好的解决方法。
数据库备份不会以任何方式更改数据库，它仅仅读取所有已使用的数据库部分，将这些部分以及一些事务日志(有关原因和程度的说明，请参阅我的博客文章)包含在备份中。从数据库备份进行的还原仅创建文件，写出备份中的内容，然后对数据库运行恢复操作。基本上，数据库中的内容即是还原时获得的内容。没有选项可以用于在还原时缩减数据库、在还原时解决索引碎片问题、在还原时更新统计数据或是人们可能需要执行的任何其他操作。
那么，如何实现您的目的呢?根据具体方案，您有三种方法。
首先，可以对生产数据库执行缩减操作，以回收空的空间。这样可使还原的数据库副本与生产数据库相同，而不会浪费空间，但是成本可能会很高。生产数据库会再次增长，因而缩减操作可能成本极高(在 CPU、I/O 和事务日志方面)，并可能导致索引碎片。索引碎片问题必须得到解决，从而会占用更多资源。您不会选择这么做。(有关使用数据文件缩减的风险的更深入说明，请参阅我的博客文章。)您可以考虑只移除文件末尾的可用空间 (DBCC SHRINKFILE WITH TRUNCATEONLY)，但这可能不会达到您所希望的缩减大小。
其次，如果在开发过程中只需要还原一次生产数据库，则需要有足够空间来还原完整数据库，然后进行缩减以回收空间。在此之后，需要确定是否要解决缩减操作所产生的碎片。
如果要运行查询以进行性能测试或进行报告，碎片可能会极大降低这些查询的性能。如果不运行这类查询，则完全不必整理碎片。若要解决碎片问题，不能重新生成索引(使用 ALTER INDEX … REBUILD 命令)，因为这需要额外空间并会导致数据库再次增大，您需要重新组织索引(使用 ALTER INDEX … REORGANIZE 命令)。
如果一定要整理碎片，请务必将数据库切换至 SIMPLE 恢复模型，以便事务日志不会因重新组织所生成的所有事务日志记录而增长。如果将数据库保留为 FULL 恢复模型，则日志会继续增长，除非您将日志备份(您可能希望避免处理这些内容)写入数据库的开发副本中。
最后，如果在开发过程中需要多次还原生产数据库，则不会希望多次重复第二种方法中的步骤。在这种情况下，最好按照第二种方法中的步骤执行，然后创建缩减(可能整理了碎片)数据库的另一个备份。
此第二个备份随后可以用于执行最小大小生产数据库的多次还原。
总而言之，要将拥有大量可用空间的生产数据库移动至开发环境，而不在初始还原时包括这些 SQL 可用空间，是无法实现的。
