内存溢出（OOM，Out of Memory）一旦发生会导致数据库进程被系统 OOM Killer 强制终止，直接引发业务中断。数据库 OOM 的发生并非单一原因， 结合生产环境实战经验，本文将系统梳理 OOM 发生的常见情况、每种情况的核心诱因、典型表现及排查要点，为处置 OOM 故障提供参考。

一、OOM 定义

1.1 OOM定义

数据库 OOM，本质是服务器物理内存（或虚拟内存）被耗尽，系统无法为数据库进程分配足够的内存，进而触发 Linux 系统 OOM Killer 机制，强制终止占用内存较高的进程（含数据库进程），以释放内存保障系统基本运行。

二、发生oom时的典型现象：

2.1应用侧

查看应用服务日志，常见异常为“连接超时”“无法获取数据库连接”；

2.2数据库侧

在操作系统层面执行ps -ef|grep dms 命令查找数据库进程是否还在，若不在查看达梦告警日志（默认路径：DM_HOME/log/alert_实例名.log），搜索“Out of memory”“cannot allocate memory”等关键词，或者观察故障时间点是否在刷检查点时，告警日志出现突然中断、无输出的情况；

2.3操作系统侧

查看操作系统日志（一般位于/var/log下的）message搜索’kill’，明确看到“Out of memory: Killed process XXX (dmserver), Killed process YYY (第三方进程名)”的记录。【如图1、图2】

【图1】

【图2】

三、达梦数据库 OOM 常见发生情况

3.1情况一：第三方进程/系统进程异常

3.1.1 发生原因

数据库所在服务器上，第三方组件进程、系统自带进程出现异常（服务器上运行的某第三方系统进程出现未知异常，其内存占用量在短时间内呈指数级飙升，快速耗尽了服务器全部物理内存资源。当系统可用内存趋近于零时，OOM Killer 触发资源回收机制，该异常进程与占用内存较高的达梦数据库进程被同时终止。例如【图3】

【图3】

3.1.2 排查要点

1、优先查看系统日志（/var/log/message），定位被 OOM Killer 终止的所有进程，区分异常进程和数据库进程，同时查看massages日志中是否存在其他进程的报错，方便后续操作系统工程师后续排查。
2、通过 ps -aux --sort=-%mem、top 命令，查看内存占用最高的进程（若故障未复现，可通过系统日志回溯历史进程内存占用）；
3、验证：单独启停异常进程和达梦数据库，观察内存变化，确认异常进程是导致内存耗尽的唯一根源。

3.2情况二：达梦数据库内存参数配置不合理

3.2.1 发生原因

达梦数据库核心内存参数配置过高，超出服务器物理内存承载范围，或参数搭配不合理，导致数据库内存占用持续攀升，最终触发 OOM。核心涉及的参数包括：MEMORY_POOL：全局内存池，配置过高会直接占用大量物理内存；BUFFER：数据缓冲区，配置过高会挤占系统和其他进程内存；SORT_BUF_SIZE、JOIN_BUF_SIZE：单会话排序、连接缓冲区，配置过高会导致高并发场景下内存叠加耗尽；MAX_SESSIONS：最大并发会话数，配置过高会导致每个会话占用的内存叠加后超出总内存。原则上达梦数据库总内存占用建议不超过服务器物理内存的 80%，否则极易触发 OOM。

3.2.2 典型表现

系统侧：内存使用率持续处于 85% 以上，达梦 dmserver 进程内存占用长期居高不下，接近服务器物理内存上限；
数据库侧：达梦告警日志频繁出现“内存分配失败”，无明显第三方进程异常；通过 V$PARAMETER 视图查询，可见核心内存参数总和超出物理内存 80% 阈值；

3.2.3 排查要点

1、执行 SQL 查看核心内存参数：SELECT NAME, TYPE, VALUE FROM V$PARAMETER WHERE NAME IN ('MEMORY_POOL', 'BUFFER', 'MAX_SESSIONS', 'SORT_BUF_SIZE', 'JOIN_BUF_SIZE');查看是否配置的合理，【如图4】

【图4】
2、通过SQL:select (select sum(n_pages * page_size)/1024/1024 from v$bufferpool)||'MB' as BUFFER_SIZE ,( select sum(total_size)/1024/1024 from v$mem_pool)||'MB' as mem_pool,(select sum(n_pages * page_size)/1024/1024 from v$bufferpool) + (select sum(total_size)/1024/1024 from v$mem_pool)||'MB' as TOTAL_SIZE from dual;计算数据库总内存占用，判断是否超过服务器物理内存的 80%；如【图5】

