SSIS包中Truncate表引发LCK_M_SCH_S锁导致任务挂起问题咨询

兄弟，这个偶发的SSIS包挂起+LCK_M_SCH_S锁问题我太熟了，结合你的场景（事务块里包含TRUNCATE表+平面文件导入），我给你拆解下核心原因和靠谱的解决办法：

• TRUNCATE的锁特性+事务范围放大了冲突概率：TRUNCATE TABLE是DDL操作，执行时会获取SCH-M（架构修改）锁，而且如果把它放在事务块里，这个锁会一直持有到整个事务提交/回滚。如果此时刚好有其他会话（比如后台报表查询、其他ETL作业）对目标表持有SCH-S（架构共享）锁，就会出现双向阻塞：你的TRUNCATE拿不到SCH-M锁被卡住，而它持有的锁又会阻止后续操作，最终导致包挂起。
• 事务内长时间持锁是关键：因为你把TRUNCATE和导入都放在同一个事务里，TRUNCATE的锁要等整个导入完成才会释放，这就给并发冲突留出了足够的“窗口”，所以问题才是偶发的——只有当其他会话刚好在这个窗口内访问目标表时才会触发。

• 拆分事务范围，分离TRUNCATE和导入
  既然你单独跑TRUNCATE再跑无截断的包完全正常，那直接把TRUNCATE步骤移出事务容器就行。具体操作：先执行TRUNCATE（不在事务内），确认成功后再启动包含导入步骤的事务容器。这样TRUNCATE的SCH-M锁会在操作完成后立即释放，不会长时间持有，冲突概率会大幅降低。
• 规避高并发时段运行包
  偶发问题大多和并发有关，尽量把包安排在业务低峰期运行，避开报表查询、其他ETL作业的执行时间，减少目标表被其他会话访问的可能。
• 排查并发会话的来源
  下次出现挂起时，用活动监视器仔细看持有SCH-S锁的会话在做什么——是不是有长时间运行的SELECT查询？或者有依赖该表的定时作业？如果是慢查询，可以考虑优化查询性能（比如加索引）；如果是其他作业，调整它们的运行时间错开就行。
• 用DELETE替代TRUNCATE（仅作为备选）
  如果业务允许，把TRUNCATE TABLE换成DELETE FROM 表名。注意：DELETE是DML操作，不会获取SCH-M锁，只会用行级锁，冲突概率更低，但数据量大的时候会很慢，还会产生大量日志，所以只适合小数据量的场景。

内容的提问来源于stack exchange，提问作者user2081126