源查询中的 ssis oledb 源死锁

Posted 2023-03-22

【中文标题】源查询中的 ssis oledb 源死锁

【英文标题】：ssis oledb source deadlock in source query

【发布时间】：2020-05-20 19:33:24

【问题描述】：

我有一个数据流、oledb 源和 oledb 目标（都是 SQL Server）。在源代码中，有两个表 A 和 B，A 有 4M 行，B 有 6M 行。他们都有 30 多列。当我进行查询时，我从 A 左连接 B 中选择 30 列，其中 a.date > '2020-01-01'。它将返回 50K 行。查询持续 9 -10 秒。有时，我会出错

事务（进程 ID 75）与另一个进程在锁定资源上死锁，并已被选为死锁牺牲品。重新运行事务。

即使我直接在源服务器上查询，我也可以得到

事务（进程 ID 67）与另一个进程在锁定资源上死锁，并已被选为死锁牺牲品。重新运行事务。

但不像 SSIS 那样频繁

是不是因为它们是事务表，所以用户可以同时进行一些更新？

如何避免。就像在 SSIS 中一样，如果失败，SSIS 是否可以等待 5 秒并重新运行它？

【参考方案1】：

SSIS 对调度一无所知。通常，这是通过 SQL 代理完成的，您可以在其中指定重试失败值。

您问题的根源是我为什么会遇到这些死锁。您正在请求数据，而您的请求正在阻止更重要的查询完成。由于您的查询不太重要，因此它会被扼杀，因此数据库作为一个系统可以保持运行。

您的问题表明您正在查询事务表，是的，系统的日常操作可能会扼杀您的查询。默认扩展事件中的死锁图将准确地揭示发生了什么（向您的 DBA 寻求帮助）。

正如 David Browne 指出的那样，您可能需要考虑使用不同的隔离级别，以允许您的读取查询在并发活动插入/删除/更新数据时对数据进行操作。这往往是您为其生成 ETL 的业务单位可以提供指导的决策点。也许使用“脏”数据是可以接受的。如果是这样，请将SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED 添加到您的查询中。 如果没有，那么您需要查看正在生成的查询计划并对其进行优化。如果您仅使用它来测试条件是否存在，那么左连接可能会被重新设计为 Exists。也许到处都在进行隐式转换。或者统计数据已经过时。或者可以创建一个覆盖索引。这里有很多选项，但关键是让查询更快，从而减少资源争用。

【参考方案2】：

使用row-versioning isolation levelsREAD_COMMITTED_SNAPSHOT 隔离或SNAPSHOT 隔离之一来防止您的SSIS 源查询获取对其读取的数据的锁定。

【讨论】：

如果我添加 ALTER DATABASE [DB_NAME] SET READ_COMMITTED_SNAPSHOT ON;在我的查询之前，会影响源表吗？