ora-01034和ora-27101是同一故障链的表里表现，根本原因是oracle实例未启动或启动失败；需优先检查ora_pmon进程、alert日志、共享内存配置（/dev/shm、kernel参数）、启动参数合法性及dbstart脚本执行结果。
ora-01034 和 ora-27101 通常不是两个独立问题，而是同一故障链的前后表现
ora-01034（oracle not available）是客户端看到的表层错误，真正根源几乎总是 ora-27101（shared memory realm does not exist）——说明 oracle 实例根本没起来，或者启动后异常退出了。别急着改 tnsnames.ora 或重连客户端，先确认实例是否真在运行。
实操建议：
- 用
ps -ef | grep ora_查看是否有ora_pmon_<sid></sid>进程存在；没有就说明实例没启动或已崩溃 - 检查
$ORACLE_HOME/diag/rdbms/<sid>/<sid>/trace/alert_<sid>.log</sid></sid></sid>，重点看最后几条 ERROR 或 ORA- 开头的记录，90% 的真实原因藏在这里（比如内存不足、参数错误、磁盘满） - 别依赖
sqlplus / as sysdba能连上就认为 OK——如果实例未启动，它会进到空闲的 SQL*Plus 环境，SELECT status FROM v$instance;会报 ORA-01012（not logged on），这才是关键信号
检查 init.ora 或 spfile 启动参数是否合法，尤其 memory_target 和 sga_target
这两个参数设得太大但系统物理内存或 /dev/shm 不够，是 ORA-27101 最常见原因。Oracle 启动时尝试分配共享内存段失败，直接退出，不写任何进程，也不留 trace。
实操建议：
- 临时改用 pfile 启动：用
create pfile='/tmp/init_test.ora' from spfile;导出，手动注释掉memory_target、sga_target、pga_aggregate_target，只保留最小必要参数（db_name、control_files）再试startup nomount - 确认
/dev/shm大小：运行df -h /dev/shm，Oracle 11g+ 默认要求至少等于memory_target；若不足，临时扩容用sudo mount -o remount,size=4G /dev/shm - 注意 Linux kernel 参数：
kernel.shmall和kernel.shmmax必须 ≥ 实例所需共享内存总量，否则内核直接拒绝分配
监听器正常 ≠ 实例正常，别被 lsnrctl status 的“READY”误导
lsnrctl status 显示某个服务状态为 READY，只代表监听器曾经收到过该实例的注册请求，并不保证它现在还活着。实例可能已在注册后几秒内崩溃，而监听器缓存未刷新。
实操建议：
- 执行
lsnrctl services，看输出里对应SID的 “Service handler type” 是否还有 “DEDICATED” 或 “SHARED”；如果只有 “UNKNOWN”，说明实例已掉线 - 用
sqlplus / as sysdba连上后立刻执行select instance_name, status from v$instance;—— 如果报 ORA-01012 或查不到数据，就是实例没运行 - 不要依赖
tnsping：它只测监听器网络通不通，和实例生死无关
数据库自动启动失败时，systemd 或 init.d 脚本常静默跳过错误
很多运维把 dbstart 加进开机脚本，但该脚本遇到启动失败默认不报错、不退出，导致你以为它启动了，其实什么都没干。
实操建议：
- 手动运行
$ORACLE_HOME/bin/dbstart $ORACLE_HOME，观察终端输出，重点关注最后一行是不是 “Database instancexxxstarted.”；如果不是，往上翻找 ORA-xxxx 错误 - 检查
$ORACLE_HOME/bin/dbstart脚本里是否设置了ORACLE_HOME_LISTNER，且该路径下listener.ora配置正确——旧版dbstart会因找不到监听器而放弃启动实例 - systemd 用户应检查
systemctl status oracle-rdbms输出，看Active:是否为active (exited)而非active (running)，后者才表示服务进程仍在后台存活
最易被忽略的一点：alert 日志里出现 ORA-27101 后，往往紧跟着一条 “Starting ORACLE instance (normal)” 的日志，但它没写成功启动的后续——这意味着实例在 allocate shared memory 阶段就跪了，连初始化参数校验都没过完。盯住 alert 日志里那句 “Starting” 后面有没有 “Real OS Memory: …” 或 “Memory Manager initialized” 才算真正起步。
