sql 2008服务器内存一直居高不下_经验之谈：内存问题造成数据库性能异常怎么破？...-CSDN博客

本文链接：https://blog.csdn.net/weixin_39969257/article/details/111339760

本文通过一个客户案例分析了SQL 2008服务器内存居高不下导致的数据库性能异常，主要表现为业务处理超时和log file sync等待事件。经过排查，发现是CVU的JAVA进程消耗大量内存，导致内存抖动和数据库卡顿。解决方案是暂停CVU服务，避免类似故障再次发生。

摘要由CSDN通过智能技术生成

作者：罗贵林

原文链接：https://mp.weixin.qq.com/s/2e5eKSoGlU9J4Rjq1zwLnw

导读：在使用数据库的过程中，内存不足常常会引起数据库异常。但是内存不足，又会为数据库带来哪些具体的影响呢？本次，我们将通过某客户现场数据库在某个时段内性能严重下降的案例来展示由于主机内存不足而造成数据库日志写入卡顿的问题分析过程。通过本案例，我们也可以对相关问题的分析方法及解决建议有一些深入的了解。

问题描述

2020年1月15号凌晨2点左右客户产线异常，应用后台消息报错业务处理超时。此外，在16号凌晨2点左右和下午2点左右，也发生业务处理超时，影响较大。

故障时段数据库的等待事件信息如下：

问题分析

查看数据库故障时间段的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一直减少。