通查数据库快照
问：我刚刚发现了数据库快照。现在，我考虑将它们用作完全恢复模式和日志备份的替代方法。我将大约每小时创建一次快照，这样当出现错误时，我可以拉回损坏的数据。这似乎是一种更省事且更快的还原方法。您认为进行这种更改会产生任何问题吗?
答：会产生问题，数据库快照不是全面的灾难恢复策略的实用或可行替代方法。在从灾难完全恢复方面，数据库快照不具备与事务日志备份相同的功能。数据库快照不包含数据库中所有页的副本，它只包含自第一次创建数据库后更改过的页的副本。这意味着，如果数据库有任何损坏，则没有底层数据库的数据库快照将没有任何用处。它只是数据库中不同页的集合，不能用于恢复。
您可以通过数据库快照拉回不小心从数据库中删除的数据，但前提是数据库本身仍可用。例如，如果从数据库中删除的表仍存在于快照中，则可以使用快照重新创建该表。
也就是因为潜在的性能问题，创建太多数据库快照(作为每一个半小时的事务日志备份的替代方法)不是一个好主意。在可以交换数据库页之前(请参阅“关闭页锁存”部分中的答案说明)，必须先将页同步地复制到尚未包含该页版本的所有现有数据库快照中。随着创建的数据库快照越来越多，要生成的页副本也越来越多，从而导致性能下降。
不要创建太多数据库快照的另一个原因是每个数据库快照将包含数据库页更改前的副本。每个副本将随着数据库中更改的内容增多而增大。这可能会导致磁盘空间问题和性能问题。
数据库快照不是为了替代频繁日志备份而设计的。您可以在白皮书 Database Snapshot Performance Considerations Under I/O-Intensive Workloads 中阅读关于数据库快照的性能影响的更深入研究。
此外，如果您要使用完全恢复模式和事务日志备份，则很明显您对最多能够恢复到灾难点和/或使用时间点还原感兴趣。(有关恢复到灾难点和时间点还原的说明，请分别参阅我于 2009 年 7 月和 2009 年 11 月发布的文章“了解 SQL Server 备份”和“SQL Server：利用备份进行灾难恢复”。)
镜像，镜像
问：我被要求为数据库设置数据库镜像，但我担心数据库镜像不能帮助解决我们的问题。我们的 SAN 存在一些损坏问题，因此打算通过数据库镜像防止我们受到损坏。损坏不会自动发送到镜像吗?数据库镜像如何帮助我们解决此问题?
答：这是一个会引起大量混淆的问题。任何提供冗余数据库副本的技术看起来似乎都容易受到从主体传播到镜像数据库(以使用数据库镜像术语)的损坏的影响，但实际上这种情况不会发生。
问题的关键在于理解镜像数据库的维护方式。如果底层同步机制将完整数据库页从主体复制到镜像数据库，则损坏肯定会传播到镜像。然后，主体中损坏的页将被放置在镜像中。
但是，数据库镜像专门避免了这种情况，因为它不将一个数据库中的数据库页复制到另一个数据库。数据库镜像过程是将事务日志记录从主体数据库复制到镜像来完成的。事务日志记录说明对数据库页所做的物理更改，它们不包含实际页本身。(有关事务日志记录、日志记录和恢复的完整说明，请参阅我于 2009 年 2 月发布的文章：“了解 SQL Server 中的日志记录和恢复功能。”)
即使数据库页被主体数据库的底层 I/O 子系统损坏，该损坏也不可能直接传播到镜像数据库。可能出现的最坏情况是如果 SQL Server 未检测到页面损坏(由于未启用页面校验和)，将使用已损坏的列值来计算存储在数据库中的值。生成的不正确结果将传播到镜像数据库，从而产生二级损坏效果。如前所述，如果启用了页面校验和，则从磁盘中读取页面时，这种损坏仍将检测不到，从而不会出现二级损坏。
此行为还说明了为什么对主体数据库运行一致性检查不会生成关于镜像数据库的一致性状态的任何信息，反之亦然。它们是通过传送对数据库而不是实际数据库页的物理更改的说明来保持同步的两个不同数据库。
