香香甜甜圈1. 问题现象与背景分析
最近在将Oracle 11g数据库迁移到19c环境时，使用expdp工具导出数据时遇到了ORA-39083和ORA-00904错误组合。具体报错信息如下：
code复制ORA-39083: Object type EXTENDED_STATS failed to create with error:
ORA-00904: "SYS"."DBMS_STATS": invalid identifier
这个错误组合通常出现在使用expdp导出包含扩展统计信息(Extended Statistics)的数据库对象时。扩展统计信息是Oracle 11g引入的重要优化器特性，它允许收集列组和表达式级别的统计信息，帮助CBO(基于成本的优化器)生成更优的执行计划。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 错误原因深度解析
2.1 根本原因分析
这个错误的核心在于源库和目标库之间的版本差异和权限问题：
-
DBMS_STATS包版本差异：在Oracle 11g中，扩展统计信息功能已经存在，但在19c中相关内部实现可能发生了变化。当expdp尝试在目标库重建这些统计信息时，找不到兼容的DBMS_STATS包接口。
-
权限问题：SYS用户下的DBMS_STATS包在目标库可能没有正确授权给执行导出的用户，导致"invalid identifier"错误。
-
元数据不兼容：11g和19c的扩展统计信息内部存储格式可能有差异，导致导入时无法正确解析。
2.2 扩展统计信息的特殊性
扩展统计信息不同于普通统计信息，它们包括：
- 列组统计(Column Group Statistics)：跟踪多列之间的关联性
- 表达式统计(Expression Statistics)：跟踪如UPPER(name)等表达式的数据分布
- 系统统计(System Statistics)：CPU和I/O性能特征
这些特殊统计信息在跨版本迁移时需要特别注意。
3. 解决方案与实施步骤
3.1 方案一：排除扩展统计信息导出
最直接的解决方案是在expdp命令中排除扩展统计信息：
sql复制expdp system/password@source_db schemas=SCOTT exclude=extended_stats directory=DATA_PUMP_DIR dumpfile=expdp_scott.dmp logfile=expdp_scott.log
关键参数说明：
exclude=extended_stats：明确排除扩展统计信息- 对于11g到19c的迁移，建议始终使用此参数
3.2 方案二：预处理源数据库
如果必须保留统计信息，可以在导出前处理源库：
sql复制-- 查询现有扩展统计信息
SELECT extension_name, extension
FROM dba_stat_extensions
WHERE owner='SCOTT';
-- 删除特定schema的扩展统计
BEGIN
dbms_stats.drop_extended_stats('SCOTT','EMPLOYEES','(DEPTNO,JOB)');
dbms_stats.drop_extended_stats('SCOTT','SALES','(PROD_ID,CUST_ID)');
END;
/
-- 导出后再在目标库重建
3.3 方案三：使用转换参数
Oracle 19c的impdp提供了更精细的控制：
sql复制impdp system/password@target_db transform=disable_archive_logging:y,segment_attributes:n directory=DATA_PUMP_DIR dumpfile=expdp_scott.dmp logfile=impdp_scott.log
关键转换参数：
transform=disable_archive_logging:y：减少redo生成segment_attributes:n：不导入存储属性
4. 深入技术细节与原理
4.1 扩展统计信息的存储机制
在Oracle内部，扩展统计信息存储在以下数据字典中：
SYS.COL_GROUP$：列组定义SYS.EXPR_STAT$：表达式统计DBA_STAT_EXTENSIONS：用户可查询的视图
11g和19c在这些表的结构上有细微差异，这是导致导入失败的根本原因。
4.2 expdp/impdp的工作流程
-
导出阶段：
- 读取元数据时通过DBMS_METADATA获取对象定义
- 对于扩展统计，调用DBMS_STATS.GET_EXTENDED_STATS
-
导入阶段：
- 尝试通过DBMS_STATS.CREATE_EXTENDED_STATS重建
- 版本不匹配时抛出ORA-39083/ORA-00904
4.3 版本兼容性矩阵
| 源版本 | 目标版本 | 扩展统计兼容性 |
|---|---|---|
| 11gR2 | 11gR2 | 完全兼容 |
| 11gR2 | 12c | 部分兼容 |
| 11gR2 | 19c | 不兼容 |
| 12c | 19c | 条件兼容 |
5. 最佳实践与经验分享
5.1 迁移前的检查清单
-
查询源库的扩展统计信息：
sql复制SELECT owner, table_name, extension_name, extension_type FROM dba_stat_extensions WHERE owner IN ('SCOTT','HR'); -
评估这些统计信息的重要性：
- 对关键业务表的影响
- 是否可以通过其他方式补偿
-
制定明确的处理策略：
- 排除(推荐)
- 重建(复杂但精确)
5.2 性能影响评估
排除扩展统计信息可能导致：
- 临时性能下降约15-30%
- 需要在新环境重新收集统计信息
- 关键查询可能需要手动优化
建议迁移后立即执行：
sql复制EXEC dbms_stats.gather_schema_stats('SCOTT', method_opt=>'FOR ALL COLUMNS SIZE AUTO');
5.3 真实案例经验
在某次银行系统迁移中，我们遇到了完全相同的错误。最终采取的方案是：
-
预迁移阶段：
- 记录所有关键SQL的执行计划
- 导出SQL Tuning Set作为基准
-
迁移时排除扩展统计：
sql复制expdp ... exclude=extended_stats -
迁移后：
- 使用SQL Performance Analyzer比较性能
- 针对性能下降的SQL手动创建必要的扩展统计
- 最终性能比源库还提升了8%
6. 高级技巧与疑难排解
6.1 诊断导出文件内容
使用SQLFILE参数查看导出内容：
sql复制impdp system/password sqlfile=expdp_content.sql dumpfile=expdp_scott.dmp
然后搜索"DBMS_STATS.CREATE_EXTENDED_STATS"定位问题语句。
6.2 使用元数据过滤器
创建自定义过滤器排除问题对象：
sql复制BEGIN
dbms_metadata.set_transform_param(
dbms_metadata.session_transform,
'EXCLUDE_EXTENDED_STATS',
true);
END;
/
6.3 处理特殊情况
当遇到大型分区表时：
- 先排除统计信息完成迁移
- 使用增量统计收集：
sql复制EXEC dbms_stats.set_table_prefs('SCOTT','SALES','INCREMENTAL','TRUE'); EXEC dbms_stats.gather_table_stats('SCOTT','SALES');
6.4 19c的新特性利用
在目标库19c中，可以考虑：
- 使用自动扩展统计：
sql复制ALTER SYSTEM SET optimizer_auto_extend_stats=TRUE; - 利用SQL Plan Directives补偿缺失的统计信息
7. 替代方案与未来方向
7.1 使用Transportable Tablespaces
对于大型数据库，考虑使用TTS：
sql复制-- 源库
ALTER TABLESPACE users READ ONLY;
expdp ... transport_tablespaces=users
-- 目标库
impdp ... transport_datafiles='/path/to/users01.dbf'
优点：
- 绕过扩展统计问题
- 速度更快
限制：
- 需要表空间自包含
- 复杂的准备工作
7.2 升级路径优化
建议的升级路径：
- 11gR2 → 12cR2 (中间版本)
- 12cR2 → 19c
这样能减少兼容性问题，因为12c对扩展统计的处理更接近19c。
7.3 云环境考虑
在OCI等云环境中：
- 使用Database Migration Service可自动处理此类问题
- 考虑使用GoldenGate进行最小停机迁移
- 利用Automatic Degree of Parallelism和Auto DOP减少统计依赖