昨天帮助一个网友处理了一个数据库异常宕机的问题，简单记录一下。
说到这个问题，也是一位网友给我发邮件说有一个数据库环境，会突然出现宕机的情况，想让我帮忙分析一下问题的原因。我一听这个问题就来了兴趣。大大小小的宕机问题也接触了不少，这个问题还是值得探究的。
我首先得到了这位朋友提供的alert日志。简单看了下，近期没有发现什么明显的异常信息。但是看到日志中去年的时候，有这样的一段内容。Mon Sep 19 14:38:17 2016
WARNING: Heavy swapping observed on system in last 5 mins.
pct of memory swapped in [3.30%] pct of memory swapped out [0.61%].
Please make sure there is no memory pressure and the SGA and PGA
are configured correctly. Look at DBRM trace file for more details.
Mon Sep 19 15:54:50 2016
在这之后，这类信息就没有出现过。
最近的一次宕机相关的日志如下：
Thu Feb 02 02:00:00 2017
Closing scheduler window
Closing Resource Manager plan via scheduler window
Clearing Resource Manager plan via parameter
Thu Feb 02 02:05:39 2017
PMON (ospid: 29552): terminating the instance due to error 471
Thu Feb 02 02:05:39 2017可以看出核心进程PMON是因为异常原因终止的，也就导致了所谓的宕库。
通过上面的信息，我心里已经有了一个大概的方向，那就是这个环境没有开启大页，存在大量的swap争用。通过启动日志看到，SGA的设置不高，服务器配置比较低，所以资源使用也比较紧张，至于宕库原因很可能是因为内存资源不足导致的，如果没猜错就是oom-killer的情况。
所以我让这位朋友去看看系统日志的情况，是否存在oom-killer的情况，没过多久，看到反馈的截图，证明了第一步猜测是正确的了，确实是oom-killer导致的。
这样一来问题的原因就比较明显了，内存资源不足，并发症就是存在大量的swap.
在这位网友的协助下，我登录到了远程端查看,可以看到当前的swap已经非常高了，机器配置不高。
Mem: 8062100k total, 7922104k used, 139996k free, 164460k buffers
Swap: 4128760k total, 3872660k used, 256100k free, 5414088k cached但是8G的内存分配了2G的SGA也不至于导致oom-killer啊。
查看了具体的环境，发现这个服务器上运行着另外的几套数据库，而根据初步的估算，4套数据库的SGA平均设置都是2G~4G,这样一来SGA就把内存占满了，还不包括PGA的设置，所以这是一种过载的配置，系统资源就那么些，配置太高，反而给系统造成了一种误导，导致在/tmp目录下生成了大量的文件。
这类文件能不能删，绝对不能直接删除，否则会导致宕库的情况发生，而怎么杜绝问题呢，就是调整SGA的大小，控制在一个相对合理的范围内，因为这是一个测试环境，所以SGA设置为1G也是可以接受的。多个数据库使用的SGA就不会溢出，调整PGA使得控制在一个相对合理的范围内。
然后我设置了内核参数来调整大页，整个过程需要重启数据库，先设置参数生效，然后逐个验证。
调整之后，根据我对问题的跟进，目前来看系统的资源情况是得到了合理控制，/tmp下也没有生成大量的临时文件。
我想这个问题应该不会再发生了。