ora-01034表示oracle实例不可用，需按五步排查：一查pmon进程是否存在；二用v$instance确认实例状态；三检共享内存与内核参数；四试pfile绕过spfile故障；五验监听器注册状态是否同步。
当Oracle数据库连接时返回“ORA-01034: ORACLE not available”，该错误并不直接等同于实例“崩溃”，而是表明客户端无法与运行中的Oracle实例进程建立有效会话。以下是针对该现象的多种诊断与恢复路径：
一、验证实例进程是否存在
ORA-01034 的根本原因之一是 Oracle 后台进程（尤其是 PMON）未运行，即实例未启动或已异常终止。需通过操作系统级命令确认进程状态，而非仅依赖连接反馈。
1、在 Linux/Unix 系统中执行：ps -ef | grep ora_pmon_，检查是否输出形如 ora_pmon_ORCL 的进程行；
2、若无任何 ora_pmon_ 进程，则说明实例确实未启动或已完全退出；
3、若有 ora_pmon_ 进程但仍报 ORA-01034，需进一步检查实例是否处于 NOMOUNT 或 MOUNT 状态而未 OPEN；
4、在 Windows 系统中打开服务管理器，确认 OracleService
二、使用 SQL*Plus 检查实例实际状态
即使能进入 SQL*Plus 命令行环境，也不代表数据库实例已加载并开放服务。必须通过动态性能视图确认实例当前生命周期阶段。
1、以操作系统认证方式登录：sqlplus / as sysdba；
2、执行查询：SELECT status FROM v$instance;；
3、若返回 OPEN，则实例正常，问题可能出在连接配置或权限；
4、若返回空结果、报错 ORA-01012: not logged on 或提示“no rows selected”，说明实例未启动或未完成初始化；
5、若返回 MOUNTED 或 NOMOUNT，则需手动执行 ALTER DATABASE OPEN; 或 STARTUP; 完成启动流程。
三、检查共享内存段与系统资源限制
Oracle 实例依赖操作系统共享内存（/dev/shm）和内核参数（如 kernel.shmall、kernel.shmmax）分配 SGA。若资源不足或配置错误，实例可能静默失败，仅表现为 ORA-01034 和 ORA-27101。
1、检查共享内存挂载大小：df -h /dev/shm，确保其容量 ≥ memory_target 参数值；
2、若空间不足，临时扩容：sudo mount -o remount,size=4G /dev/shm；
3、检查内核参数：sysctl kernel.shmall kernel.shmmax，确认其不低于实例所需共享内存总量；
4、查看告警日志末尾是否有 ORA-27101 或 ORA-27123 等内存相关错误记录。
四、绕过 SPFILE 使用 PFILE 启动验证
SPFILE（服务器参数文件）损坏、语法错误或路径不可读会导致 startup 命令静默失败，仅报 ORA-01034 而不提示具体原因。使用文本型 PFILE 可规避此问题并快速定位参数故障点。
1、切换至 oracle 用户并进入 SQL*Plus：sqlplus /nolog；
2、尝试以 NOMOUNT 方式启动：STARTUP NOMOUNT PFILE='/path/to/init.ora';；
3、若成功，说明原 SPFILE 存在问题；可先用 CREATE PFILE FROM SPFILE; 导出当前配置，再逐行注释可疑参数（如 memory_target、control_files 路径）后重试；
4、若 PFILE 启动仍失败，需检查 db_name 是否与实际数据库名一致，以及 control_files 所列路径是否存在且 Oracle 用户具备读写权限。
五、排查监听器与实例注册状态错位
监听器（Listener）独立于数据库实例运行，其显示“READY”仅表示曾收到过实例注册请求，并不反映实例当前存活状态。实例可能在注册后数秒内崩溃，而监听器缓存未更新，导致客户端误判。
1、执行：lsnrctl services，观察目标 SID 对应的服务条目中 “Service handler type” 是否为 DEDICATED 或 SHARED；
2、若显示为 UNKNOWN，说明实例已掉线，需立即检查 PMON 进程及 alert.log；
3、检查 local_listener 参数是否正确指向监听器地址，避免动态注册失败；
4、强制刷新注册：ALTER SYSTEM REGISTER;，再执行 lsnrctl services 确认服务状态是否更新。
