好的，对于标准的非镜像数据库，事务日志可以通过简单的数据库处于简单模式或定期备份来进行检查。我们保持简单，因为我们正在进行 SAN 快照备份，并且不需要 SQL 备份。
我们现在要进行镜像。我显然不再有简单模式的选择，必须使用完整模式。这显然会导致大型日志文件和日志备份的需要。没关系，我可以处理；进行日志备份并丢弃任何以前的维护计划。我意识到如果没有它的前辈，这个备份基本上是无用的，但是 SAN 快照正在执行备份。
我的问题是……
a) 有没有办法在不创建备份的情况下截断所有已处理行的日志文件？ （因为无论如何我都不能使用它们......）
b) 维护计划是服务器本地的，不会跨镜像对复制。应该如何在镜像设置上完成？这样当数据库故障转移时，计划开始在新主体上运行，但当它是镜像时不会感到不安？
谢谢
【问题讨论】：
标签： sql sql-server-2005 mirroring database-mirroring
A.如果您的服务器足够重要以对其进行镜像，那么为什么对事务日志备份不够重要呢？ SAN 快照是仅一个时间点的时间点映像，但它们无法让您在沿途的不同时间点停下来。当您的开发人员截断表时，您希望重播所有日志直到该语句，然后停止。这就是事务日志备份的好处。
B.设置一个维护计划（或者更好的是，像 Ola Hallengren 在http://ola.hallengren.com 上的 T-SQL 脚本）来备份所有数据库，但选中复选框以仅备份在线数据库。 （在我的脑海中，不确定这是否是 2005 年的一个选项 - 可能仅限于 2008 年。）这样，无论发生什么故障转移，您总能得到。
当然，请记住，您需要小心清理脚本和复制这些备份文件等事情。如果您将一半的 t-log 备份放在一个共享上，另一半放在另一个共享上，则恢复起来会更加困难。
【讨论】：
a) 不，您不能截断属于镜像数据库的日志。备份日志是您的最佳选择。我有几个数据库，它们只是根据 HA 需求设置了镜像，但由于各种原因不需要 DR。好像是你的情况？我真的仍然建议将日志备份保留一段时间。没有理由取消您的 HA 策略添加的完美恢复计划。 :)
b) 我自己的解决方案是有一个辅助代理作业，它根据镜像的状态进行监控。如果发现镜像发生更改，则启用镜像实例上的辅助作业，如果可能，禁用旧主体。如果主体已关闭并重新启动，则该作业仍处于禁用状态。作业本身被切换回的唯一方法是再次发生强制故障转移。
【讨论】：