记一次ORACLE ORA-00600 [19004] 错误的分析与解决方法

ORACLE ORA-00600 [19004] 错误的分析与解决方法

摘要：本文记录了一次在使用 impdp 导入 .dmp 文件后，出现 ORA-00600 [19004] 内部错误的排查过程。经过深入分析，确认该问题是 Oracle 11.2.0.1.0 版本中的一个已知 Bug，与统计信息异常有关。通过清理并重新收集表统计信息成功解决问题。适用于 DBA 或开发人员在遇到类似问题时参考。

一、问题背景

在一次数据迁移过程中，我们使用 Oracle 的 impdp 工具将生产环境的 .dmp 备份文件导入到测试环境中。导入过程顺利完成，但在后续业务用户访问系统时，执行某些复杂多表关联查询时，数据库报出如下严重错误：

ORA-00600: internal error code, arguments: [19004], [], [], [], [], [], [], [], [], [], [], []

ORA-00600 是 Oracle 的内部错误，通常意味着数据库核心组件出现了意料之外的问题，需要高度重视。

二、初步排查思路

首先怀疑是导入的数据存在异常或结构不一致，因此进行了以下检查：

• 检查表结构是否一致（字段类型、约束等）
• 查看是否存在坏块（dbv 工具验证 dump 文件）
• 检查 alert.log 日志是否有其他伴随错误

但均未发现明显异常。

进一步测试发现：简单的单表查询正常，而涉及多个大表关联的复杂 SQL 会触发 ORA-00600 [19004] 错误。

这提示我们问题可能出在 执行计划生成阶段，即 优化器（Optimizer） 出现了问题。

三、定位根本原因

结合文档和社区资料查询，最终确认：

ORA-00600 [19004] 在 Oracle 11.2.0.1.0 版本中是一个已知 Bug，主要由 统计信息损坏或不一致 引起，导致优化器在生成执行计划时发生内部错误。

而 Oracle 11.2.0.4.0 及以上版本已修复此问题。

因此判断：本次 impdp 导入操作可能携带了旧环境的统计信息，这些统计信息在目标库中不兼容或已损坏，从而引发优化器崩溃。

四、解决方案

解决思路非常明确：清除有问题的统计信息，并重新收集。

✅ 方法一：删除并重新收集指定表的统计信息

1. 删除表统计信息

-- 删除 POSSellOutDetail 表统计信息
EXEC DBMS_STATS.DELETE_TABLE_STATS(ownname => 'XZT', tabname => 'POSSELLOUTDETAIL');

-- 删除 SUBYWK 表统计信息
EXEC DBMS_STATS.DELETE_TABLE_STATS(ownname => 'XZT', tabname => 'SUBYWK');

2. 重新收集统计信息

BEGIN
    DBMS_STATS.GATHER_TABLE_STATS(
        ownname            => 'XZT',
        tabname            => 'POSSELLOUTDETAIL',
        cascade            => TRUE,                    -- 同时收集索引统计信息
        estimate_percent   => DBMS_STATS.AUTO_SAMPLE_SIZE,
        method_opt         => 'FOR ALL COLUMNS SIZE AUTO',
        degree             => DBMS_STATS.AUTO_DEGREE
    );
    DBMS_OUTPUT.PUT_LINE('POSSellOutDetail 统计信息收集完成');
END;
/

BEGIN
    DBMS_STATS.GATHER_TABLE_STATS(
        ownname            => 'XZT',
        tabname            => 'SUBYWK',
        cascade            => TRUE,
        estimate_percent   => DBMS_STATS.AUTO_SAMPLE_SIZE,
        method_opt         => 'FOR ALL COLUMNS SIZE AUTO',
        degree             => DBMS_STATS.AUTO_DEGREE
    );
    DBMS_OUTPUT.PUT_LINE('SUBYWK 统计信息收集完成');
END;
/

✅ 执行完成后，再次运行之前报错的复杂查询，问题消失，查询正常返回结果。

✅ 方法二：批量清理整个用户的统计信息（适用于大规模问题）

如果多个表都受影响，建议直接清理整个 Schema 的统计信息：

-- 删除指定用户的所有统计信息
EXEC DBMS_STATS.DELETE_SCHEMA_STATS('XZT');

然后可选择性地重新收集关键表或全 Schema 统计信息：

-- 收集整个 Schema 的统计信息
EXEC DBMS_STATS.GATHER_SCHEMA_STATS(
    ownname            => 'XZT',
    estimate_percent   => DBMS_STATS.AUTO_SAMPLE_SIZE,
    method_opt         => 'FOR ALL COLUMNS SIZE AUTO',
    degree             => DBMS_STATS.AUTO_DEGREE,
    cascade            => TRUE
);

五、验证统计信息状态

可通过以下 SQL 查看表的统计信息最后分析时间及行数：

SELECT 
    owner,
    table_name, 
    num_rows, 
    last_analyzed 
FROM 
    all_tables 
WHERE 
    table_name IN ('POSSELLOUTDETAIL', 'POSSELLOUT', 'SUBYWK')
    AND owner = 'XZT';

输出示例：

OWNER | TABLE_NAME           | NUM_ROWS | LAST_ANALYZED
------|----------------------|----------|-------------------
XZT   | POSSELLOUTDETAIL     | 120345   | 2025-04-05 10:20:30
XZT   | POSSELLOUT           | 88765    | 2025-04-05 10:18:12
XZT   | SUBYWK               | 23001    | 2025-04-05 10:21:45

确保 last_analyzed 时间为最近，且 num_rows 非空，说明统计信息已正确收集。

六、总结与建议

🛠️ 推荐导入参数（impdp）

impdp username/password@db directory=DATA_PUMP_DIR dumpfile=xxx.dmp logfile=imp.log EXCLUDE=STATISTICS

导入完成后再手动收集统计信息，更加安全可控。

✅ 觉得有用？点赞 + 收藏 + 关注，获取更多数据库运维干货！