【问题标题】:SQL Server Using TableDiff on large tablesSQL Server 在大型表上使用 TableDiff
【发布时间】:2015-08-31 16:26:17
【问题描述】:

我们有一个使用 SQL Server 惊人的 tableDiff 的进程:

Microsoft SQL Server\100\COM\Tablediff.exe

它是 SQL Server 2008 R2。它从一个实例连接到另一个相同的实例。它工作得很好!

我有一种情况,现在有 10767594 条记录的表需要 2.5 小时才能完成,它只有一个表在工作中。我该如何改进?

该进程由 Windows 计划任务触发,这会调用 .bat 文件,.bat 文件包含没有问题的推荐代码。我们有几个这样的地方并且已经有一段时间了。这只是从一个实例到另一个实例处理大表的一项工作,耗时太长。

我意识到源表确实有索引,但目标表没有。我会在这张表上放一个索引,我还能做什么?

table diff 使用索引是否运行得更好?

有没有办法更有效地使用表差异?

例如如果我捕获了lastProcessedID,我可以下次对所有记录运行tableDiff where id > lastProcessedID吗?

任何建议都会很棒。提前谢谢你

编辑:

我的解决方案 - 这是一个非常非常大的惊喜。正如我上面提到的,1000 万多条记录表在源和目标上是相同的,除了 2 个索引(在源上)。由于这是一个内部生产服务器,在等待了几个小时后,我将索引应用于源。现在我运行根本没有更改的 tableDiff 作业,它在 2 分钟内完成。 2.5 小时到 2 分钟!

我接受了下面的答案,因为它非常有帮助。我确实走上了合并复制路径,但是在设置复制和发布之后,我发现生产实例无法成为订阅者,因为在安装时没有勾选复制。正如杰森所说,这是合理的研究、学习和设置。由于我不是 DBA,并且在这值得体验之前没有看过这个。

【问题讨论】:

    标签: sql-server sql-server-2008-r2 batch-processing


    【解决方案1】:

    性能问题是因为远程查询从每个地方提取每条记录以进行比较以生成输出。索引有助于稍微加快从每个位置拉取的速度,但效果可能不大。

    增量方法肯定更好。我不相信 tablediff 直接支持比较 2 个查询。如果是这样,您可以执行 EXCEPT 或 INTERSECT 之类的操作来进行比较。如果您想使这些数据库保持同步,为什么不考虑其他解决方案,例如日志传送、镜像、SSIS、复制、集群等。

    【讨论】:

    • 感谢您的评论。一些表在一个实例中是主表,因此数据以一种方式传输,而另一些实例中的一些表是主表,因此数据以另一种方式传输。 tableDiff 长期以来一直运行良好。这只是一张大桌子的一项工作,这成为了一个问题,因为我想每小时运行一次。我找不到关于 tableDiff 限制的太多信息。它甚至不是 SO 上的标签。鉴于此,您会使用什么方法?
    • 如果您只有几个表要同步,我会考虑复制。我提到的大多数其他事情是数据库甚至服务器级别。复制让您同步特定的表。设置起来可能有点乏味,但只有几张桌子,它对您的场景很有效。我可能会做合并复制。
    • 再次感谢 Jason,您的建议很棒。我已经编辑了我的 OP 以解释您的建议有多么有用,并且将索引应用于目的地实际上产生了巨大的差异,足以提供解决方案。我猜 tableDiff 可能不是一个很好的长期解决方案。我将需要实现某种增量差异复制,因为该表将继续增长。您认为应该在什么时候不再使用 tableDiff。时间因素,记录数?
    • 我很高兴它对你有用!老实说,我无法说出截止可能是什么——这真的取决于你的硬件和其他运行的查询,我什么时候会采取行动。随着请求量的增加,您可能会开始看到阻塞甚至锁定升级,这将随着时间的推移开始减慢速度。由于复制不是配置的选项,因此如果您注意到时间开始计时到您感到不舒服的程度,请查看创建一个简单的 SSIS 包,您可以在其中使用查询的处理日期。这对你来说可能是一个很好的下一步。
    猜你喜欢
    • 2013-07-18
    • 2020-02-10
    • 2021-11-06
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-09-16
    • 2012-04-19
    • 2023-03-21
    相关资源
    最近更新 更多