亚马逊Redshift定时查询运行失败，如何查询具体失败原因？

可用于排查的系统视图/表 #

你可以通过以下Redshift系统视图关联调度任务返回的查询ID，获取具体错误原因：

• SYS_QUERY_HISTORY：记录所有查询的基础执行信息，包含错误摘要、执行用户、执行时间等核心字段
• SYS_ERROR：存储所有查询执行的错误详情，包含错误码、详细报错信息、报错位置等
• STL_QUERYTEXT：可查询完整的调度执行SQL文本，确认是否存在SQL截断问题

具体查询语句 #

1. 基础错误查询 #

替换语句中的[调度查询唯一ID]为你在调度历史中拿到的ID直接执行即可：

SELECT
  query_id,
  user_name,
  status,
  error_message,
  start_time,
  query_text
FROM SYS_QUERY_HISTORY
WHERE query_id = [调度查询唯一ID];

2. 关联详情错误查询 #

如果上述查询返回的错误信息不完整，可关联SYS_ERROR视图获取更详细的报错：

SELECT
  qh.query_id,
  qh.user_name,
  e.error_code,
  e.error_message,
  e.detail,
  qh.query_text
FROM SYS_QUERY_HISTORY qh
LEFT JOIN SYS_ERROR e
  ON qh.query_id = e.query_id
WHERE qh.query_id = [调度查询唯一ID];

3. 验证SQL是否被截断 #

如果你的SQL长度较长，可通过STL_QUERYTEXT确认调度执行的SQL是否完整：

SELECT
  query_id,
  text
FROM STL_QUERYTEXT
WHERE query_id = [调度查询唯一ID]
ORDER BY sequence;

常见失败原因参考 #

针对你提到的手动执行正常、调度失败的场景，大概率是以下几种问题导致：

• 权限不匹配：手动执行用的账号和调度任务绑定的服务账号/IAM角色权限不一致，后者没有对应表、schema的读写权限
• SQL长度超限：Redshift定时调度的SQL长度默认上限为32KB，超出后会被截断导致语法错误，而手动查询编辑器的长度上限更高，不会触发该问题
• 运行上下文差异：调度任务的默认schema、search_path配置和你手动执行时的配置不同，导致无法找到对应数据库对象
• 资源不足：调度触发的时间点集群计算/内存资源不足，查询排队超时被强制终止

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