不需要。oracle 23ai 安装或升级后字典视图已由安装程序自动构建并验证完成，catqm.sql、catpc.sql 等脚本已在静默安装阶段执行完毕，无需手动重建。
oracle 23ai 安装后字典视图是否需要手动重建？
不需要。oracle 23ai 在安装或升级完成后，数据字典视图（如 all_tables、dba_indexes）已由安装程序自动构建并验证完成，catqm.sql、catpc.sql 等核心脚本已在静默安装阶段执行完毕。所谓“重建字典视图”不是常规运维操作，强行运行重建脚本反而可能破坏字典一致性。
哪些旧应用兼容性问题实际需要关注？
真正影响旧应用的不是字典视图缺失，而是语义变更、权限模型收紧、默认参数调整等隐性变化。常见触发点包括：
-
SELECT * FROM USER_OBJECTS返回列顺序或新增列（如EDITIONABLE、ORIGIN_CON_ID），导致旧应用字段越界解析失败 - 旧版 JDBC 驱动（如 ojdbc6）连接 23ai 时默认启用
oracle.jdbc.mapDateToTimestamp=false，但 23ai 的DATE列在字典中被标记为TIMESTAMP类型，引发类型转换异常 -
DBA_*视图默认仅对具有SELECT_CATALOG_ROLE或DBA角色的用户可见，而旧应用常以普通用户直连并硬编码查询DBA_TABLES，直接报ORA-00942: table or view does not exist - 23ai 默认启用
COMPATIBLE=23.0.0，禁用部分 12c/19c 兼容语法（如某些MODEL子句变体），旧 SQL 执行时报ORA-00907: missing right parenthesis
如果真要重编译/刷新字典相关对象，该怎么做？
极少数场景下（例如从 19c 升级后发现 ALL_SYNONYMS 缺失 OWNER 列），可安全执行以下最小干预操作：
以 SYS 用户登录：
SQL> @?/rdbms/admin/utlrp.sql
该脚本仅重新编译失效的字典包和视图定义，不重建底层基表，不影响数据一致性。注意：
- 不要运行
@?/rdbms/admin/catalog.sql或@?/rdbms/admin/catproc.sql—— 这些是安装期专用脚本，23ai 中调用会报ORA-01432: public synonym to be dropped does not exist并中断 - 避免使用
DBMS_UTILITY.COMPILE_SCHEMA编译SYS模式，会导致STANDARD包版本错乱 - 若需验证字典完整性，用
SELECT COUNT(*) FROM OBJ$ WHERE TYPE# IN (4,5,6,7)检查核心对象数量是否与同版本新库一致，而非依赖视图输出
旧应用连不上 23ai 的第一排查点
跳过“重建字典”这类误导性思路，直接检查三处真实瓶颈：
- 客户端
sqlnet.ora是否含SQLNET.ALLOWED_LOGON_VERSION_SERVER=8？23ai 默认要求最低协议版本为 12a（对应值 12），设太低会拒绝连接并报ORA-28040: No matching authentication protocol - 应用连接串是否仍用
jdbc:oracle:thin:@host:port:sid？23ai 默认禁用 SID 连接，必须改用服务名格式：jdbc:oracle:thin:@host:port/service_name - 数据库是否启用了统一审计（
UNIFIED_AUDIT_TRAIL）且旧应用尝试查询AUD$？此时应授权SELECT ON UNIFIED_AUDIT_TRAIL而非修复已废弃的AUD$视图
字典视图本身很稳定，但围绕它的权限、协议、连接方式、驱动行为这些链路环节，才是旧系统迁移时最常断裂的地方。
