我有一个DTS包，它在每天运行几年后没有任何问题，已经开始起作用了。最初它是将数据插入表中，然后触发插入触发器。触发器使用[inserted]更新表中的三列。通常，它正在更新大约500,000行插入数据。
当问题开始时，触发器内的更新语句需要花费数小时才能运行，通常不得不取消。禁用触发器允许DTS正常运行。在常规查询窗口中运行UPDATE语句不会导致任何问题 - 它在不到10秒的时间内运行。
为了解决这个问题，另一个任务被添加到DTS以在INSERT之后代替触发器运行UPDATE。这工作好了一段时间，但单独的UPDATE任务现在已经开始表现出与触发器相同的问题。如果在常规查询窗口中完成，UPDATE仍然按预期运行。
DTS包是在SQL 2000中创建的，并且在SQL 2005 Enterprise x64上运行。
我有点失落，试图想出这个。有什么想法吗？
答案 0 :(得分：1)
SQL引擎本身很好地涵盖了查询的并行化（SELECT），但是当涉及大量数据修改（UPDATE，INSERT，DELETE）时，标准引擎会并行化以最大限度地利用所有可用资源（磁盘） ，多个cpu核心等。）。
因此，您可以查看SQL Parallel Boost的方法 http://www.ibax.ch/-IBX-/plain.simpleimagetitletextlinklist.en.solutions.products.parallelboost/default.aspx
此方法也可用于并行执行多个SQL语句。
纯粹的SQL引擎相关并行化解决方案利用了最小化的复杂性，并且没有涉及SSIS等“外部”组件，而且它是关于任务分割和同步的最佳性能解决方案，因为它没有潜在的连接和通信开销。通过与SQL Parallel Boost并行化的整体性能提升高达10！
如果您不想重建自己的解决方案，SQL Parallel Boost提供了一个独立的纯T-SQL解决方案，可以轻松嵌入到现有应用程序和ETL流程任务中。
答案 1 :(得分：0)
您是否尝试过查看UPDATE语句的查询计划？您可以在查询分析器/ ssms中执行此操作。
该表有哪些索引？也许他们必须得到维护并且正在减慢更新速度。
您可以详细了解更新吗？是一个SQL语句还是使用CURSOR？
将整个事物转换为SSIS很可能会增加性能，但这取决于您在DTS中实际执行的操作。