我们正在使用变更数据捕获工具将源数据近乎实时地迁移到目标数据库。挑战在于尽可能准确地识别源和目标之间存在的数据迁移延迟。该工具的延迟报告功能并不令我们满意，因此我的任务是开发一个可以更好地监控这个特定指标的流程。
我们需要知道这一点的主要原因有两个：
1：为我们的用户提供准确的数据可用性矩阵，以支持报告调度。例如，考虑到我们希望尽快获得此信息，在为前一天安排每日对账报告之前，应该在午夜之后经过多长时间？
2：识别数据镜像过程运行速度比平时慢（或什至停止）的情况。这将触发一封电子邮件给我们的支持团队进行调查。
我正在寻找一些关于如何最好地完成这个看似简单的任务的一般想法
我首选的方法是专门的心跳或健康检查表。在源表有一个标识列 (SQLserver) 列或来自序列 (Oracle) 的值作为主要标识符；一个固定的任务名称字符串；固定服务器字符串（如果任务名称尚未标识；以及当前时间。
在源上有一个脚本/作业以每分钟（或 2 分钟或 10 分钟）插入一条记录
在 CDC 引擎（如果有）中，添加一列，其中包含处理更改事件的时间。
在目标处，添加最后一列，默认为插入时的当前时间。
一个目标表可以容纳多个源/任务。
常规的 blib 将让人们一眼就能看出更改是否正在实现，应用程序是否正在生成更改。
一个简单的报告可以显示当前的延迟，以及随时间变化的延迟。很高兴能够将“这个星期一”与“上星期一”进行比较，看看情况是否相似、更好或更坏。
干杯，海因。