ora-3113是后台进程崩溃后的表象，真正原因需查alert.log中其前几行的致命错误：如ora-07445（核心转储）、ora-27102（内存不足）、ora-19809（闪回区满）、ora-01991（密码文件失效）等，rac环境还需结合crs_stat和grid日志定位单节点或集群级故障。
ora-3113 几乎从不单独发生，它只是后台进程崩溃后的“遗言”——必须先查 alert.log，否则所有操作都是碰运气。
看 alert.log 里紧挨着 ORA-3113 的第一条致命错误
ORA-3113 本身不说明原因，真正线索藏在它前面几行。常见组合有：
-
ORA-07445+ core dump 地址 → 某个 Oracle 进程（如PMON、DBW0）遇到未处理异常，通常是 bug 或内存越界 -
ORA-27102: out of memory→memory_target或sga_target设得太大，系统物理内存或 swap 不足 -
ORA-19809/ORA-19804→db_recovery_file_dest_size耗尽，归档写不进闪回区，导致 LGWR 挂掉 -
ORA-01991: invalid password file→orapwd文件损坏或与当前SYS密码不一致，尤其在 RAC 多实例共用密码文件时容易出问题 - 直接出现
PID nnnn died或Instance terminated by <code>PMON, pid = ... → 实例已非正常终止，不是连接问题而是根本起不来
RAC 环境下必须确认是单节点还是全集群故障
别急着连数据库，先确认影响范围：
- 执行
crs_stat -t，看ora.<db>.db</db>和各ora.<inst>.inst</inst>状态是否为OFFLINE或反复INTERMEDIATE - 检查对应节点的
grid日志：$GRID_HOME/log/<hostname>/alert<hostname>.log</hostname></hostname>，确认 CRS 是否稳定 - 如果只有 1 个实例报 ORA-3113，而其他实例正常，重点查该节点的 OS 资源（内存、磁盘空间、ulimit）、
listener.ora配置是否指向本地 VIP、以及该实例的独立alert.log - 如果所有实例同时失败，优先排查共享存储（ASM diskgroup offline？OCR/Voting Disk 不可访问？）、网络心跳（
oifcfg getif确认私网接口配置）
针对常见诱因的快速验证和修复动作
根据 alert.log 线索，直奔核心检查点：
- 如果是内存不足（
ORA-27102）：立刻检查free -g和swapon -s；临时降低memory_target值（例如从 2G 改为 1.5G），再用srvctl start instance -d <db> -i <inst></inst></db>启动单实例 - 如果是闪回区满（
ORA-19809）：登录该实例（export ORACLE_SID=<inst></inst>），进rman target /执行crosscheck archivelog all; delete expired archivelog all;；若需立即释放空间，再加delete archivelog until time 'sysdate-1'; - 如果是密码文件失效（
ORA-01991）：确认当前实例使用的密码文件路径（show parameter remote_login_passwordfile+ls -l $ORACLE_HOME/dbs/orapw*），用orapwd file=<path> password=<sys_pwd> force=y</sys_pwd></path>重建，并同步到所有 RAC 节点相同路径 - 如果是防火墙中断长连接（应用端报 ORA-3113/3114）：在数据库侧启用 DCD，设置
sqlnet.ora中SQLNET.EXPIRE_TIME=10（单位分钟），确保小于防火墙空闲超时阈值
真正棘手的是 ORA-07445 类核心转储，它往往意味着 Oracle 已知 bug —— 此时 alert.log 里的 incident trace 文件名（如 ora_12345.trc）比任何猜测都重要，必须提取并比对 MOS 文档中的 Bug 号。忽略这一步，重装或调参都只是拖延时间。
