我有两个地理上分开的 SQL Server 2005 实例。使用事务复制将重要数据库从主位置复制到辅助位置。
我正在寻找一种可以监控此复制并在失败时立即收到警报的方法。
过去我们曾遇到过两个实例之间的网络连接中断一段时间的情况。由于无法进行复制并且我们不知道，因此事务日志爆出并填满了磁盘，从而导致主数据库也中断。
前段时间我的谷歌搜索导致我们监控MSrepl_errors 表并在有任何条目时发出警报，但这根本不起作用。上次复制失败（昨晚因此问题），错误仅在重新启动时影响该表。
还有其他人监控复制吗？您是如何监控的？
只是一点点额外的信息：
似乎昨晚的问题是日志读取器代理死了并且没有再次启动。我相信这个代理负责读取事务日志并将记录放入分发数据库，以便可以在辅助站点上复制它们。
由于此代理在 SQL Server 中运行，我们不能简单地确保 process 在 Windows 中运行。
【问题讨论】：
标签： sql-server configuration replication
我们收到了有关合并复制失败的电子邮件。我没有使用过事务复制，但我想你可以设置类似的警报。
最简单的方法是通过复制监视器进行设置。
转到复制监视器并选择一个特定的发布。然后选择警告和代理选项卡，然后配置您要使用的特定警报。在我们的例子中是复制：代理失败。
对于此警报，我们将响应设置为执行发送电子邮件的作业。这项工作还可以做一些工作，包括失败的细节等。
这足以提醒我们注意问题，以便我们可以立即解决它。
【讨论】：
您可以定期检查是否正在发生数据更改，尽管这可能很复杂，具体取决于您的应用程序。
如果您有某种形式的定期更新的审计训练表（即我们的主要产品有一个基础审计表，其中列出了导致数据更新或删除的所有操作），那么您可以在两台服务器上查询该表并确保返回的结果相同。比如：
SELECT CHECKSUM_AGG(*)
FROM audit_base
WHERE action_timestamp BETWEEN <time1> AND BETWEEN <time2>
where 和是舍入值，以允许在联系数据库时出现不同的延迟。例如，如果您在 10 点后检查，您可能会检查从最后一个小时开始到本小时开始的项目。您现在有两个小值，您可以将它们传输到某处并进行比较。如果它们不同，则很可能在复制过程中出现问题 - 检查/比较会向您发送邮件和 SMS 的任何过程，以便您知道检查和解决任何需要注意的问题。
通过使用 SELECT CHECKSUM_AGG(*)，每个表的数据量非常小，因此检查的带宽使用将是微不足道的。您只需要确保您的检查在适用于服务器的负载中不会太昂贵，并且您不检查可能是开放复制事务的一部分的数据，因此可能会在那时有所不同（因此检查在我的示例中，审计跟踪是几分钟前的时间而不是现在），否则你会收到太多的误报。
根据您的数据库结构，上述方法可能不切实际。对于在检查时间范围内不是仅插入（没有更新或删除）的表（如上面的审计跟踪），找出可以安全比较的内容同时避免误报可能既复杂又昂贵，如果实际上并非不可能做到可靠。
如果您还没有滚动插入表，则可以通过定期向其中添加一行的小表（仅包含一个索引时间戳列）来制造一个滚动插入表 - 此数据除了存在之外没有其他用途因此您可以检查表的更新是否被复制。您可以删除比您的检查窗口更早的数据，因此表格不应变大。只测试一个表并不能证明所有其他表都在复制（或任何个其他表），但在这个表中发现错误将是一个很好的“canery”检查（如果这表没有在副本中更新，那么其他的可能也没有）。
这种检查具有独立于复制过程的优点 - 您无需等待复制过程在日志中记录异常，而是主动测试一些实际数据。
【讨论】：