Oracle应急处理：IO等待严重，数据库业务响应慢

小亦智能运维
212 阅读3分钟

这篇文章开始小亦平台会额外给大家科普一些Oracle数据库的应急处理方案

，运维朋友们可以在应急处理方案专栏查看更多案例。

问题概述

  • 核心问题： 数据库业务响应缓慢。

  • 主要现象：

    • IO 读写负载高。
    • 磁盘 TPS (每秒事务处理量) 高。
    • 系统出现显著的 IO 等待 (%iowait 过高)。

  • 影响： 数据库操作延迟，用户体验或业务流程受阻。

问题分析

数据库响应慢且伴随高 IO 活动，核心问题通常在于磁盘子系统无法及时满足数据库的读写请求，导致进程在等待 IO 操作完成上耗费大量时间。具体分析步骤如下：

  1. 确认系统级IO瓶颈：

    • 使用 iostat -c 2 30 检查 %iowait。该值过高（通常持续超过 10-20%）是系统层面存在 IO 瓶颈的直接证据，表明 CPU 空闲时间主要是在等待磁盘 IO。
    • 使用 iostat -k 2 30 检查磁盘的 读写量 (TPS, KB/s)。对比存储设备正常的性能指标范围，判断当前的读写压力是否超出了磁盘的承载能力。

  2. 定位数据库内部IO等待源：

    • 生成关键报告：

      • 创建当前快照：exec dbms_workload_repository.create_snapshot('TYPICAL');
      • 生成 AWR 报告 (@?/rdbms/admin/awrrpt)：提供指定时间段内数据库整体性能概览，重点关注 Top Timed Events 部分，确认 db file sequential read (单块读，常关联索引访问)、db file scattered read (多块读，常关联全表扫描)、direct path read/write、log file sync 等与 IO 相关的等待事件是否占据主导地位及其严重程度。
      • 生成 ASH 报告 (@?/rdbms/admin/ashrpt)：提供近实时的会话级活动采样（默认最近1小时），用于精确定位在问题时间点哪些具体 SQL、会话(SID)、对象正在经历高 IO 等待。这是识别“罪魁祸首”会话的关键。

  3. 分析问题会话与事务：

    • 通过 ASH/AWR 报告确定高 IO 等待的 SID (会话 ID)。
    • 查询该会话的长时间操作状态：
COLUMN operation FORMAT A40 Trunc
select substr(opname,1,40) operation, SOFAR/TOTALWORK current_per,
to_char(START_TIME,'MON dd HH24:MI:SS') start_time,
to_char(LAST_UPDATE_TIME,'MON dd HH24:MI:SS') LAST_UPDATE_TIME,
TIME_REMAINING, ELAPSED_SECONDS
from v$session_longops
where sid = &sid;
  • 检查该会话的事务状态（特别是考虑终止会话时）：
select a.sid, a.serial *#, a.username, b.used_urec, b.used_ublk*
from v$session a, v$transaction b
where a.saddr = b.ses_addr and a.sid = &sid;

关注点： used_ublk (使用的回滚块数)。如果值很大，强行终止会话 (kill session) 会导致事务回滚，可能产生长时间的 undo 应用（回滚），期间仍会消耗 IO 资源并阻塞相关资源。

解决方案与优化建议

  1. 应急处理 (终止问题会话 - 谨慎评估后执行)：

    • 目标： 立即终止导致异常高 IO 的源头会话，快速缓解系统压力。

    • 决策依据：

      • 结合 ASH 报告确认该会话是问题主因。
      • 评估 v$session_longops 中的预估剩余时间：如果非常长或不可接受，考虑终止。
      • 评估 v$transaction.used_ublk：如果很大，需权衡立即终止带来的回滚 IO 消耗与让会话继续执行消耗的 IO 和时间。若会话操作本身异常且回滚时间相对可接受，仍可选择终止。

    • 终止方法 (按推荐优先级排序)：

a)  最佳(应用层关闭):在应用服务器定位并关闭发起问题会话的应用程序。影响最小，但定位可能复杂，需应用团队配合。

b)  次选(OS层Kill):

     查询会话的 OS 进程 ID (SPID): select spid from v$process where addr in (select paddr from v$session where sid=&session_id);

    在数据库服务器操作系统层面执行: kill -9 <SPID>

    优点: 清除效率较高，PMON 能较快启动清理。 风险 : 极低概率引发数据库崩溃。

c)  最后选择(数据库层Kill):

     查询会话的 SID 和 SERIAL#: select sid, serial# from v$session where sid=&sid; (或结合事务查询)

     执行: alter system kill session '<SID>,<SERIAL#>' immediate;

    优点: 纯数据库操作。 缺点: 资源释放依赖 PMON，可能较慢；同样有极低崩溃风险。

终止后操作：

为已终止的会话生成专门的 ASH 报告：

su - oracle
sqlplus “/ as sysdba”
@?/rdbms/admin/ashrpti.sql

根据提示输入sid生成报告，深挖根本原因（如具体 SQL、访问对象）。

点击即刻前往小亦知识库查看应急预案完整版：www.ces-xiaoyi.com.cn/#/welcome/k…

运维工作中遇到难题？立即提交工单：www.ces-xiaoyi.com.cn/#/workOrder… 小亦平台工程师火速响应，助您快速修复故障!

avatar
文章
阅读
粉丝