Redshift CheckMaxRowError报错：sys_load_error_detail无记录排查求助

1. 先抓COPY命令的完整输出 #

Lambda里用的Redshift客户端（比如psycopg2）别只抓最终异常，要把COPY执行的所有返回信息都打出来。有时候COPY的错误细节不会直接抛成异常，或者异常信息被截断了，直接看命令的原始输出可能能找到线索。另外注意：如果COPY失败后没回滚就直接提交事务，临时表（包括关联的错误日志）会跟着会话结束被清掉，这也会导致sys_load_error_detail为空。

2. 核对表结构和CSV格式 #

• 临时表的列数、数据类型必须和CSV完全对应，比如CSV有12列但表只建了11列，或者某列定义为DATE但CSV里是乱码字符串，都会触发行错误，错误多了就会触发CheckMaxRowError。
• 检查COPY的参数：DELIMITER是不是和CSV的分隔符一致，有没有加QUOTE '"'（如果CSV用双引号包字段），IGNOREHEADER有没有设对（比如CSV有表头就设1）。参数错了大概率会批量报错。
• 先测小批量数据：从S3拿前100行CSV，手动跑COPY命令，看能不能成功。如果小批量没问题，再逐步加数据量，定位是不是某几行数据有问题。

3. 检查MAXERROR阈值 #

CheckMaxRowError本质是错误行数超过了COPY命令的MAXERROR限制。默认MAXERROR是0，哪怕1行错都会触发。你可以临时把MAXERROR调高（比如MAXERROR 100）再跑加载，之后查临时表的行数，对比总数据行数，算一下有多少行被拒，再针对性找问题行。

4. 确认S3权限和数据完整性 #

• 确保Lambda或Redshift用的IAM角色有S3桶的GetObject权限，要是权限不够，也可能导致加载失败但日志没记录。
• 检查S3文件路径有没有拼错，文件是不是没损坏（比如下载下来打开看看，有没有乱码、换行符异常），如果文件加密了，COPY命令里要加对应的KMS密钥参数。

5. 隔离存储过程的影响 #

先别调用存储过程，只跑创建临时表+COPY+提交这几步，看还会不会报错，sys_load_error_detail有没有内容。要是这时候正常，那问题大概率出在存储过程里，比如它修改了临时表数据或者清理了错误日志。

6. 找管理员查查询日志 #

虽然你看不了STL/STV表，但可以找Redshift管理员查CloudWatch里的查询日志，或者控制台的查询历史，里面会记录COPY命令的详细执行信息，包括错误行数、具体错误原因。

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