转载

远程协助解决异常宕库的问题(r11笔记第75天)

  昨天帮助一个网友处理了一个数据库异常宕机的问题,简单记录一下。

  说到这个问题,也是一位网友给我发邮件说有一个数据库环境,会突然出现宕机的情况,想让我帮忙分析一下问题的原因。我一听这个问题就来了兴趣。大大小小的宕机问题也接触了不少,这个问题还是值得探究的。

   我首先得到了这位朋友提供的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导致的。

远程协助解决异常宕库的问题(r11笔记第75天)

    这样一来问题的原因就比较明显了,内存资源不足,并发症就是存在大量的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下也没有生成大量的临时文件。

    我想这个问题应该不会再发生了。




正文到此结束
Loading...