SQLPlus登录卡住通常因数据库内部阻塞，首查alert.log中ORA-19815（FRA满）或“RVWR is stuck”线索；若无alert日志，用v$diag_info或ps/grep定位路径；遇ORA-00600/ORA-07445须查MOS并分析trace文件；最后排查OS级问题如OOM、硬件错误或SELinux拦截。
SQLPlus登录卡住，先看alert日志有没有ORA-19815或RVWR stuck
实例启动挂起、sqlplus / as sysdba无响应，十有八九不是网络或密码问题，而是数据库内部进程被阻塞。最常见的是闪回恢复区（fra）爆满，导致rvwr进程卡死，进而拖垮整个实例启动流程。
直接去翻alert_<instance_name>.log</instance_name>，重点搜这两类线索：
-
ORA-19815：明确提示db_recovery_file_dest_size已100%用满，剩余空间为0 -
Recovery Writer (RVWR) is stuck：说明闪回日志写不进去，实例无法完成启动阶段的恢复初始化 - 往上翻几屏，常能看到
Unable to allocate flashback log of XXX blocks这类具体失败描述
别急着删归档——如果存在guaranteed restore point，闪回日志不能自动清理，必须先DROP RESTORE POINT再腾空间。
找不到alert日志？用v$diag_info查真实路径，别硬猜$ORACLE_BASE
很多人在$ORACLE_BASE/diag/rdbms/...下死磕，结果发现目录不存在，是因为实例根本没成功启动，diag目录可能压根没建出来；或者用了Flex ASM、多租户，路径结构变了。
更可靠的方式是用已有连接（比如另一个能连上的实例，或刚启动一半的实例）执行：
SELECT value FROM v$diag_info WHERE name = 'Diag Trace';
返回值就是alert_*.log所在的准确目录。如果连这个都执行不了，就退一步，用系统命令找：
-
ps -ef | grep pmon看到pmon_<sid>进程，确认$ORACLE_SID -
echo $ORACLE_BASE和echo $ORACLE_HOME确认基础环境 - 然后拼路径：
$ORACLE_BASE/diag/rdbms/<db_unique_name>/<instance_name>/trace/alert_<instance_name>.log
注意：db_unique_name不一定等于ORACLE_SID，尤其在Data Guard环境中，别直接替换。
看到ORA-00600或ORA-07445，立刻停在那行，别往下扫
这类内部错误不是警告，是Oracle内核抛出的严重异常。它们后面通常跟着一长串参数，比如ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1], [2], [123456789], []，这些参数就是定位根因的关键指纹。
此时要做的不是“继续看日志”，而是：
- 复制整行错误（含所有方括号里的参数）
- 去My Oracle Support搜这个错误号+第一组参数，90%以上都有官方文档（Note）说明触发条件和修复步骤
- 别自己瞎猜“是不是内存不够”或“是不是磁盘坏了”，
ORA-00600 [kcratr_nab_less_than_odr]几乎只发生在控制文件损坏或崩溃恢复异常时 - 如果日志里紧跟着
Errors in file ... .trc，那个trace文件名就是下一步要看的后台跟踪文件
跳过它直接看后面几百行日志，大概率错过唯一线索。
跟踪文件里出现*** SESSION ID:(XX.XX) 2026-03-29T08:45:22.123，说明问题出在会话级而非实例级
当alert日志里没报错，但SQLPlus就是连不上，就要怀疑是不是某个关键后台进程（如LMD、LMS）挂了，或者RAC节点间心跳中断。这时候光看alert.log不够，得找对应进程的trace文件。
从alert日志里找到类似这样的行：
Errors in file /oracle/app/oracle/diag/rdbms/wind2/wind2/trace/wind2_lmd0_12345.trc
打开这个.trc文件，开头的*** SESSION ID或*** 2026-03-29T...时间戳，说明这是某个后台进程在那个时刻崩溃或卡死的快照。重点关注：
- 最后几行的
----- Call Stack Trace -----，看卡在哪一行函数（比如ksfmsync、kjmxon） - 是否有
waiting for 'gc cr block busy'这类等待事件，指向RAC资源争用 - 是否反复出现
IPC send timeout，暗示节点间网络或心跳异常
这类问题往往不报错，但会让实例“活着却动不了”，必须结合trace才能确诊。
最麻烦的情况是alert日志干净、所有trace文件也无异常，但实例就是起不来——这时候要检查操作系统层面：/proc/meminfo是否OOM Killer干掉了Oracle进程，dmesg -T有没有硬件报错，或者SELinux/AppArmor是否拦截了Oracle的共享内存操作。日志只是入口，不是全部。
