一次Oracle的非正常关闭

数据库自己会关闭吗？

从现象来说Oracle MySQL Redis等都会出现进程意外停止的情况。而这些停止都是非人为正常关闭或者暴力关闭（abort或者kill 进程）

一次测试环境的非关闭

一般遇到这种情况先看一下错误日志吧。

2025-06-01T06:26:06.352576+08:00
PMON (ospid: ): terminating the instance due to ORA error
2025-06-01T06:26:06.374973+08:00
Cause - ‘Instance is being terminated due to fatal process death (pid: 14, ospid: 118685, DBRM)’
2025-06-01T06:26:06.968910+08:00
System state dump requested by (instance=1, osid=118660 (PMON)), summary=[abnormal instance termination].
System State dumped to trace file /u01/oracle/diag/rdbms/uatsoc/uatsoc/trace/uatsoc_diag_118680.trc
2025-06-01T06:26:12.505063+08:00
Instance terminated by PMON, pid = 118660

从字面翻译：由于进程死亡，实例正在终止。这里提到一个关键字DBRM。按说应该是Oracle资源管理器（Oracle Database Resource Manager，简称DBRM）管理数据库的资源分配。那么一般都是CPU、IO和内存之类的。就去这些看看。
从trace文件中看到一开始（一般外国人的产品思维先把重要的写在前面）

俗话说：事情出现之前都有先兆（我说的）

• 通常这种情况下我会先看一下出问题之前的最近的AWR

• 第一个等待事件非常少见。Failed Logon Delay这个异常一般都是因为有自动或者定时任务的程序使用的用户名和密码错误引起的。只能猜测不停地连接，而Oracle为了防止暴力破解，每次输入错误，会延迟下一次输入的时间。这个就行手机密码错了，然后要再多一段时间才行。但是一般来说不至于说登录密码错误多了就导致数据库奔溃。

  

• 似乎内存分配的多了一点。SGA和PGA占了物理内存86%左右。这是出问题前30分钟的AWR后面就没有生成了。

• 

• 只能靠ASH看看有没有进一步的信息。
  select session_type,event,session_state from dba_hist_active_sess_history t where t.SAMPLE_TIME>to_date(‘2025-06-01 06:00’,‘yyyy-mm-dd hh24:mi’) and t.SAMPLE_TIME<to_date(‘2025-06-01 06:26’,‘yyyy-mm-dd hh24:mi’)

• 结果大致是这样的：

• 

• PX Deq: Join ACK这个我没有专门研究过，直到现在依然发现还有很多不懂的。

• 以我个人愚见：这些进程自动死亡（trace中的确写了很多进程死掉了）

• 那么为什么进程死掉？结合刚才说的错误等待和内存占用高，可能是内存不足？

• 查找message日志

  

看到这里的确是oom被系统kill了。还提到了swap用完了。

• 当然这本身和分配过大有关。
• 为什么要分配这么大？因为测试环境的SQL质量不高，SGA和PGA都有很高的占用

记录一下这个案例

• 给数据库分配内存过大是迁就
• 根本上还是要SQL治理