导读：在使用数据库的过程中，内存不足常常会引起数据库异常。但是内存不足，又会为数据库带来哪些具体的影响呢？本次，我们将通过某客户现场数据库在某个时段内性能严重下降的案例来展示由于主机内存不足而造成数据库日志写入卡顿的问题分析过程。通过本案例，我们也可以对相关问题的分析方法及解决建议有一些深入的了解。本文出自《云和恩墨月技术通讯(2月刊)》，下载链接：https://www.modb.pro/doc/2249(复制到浏览器中打开或者点击左下角“阅读原文”)

问题描述2020年1月15号凌晨2点左右客户产线异常，应用后台消息报错业务处理超时。此外，在16号凌晨2点左右和下午2点左右，也发生业务处理超时，影响较大。故障时段数据库的等待事件信息如下：

问题分析

1. 查看数据库故障时间段的ash信息，可以看到确实在1：56~1：57分的时候，等待比较严重：select trunc(sample_time, 'mi'), count(1)

from gv$active_session_history

where sample_time >=  to_date('2020-01-16 01:50:00', 'yyyy-mm-dd hh24:mi:ss')

and sample_time < to_date('2020-01-16  01:59:00', 'yyyy-mm-dd hh24:mi:ss')

and event is not null

group by trunc(sample_time,  'mi')

order by 1;

2. 进一步分析等待事件，可以看到log file sync等待排名第一，而其他等待事件很少。因此主要是log filesync等待事件发了超时：select inst_id, event, count(1)

from gv$active_session_history

where sample_time >=

to_date('2020-01-16  01:50:00', 'yyyy-mm-dd hh24:mi:ss')

and sample_time <

to_date('2020-01-16  01:58:00', 'yyyy-mm-dd hh24:mi:ss')

and event is not null

group by inst_id, event

order by 1, 3 desc;

3.    进一步查看lgwr 的 trace，但没有发现异常信息。4.    继续查看log file sync等待信息，可以看到都是被同一条SQL的会话阻塞。该SQL对应的文本为insert into xxx……，是用于业务写日志的语句，体现在应用日志上就是卡在进程刚开始的时候超时的执行。5.    由于告警日志和LGWR TRACE里都没有异常信息，于是我们可以查看那条SQL的执行情况，发现故障时点每次执行时间变长了。

6.    继续查询故障时段log file sync、LGWR wait for redo copy等待事件直方图信息。从这条insert sql执行历史信息，调用次数并没有突增的情况，但是log filesync/LGWR wait for redo copy等待抖动比较严重：

根据故障处理经验来判断，LGWR抖动比较严重，怀疑物理IO出现了问题。7.    分析排查物理IO问题，IO没看到异常情况，所以在这里排除了IO引起的日志写入抖动的问题。8.    查询故障时段SQL占用CPU排名的情况

而该sql_id的sql_text则是：

对故障时间点的ASH报告进行分析，故障时间点这个select 1 from dual占用的cpu最高，这个sql一般是weblogic等中间件测试连接池连接用的，一般不会引起CPU的使用问题，且总体CPU使用率并没有撑满。故在这里可以排除CPU使用影响的情况，由于这套数据库平时内存的使用率就是98%左右，只剩2G空闲内存，而故障时点，只剩几百兆内存。因此，分析到这里基本可以定位是内存消耗过高引起的问题，这里考虑到触发故障的时间点有高度规律性，于是考虑可能是由于一些定时任务引起的，于是检查了crontab，job定时任务、备份等，但都没发现有故障时间的运行的信息。这个时候考虑数据库主机层面上定时任务和进程分析一些信息，由于以前出现故障的时候，有让客户开启oswatch采集，故这次也同样从osw中top的采样时间进行检查，且最终发现在异常时osw的采样时间也变长了，说明故障出现的时候整个操作系统都有受影响。9.    查看osw中ps的信息

将osw采样的时间加大到42秒的和正常15秒内的两个时间进行比对，可以发现故障出现的事件点内，多出来的一个进程是CVU的JAVA进程。故怀疑是cvu的java进程对主机的内存造成了大量的消耗。查看cvu的运行日志，可以看到cvu是6小时执行一次，而在1：56和13:56的时候主机确实都运行了这个进程。当然，cvu服务停用并不影响数据库实例正常使用，只是在运行cluvfy时有调用到，而在01:56:25~01:57:07这个中间系统中是卡着的，且内存的free一直减少。

从vmstat上看，也验证了异常时主要是内存问题，交换空间页面切换和系统调用次数也在加大。

综合以上的分析，可以确认是cvu定时调用导致内存消耗过大，而内存本身就不足，在调用的那一瞬间引起了数据库主机内存抖动，引起了数据库主机的卡顿，临时处理方法是停止cvu服务，在之后的跟踪中没有发现同样的故障发生，故障处理完成。cvu定时任务是集群软件调用cvu工具定时检查集群运行状态，记录到日志文件中的。它的运行导致现有服务器内存资源过于紧张，导致几乎所有进程都变慢。

问题解决本次案例出现的主要原因是由于cvu定时任务进程的调用导致现有服务器内存资源过于紧张，引起了数据库主机内存抖动，造成数据库卡顿。临时处理方法是停止cvu服务，在之后的跟踪中没有发现同样的故障发生，故障处理完成。

提示：在处理数据库问题时，很多时候主机的相关性能信息及计数信息可以帮我们更精准的定位问题，譬如内存使用信息、当前进程信息、网络计数信息等，尤其是RAC集群中。在过往的多个案例中，也很大程度上利用了Oracle osw工具采集的主机性能信息。因此，强烈建议在数据库主机上尽量部署osw工具，以便在出故障之后更好的定位根因。