OA数据库服务器内次异常增长问题分析

# OA数据库服务器内次异常增长问题分析

## 一、问题描述

时间：2025/08/18 09:17

服务器：10\.7\.8\.8

问题概述：数据库服务器的oracle数据库服务被中断，导致OA系统不可用

## 二、问题分析

1、 服务器资源分析(服务器的cpu/内存/磁盘读写在1\-2分钟内全部跑满)

![](/media/202508/20250820145614464501.png)

（CPU）

![](/media/202508/20250820145614480026.png)

(内存)

![](/media/202508/20250820145614489224.png)

（磁盘io）

2、 数据库告警日志分析：oracle KSRPMON进程异常，数据库连接KSRPMON超时，直接导致数据库宕掉,

![](/media/202508/20250820145614498496.png)

（告警日志：9点10\+分时间段的日志信息）

![](/media/202508/20250820145614508781.png)

（告警日志：宕机后发生数据块异常告警）

3、 数据库服务器系统日志分析： OOM杀掉了oracle/edr/alicloud等的部分进程（KSRPMON进程）

![](/media/202508/20250820145614517317.png)

（dmesg分析）

![](/media/202508/20250820145614525523.png)

（OS messages日志)

4、资源跑高原因分析

1\) EDR原因排查：基本排除

EDR内存耗用排查：深信服反馈EDR软件使用内存几十兆左右；

EDR内存泄漏可能性排查:无泄漏![](/media/202508/20250820145614533663.png)

2\)ORACLE数据库排查：当时服务器top 5进程皆为oracle进程

![](/media/202508/20250820145614540778.png)

(2025/08/18 09:13:45 top 5 进程)

3\)AWR报告分析：sql\_id\=’[**2q36jkyj2u7rm**](file:///C:\Users\XUM\Desktop\awrrpt_1_41082_41083.html#2q36jkyj2u7rm)’ 在执行时间/cpu使用率等耗用较高（该值取自数据库8点\-9点数据库快照，9点\-10点快照因数据库中断原因无法获取）

![](/media/202508/20250820145614552092.png)![](/media/202508/20250820145614560477.png)![](/media/202508/20250820145614568510.png)

以上，问题复盘如下：

1. **源头 (09:10 AM)**：应用端**高负载操作**（很可能是sql\_id\=’[2q36jkyj2u7rm](file:///C:\Users\XUM\Desktop\awrrpt_1_41082_41083.html#2q36jkyj2u7rm)’）开始运行，它产生了海量的读写操作。
2. **I/O瓶颈 (09:10 AM)**：巨大的读写流量瞬间淹没了磁盘 **vdb** 的I/O处理能力。
	* 磁盘利用率 %util 爆表（71%）。
	* I/O响应时间 await 飙升到灾难性的 **61毫秒**。
3. **系统僵死 (09:10 \- 09:14\)**：由于I/O是系统最慢的组件，I/O瓶颈导致：
	* **CPU**：因等待I/O完成而空闲。
	* **内存**：因Oracle进程无法及时将数据写入磁盘，脏数据在内存中堆积，可用内存逐渐耗尽。
	* **进程**：所有依赖I/O的进程（包括Oracle和EDR）都卡在等待状态。
4. **EDR崩溃 (09:14:57\)**：EDR进程 (edr\_agent) 在尝试执行文件扫描或系统调用时，因系统资源极度紧张（特别是I/O无响应）而**发生段错误**。它是系统僵死的**受害者**和**指示灯**。
5. **最终崩溃 (09:16:24\)**：内存最终被耗尽，触发OOM\-Killer，杀死Oracle关键进程，导致 ORA\-16198 和实例终止，并最终留下数据块损坏 ORA\-01578。

## 三、处理及总结

1、停用EDR：已完成

2、持续观察oracle数据库告警日志文件/系统日志messages：关闭EDR后，系统messages未发生edr 段错误，alert.log未发现ORA\-01578/ORA\-01110报错。

3、修复损坏的数据块：确定已修复,重建索引OA. IDX\_INFO\_READ\_US

![](/media/202508/20250820145614578719.png)

4、优化sql\_id\=[2q36jkyj2u7rm](file:///C:\Users\XUM\Desktop\awrrpt_1_41082_41083.html#2q36jkyj2u7rm):已完成，添加索引后可以大大降低该语句的资源消耗：

create index OA.IDX\_HRMRESOURCE\_WORKCODE on OA.HRMRESOURCE("WORKCODE");

create index OA.IDX\_HRMLEADERINFO\_EMP\_LECODE on OA.HRMLEADERINFO("employee\_code","leader\_code");

5、调整sql\_id\=[2q36jkyj2u7rm](file:///C:\Users\XUM\Desktop\awrrpt_1_41082_41083.html#2q36jkyj2u7rm)相关作业的执行时间：尽量避开早上8点半\-10点半时间段，该时间段为OA系统繁忙时间段，特别是每周一早上9点左右是最繁忙的时候，应尽量避开。

6、sql\_id\=[2q36jkyj2u7rm](file:///C:\Users\XUM\Desktop\awrrpt_1_41082_41083.html#2q36jkyj2u7rm)语句为全量更新全部人员的上级，该SQL每次执行35s左右，在8/18日早上8点\-9点之间累计执行了17次，9点\-10点之间执行次数不可统计：

UPDATE HRMRESOURCE D1

SET ( D1\.managerid ) \= (

SELECT H2\.ID AS managerid FROM HRMRESOURCE H JOIN HRMLEADERINFO L ON L."employee\_code" \= H.WORKCODE JOIN HRMRESOURCE H2 ON L."leader\_code" \= H2\.WORKCODE WHERE D1\.WORKCODE \= H.WORKCODE

)

WHERE D1\.WORKCODE IS NOT NULL