每月存档过程的日志传送

Question

我们将在接下来的几周内在我们的生产环境中实施日志传送。

我们每月执行一次数据库“清理”，将数据库设置为SIMPLE恢复模式，将记录复制到历史数据库，然后从原始数据库中删除以释放空间。

我知道将数据库恢复模型更改为 simple 会破坏日志传送（因为 LSN 链会被破坏）。在这种情况下，我必须在辅助服务器上恢复完整备份并重新开始日志传送过程。我不想这样做。

我是一个“偶然的 DBA”，继承了这个归档过程。该过程就像从实时数据库中选择行，将它们插入存档数据库，然后从实时数据库中删除它们一样简单。

我担心的是，如果我在删除过程中将数据库保持在完整恢复模式中，事务日志可能会以这样的方式增长，从而可能导致空间问题和/或使辅助服务器大大落后于主服务器。

我在这里有哪些选择？任何建议将被认真考虑。

Answer 1

您可以根据清理过程使用 TSQL 和 SQL 代理作业编写整个过程的脚本 - 我假设您可以或已经编写了脚本，但以下是我在我维护和支持的环境中处理类似问题的基础知识。

1. 在主数据库上将恢复模式切换为简单（带有 SQL 代理作业步骤的 TSQL）——这将破坏日志传送链，因此在发生这种情况时，您的 LSCopy、LSBackup 和 LSRestore 作业将在此时超时——然后在主数据库

2. 将您的主数据库切换回完全恢复模式（带有 SQL 代理作业步骤的 TSQL），将您的主日志文件增大（或缩小）回“通常”大小（再次是 SQL 代理 TSQL）

3. 运行（或带有 SQL 代理作业的 TSQL 脚本）主数据库的完整备份到“通常的”完整备份位置

4. 使用完整备份文件恢复辅助数据库，如上面 #3 所示（TSQL 和 SQL 代理作业步骤）

之后，由于某些测试超时，您已经了解了时间等信息，LSBackup、LSCopy 和 LSRestore 作业应该再次开始工作。

我记得不太清楚，但您可能需要在上述步骤 #1 之后清除主数据库和辅助数据库上的 LSBackup 和 LSCopy TRN 文件，以确保 SQL 不会尝试将断链 TRN 文件应用到辅助数据库。

这是可以做到的，而且我以前也做到过。它可能不是“最佳实践”，但如果有业务需求，如果它有效、能完成工作并允许您对其进行一些自动化，那么这应该是足够的理由。