ora-01034表示oracle实例不可用，并非数据库损坏，而是客户端无法连接到运行中的实例；根本原因通常是实例未启动或启动失败，需优先检查ora_pmon进程、/dev/shm大小、alert日志及v$instance状态。
ORA-01034 不代表数据库损坏，而是你根本没连上一个运行中的实例——它连“空闲例程”都算不上，只是 SQL*Plus 启动了但 Oracle 实例压根没起来。
sqlplus / as sysdba 显示“已连接到空闲例程”就说明没问题？
完全不是。这个提示极具误导性：它只表示 SQL*Plus 成功启动并尝试用操作系统认证连接，但若此时 Oracle 实例尚未启动（或启动失败），它不会报错，而是给你一个“空闲例程”假象。真正判断依据只有一个：SELECT status FROM v$instance; —— 如果执行这句报 ORA-01012: not logged on 或直接返回空，就坐实了实例未运行。
- 看到“已连接到空闲例程”后，必须立刻执行
SELECT status FROM v$instance;，不能跳过 - 如果报
ORA-01012，说明后台进程（尤其是ora_pmon_<sid></sid>）根本不存在，ps -ef | grep ora_pmon_会返回空 - Windows 下检查服务名
OracleService<sid></sid>是否为“正在运行”，而非仅看服务存在
ORA-01034 总和 ORA-27101 一起出现，该先查哪个？
ORA-27101: shared memory realm does not exist 是更底层的真相，ORA-01034 只是它的客户端侧回声。只要看到这对组合，直接按以下顺序排查：
- 先跑
df -h /dev/shm：Oracle 11g+ 要求/dev/shm大小 ≥memory_target；若只有 2G 却配了 4G，实例必然启动失败且不写 alert 日志 - 再翻
$ORACLE_HOME/diag/rdbms/<sid>/<sid>/trace/alert_<sid>.log</sid></sid></sid>最后 20 行，重点盯ORA-和ERROR开头的行——90% 的真实原因（如参数语法错误、控制文件路径错、磁盘满）都在这里 - 临时绕过 SPFILE 故障：用
create pfile='/tmp/init_test.ora' from spfile;导出，手动注释掉memory_target、sga_target等大内存参数，只留db_name和control_files，再试startup nomount
startup 命令执行后卡住或报 ORA-03113？
这通常发生在 MOUNT 阶段之后、OPEN 之前，说明实例已部分启动但无法加载数据文件。常见原因不是连接问题，而是数据库自身状态异常：
- 检查控制文件是否损坏或路径失效：
show parameter control_files输出的路径是否存在且可读 - 确认所有联机日志组状态正常：
SELECT group#, status, member FROM v$logfile JOIN v$log USING(group#);，若某组STATUS为INVALID或文件丢失，startup会 hang 或报ORA-03113 - 警惕
LOCAL_LISTENER参数配置错误：比如tnsnames.ora里缺了LISTENER_<sid></sid>定义，实例能 MOUNT 但注册监听失败，后续操作易中断
最常被忽略的一点：不要在没确认 ora_pmon_<sid></sid> 进程存活的前提下反复执行 startup。Oracle 启动失败时可能残留共享内存段，导致下一次启动分配失败，此时应先清理：ipcs -mt 查段，ipcs -d 删除（仅限测试环境，生产需谨慎）。
