我们的一个供应商通过使用复制（“出版物类型：事务性或快照”）与我们共享数据，以向我们提供其数据库之一的本地副本。我们有一个SSIS作业，该作业会定期执行，以使用高水位标记方法从此表中提取数据。具体来说，到达表中的数据具有一个ID列，该ID列是连续的整数（我很确定在这方面这是一个Identity列，但我仍在尝试确认这一点。）
我们存储前一个高水位线，然后在下一轮作业中提取ID大于此ID的所有内容。然后，在提取的末尾，将存储的高水印ID设置为我们刚刚提取的最高ID。
但是，我们发现提取的数据中存在漏洞。这些漏洞似乎与影响大量行的更新相关，这表明复制过程以并行或多线程方式运行，并且这些漏洞代表提取时未提交的写操作（或任何等效的复制操作）。后来，有一些较小的写道，已经已提交。
问：这是怎么回事？
据我所知，不更改提取策略的唯一可行方法是将事务隔离级别更改为可序列化的 if （并且仅在 >）它也将适用于复制。否则，我认为我们必须更改提取策略以将记录标记为已提取，以便我们可以弥补漏洞。
问：有人可以建议其他低影响力的解决方案吗？
谢谢。
答案 0 :(得分：0)
这个时间太长，无法发表评论。
您的前两个句子有些不一致。
我们的一个供应商通过使用复制（“出版物类型：事务性或快照”）与我们共享数据，以向我们提供其数据库之一的本地副本。
我们有一个SSIS作业，该作业会定期执行以使用高水位标记方法从该表中提取数据。
如果您正在运行 transactional 复制，则不会出现此问题，因此，从广义上讲，答案可能是开始进行事务复制，但存在开销在您的情况下可能会接受或可能不会接受。
如果您正在运行快照复制，则每次触发时，您的数据不一致都会消失一段时间，因为在那一刻，表的两个版本应该几乎完全同步。
我怀疑您正在执行的是定期快照复制（也许一天一次？），该复制为您感兴趣的表的状态提供了一个新的本地副本，然后在整个过程中运行SSIS包。天抢新行。正如SMor在评论中指出的那样，这样做会丢失更新和删除。另外，如果该行标识符是SEQUENCE而不是IDENTITY，则很可能会在您感兴趣的表上以外的其他位置生成新行，然后再添加。我曾经在某个销售代表可以在订单上生成报价的地方工作。报价将获得实时订单号，但直到销售代表将报价转换为订单后，它才会出现在ORDER表中。并且有一条记录是按数字顺序“按顺序”添加的，而不是按时间顺序。
我们只是从头开始研究。
您遇到了一个真正的问题，并且要花很多时间来解决它，但这并不是真正的问题，您可以从Stack Overflow获得很多帮助社区，直到您对实际的数据问题有了更清晰的认识。