ORA-01034本质是Oracle实例未启动，首要排查ora_pmon_进程是否存在；若不存在，需检查ORACLE_SID是否正确、/dev/shm共享内存是否充足、alert.log中是否有分配失败等关键错误。
ORA-01034 错误本质是实例没起来，不是连接配置问题
ora-01034 报错时，sqlplus / as sysdba 显示 “connected to an idle instance”，这说明 oracle 客户端连上了本地进程（即 sql*plus 启动成功），但数据库实例根本没启动——ora_pmon_<sid></sid> 进程不存在，v$instance 查不到数据，select status from v$instance 直接报 ora-01012: not logged on。这不是 tns 配置、密码或网络问题，而是本地环境与实例状态脱节的信号。
检查并修正 ORACLE_SID 是最常见有效的修复动作
Linux/Unix 下 ORACLE_SID 大小写敏感，Windows 下虽不敏感但注册表和命令行必须一致。错误常发生在多实例共存、脚本切换 SID 不彻底、或 .bash_profile 里写错 SID 名（比如把 orcl 写成 ORCL 或 orcl1）。
-
echo $ORACLE_SID输出为空或与实际实例名不符 → 立即修正 -
ps -ef | grep pmon应看到类似ora_pmon_orcl的进程；若只有ora_pmon_（空后缀）或完全没匹配，说明 SID 设置失效 - 临时生效：
export ORACLE_SID=orcl（替换为你的实际 SID），再运行sqlplus / as sysdba→startup - 永久生效：修改
~/.bash_profile或/etc/profile，确保export ORACLE_SID=orcl在export ORACLE_HOME=...之后执行
ORA-01034 + ORA-27101 组合出现时，优先排查共享内存分配失败
ORA-27101 是 ORA-01034 的底层原因：Oracle 启动时申请共享内存段失败，直接退出，不留进程、不写 alert 日志正文（只在最后几行留痕迹）。此时即使 SID 正确也起不来。
-
df -h /dev/shm：Oracle 11g+ 要求/dev/shm容量 ≥memory_target值；若不足，用sudo mount -o remount,size=4G /dev/shm临时扩容 -
cat /proc/sys/kernel/shmall和cat /proc/sys/kernel/shmmax：两个值都必须 ≥ 实例所需共享内存总量（单位页数 / 字节），否则内核拒绝分配 - 检查
$ORACLE_HOME/diag/rdbms/<sid>/<sid>/trace/alert_<sid>.log</sid></sid></sid>最后 20 行，重点找ORA-、ERROR、Failed to allocate等关键词 - 参数冲突典型场景：
sga_max_size>memory_target→ 必须先用create pfile from spfile导出文本参数文件，手动调小sga_max_size，再create spfile from pfile
别被 lsnrctl status 的 “READY” 假象误导
监听器显示某服务状态为 READY，只代表它曾经收到过该实例的 PMON 注册请求，不保证实例当前存活。实例可能已崩溃，而监听器缓存未刷新。
- 运行
lsnrctl services，确认输出中对应 SID 的 “Service handler type” 是DEDICATED或SHARED；若为UNKNOWN，说明实例已掉线 - 用
sqlplus / as sysdba连上后立刻执行select instance_name, status from v$instance;—— 返回结果才可信，空结果或报错就是实例没起来 - 不要依赖 “能 ping 通监听端口” 或 “tnsping 能通” 来判断实例状态，它们只测监听器，不测数据库
真正卡住人的地方往往不是技术复杂度，而是诊断顺序错了：先查进程、再看日志、最后动参数。改完 ORACLE_SID 还不行？别急着重装或改 tnsnames.ora，去 alert_<sid>.log</sid> 里翻最后一屏——90% 的真实原因就藏在那里，比如磁盘满、控制文件路径错、归档日志目录不可写，这些比 SID 拼写错误更隐蔽，也更容易被忽略。
