使用SQL Developer迁移数据遇GDK-05043：无效月份问题求助

你遇到的这个问题其实挺常见的——就算两端数据库的NLS设置表面一致，也可能因为导出/导入环节的细节疏漏掉坑，给你几个具体的排查方向：

• 检查CSV文件中的日期数据细节
  直接打开导出的CSV文件，重点盯日期列：

  • 有没有格式不一致的行？比如大部分是2024-05-15，但某几行混了2024/05/15或15-05-2024；
  • 如果是英文月份，有没有拼写错误？比如把Jan写成Jna，全拼January写成Januray；
  • 有没有空值或特殊字符混入？比如日期列里藏着NULL、N/A，或者看不见的空格、制表符。

• 确认SQL Developer导出时的日期格式是否严格遵循NLS
  导出CSV时，SQL Developer可能会用自身的显示格式而非数据库的NLS_DATE_FORMAT：

  • 导出向导里有没有手动指定过自定义日期格式？比如选了DD-MON-YYYY但数据库NLS是YYYY-MM-DD；
  • 导出前有没有临时修改过SQL Developer的日期显示设置？比如在「工具→首选项→数据库→NLS」里改了格式，导出时用了这个临时配置而非数据库默认。

• 排查导入时SQL Developer的日期解析设置
  就算数据库NLS对了，SQL Developer导入CSV时可能单独指定了格式：

  • 导入向导里，有没有给日期列单独设置解析格式？比如选了DD-MM-YYYY但实际CSV是YYYY-MM-DD；
  • 导入时的字符编码是否和CSV文件一致？比如CSV是UTF-8但导入时选了GBK，导致中文月份（比如「五月」）被乱码解析成无效字符。

• 验证数据库会话级的NLS设置
  虽然你说db2和db1的NLS一致，但要确认导入会话的实际设置：

  • 登录db2后执行SELECT * FROM NLS_SESSION_PARAMETERS WHERE PARAMETER LIKE '%DATE%'，查看会话级的NLS_DATE_FORMAT、NLS_DATE_LANGUAGE是否和db1完全匹配；
  • 有没有可能导入用的用户有单独的NLS配置？比如用户的profile里指定了不同的日期格式。

• 测试单条数据导入
  挑几个CSV里的日期值，直接在db2执行插入语句测试：

  INSERT INTO your_target_table (date_column) VALUES ('2024-05-15');
  

  如果这条语句报错，说明还是会话或数据库的NLS有问题；如果不报错，那大概率是CSV文件有脏数据或导入向导的配置问题。

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