1. 项目概述当Oracle服务器CPU持续满载最近在线上巡检时发现一台核心数据库服务器的CPU使用率长时间维持在100%系统响应变得异常缓慢业务方已经开始抱怨查询超时。这种“CPU打满”的情况对于任何DBA或运维工程师来说都是一个需要立即响应的严重警报。它不像偶尔的尖峰可以忽略持续的100%占用率意味着系统资源已被耗尽正在排队处理请求随时可能导致服务雪崩。这个问题并不罕见但排查起来却像一场“全科会诊”需要从操作系统、数据库实例、SQL语句乃至应用逻辑等多个层面进行系统性分析。盲目地重启数据库或者杀掉几个进程往往只能暂时缓解无法根治甚至可能引发更严重的数据一致性问题。今天我就结合这次实际的排查经历梳理出一套从外到内、由表及里的标准化排查流程。无论你是刚接触Oracle的新手还是经验丰富的DBA这套方法都能帮你快速定位到CPU资源的“元凶”。2. 排查思路与整体设计建立系统性诊断框架面对CPU 100%的告警切忌一头扎进海量的数据中。一个清晰的排查框架能让你事半功倍。我的核心思路是遵循“先整体后局部先外部后内部”的原则将整个排查过程划分为四个层次。2.1 分层诊断模型第一层是操作系统层。这是最外部的视角我们需要确认CPU高负载是否确实由Oracle进程引起还是其他系统进程如病毒、备份任务、其他应用造成的。同时检查系统的基础资源如内存和I/O因为它们的瓶颈常常会以CPU高负载的形式表现出来。第二层是Oracle实例层。确认是Oracle的问题后我们需要进入数据库内部查看整个实例的健康状态。重点在于识别是哪些后台进程、服务器进程或并行进程在消耗资源以及实例级别的等待事件是否指向了特定的资源争用。第三层是会话与SQL层。这是定位问题的关键。我们需要找出是哪些具体的数据库会话Session在疯狂消耗CPU并捕获这些会话正在执行的SQL语句。一条糟糕的SQL足以拖垮整个数据库。第四层是应用与逻辑层。找到问题SQL后工作并未结束。我们需要分析SQL为何低效——是缺少索引、统计信息过时还是业务逻辑本身就有缺陷如笛卡尔积、循环调用。这一层往往需要与开发人员协同。2.2 核心工具选型与理由工欲善其事必先利其器。在Linux环境下我主要依赖以下工具组合操作系统监控top/htop,vmstat,pidstattop命令是快速查看整体CPU使用情况和进程排名的首选。使用top -c可以显示完整的命令行方便识别Oracle进程。htop是top的增强版交互性更好支持树状视图查看进程关系。vmstat 2 5每2秒采样一次共5次可以查看系统范围的CPU、内存、I/O状态帮助判断是否存在系统级瓶颈。pidstat -u -p PID 2 5可以针对特定进程如Oracle的ora_dbw0_等监控其详细的CPU使用情况用户态、内核态。Oracle动态性能视图V$SESSION,V$PROCESS,V$SQL,V$SESSION_LONGOPS这些视图是Oracle提供的“内窥镜”可以实时查看会话、进程、SQL的执行状态。它们是连接操作系统进程和数据库逻辑操作的桥梁。Oracle诊断工具ASH报告、AWR报告ASH (Active Session History)相当于数据库的“飞行记录仪”每秒采样一次活动会话的信息。当问题正在发生时ASH报告是定位当前性能问题的利器它能告诉你过去一段时间内会话在“等待”什么以及CPU时间花在了哪里。AWR (Automatic Workload Repository)是数据库的“体检报告”每小时自动生成一次快照。当问题发生在过去某个时段例如凌晨的批处理任务AWR报告可以通过对比问题时段和正常时段的快照系统性地分析负载变化、TOP SQL、等待事件等找到根本原因。选择这些工具的原因在于它们构成了一个从实时到历史、从宏观到微观的完整证据链。操作系统命令提供硬件资源消耗的“硬证据”Oracle动态视图提供实时的“现场线索”而ASH/AWR报告则提供用于深度归因的“历史档案”。3. 实操过程四步定位CPU消耗元凶下面我将详细拆解这次排查的具体步骤。假设我们通过监控系统发现oraclesvr01这台服务器的CPU使用率在过去一小时内持续在95%以上。3.1 第一步操作系统层初步定位首先通过SSH登录服务器使用top命令进行全局观察。top -c -u oracle使用-u oracle参数过滤出Oracle软件属主的进程能快速聚焦。在top的输出中我们重点关注%Cpu(s)行看us用户态和sy内核态的占比。如果us很高通常是应用或数据库逻辑计算如果sy很高可能是系统调用频繁比如大量的I/O等待导致的上下文切换。进程列表查看哪些进程的%CPU列数值最高。很可能会看到多个名为oracle_后台进程或ora_jxxx_作业进程的进程或者一个名为oracle服务器进程的进程独占大量CPU。例如我们发现一个PID为6879的进程持续占用近40%的CPU其命令显示为oracleORCL (LOCALNO)。这是一个来自远程连接的专用服务器进程。注意LOCALNO代表这是一个来自远程客户端连接的专用服务器进程。如果看到大量此类进程且CPU都很高可能意味着应用层存在并发问题或低效SQL被频繁执行。为了更精确地分析这个进程我们使用pidstatpidstat -p 6879 2 5这个命令会每2秒采样一次该进程的CPU使用详情共5次可以观察其消耗是持续性的还是间歇性的。同时运行vmstat 2 5观察r运行队列列的值。如果该值持续超过CPU核心数例如8核服务器r值长期大于8说明有进程在排队等待CPU系统已经过载。操作系统层结论确认高CPU主要由Oracle数据库进程引起并记录下消耗最高的几个Oracle进程的PID。3.2 第二步数据库实例层关联与会话定位拿到了操作系统层的PID例如6879我们需要在数据库内部找到对应的会话Session和它正在执行的SQL。连接到Oracle数据库使用SQL*Plus或任何客户端以DBA身份执行以下查询SELECT s.sid, s.serial#, s.username, s.program, s.machine, p.spid AS OS PID, s.sql_id, s.event, s.state, s.seconds_in_wait, sq.sql_text FROM v$session s JOIN v$process p ON s.paddr p.addr LEFT JOIN v$sql sq ON s.sql_id sq.sql_id WHERE p.spid 6879; -- 替换为实际的OS PID这个查询是关键的一步它通过V$PROCESS和V$SESSION的关联将操作系统的进程号SPID映射到数据库内部的会话SID, SERIAL#并同时抓取该会话当前正在执行的SQL ID (SQL_ID) 和等待事件 (EVENT)。结果解读如果EVENT列显示CPU used或ON CPU说明这个会话正在消耗CPU进行计算。如果EVENT列显示其他等待事件如db file sequential read但CPU依然很高则可能是该会话在“CPU计算”和“I/O等待”间快速切换整体上表现出高CPU。SQL_ID和SQL_TEXT直接告诉我们罪魁祸首是哪条SQL语句。如果上述查询没有结果可能进程是后台进程或者想查看所有正在消耗CPU的会话可以使用这个查询SELECT s.sid, s.serial#, s.username, s.sql_id, sq.sql_text, s.machine, s.program, ROUND(p.value / 1000000, 2) AS CPU Used (Sec) FROM v$session s, v$sesstat p, v$statname n, v$sql sq WHERE s.sid p.sid AND p.statistic# n.statistic# AND n.name CPU used by this session AND s.sql_id sq.sql_id() AND p.value 10000000 -- 筛选出CPU使用超过10秒的会话 ORDER BY p.value DESC;3.3 第三步深入分析问题SQL与执行计划通过第二步我们大概率已经捕获到了导致高CPU的SQL_ID例如gxpk8vahyk04s。下一步就是深入分析这条SQL。首先获取SQL的完整文本和执行计划-- 获取SQL文本 SELECT sql_text FROM v$sql WHERE sql_id gxpk8vahyk04s; -- 获取该SQL最近的执行计划可能需要特定会话的SQL_ID和CHILD_NUMBER SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(gxpk8vahyk04s, NULL, ALLSTATS LAST));分析执行计划时要像侦探一样寻找线索全表扫描TABLE ACCESS FULL这是最常见的性能杀手。对于大表全表扫描会消耗巨大的CPU和I/O资源。检查是否因为缺少索引、索引失效或SQL写法导致优化器无法使用索引。错误的连接顺序或连接方式例如该用HASH JOIN的地方用了NESTED LOOPS且驱动表很大会导致循环次数爆炸。低效的操作如SELECT *、在WHERE条件中对字段使用函数WHERE UPPER(name)...、隐式类型转换等都会阻止索引使用。笛卡尔积CARTESIAN JOIN由于连接条件缺失或错误导致两个表直接做笛卡尔积数据量呈乘积级增长瞬间耗尽CPU。并行执行PX失控如果SQL使用了并行执行执行计划中出现PX相关操作但并行度DOP设置过高或者多个并行SQL同时运行会瞬间抢光所有CPU资源。实操心得很多时候直接看执行计划可能不够直观。一个更有效的方法是对比“好”与“坏”的执行计划。如果AWR报告显示该SQL在历史某个时段执行很快可以尝试用DBMS_XPLAN.DISPLAY_AWR来获取历史执行计划进行对比看看是否执行计划发生了突变Plan Change这通常是由于统计信息过时或绑定变量窥视Bind Peeking导致。3.4 第四步生成与解读ASH/AWR报告对于复杂问题或者需要分析一段时间内的整体情况ASH和AWR报告是不可或缺的。生成ASH报告针对最近15-30分钟的问题-- 连接到数据库后运行以下脚本通常位于$ORACLE_HOME/rdbms/admin目录下 -- 在SQL*Plus中执行 ?/rdbms/admin/ashrpt.sql根据提示输入报告格式html、开始时间和持续时间例如最近15分钟。报告会清晰列出Top Events最主要的等待事件是什么。Top SQL消耗CPU/等待时间最多的SQL。Top Sessions最活跃的会话。Activity Over Time活动随时间的变化图。生成AWR报告针对历史时段如凌晨2点-4点的问题?/rdbms/admin/awrrpt.sql需要输入开始和结束的快照ID可以通过查询DBA_HIST_SNAPSHOT视图获得。AWR报告内容更全面重点看Load Profile对比两个快照间的负载变化。Top 5 Timed Foreground Events这是报告的精华直接告诉你数据库在“等”什么。SQL Statistics-SQL ordered by CPU Time这里列出了消耗CPU时间最多的SQL是定位问题的直接证据。Segment Statistics看看是否有表或索引经历了异常多的物理读。重要提示解读AWR报告时不要孤立地看一个数据。例如高“CPU Time”可能源于SQL本身也可能是因为“Buffer Busy Waits”或“Latch Free”等等待事件导致会话在持有CPU旋转spin等待。需要结合多个章节综合判断。4. 常见根因与针对性解决方案根据以上排查我们通常能将问题归为以下几类并采取相应措施4.1 SQL效率低下这是最常见的原因占比超过70%。解决方案优化SQL重写SQL避免全表扫描确保索引被正确使用。使用绑定变量减少硬解析。添加/优化索引根据执行计划和查询条件创建合适的组合索引。注意索引维护开销。更新统计信息对相关表执行DBMS_STATS.GATHER_TABLE_STATS为优化器提供准确的数据分布信息。使用SQL Profile或SPM对于执行计划不稳定的SQL可以考虑使用SQL Profile固定一个高效的执行计划或使用SQL Plan Management (SPM) 来防止计划退化。4.2 并发与资源争用多个会话同时执行或竞争同一资源。解决方案调整应用逻辑优化业务代码减少不必要的数据库调用使用连接池并控制并发线程数。使用队列对于高并发的更新操作考虑使用Advanced Queue (AQ) 进行排队处理削峰填谷。调整初始化参数检查SESSION_CACHED_CURSORS,OPEN_CURSORS等参数是否过小导致频繁的软解析/硬解析消耗CPU。4.3 数据库内部问题Bug或缺陷某些Oracle版本可能存在已知的Bug会导致特定操作CPU异常。解决方案查询My Oracle Support (MOS)根据错误号或现象寻找对应的补丁Patch。在测试环境验证后安排停机打补丁。递归调用过多例如频繁的DDL操作、审计日志写入、空间管理如自动扩展可能引发大量的递归SQL消耗CPU。解决方案通过ASH报告查看“Top SQL”中是否有很多递归SQL如INSERT INTO AUD$。可以适当调整审计策略或优化表空间管理使用统一区大小管理。4.4 系统与配置问题并行查询滥用PARALLEL_MAX_SERVERS设置过高或大量SQL被错误地提示使用并行。解决方案审查并修正使用/* PARALLEL */提示的SQL。在系统级或会话级合理设置PARALLEL_DEGREE_POLICY和PARALLEL_MIN_SERVERS/PARALLEL_MAX_SERVERS。资源管理器Resource Manager配置不当未对不同的用户组进行CPU资源限制导致某个批处理任务耗尽所有CPU。解决方案创建资源管理器计划为在线用户组和批处理用户组分配不同的CPU资源份额。5. 高级技巧与预防性措施排查并解决一次CPU问题后更重要的是建立预防机制。5.1 使用实时监控与自动化脚本可以编写一个Shell脚本定期如每分钟采集高CPU会话和SQL信息并记录到日志文件中便于事后分析。#!/bin/bash # 保存为 check_hcpu_session.sh ORACLE_SIDORCL export ORACLE_HOME/u01/app/oracle/product/19c/dbhome_1 export PATH$ORACLE_HOME/bin:$PATH LOG_FILE/tmp/hcpu_session_$(date %Y%m%d).log sqlplus -s / as sysdba EOF $LOG_FILE SET LINESIZE 200 PAGESIZE 1000 COLUMN CPU Used (Sec) FORMAT 999999.99 SELECT TO_CHAR(SYSDATE, YYYY-MM-DD HH24:MI:SS) AS Check Time, s.sid, s.serial#, s.username, s.sql_id, SUBSTR(sq.sql_text, 1, 100) AS sql_text_part, s.machine, ROUND(p.value / 1000000, 2) AS CPU Used (Sec) FROM v\$session s, v\$sesstat p, v\$statname n, v\$sql sq WHERE s.sid p.sid AND p.statistic# n.statistic# AND n.name CPU used by this session AND s.sql_id sq.sql_id() AND p.value 30000000 -- CPU使用超过30秒 AND s.username IS NOT NULL AND s.status ACTIVE ORDER BY p.value DESC; EOF echo ---------------------------------------- $LOG_FILE通过crontab定时运行此脚本可以建立一个简单的历史追踪档案。5.2 建立性能基线与告警定期收集AWR基线例如工作日的上午10点和下午3点各一份。当出现性能问题时将问题时段的AWR报告与基线报告对比可以快速发现异常。利用Oracle Enterprise Manager (OEM) 或第三方监控工具如Zabbix, Prometheus with Grafana设置CPU使用率的告警阈值例如持续5分钟超过85%并配置告警动作如自动抓取一次ASH报告并发送给DBA实现主动预警。5.3 定期健康检查清单将CPU高负载的排查思路固化为定期健康检查的一部分每日巡检快速查看top和V$SYSMETRIC视图中的CPU指标。每周回顾分析AWR报告中的“SQL ordered by CPU Time”前十名对新增的或消耗增长的SQL进行提前优化。版本与补丁管理关注MOS上关于CPUCritical Patch Update和性能相关补丁的发布信息。CPU占用率100%的排查是一个融合了操作系统知识、数据库原理和SQL优化经验的综合性工作。它没有一成不变的答案但有一套可循的方法。从操作系统进程定位到数据库会话从捕获问题SQL到分析执行计划最后结合ASH/AWR报告进行深度归因这套流程在实践中被反复验证是有效的。最关键的是养成系统性思考的习惯避免“头痛医头脚痛医脚”。每次解决一个棘手的性能问题都是对数据库理解更深一步的机会。把这次排查过程中的查询语句、分析思路记录下来形成你自己的“诊断手册”下次再遇到类似问题你就能更加从容不迫。