排查AWS Redshift COPY命令执行挂起问题及原因咨询

一、为什么SqlWorkbenchJ会话同时存在时，JDBC的COPY命令会挂起？ #

这大概率是Redshift的锁机制与会话资源冲突导致的：

• 当你在SqlWorkbenchJ中保持活跃会话时，该会话可能已经持有了目标表my_schema.mytable的共享锁（比如你之前在SqlWorkbenchJ里执行过对该表的查询，或是单纯保持着连接上下文）。而Redshift的COPY命令需要获取表的排他锁来写入数据，这就造成了锁等待——JDBC程序会一直等待锁释放，表现为“挂起”。
• 另外，Redshift集群的并发连接数是有限制的（默认500，具体看集群配置），如果SqlWorkbenchJ占用了连接资源，且JDBC连接没有设置超时时间，也会导致无限等待。不过结合你断开SqlWorkbenchJ就恢复正常的情况，锁冲突是最核心的原因。

二、Redshift侧的故障排查手段（用于类似问题的定位） #

即使现在问题解决了，这些方法也能帮你快速定位Redshift端的执行状态：

1. 查询Redshift系统表 #

Redshift内置了大量系统表来监控查询、锁和错误：

• 查看当前运行的查询：执行以下SQL，能看到所有正在运行/最近运行的查询，包括你的COPY命令的状态（是等待中还是执行中）：

  SELECT * FROM stv_recents;
  

• 排查锁冲突：通过这个表可以看到哪些会话持有锁，哪些会话在等待锁，关联会话ID就能找到SqlWorkbenchJ和JDBC连接的锁冲突：

  SELECT * FROM stv_locks;
  

• 查看COPY命令日志：筛选包含COPY的查询日志，能看到执行时长、阶段状态等细节：

  SELECT * FROM svl_qlog WHERE query LIKE '%COPY%';
  

• 检查LOAD错误：如果COPY命令有隐性错误（比如数据格式、权限问题），会记录在这个表里：

  SELECT * FROM stl_load_errors WHERE tablename = 'mytable';
  

2. 通过AWS控制台排查 #

• 查询监控面板：进入AWS Redshift控制台，找到你的集群，点击「查询监控」标签，这里能直观看到所有查询的状态、等待原因（比如“锁等待”）。
• CloudWatch日志：如果你的集群开启了日志导出到CloudWatch，可以在CloudWatch中搜索Redshift日志，找到COPY命令的执行细节和错误信息（需要先在集群属性里开启日志导出）。

3. 代码层面的补充优化 #

虽然你的问题根源不在代码，但可以加两个小优化避免类似情况：

• 明确开启自动提交：在获取连接后加上conn.setAutoCommit(true);，确保COPY命令执行后立即提交。
• 设置查询超时：给Statement设置超时时间，避免无限挂起：

  statement.setQueryTimeout(300); // 5分钟超时
  

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