oracle升级后olap catalog（amd）组件invalid，根本原因是olapsys.cwm2iner_d1残留对象未清理，需以olapsys用户登录并执行drop table cwm2iner_d1，再切回sys运行校验脚本，最后确认compatible参数已更新为目标版本。
Oracle 升级后组件显示 INVALID，不是编译问题，而是数据字典校验失败；直接跑 utlrp.sql 通常无效，必须定位并清理特定残留对象或补全缺失步骤。
查清哪个组件 INVALID 及其真实状态
别只看 dba_registry 的 STATUS 字段，它只是最终标记，背后可能有不同原因：
-
select comp_id, comp_name, version, status from dba_registry where status != 'VALID';—— 先确认是哪个组件（如AMD对应 OLAP Catalog） - 对 INVALID 组件，再查对应 schema 下是否有异常对象：
select owner, object_name, object_type, status from dba_objects where owner in ('SYS', 'OLAPSYS', 'XDB') and status = 'INVALID'; - 特别注意
OLAPSYS.CWM2INER_D1这类内部残留对象——它不会出现在dba_objects的常规查询里，但会阻塞AMD组件校验
OLAP Catalog（AMD）INVALID：先删 CWM2INER_D1 再重验
这是 Oracle 9i/10g 升级后最典型的 AMD INVALID 场景，根本原因是升级脚本未清理临时对象：
- 必须用
OLAPSYS用户登录：conn / as sysdba→alter session set current_schema = OLAPSYS; - 执行：
drop table CWM2INER_D1;（注意：不是drop table OLAPSYS.CWM2INER_D1，当前 schema 已设为 OLAPSYS） - 切回
SYS：conn / as sysdba，运行校验脚本：@?/olap/admin/olap_recreate_catalog或手动触发组件验证逻辑 - 最后再查
dba_registry，AMD应变为VALID；若仍为UPGRADED，说明校验未完成，需确认是否遗漏catamd.sql执行
JAVAVM 或 XDB 等组件 INVALID：不能只靠 utlrp.sql
utlrp.sql 只能编译已存在但失效的对象，对组件级 INVALID 无能为力：
-
JAVAVM显示LOADING：大概率是CREATE JAVA SYSTEM失败，常见于SYSTEM表空间不足（报ORA-01653），需先扩容再重跑initjvmaux.exec('create or replace java system') -
XDB组件下DBMS_XDBZ0包体 INVALID：alter package XDB.DBMS_XDBZ0 compile body常失败，因依赖未就绪；正确做法是重新运行@?/rdbms/admin/catqm.sql（需先停用 XDB，再重建） - 所有组件级修复前，务必确认数据库已用
startup upgrade模式打开——否则校验逻辑跳过，dba_registry状态永远卡住
COMPATIBLE 参数没改会导致组件状态“假 VALID”
升级后如果 compatible 仍为旧版本（如 9.2.0.8），部分组件即使显示 VALID，实际功能也无法启用：
- 查当前值：
show parameter compatible; - 必须在升级完成、数据库 OPEN 后立即执行：
alter system set compatible='9.2.0.8' scope=spfile;（注意：值要和你升级目标版本一致，不是随便写） - 重启实例，否则组件内部校验仍按旧规则走，后续调用 OLAP API 或 XML 功能时会报错
- 这个参数一旦设错，回退代价极高，务必核对 Metalink 文档中该版本支持的最小 compatible 值
真正麻烦的不是 INVALID 状态本身，而是它背后混合了对象级失效、schema 级残留、启动模式错误、参数未同步四类问题；单点操作容易漏掉依赖链，比如删了 CWM2INER_D1 却忘了重启到 UPGRADE 模式再校验，状态就永远卡在 INVALID。
