SQL Server环境下连续两次执行dbt run报错如何解决

以下是该问题经过验证的通用排查及修复路径，覆盖90%以上的同类场景：

1. 最常见诱因：会话残留导致的对象/锁冲突 #

首次执行dbt run时生成的临时表、未提交事务、表锁没有随进程结束自动释放，第二次执行时触发同名对象存在、锁等待超时类报错，典型报错信息包含There is already an object named 'xxx' in the database、Lock request time out period exceeded。
对应修复操作：

• 修改dbt项目下profiles.yml中的SQL Server连接配置，开启自动提交、调整连接池大小避免会话复用，参考配置如下：

# 把对应字段替换成你自己的连接信息
your_project_profile:
  target: dev
  outputs:
    dev:
      type: sqlserver
      host: your_db_host
      port: 1433
      database: your_db_name
      schema: your_dbt_schema
      username: your_account
      password: your_password
      autocommit: True
      pool_size: 1
      connect_timeout: 30

• 如果模型SQL中自定义了#开头的SQL Server本地临时表，在对应模型SQL末尾主动添加DROP TABLE IF EXISTS #你的临时表名语句，不要依赖会话自动回收临时对象。
• 如果上一次dbt run是被手动强制终止的，先连接SQL Server执行以下语句清理残留锁会话：

-- 查询持有dbt相关表锁的残留会话
SELECT request_session_id 
FROM sys.dm_tran_locks 
WHERE resource_database_id = DB_ID('你的业务数据库名')
AND resource_associated_entity_id IN (
    SELECT object_id FROM sys.objects WHERE name LIKE 'dbt%'
)
-- 把上面查询返回的session_id替换到下方语句，杀掉残留会话
KILL <替换为查到的会话ID>;

2. 次常见诱因：增量模型配置错误 #

如果报错信息包含Violation of PRIMARY KEY constraint、Cannot insert duplicate key，说明是增量模型的合并逻辑出问题：第二次执行增量同步时，待写入数据和已有主键冲突。
对应修复操作：

• 检查所有配置了materialized='incremental'的模型，补全unique_key参数，确保merge逻辑能唯一匹配已有记录
• 先执行dbt run --full-refresh做一次全量重跑，如果全量运行正常，就可以定位是增量过滤条件的问题，调整模型中{% if is_incremental() %}块下的过滤逻辑，避免重复拉取已经同步过的数据即可。

3. 临时验证小技巧 #

如果不确定是哪类问题，可以在第一次执行完dbt run后等待10-15秒再发起第二次执行，排除连接回收延迟导致的偶发报错；如果等待后依然报错，再按上面两类场景逐一排查即可。

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