AWS Glue作业第6次查询触发Pymssql 'DBPROCESS'错误排查求助

1. 深挖FreeTDS协议与连接细节 #

• 开启FreeTDS全量调试日志：在Glue作业环境变量中添加 TDSDUMP=/tmp/freetds.log，运行后下载该日志，重点对比第6次调用前后的TDS数据包交互，确认是连接被提前终止、数据传输中断还是SQL Server返回了异常信号。
• 强制指定FreeTDS核心配置：在作业中创建临时freetds.conf文件，通过环境变量FREETDSCONF=/tmp/freetds.conf加载，明确设置tds version=7.4（匹配你的SQL Server版本）、client charset=UTF-8，禁用auto-login等可能干扰连接生命周期的参数。

2. 彻底隔离每次调用的连接资源 #

• 每次调用后显式销毁连接：即使关闭了SQLAlchemy连接池，也要手动调用engine.dispose()彻底销毁引擎实例，避免复用隐性损坏的连接句柄。示例代码：

  def execute_proc():
      engine = create_engine("mssql+pymssql://user:pass@host/db")
      with engine.connect() as conn:
          df = pd.read_sql("EXEC your_stored_proc", conn)
      engine.dispose()  # 强制释放所有连接资源
      return df
  

• 给第6次调用分配独立连接上下文：单独封装最后一次调用逻辑，使用全新的引擎实例，不与前5次共享任何连接资源，验证是否是连接复用导致的累积问题。

3. SQL Server端会话状态追踪 #

• 查询目标会话的生命周期：在SQL Server执行以下语句，定位Glue作业对应的会话，对比前5次与第6次调用的会话状态：

  SELECT session_id, login_time, last_request_end_time, status, reads, writes
  FROM sys.dm_exec_sessions 
  WHERE login_name = 'your_glue_login'
  

  重点确认第6次调用完成后，会话是否被异常终止，是否存在未释放的锁或事务。
• 检查SQL Server错误日志：查看第6次调用时间点附近的日志，是否有针对该连接的强制断开、资源耗尽（如连接数上限、内存不足）等记录。

4. 替换pandas.read_sql的底层执行逻辑 #

• 用原生SQLAlchemy执行替代pandas封装：避免pandas游标处理可能存在的隐性问题，示例代码：

  from sqlalchemy import text
  
  with engine.connect() as conn:
      result = conn.execute(text("EXEC your_stored_proc"))
      df = pd.DataFrame(result.fetchall(), columns=result.keys())
  

• 优化存储过程输出：在存储过程开头添加SET NOCOUNT ON，避免返回额外的行计数结果干扰游标读取；同时确认第6次调用的结果集是否与前5次存在差异（如超大行数、特殊字段类型）。

5. 排查Glue作业的环境与资源限制 #

• 监控作业资源使用：在每次调用前后添加内存/CPU监控代码（如import psutil; print(psutil.virtual_memory())），确认第6次调用时是否出现资源耗尽导致连接被系统强制回收。
• 本地环境复现测试：使用与Glue一致的Python、pymssql、FreeTDS版本，模拟连续调用场景，确认问题是否为Glue专属环境导致（如网络代理、安全组波动）。

6. 针对“当日重试必失败”的特殊排查 #

• 检查SQL Server登录限制：查询sys.server_principals确认Glue使用的登录账号是否被临时锁定，或是否触发了IP层面的连接黑名单（需联系云服务商确认网络规则）。
• 清理Glue临时缓存：在作业开头添加清理逻辑，删除/tmp下的FreeTDS日志、缓存文件，避免首次失败后的残留文件影响后续重试。

内容的提问来源于stack exchange，提问作者J. Mini