如何确保SQL Server复制正在运行?

我们收到了有关合并复制失败的电子邮件。我没有使用事务复制,但我想您可以设置类似的警报。

最简单的方法是通过复制监视器设置它。

转到复制监视器并选择特定的发布。然后选择“警告和代理”选项卡,然后配置要使用的特定警报。在我们的例子中,它是复制:代理失败。

对于此警报,我们设置了响应以执行发送电子邮件的作业。该工作还可以做一些工作,包括失败的细节等。

这足以提醒我们该问题,以便我们立即解决。

您可以定期检查数据是否发生了更改,但这可能会很复杂,具体取决于您的应用程序。

如果您有一些定期更新的审计培训表(即我们的主要产品有一个基本审计表,列出 全部的 操作导致数据被更新或删除),然后可以在两台服务器上查询该表,并确保返回的结果相同。比如:

SELECT CHECKSUM_AGG(*) 
FROM   audit_base 
WHERE  action_timestamp BETWEEN <time1> AND BETWEEN <time2> 

其中和是舍入值,以允许在联系数据库时出现不同的延迟。例如,如果您在过去一个小时的10点进行检查,您可以从最后一个小时的开始到这个小时的开始检查项目。现在您有两个小值,可以在某处传输并进行比较。如果它们是不同的,那么在复制过程中很可能发生了一些错误——检查/比较会向您发送一封邮件和一条短信息,这样您就知道检查和修复任何需要注意的问题。

通过使用select checksum_agg(*)每个表的数据量非常小,因此检查的带宽使用将无关紧要。您只需要确保您的检查在应用于服务器的负载上不太昂贵,并且您不检查可能是开放复制事务的一部分的数据,因此可能会在当时有所不同(因此,在我的示例中,检查几分钟后的审计跟踪而不是现在),否则您将获得太多的任何错误警报。

根据您的数据库结构,上述操作可能不实际。对于在检查的时间范围内(如上面的审计跟踪)不只是插入(没有更新或删除)的表,在避免错误警报的同时,计算出可以安全比较的内容可能既复杂又昂贵,如果实际上不可能做到可靠的话。

如果您还没有滚动插入表,您可以创建一个滚动插入表,方法是创建一个小表(只包含一个索引时间戳列),定期向其中添加一行-此数据除了存在之外没有其他用途,因此您可以检查表的更新是否被复制。您可以删除早于检查窗口的数据,这样表就不会变大。只有测试一个表并不能证明所有其他表都在复制(或 任何 其他表),但是在这个表中找到一个错误将是一个很好的“canery”检查(如果这个表没有在副本中更新,那么其他表也可能不是)。

这种检查的优点是独立于复制过程—您不需要等待复制过程在日志中记录异常,而是主动测试一些实际数据。