ora-00942在oracle初始化阶段出现，主因是catalog.sql未成功执行导致数据字典视图缺失；须以sys as sysdba连接、数据库open、system表空间online后，先运行catalog.sql再运行catproc.sql，并用三连查询验证。
ora-00942 在 oracle 安装或数据库初始化阶段出现，和日常查询时的报错逻辑不同——它往往不是权限或 schema 问题，而是核心数据字典对象压根没建好。典型场景是：手动执行 catalog.sql 失败、中断，或用非标准方式创建数据库（比如未走 dbca），导致 all_tables、dba_objects 等关键视图缺失。
直接运行 catalog.sql 前必须确认实例状态
catalog.sql 是 Oracle 提供的系统视图初始化脚本，依赖 SYS 用户、SYSTEM 表空间、以及已启动的数据库实例。如果数据库还没 open，或者当前连接不是 SYS AS SYSDBA，脚本会大量报 ORA-00942，甚至卡在中间。
- 必须以
SYS AS SYSDBA身份连接（不能是普通 DBA 角色用户） - 数据库状态需为
OPEN：执行SELECT STATUS FROM V$INSTANCE;，返回OPEN才可继续 - 检查
SYSTEM表空间是否 online：SELECT STATUS FROM DBA_TABLESPACES WHERE TABLESPACE_NAME = 'SYSTEM';，必须是ONLINE - 若刚执行过
CREATE DATABASE，但没运行catalog.sql，ALL_TABLES这类视图物理上就不存在，此时任何查字典的语句都会触发ORA-00942
catalog.sql 执行失败的常见卡点
这个脚本本身会建几百个视图和同义词，中间某一步失败（比如因磁盘满、权限不足、或已有对象冲突），后续所有依赖它的对象都建不起来，错误会层层传导。
- 最常卡在
CREATE VIEW ALL_TABLES或CREATE SYNONYM DBA_TABLES这类语句上，报ORA-00942实际是上游基础表（如OBJ$、USER$）还没准备好 - 如果之前执行过但中断了，再次运行前要先清理残留：
DROP VIEW ALL_TABLES;可能失败（因为根本不存在），更稳妥的是重启实例后重跑，或检查catqm.sql是否被误跳过（尤其在启用 Oracle Text 或 JVM 时） - 脚本路径必须准确：通常位于
$ORACLE_HOME/rdbms/admin/下，用 SQL*Plus 运行时别漏掉扩展名：@?/rdbms/admin/catalog.sql（?代表$ORACLE_HOME）
别把 catalog.sql 和 catproc.sql 搞混
这两个脚本职责不同，缺一不可，但顺序不能错：
-
catalog.sql：建数据字典视图（ALL<em>*</em>、DBA<em></em>、USER_开头的），是查询元数据的基础 -
catproc.sql：建内置 PL/SQL 包（DBMS_LOB、UTL_FILE等）和系统过程，很多 DBA 工具依赖它 - 必须先跑
catalog.sql，再跑catproc.sql；反过来或只跑一个，都会让部分视图或包报ORA-00942 - 验证是否完整：运行
SELECT COUNT(*) FROM DBA_VIEWS WHERE OWNER = 'SYS' AND VIEW_NAME LIKE 'ALL%';，正常应返回 200+ 行；若为 0，说明catalog.sql没生效
真正麻烦的不是脚本怎么运行，而是执行完之后——你以为万事大吉，但某个视图建了一半、同义词指向了不存在的对象，这种“半成品”状态极难排查。建议每次运行后，用 SYS 用户执行一条最基础的字典查询：SELECT <em> FROM DUAL;</em>（必须通）、SELECT FROM V$VERSION;（必须通）、SELECT * FROM ALL_TABLES WHERE ROWNUM = 1;（这是检验 catalog.sql 成效的黄金三连）。任何一个不通，就得回溯日志，而不是盲目重试。
