我有一个数据流，oledb源和oledb目标（都是sql server）。在source中，有两个表a和b，a有4m行，b有6m行。它们都有30多列。当我进行查询时，我从左连接b中选择30列，其中a.date>'2020-01-01'。它将返回5万行。查询将持续9-10秒。有时候，我会犯错
事务（进程id 75）在另一个进程的锁资源上被死锁，并被选为死锁受害者。重新运行事务。
即使我直接在源服务器上进行查询，我也可以得到
事务（进程id 67）在另一个进程的锁资源上被死锁，并被选为死锁受害者。重新运行事务。
但不像SSI上那样频繁
是因为它们是事务表，所以用户可以同时进行一些更新吗？
如何避免。就像在ssis中一样，如果失败，ssis能否等待5秒钟并重新运行它？
2条答案
按热度按时间qlckcl4x1#
ssis对调度一无所知。通常，这是通过sql代理完成的，您可以在其中指定失败时重试的值。
你问题的根源是我为什么会陷入僵局。您正在请求数据，而您的请求正在阻止完成更重要的查询。因为您的查询不太重要，所以它会被删除，这样数据库作为一个系统就可以保持可操作性。
您的问题表明您正在查询事务表，是的，系统的日常操作很可能会终止您的查询。默认扩展事件中的死锁图将精确地显示发生了什么（向dba寻求帮助）。
正如davidbrowne所指出的，您可能需要考虑使用不同的隔离级别，以便在并发活动插入/删除/更新数据时允许您的读取查询对数据进行操作。这往往是您正在生成etl的业务部门可以提供指导的决策点。也许处理“脏”数据是可以接受的。如果是，添加
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED你的问题。如果没有，那么您需要查看正在生成的查询计划并对其进行优化。如果只使用左连接来测试条件是否存在，那么左连接可能会被重写为exists。也许到处都在进行隐性转化。或者统计数据已经过时了。或者可以创建一个覆盖索引。这里有很多选项，但关键是要加快查询速度，这样就减少了资源争用。ecfdbz9o2#
使用行版本控制隔离级别read\u committed\u snapshot isolation或snapshot isolation之一可以防止ssis源查询获取对其读取的数据的锁定。