RAC 一个节点 CPU 直接打满，idle 掉到 0、Load Average 飙到 138，现场第一反应永远是："上 Top SQL！"------可顺着 OS PID 追到 Oracle Session，又看到满屏的 i/o slave wait，执行计划却个个正常。
这条线索把"SQL 把 CPU 打满"的假设直接推翻了：SQL 没毛病，是 Oracle 在调异步 I/O 时，被 Linux 内核的 AIO 资源卡了脖子。
真相在 /proc/sys/fs/aio-nr里：aio-nr=65520几乎贴着 aio-max-nr=65536 的天花板，io_submit 开始失败。
这篇 Oracle 19c RAC 实战，带你走完"OS→进程→Session→内核"的完整证据链。
01
故障背景
某生产环境采用 Oracle Database 19c RAC 架构，共有两个 RAC 节点。
业务运行一段时间后，突然出现：
-
应用访问数据库明显变慢；
-
部分业务SQL执行时间明显增加；
-
RAC 整体业务响应变慢；
-
其中一个 RAC 节点 CPU 使用率接近 100%；
-
OS Load Average 持续升高；
-
数据库侧大量会话出现 I/O 相关等待。
现场第一反应通常是：CPU 100% → 是否存在高CPU SQL？
但经过逐层排查发现，真正的问题并不是 SQL 执行计划异常，而是Oracle 数据库异步 I/O 所依赖的 Linux AIO 内核资源接近耗尽。
02
第一现场：RAC节点 CPU 100%
首先从操作系统层面确认问题。
典型现场：
可以看到：
说明该节点 CPU 基本处于满负荷状态。
此时不能直接得出：数据库CPU消耗过高。
因为 CPU 100% 只是现象，还需要继续确认到底是什么进程消耗CPU。
03
第二步：确认到底是谁消耗CPU
执行：
或者：
重点观察 Oracle 进程。
典型现场：
进一步查看：
发现大量 CPU 消耗来自：
此时可以确定：CPU压力主要来自 Oracle 数据库进程。
但是这里仍然不能马上认定是 SQL CPU 消耗。
04
第三步：从 OS PID 定位 Oracle
Session
Oracle 19c RAC 中，可以根据 OS PID 找到对应的数据库会话。
首先查看：
例如：
这样就完成了：
这一步非常重要。
因为 DBA 不能只看到：
就直接去优化 SQL。
必须继续往 Oracle 内部追。
05
第四步：检查等待事件
进一步检查当前会话：
如果现场出现大量 I/O 相关等待，例如：
那么诊断方向就发生变化。
现在的问题已经不是："哪个 SQL 把 CPU 打满？"
而应该变成："为什么大量 Oracle 会话在进行 I/O 的同时，Oracle 进程出现异常的 CPU 消耗？"
06
第五步：不要看到等待事件就直接
优化SQL
此时选择几个 CPU 使用率较高的 Oracle 进程进行分析。
根据 PID 定位：
发现这些 Session 对应的 SQL 比较类似。
于是最容易产生一个误判：是不是这个 SQL 本身存在性能问题？
于是进一步检查 SQL。
07
第六步：检查 SQL 执行计划
Oracle 19c 可以通过：
重点关注：
-
执行计划是否发生变化；
-
是否出现全表扫描；
-
是否存在异常Nested Loop；
-
实际行数与估算行数是否严重偏差；
-
Buffer Gets；
-
Physical Reads；
-
A-Time；
-
Starts；
-
是否存在大量临时表空间操作。
例如：
从执行计划来看：
-
SQL本身执行路径合理；
-
行数估算基本正常；
-
索引访问正常；
-
没有明显的执行计划异常；
-
单次SQL执行时间并不高。
因此可以暂时排除：单纯由于执行计划异常导致CPU 100%。
08
第七步：开始怀疑Oracle I/O
机制
此时需要换一个思路。
现场出现：
那么需要继续检查：Oracle执行I/O的时候发生了什么？
Oracle 19c 在 Linux 平台上通常会使用异步 I/O 等机制。
因此需要检查 Oracle I/O 相关参数。
例如：
继续检查：
例如：
这说明 Oracle 正在使用异步 I/O。
09
第八步：检查Oracle Trace中的
AIO异常
这一步是整个案例最关键的转折点。
针对异常 Oracle Process，可以使用：
然后：
并获取 Trace 文件位置：
Oracle 19c 中也可以结合 ADR 查看：
例如：
在 Process State / Trace 中发现类似异常信息：
此时整个问题开始清晰起来：
10
第九步：检查Linux AIO资源
继续从操作系统检查：
以及：
例如现场：
可以看到：
说明系统当前可用的异步 I/O 资源已经非常紧张。
这与 Oracle Trace 中出现的：
以及：
能够形成完整的证据链。
11
第十步：形成最终根因
至此可以排除几个常见方向：
不是单纯CPU不足
虽然表现为：
但 CPU 高并不是根因。
不是单条SQL执行计划异常
检查多个高CPU会话对应的 SQL 后：
-
执行计划正常；
-
SQL本身执行效率正常；
-
没有发现明显的计划突变；
-
没有发现异常的全表扫描或笛卡尔积。
不是单纯磁盘IO慢
如果只是存储性能下降，通常应该重点观察：
以及：
但本案例最关键的证据并不是磁盘响应时间，而是：
12
最终根因
最终定位为：Oracle 19c RAC节点所在Linux操作系统的异步I/O资源配置不足，AIO资源接近耗尽，导致Oracle异步I/O请求受到限制，进一步引发Oracle进程异常处理和大量I/O相关等待，最终表现为RAC节点CPU异常升高、系统Load持续升高以及业务响应变慢。
整个故障链条可以总结为：
13
处理方案
首先确认当前参数：
临时调整：
检查：
确认：
然后持续观察：
同时观察：
以及 Oracle：
重点确认：
14
永久配置
如果确认调整后的参数能够解决问题，需要写入系统配置。
例如：
执行：
确认：
实际生产环境中，具体参数值不能机械照搬，需要结合：
-
Oracle实例数量；
-
RAC节点数量；
-
并发Session；
-
数据库I/O规模；
-
存储架构；
-
Oracle版本；
-
Linux内核版本；
-
当前 aio-nr 使用情况；
综合评估。
15
这个案例最值得DBA学习的地方
这个案例最大的价值，并不是记住：
而是学习故障定位思维。
很多 DBA 看到：
第一反应就是：
但这个案例说明：CPU 100%只是现象，不一定意味着SQL在消耗CPU。
正确的诊断路径应该是：
也就是说：DBA诊断性能问题，不能只盯着SQL，要建立"OS → Oracle进程 → Session → Wait Event → SQL → 内核资源"的完整证据链。
16
Oracle 19c RAC生产故障诊断
检查清单
出现"RAC节点CPU 100%"时，可以按照下面的顺序排查：
第一层：OS
确认：
第二层：RAC实例
确认到底是：
还是：
出现异常。
第三层：Session
第四层：Top SQL
第五层：执行计划
第六层：Oracle进程
根据 OS PID：
第七层：Process State
重点关注：
第八层：Linux内核资源
重点检查：
形成最终判断：
17
DBA最终应该记住的一句话
Oracle 19c RAC出现CPU 100%，不要看到CPU高就直接去找"高CPU SQL"。
真正成熟的排障方式是：先确认CPU是谁消耗的，再确认Oracle进程在干什么；再结合等待事件判断问题属于CPU、I/O、锁还是资源限制；最后把Oracle内部证据和OS层证据串起来。
本案例最终形成的证据链就是：
写在最后
这篇案例最该刻进 DBA DNA的一句话：CPU 100% 只是现象，不一定等于 SQL 在吃 CPU------先确认 CPU 被谁消耗，再看 Oracle 进程在等什么，最后把 Oracle 内部证据和 OS 内核资源串成一条链。
本例根因是 Linux AIO 配额（fs.aio-max-nr）耗尽，而 sysctl -w fs.aio-max-nr=1048576只是止血，具体值得按实例数 / RAC 节点 / 并发量重新评估，别照抄。
记住那个黄金排查顺序：OS → Oracle 进程 → Session → Wait Event → SQL_ID → 执行计划 → Process State → OS 内核资源。
看到 CPU 高就直奔 Top SQL，是最容易白忙活的诊断姿势。
作者介绍
大家好，我是刘峰，安丫科技创始人，一名专注数据库实战的技术讲师与顾问。
我拥有 Oracle OCM 和PostgreSQL ACE 双认证 ，同时是 PostgreSQL 中国分会官方授权讲师。
技术栈覆盖主流商业库Oracle、SQL Server、MySQL，开源库 PostgreSQL，以及国产数据库 OceanBase、达梦、瀚高等产品。
过去十余年，我深度参与了电信、金融、政务、制造、互联网等多个行业的数据库项目。
完整经历过从传统 Oracle、MySQL 架构向 PostgreSQL、分布式数据库、国产信创库的技术演进与迁移实战。
项目交付内容涵盖数据库安装部署、备份恢复、巡检监控、高可用建设、性能调优、版本升级、异构迁移以及运维规范建设等多个方向。
在性能优化与故障诊断方面，我积累了大量实战经验。
从慢查询诊断、执行计划分析、索引优化、参数调优，到故障根因定位、应急处理，能够快速定位问题并给出可落地的解决方案。
特别是在跨数据库平台的性能对比与优化适配上，形成了一套相对系统的方法论。
除项目交付外，我也长期投入企业数据库技术培训工作。
面向 DBA 团队、开发团队和运维团队开展专题课程，内容包括 PostgreSQL 运维与调优、Oracle 数据库管理、MySQL 性能优化、国产数据库迁移适配、SQL 调优方法论、故障案例分析等。
安呀智数据坊｜我们能做什么
无论你是业务系统的技术负责人，还是数据部门的第一响应人，我们都能为你提供可靠的支持：
- 数据库类型支持
Oracle / MySQL / PostgreSQL / SQL Server 等主流数据库
- 核心服务内容
性能优化 / 故障处理 / 数据迁移 / 备份恢复 / 版本升级 / 补丁管理
- 系统性支持
深度巡检 / 高可用架构设计 / 应用层兼容评估 / 运维工具集成
- 专项能力补充
定制课程培训 / 甲方团队辅导 / 复杂问题协作排查 / 紧急救援支持
【安呀智数据坊·应急响应中心】
数据库故障往往发生在那 1% 的不可控时刻。
如果你正面临生产库崩溃、误操作导致数据丢失，且通过常规手段无法解决，请直接联系我们。
服务承诺： 我们秉承**"问题解决为先，方案闭环为本"**的服务理念。
安全底线： 全程签署企业级保密协议（NDA），保障数据安全是我们的第一铁律。
技术支援： 拥有 Oracle ACE 专家带队的"十五年数据库急诊"团队。
END

本文涉及关键词：
Oracle 19c RAC、CPU 100%、aio-max-nr、aio-nr、Linux AIO、异步 I/O、io_submit failed、i/o slave wait、oradebug processstate、fs.aio-max-nr、RAC 节点 CPU、gv$session、等待事件、内核资源耗尽、Oracle 性能诊断