sql - SQL Server 中的批量更新和提交频率

Question

我的数据库背景主要是 Oracle，但我最近一直在帮助一些 SQL Server 工作。我的小组继承了一些 SQL Server DTS 包，这些包每天加载和更新大量数据。目前在SQL Server 2000中运行，但很快就会升级到SQL Server 2005或2008。大量更新运行速度太慢。

关于代码我注意到的一件事是一些大的更新是在循环的过程代码中完成的，因此每个语句在单个事务中只更新表的一小部分。这是在 SQL Server 中进行更新的可靠方法吗？并发 session 的锁定应该不是问题，因为在进行批量加载时用户对表的访问被禁用。我搜索了一些，发现一些文章建议这样做可以节省资源，并且每次更新提交时都会释放资源，从而提高效率。在 Oracle 中，这通常是一种糟糕的方法，我已经使用单个事务进行非常大的更新，并在 Oracle 中取得了成功。频繁提交会减慢进程并在 Oracle 中使用更多资源。

我的问题是，对于 SQL Server 中的大量更新，使用过程代码并提交许多 SQL 语句或使用一个大语句来完成整个更新通常是一种好的做法吗？

Answer 1

抱歉各位，

以上都不能回答问题。它们只是您可以如何做事的示例。答案是，频繁提交会使用更多资源，但是，事务日志不能在提交点之前被截断。因此，如果您的单个跨越事务非常大，它会导致事务日志增长并可能碎片化，如果未检测到，稍后会导致问题。此外，在回滚情况下，持续时间通常是原始事务的两倍。因此，如果您的事务在 1/2 小时后失败，则需要 1 小时才能回滚并且您无法停止它:-)

我曾使用过 SQL Server2000/2005、DB2、ADABAS，以上内容适用于所有人。我真的不明白 Oracle 有何不同的工作方式。

您可以用 bcp 命令替换 T-SQL，这样您就可以设置批处理大小而无需编写代码。

在单个表扫描中发出频繁请求提交比使用小处理数量运行多个扫描更可取，因为通常如果需要表扫描，即使您只返回一个小子集，也会扫描整个表。

远离快照。快照只会增加IO数量，争抢IO和CPU