【图5】
3、查看活跃会话数：SELECT COUNT(*) FROM V$SESSIONS WHERE STATUS='ACTIVE';，判断是否因会话过多导致内存叠加耗尽；
4、对比参数配置与服务器物理内存，定位是否存在配置过高的参数；

3.3情况三：高内存消耗 SQL/慢 SQL 堆积

3.3.1 发生原因

业务中存在高内存消耗 SQL（如无索引全表扫描、大表关联、超大结果集查询、多层嵌套子查询），或慢 SQL 长期堆积，导致数据库内存占用持续飙升，最终触发OOM。

3.3.2 典型表现

应用侧：特定业务执行时，出现“SQL 执行超时”“连接超时”或某个特定业务无法进行查询等，但是其他业务无明显异常；
系统侧：dmserver 进程内存占用短时间内快速攀升，高峰时达到物理内存上限，触发 OOM；
数据库侧：通过分析对应时间节点的SQLOG日志，可排查到执行时间长、内存占用高的 SQL；或通过复现场景定位到导致发生OOM问题的SQL，其他无明显第三方进程异常，内存参数配置合理。

3.3.3 排查要点

1、可以查询长时间执行的SQL：select * from (SELECT sess_id,sql_text,datediff(ss,last_recv_time,sysdate) Y_EXETIME,
SF_GET_SESSION_SQL(SESS_ID) fullsql,clnt_ip FROM
V$SESSIONS WHERE STATE = 'ACTIVE') where Y_EXETIME>=6;（可根据需要修改对应的Y_EXETIME时间，此处为6s）
2、可以查询高内存占用前5的SQL：select TOP 5 A.NAME,
A.creator,
A.sum_total_size_MB,
b.SESS_ID,
b.SQL_TEXT,
A.CJSJ
FROM (select MAX(NAME) NAME,
creator,
sum(total_size/1024.0/1024) sum_total_size_MB,
sysdate CJSJ
from v$mem_pool
group by creator) A
LEFT JOIN V$SESSIONS b
ON A.creator=B.THRD_ID
ORDER BY 3 DESC;
3、定位到问题SQL后，查看 SQL 执行频率，分析 SQL 执行计划：通过 EXPLAIN、EXPLAIN FOR 命令，查看 SQL 是否存在全表扫描、不合理排序、大表关联等问题，针对问题SQL再进行优化；

四、不同 OOM 情况的应急处置方案

无论何种情况引发的 OOM，核心目标是“快速恢复业务”，再排查根源。以下应急处置流程适用于所有 OOM 场景，可尽快完成业务恢复。

4.1 紧急止损

1、终止异常进程：若为“第三方进程异常”“系统进程异常”，执行 kill -9 进程ID，快速释放内存；若为“高内存 SQL”，执行SP_CLOSE_SESSION(SESS_ID);，终止相关会话；
2、关闭非必要进程：终止服务器上无关的监控、日志采集等非核心进程，释放内存资源。

4.2 恢复数据库服务

1、检查数据库状态：进入到数据库的bin目录，执行./DmServiceXXXX status，确认数据库进程已终止；如【图6】

【图6】
2、启动数据库服务：执行./DmServiceXXXX start ，启动数据库；如【图7】

【图7】
3、验证数据库可用性：登录达梦数据库，执行 SELECT STATUS FROM V$INSTANCE;，确认数据库状态为“OPEN”；同时执行核心业务 SQL，验证数据库可正常读写。

五、不同 OOM 情况的长效防控策略

策略一：部署前进行性能测试和内存泄漏检测，确认其内存占用稳定；
策略二：强化进程监控：将第三方进程、系统进程的内存占用、运行状态纳入监控体系，设置内存异常飙升告警；
策略三:规范参数配置：遵循“达梦总内存不超过物理内存 80%”的原则，合理配置 MEMORY_POOL、BUFFER 等参数；
策略四：常态化巡检：每周检查内存参数配置，对比服务器物理内存，及时发现内存使用异常情况；
策略五：建立 SQL 审核机制：业务上线前，对 SQL 进行执行计划分析，禁止或优化占用高内存查询的操作；
策略六：监控 SQL 执行、常态化优化 SQL，实时监控长会话和慢 SQL，每周排查慢 SQL 日志和高内存消耗 SQL，对问题SQL进行优化；