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