1. 问题引入当Oracle服务器的CPU持续“高烧不退”如果你负责运维Oracle数据库最不想看到的系统告警之一大概就是“CPU使用率100%”了。这就像汽车的发动机转速表一直顶着红线不仅意味着系统正在超负荷运转随时可能“开锅”更预示着业务响应会变得极其缓慢甚至完全停滞。我经历过不少这样的紧急时刻半夜被电话叫醒登录服务器一看CPU占用率那条线稳稳地贴在100%的位置心里咯噔一下就知道今晚又是个不眠夜。CPU满载本身不是问题问题是它背后隐藏的原因。是某个SQL语句突然“发疯”还是系统资源被异常进程抢占是数据库内部机制出现了死锁循环还是操作系统层面有“不速之客”盲目重启虽然可能暂时缓解但无异于掩耳盗铃问题大概率会卷土重来。因此一套系统化、高效的排查思路是每个DBA数据库管理员必须掌握的“急救术”。今天我就结合多次实战踩坑的经验梳理出一套从宏观到微观、从操作系统到数据库内部的完整排查流程。这套方法不仅能帮你快速定位到“元凶”更能让你理解其背后的原理做到举一反三。我们不会只停留在“运行这个命令”的层面而是会深入探讨“为什么要运行这个命令”以及“看到结果后该如何分析”。2. 排查前的准备工作建立你的“诊断工具箱”在开始具体排查之前做好准备工作能让你事半功倍避免在紧张的处理过程中手忙脚乱。这就像医生出诊前必须检查听诊器、血压计是否完好一样。2.1 获取必要的访问权限和工具首先确保你拥有操作系统和数据库的足够权限。对于Linux/Unix服务器你需要root或具有sudo权限的账号来运行系统级监控命令。对于数据库你需要一个具有DBA角色或至少SELECT ANY DICTIONARY权限的账号以便查询性能视图。其次准备好你的“武器库”操作系统工具top/htop,vmstat,mpstat,pidstat,sar如果已安装sysstat包。htop比top更直观建议优先使用。数据库工具SQL*Plus 或你喜欢的图形化客户端如SQL Developer。确保你知道如何连接到数据库。监控与日志熟悉Oracle的告警日志Alert Log位置通常位于$ORACLE_BASE/diag/rdbms/db_name/instance_name/trace/alert_instance_name.log。这是发现数据库自身问题的第一现场。2.2 建立性能基准与快照意识在问题发生前如果你有系统正常时的性能基准数据如AWR报告、操作系统sar历史数据那将是无比珍贵的对比资料。如果没有也不用慌。关键在于在开始排查时有意识地为当前状态“拍照”。一个重要的方法是在开始深入排查前立即生成一个Oracle的AWR自动工作负载仓库报告覆盖过去一小段时间例如最近15分钟。即使问题持续这个报告也能捕捉到问题发生时的负载特征。命令如下在SQL*Plus中执行-- 首先获取快照ID SELECT MIN(snap_id) begin_snap, MAX(snap_id) end_snap FROM dba_hist_snapshot WHERE begin_interval_time SYSDATE - 30/1440; -- 最近30分钟 -- 假设得到的begin_snap1000, end_snap1001然后生成报告 ?/rdbms/admin/awrrpt.sql执行后会提示你选择报告格式html或text输入快照范围即可生成报告。这个报告我们稍后会详细分析。注意生成AWR报告需要Oracle诊断包Diagnostics Pack的许可。如果你的环境没有购买此许可可以使用ASH活动会话历史报告或AWR的替代方案如手动查询V$SESSION、V$SQL等动态性能视图但信息量和便捷性会打折扣。3. 第一现场勘查操作系统层面定位资源消耗者当CPU告警响起我们首先需要登上服务器从操作系统的视角看看是哪些进程在“兴风作浪”。这一步的目标是快速区分问题是数据库进程引起的还是操作系统其他进程如病毒、备份软件、异常应用导致的。3.1 使用 top/htop 进行全局观察运行top命令然后按下数字1可以展开显示所有CPU核心的占用情况。这是你的第一张“全景X光片”。你需要重点关注以下几列%CPU: 进程的CPU使用率。持续接近100%的单个进程是首要怀疑对象。PID: 进程ID。USER: 进程所有者。如果看到大量oracle用户的进程占用CPU那么问题很可能出在数据库内部。COMMAND: 命令名称。对于Oracle你可能会看到ora_、oracle后台进程、LOCALNO服务器进程通常对应客户端连接等。htop提供了更友好的彩色界面和树状视图可以更直观地看到进程关系。如果发现某个oracle进程CPU异常高记下它的PID。3.2 深入进程内部pidstat与CPU时间分解top给了我们目标pidstat则可以提供更精细的“病理分析”。使用以下命令针对可疑的Oracle进程PID例如12345进行采样pidstat -p 12345 1 5这个命令会以1秒为间隔连续采样5次输出该进程的详细CPU使用情况。关键指标是%usr用户态CPU时间和%system内核态CPU时间高 %usr通常意味着进程正在繁忙地执行应用程序代码。对于Oracle来说这很可能是一个正在疯狂进行逻辑读Buffer Gets、计算或排序的SQL语句。高 %system意味着进程频繁进行系统调用比如等待I/O、申请内存、进程调度等。在Oracle中这可能暗示着大量的物理读Disk Reads、日志文件同步log file sync等待或者闩锁Latch争用。如果%system占比异常高就需要结合数据库等待事件进一步分析。3.3 排查非数据库因素在聚焦Oracle之前务必排除“环境干扰”其他用户进程top中是否有非oracle用户的高CPU进程可能是系统备份、文件扫描、编译任务等。系统进程ksoftirqd、kworker等内核线程偶尔也会因中断处理或特定驱动问题导致CPU高。如果它们持续过高可能需要检查硬件或驱动。CPU就绪队列使用vmstat 1命令观察r就绪队列长度列。如果该值持续超过CPU核心数例如8核服务器r持续大于8说明有大量进程在排队等待CPU系统已经严重过载需要找出是哪些进程在产生这么多可运行任务。上下文切换vmstat中的cs上下文切换次数列如果异常高也会消耗大量CPU。过多的上下文切换可能源于过多的活跃进程或不当的进程调度策略。实操心得我遇到过一种情况top显示一个oracle进程CPU很高但用pidstat细看其%system占了80%。顺着这个线索最后发现是存储阵列出现间歇性延迟导致该进程在等待db file sequential read单块读事件时频繁陷入内核态从等待中唤醒后立刻又去执行造成了CPU忙的假象。根本原因在I/O子系统而非SQL本身。4. 深入数据库腹地定位罪魁祸首的SQL与会话当确认高CPU消耗来自Oracle进程后我们的战场就转移到了数据库内部。目标是找到正在执行或刚刚执行完的、消耗大量CPU资源的SQL语句和会话。4.1 实时抓取高负载会话连接到数据库查询当前活动会话视图V$SESSION和V$PROCESS的关联信息SELECT s.sid, s.serial#, s.username, s.program, s.machine, p.spid as os_pid, -- 操作系统PID用于与top结果关联 s.sql_id, s.event, s.last_call_et as active_seconds, s.status FROM v$session s JOIN v$process p ON s.paddr p.addr WHERE s.type USER AND s.status ACTIVE AND s.last_call_et 1800 -- 只查最近30分钟内有活动的会话 ORDER BY s.last_call_et;这个查询能帮你快速找到哪些用户会话正处于ACTIVE状态以及它们正在等待什么事件event列。如果event是CPU used when call started或null且active_seconds很大那这个会话很可能就是CPU消耗大户。记下它的SID,SERIAL#和SQL_ID。更直接的方法是Oracle提供了一个内置脚本可以列出当前消耗资源最多的会话?/rdbms/admin/sqlash.sql -- 或者使用更详细的版本 ?/rdbms/admin/ashrpt.sqlsqlash.sql会提示你输入一个时间范围例如最近5分钟然后生成一个基于ASH的简易报告直接列出TOP SQL和TOP会话。4.2 剖析消耗CPU的SQL语句获取到可疑的SQL_ID后下一步就是深入分析这条SQL。为什么它这么“吃”CPU通常原因无外乎以下几点全表扫描Full Table Scan处理了大量不需要的数据行。低效的连接Join方式如笛卡尔积、嵌套循环连接驱动表过大。昂贵的排序SortORDER BY,GROUP BY,DISTINCT, 创建索引等操作在内存PGA不足时会进行磁盘排序Temp表空间I/O但排序过程本身也消耗CPU。函数滥用在WHERE条件中对列使用函数如TO_CHAR(column)...导致索引失效。错误的执行计划统计信息过时或缺失导致优化器选择了错误的执行路径。使用以下查询获取SQL的详细信息和执行计划-- 根据SQL_ID获取SQL文本 SELECT sql_text FROM v$sqltext WHERE sql_id sql_id ORDER BY piece; -- 获取该SQL的执行统计信息可能有多条子游标 SELECT sql_id, plan_hash_value, executions, elapsed_time/1e6 as elapsed_secs, cpu_time/1e6 as cpu_secs, buffer_gets, disk_reads, rows_processed FROM v$sql WHERE sql_id sql_id; -- 获取该SQL最新的执行计划 SELECT * FROM TABLE(dbms_xplan.display_cursor(sql_id));分析display_cursor的输出重点关注执行计划的行估算Rows是否与实际A-Rows严重不符这通常是统计信息问题的标志。是否存在TABLE ACCESS FULL连接方法HASH JOIN,NESTED LOOPS是否合理是否有SORT ORDER BY,WINDOW SORT等昂贵操作踩坑实录有一次一条报表SQL突然CPU暴增。查看执行计划发现一个原本应该走索引范围扫描的步骤变成了全表扫描。原因是该表在前一晚进行了大规模数据导入但导入后忘记收集统计信息。优化器还按照旧统计信息显示数据量很少认为全表扫描更快。收集统计信息后执行计划恢复正常CPU使用率立刻降了下来。4.3 利用AWR/ASH报告进行历史分析如果问题不是持续发生或者当你介入时高负载的会话已经结束实时查询就抓不到现场了。这时之前生成的AWR报告或者ASH报告就派上了大用场。AWR报告查看“SQL Statistics”部分特别是“SQL ordered by CPU Time”和“SQL ordered by Elapsed Time”。这里列出了在快照期间消耗CPU最多和运行时间最长的SQL。结合“Load Profile”部分看平均每秒的CPU使用、逻辑读/物理读等可以对系统负载有整体认识。ASH报告如果问题发生在几分钟内ASH报告比AWR更精细。它每秒采样一次活动会话能更精确地定位问题发生时间点的TOP等待事件和TOP SQL。生成命令为?/rdbms/admin/ashrpt.sql。在AWR报告中除了看TOP SQL还要关注“Instance Efficiency Percentages”中的Buffer Hit Ratio缓冲命中率。如果这个值很低例如低于90%说明大量数据需要从磁盘读取虽然这主要增加I/O等待但随之而来的数据块在Buffer Cache中的构造和管理也会增加CPU开销。5. 超越SQL系统级参数与内部争用排查有时候CPU高的根源不在某一条“坏”SQL而在于数据库整体的配置或内部资源争用。这就像交通拥堵不一定是因为某辆车开得慢而是因为道路设计不合理或信号灯失灵。5.1 检查数据库参数与资源配置一些关键的初始化参数设置不当会直接导致CPU利用率升高parallel_max_servers和parallel_min_servers如果并行查询Parallel Query被滥用或配置过高会瞬间创建大量并行进程榨干CPU。检查AWR报告中的“Parallel Statistics”部分或者查询V$PX_PROCESS_SYSSTAT视图看并行进程使用是否异常。processes和sessions设置过低会导致无法建立新连接设置过高则会增加内存和进程管理开销。虽然不直接导致高CPU但连接数暴增可能伴随大量低效SQL间接推高CPU。PGA管理如果pga_aggregate_target设置过小导致大量排序、哈希连接操作无法在内存中完成转而使用磁盘临时表空间会造成大量的direct path read/write temp等待同时排序和哈希运算本身也消耗CPU。cursor_sharing设置为FORCE或SIMILAR有时可以缓解硬解析问题但也可能导致执行计划不优增加CPU消耗。需要结合具体场景分析。5.2 识别内部争用Latch和MutexOracle使用闩锁Latch和互斥量Mutex来保护其共享内存结构如Buffer Cache、Library Cache的并发访问。当大量进程试图同时访问同一个受保护的结构时就会发生争用。进程会进入“自旋”spin状态在CPU上空转反复尝试获取锁这会导致CPU使用率飙升而实际工作进展缓慢。常见的相关等待事件包括latch: shared poollatch: library cachelatch: cache buffers chainsmutex waits查询V$LATCH或V$LATCHHOLDER视图可以查看闩锁争用情况。在AWR报告的“Wait Events”部分如果看到上述等待事件排名靠前并且平均等待时间很短说明进程很快通过自旋获得了锁但自旋消耗了CPU那么闩锁争用就很可能是高CPU的元凶。解决方案思路Shared Pool争用可能源于过多的硬解析。考虑使用绑定变量、调整shared_pool_size、刷新共享池谨慎操作或应用cursor_sharing。Cache Buffers Chains争用通常是因为热点块Hot Block。可能是某个索引的根块或分支块或者一个小表被频繁全表扫描。解决方法包括优化SQL减少逻辑读、使用反向键索引打散热点、考虑分区等。5.3 后台进程异常不要忽略Oracle的后台进程。例如CKPT检查点进程如果数据库有大量脏块需要写入检查点活动会加剧。DBWn数据库写进程同样频繁的写脏块会增加I/O和CPU。LGWR日志写进程如果提交非常频繁log file sync等待和LGWR的写活动也会增加。MMON/MMNL管理监控进程负责AWR快照和告警通常开销不大但异常时也需检查。可以通过top命令观察名为ora_开头的后台进程的CPU使用情况或者查询V$BGPROCESS视图。6. 系统性性能优化与根治策略找到并解决一个高CPU问题后更重要的是建立长效机制防止问题复发。这需要从开发、运维和架构多个层面入手。6.1 SQL审核与绑定变量强制使用很多CPU问题源于低效的SQL。建立严格的SQL审核机制在上线前对SQL进行评审和执行计划检查。在应用端强制使用绑定变量是减少硬解析、降低Library Cache Latch争用的最有效手段。对于Java应用确保使用PreparedStatement对于PL/SQL直接使用绑定变量语法。6.2 统计信息管理自动化与策略优化过时或缺失的统计信息是错误执行计划的罪魁祸首。确保对核心表、频繁变更的表设置合理的自动统计信息收集策略。Oracle默认的自动收集任务GATHER_STATS_JOB通常在维护窗口运行对于24小时运营的系统可能需要调整窗口时间或对关键表使用增量统计、并发收集等高级特性。对于超大规模的表可以考虑使用基于比例的估算ESTIMATE_PERCENT或仅收集关键列的统计信息以平衡准确性和收集开销。6.3 资源管理Resource Manager对于混合负载OLTP和报表并存的环境可以使用Oracle资源管理器Resource Manager来限制某些用户组或会话的资源使用。例如你可以创建一个“报表用户”消费组限制其最大并行度、CPU使用率或活动会话数防止其资源密集型查询拖垮整个OLTP系统。6.4 容量规划与监控告警CPU持续100%可能是一个单纯的容量问题。业务量增长了但硬件资源没有跟上。需要建立长期的性能容量规划监控CPU、内存、I/O的使用趋势在资源使用率达到警戒线如70%之前就提前扩容。建立完善的监控告警体系不仅监控CPU整体使用率更要监控关键指标数据库层面的每秒逻辑读Logical Reads、解析次数Parse Count、硬解析次数Hard Parses。等待事件中的CPU used when call started和其他TOP等待事件。设置针对单条SQL的CPU_TIME或BUFFER_GETS的阈值告警以便在问题扩大化之前就捕获到“坏”SQL。6.5 定期健康检查与AWR基线比对定期如每周或每月生成AWR报告并与一个“健康”时期的基线报告进行比对。关注关键指标的变化趋势如CPU时间占比、逻辑读/物理读比率、TOP SQL的变化等。这种趋势分析往往能提前发现潜在的性能退化问题。我自己在维护核心系统时会建立一个“黄金基线”即系统在业务平稳期、性能最佳时的一套AWR数据。之后任何时期的报告都会与之对比任何指标的显著恶化比如同一SQL的CPU时间增长50%都会触发深入调查。这种主动式的管理让我在用户抱怨之前就解决了很多性能隐患。排查Oracle的CPU高占用问题是一个从外到内、由表及里的系统性工程。它考验的不仅是DBA对Oracle内部机制的理解深度更是其结构化思维和问题分解的能力。从操作系统的进程观察到数据库会话和SQL的定位再到参数、争用等系统级原因的深挖每一步都需要严谨的分析和验证。记住没有“银弹”最有效的工具是你的经验和对系统行为的好奇心。每一次成功的排障不仅是解决问题的过程更是加深你对这个复杂而精密的数据库系统理解的过程。
1. 问题引入当Oracle服务器的CPU持续“高烧不退”如果你负责运维Oracle数据库最不想看到的系统告警之一大概就是“CPU使用率100%”了。这就像汽车的发动机转速表一直顶着红线不仅意味着系统正在超负荷运转随时可能“开锅”更预示着业务响应会变得极其缓慢甚至完全停滞。我经历过不少这样的紧急时刻半夜被电话叫醒登录服务器一看CPU占用率那条线稳稳地贴在100%的位置心里咯噔一下就知道今晚又是个不眠夜。CPU满载本身不是问题问题是它背后隐藏的原因。是某个SQL语句突然“发疯”还是系统资源被异常进程抢占是数据库内部机制出现了死锁循环还是操作系统层面有“不速之客”盲目重启虽然可能暂时缓解但无异于掩耳盗铃问题大概率会卷土重来。因此一套系统化、高效的排查思路是每个DBA数据库管理员必须掌握的“急救术”。今天我就结合多次实战踩坑的经验梳理出一套从宏观到微观、从操作系统到数据库内部的完整排查流程。这套方法不仅能帮你快速定位到“元凶”更能让你理解其背后的原理做到举一反三。我们不会只停留在“运行这个命令”的层面而是会深入探讨“为什么要运行这个命令”以及“看到结果后该如何分析”。2. 排查前的准备工作建立你的“诊断工具箱”在开始具体排查之前做好准备工作能让你事半功倍避免在紧张的处理过程中手忙脚乱。这就像医生出诊前必须检查听诊器、血压计是否完好一样。2.1 获取必要的访问权限和工具首先确保你拥有操作系统和数据库的足够权限。对于Linux/Unix服务器你需要root或具有sudo权限的账号来运行系统级监控命令。对于数据库你需要一个具有DBA角色或至少SELECT ANY DICTIONARY权限的账号以便查询性能视图。其次准备好你的“武器库”操作系统工具top/htop,vmstat,mpstat,pidstat,sar如果已安装sysstat包。htop比top更直观建议优先使用。数据库工具SQL*Plus 或你喜欢的图形化客户端如SQL Developer。确保你知道如何连接到数据库。监控与日志熟悉Oracle的告警日志Alert Log位置通常位于$ORACLE_BASE/diag/rdbms/db_name/instance_name/trace/alert_instance_name.log。这是发现数据库自身问题的第一现场。2.2 建立性能基准与快照意识在问题发生前如果你有系统正常时的性能基准数据如AWR报告、操作系统sar历史数据那将是无比珍贵的对比资料。如果没有也不用慌。关键在于在开始排查时有意识地为当前状态“拍照”。一个重要的方法是在开始深入排查前立即生成一个Oracle的AWR自动工作负载仓库报告覆盖过去一小段时间例如最近15分钟。即使问题持续这个报告也能捕捉到问题发生时的负载特征。命令如下在SQL*Plus中执行-- 首先获取快照ID SELECT MIN(snap_id) begin_snap, MAX(snap_id) end_snap FROM dba_hist_snapshot WHERE begin_interval_time SYSDATE - 30/1440; -- 最近30分钟 -- 假设得到的begin_snap1000, end_snap1001然后生成报告 ?/rdbms/admin/awrrpt.sql执行后会提示你选择报告格式html或text输入快照范围即可生成报告。这个报告我们稍后会详细分析。注意生成AWR报告需要Oracle诊断包Diagnostics Pack的许可。如果你的环境没有购买此许可可以使用ASH活动会话历史报告或AWR的替代方案如手动查询V$SESSION、V$SQL等动态性能视图但信息量和便捷性会打折扣。3. 第一现场勘查操作系统层面定位资源消耗者当CPU告警响起我们首先需要登上服务器从操作系统的视角看看是哪些进程在“兴风作浪”。这一步的目标是快速区分问题是数据库进程引起的还是操作系统其他进程如病毒、备份软件、异常应用导致的。3.1 使用 top/htop 进行全局观察运行top命令然后按下数字1可以展开显示所有CPU核心的占用情况。这是你的第一张“全景X光片”。你需要重点关注以下几列%CPU: 进程的CPU使用率。持续接近100%的单个进程是首要怀疑对象。PID: 进程ID。USER: 进程所有者。如果看到大量oracle用户的进程占用CPU那么问题很可能出在数据库内部。COMMAND: 命令名称。对于Oracle你可能会看到ora_、oracle后台进程、LOCALNO服务器进程通常对应客户端连接等。htop提供了更友好的彩色界面和树状视图可以更直观地看到进程关系。如果发现某个oracle进程CPU异常高记下它的PID。3.2 深入进程内部pidstat与CPU时间分解top给了我们目标pidstat则可以提供更精细的“病理分析”。使用以下命令针对可疑的Oracle进程PID例如12345进行采样pidstat -p 12345 1 5这个命令会以1秒为间隔连续采样5次输出该进程的详细CPU使用情况。关键指标是%usr用户态CPU时间和%system内核态CPU时间高 %usr通常意味着进程正在繁忙地执行应用程序代码。对于Oracle来说这很可能是一个正在疯狂进行逻辑读Buffer Gets、计算或排序的SQL语句。高 %system意味着进程频繁进行系统调用比如等待I/O、申请内存、进程调度等。在Oracle中这可能暗示着大量的物理读Disk Reads、日志文件同步log file sync等待或者闩锁Latch争用。如果%system占比异常高就需要结合数据库等待事件进一步分析。3.3 排查非数据库因素在聚焦Oracle之前务必排除“环境干扰”其他用户进程top中是否有非oracle用户的高CPU进程可能是系统备份、文件扫描、编译任务等。系统进程ksoftirqd、kworker等内核线程偶尔也会因中断处理或特定驱动问题导致CPU高。如果它们持续过高可能需要检查硬件或驱动。CPU就绪队列使用vmstat 1命令观察r就绪队列长度列。如果该值持续超过CPU核心数例如8核服务器r持续大于8说明有大量进程在排队等待CPU系统已经严重过载需要找出是哪些进程在产生这么多可运行任务。上下文切换vmstat中的cs上下文切换次数列如果异常高也会消耗大量CPU。过多的上下文切换可能源于过多的活跃进程或不当的进程调度策略。实操心得我遇到过一种情况top显示一个oracle进程CPU很高但用pidstat细看其%system占了80%。顺着这个线索最后发现是存储阵列出现间歇性延迟导致该进程在等待db file sequential read单块读事件时频繁陷入内核态从等待中唤醒后立刻又去执行造成了CPU忙的假象。根本原因在I/O子系统而非SQL本身。4. 深入数据库腹地定位罪魁祸首的SQL与会话当确认高CPU消耗来自Oracle进程后我们的战场就转移到了数据库内部。目标是找到正在执行或刚刚执行完的、消耗大量CPU资源的SQL语句和会话。4.1 实时抓取高负载会话连接到数据库查询当前活动会话视图V$SESSION和V$PROCESS的关联信息SELECT s.sid, s.serial#, s.username, s.program, s.machine, p.spid as os_pid, -- 操作系统PID用于与top结果关联 s.sql_id, s.event, s.last_call_et as active_seconds, s.status FROM v$session s JOIN v$process p ON s.paddr p.addr WHERE s.type USER AND s.status ACTIVE AND s.last_call_et 1800 -- 只查最近30分钟内有活动的会话 ORDER BY s.last_call_et;这个查询能帮你快速找到哪些用户会话正处于ACTIVE状态以及它们正在等待什么事件event列。如果event是CPU used when call started或null且active_seconds很大那这个会话很可能就是CPU消耗大户。记下它的SID,SERIAL#和SQL_ID。更直接的方法是Oracle提供了一个内置脚本可以列出当前消耗资源最多的会话?/rdbms/admin/sqlash.sql -- 或者使用更详细的版本 ?/rdbms/admin/ashrpt.sqlsqlash.sql会提示你输入一个时间范围例如最近5分钟然后生成一个基于ASH的简易报告直接列出TOP SQL和TOP会话。4.2 剖析消耗CPU的SQL语句获取到可疑的SQL_ID后下一步就是深入分析这条SQL。为什么它这么“吃”CPU通常原因无外乎以下几点全表扫描Full Table Scan处理了大量不需要的数据行。低效的连接Join方式如笛卡尔积、嵌套循环连接驱动表过大。昂贵的排序SortORDER BY,GROUP BY,DISTINCT, 创建索引等操作在内存PGA不足时会进行磁盘排序Temp表空间I/O但排序过程本身也消耗CPU。函数滥用在WHERE条件中对列使用函数如TO_CHAR(column)...导致索引失效。错误的执行计划统计信息过时或缺失导致优化器选择了错误的执行路径。使用以下查询获取SQL的详细信息和执行计划-- 根据SQL_ID获取SQL文本 SELECT sql_text FROM v$sqltext WHERE sql_id sql_id ORDER BY piece; -- 获取该SQL的执行统计信息可能有多条子游标 SELECT sql_id, plan_hash_value, executions, elapsed_time/1e6 as elapsed_secs, cpu_time/1e6 as cpu_secs, buffer_gets, disk_reads, rows_processed FROM v$sql WHERE sql_id sql_id; -- 获取该SQL最新的执行计划 SELECT * FROM TABLE(dbms_xplan.display_cursor(sql_id));分析display_cursor的输出重点关注执行计划的行估算Rows是否与实际A-Rows严重不符这通常是统计信息问题的标志。是否存在TABLE ACCESS FULL连接方法HASH JOIN,NESTED LOOPS是否合理是否有SORT ORDER BY,WINDOW SORT等昂贵操作踩坑实录有一次一条报表SQL突然CPU暴增。查看执行计划发现一个原本应该走索引范围扫描的步骤变成了全表扫描。原因是该表在前一晚进行了大规模数据导入但导入后忘记收集统计信息。优化器还按照旧统计信息显示数据量很少认为全表扫描更快。收集统计信息后执行计划恢复正常CPU使用率立刻降了下来。4.3 利用AWR/ASH报告进行历史分析如果问题不是持续发生或者当你介入时高负载的会话已经结束实时查询就抓不到现场了。这时之前生成的AWR报告或者ASH报告就派上了大用场。AWR报告查看“SQL Statistics”部分特别是“SQL ordered by CPU Time”和“SQL ordered by Elapsed Time”。这里列出了在快照期间消耗CPU最多和运行时间最长的SQL。结合“Load Profile”部分看平均每秒的CPU使用、逻辑读/物理读等可以对系统负载有整体认识。ASH报告如果问题发生在几分钟内ASH报告比AWR更精细。它每秒采样一次活动会话能更精确地定位问题发生时间点的TOP等待事件和TOP SQL。生成命令为?/rdbms/admin/ashrpt.sql。在AWR报告中除了看TOP SQL还要关注“Instance Efficiency Percentages”中的Buffer Hit Ratio缓冲命中率。如果这个值很低例如低于90%说明大量数据需要从磁盘读取虽然这主要增加I/O等待但随之而来的数据块在Buffer Cache中的构造和管理也会增加CPU开销。5. 超越SQL系统级参数与内部争用排查有时候CPU高的根源不在某一条“坏”SQL而在于数据库整体的配置或内部资源争用。这就像交通拥堵不一定是因为某辆车开得慢而是因为道路设计不合理或信号灯失灵。5.1 检查数据库参数与资源配置一些关键的初始化参数设置不当会直接导致CPU利用率升高parallel_max_servers和parallel_min_servers如果并行查询Parallel Query被滥用或配置过高会瞬间创建大量并行进程榨干CPU。检查AWR报告中的“Parallel Statistics”部分或者查询V$PX_PROCESS_SYSSTAT视图看并行进程使用是否异常。processes和sessions设置过低会导致无法建立新连接设置过高则会增加内存和进程管理开销。虽然不直接导致高CPU但连接数暴增可能伴随大量低效SQL间接推高CPU。PGA管理如果pga_aggregate_target设置过小导致大量排序、哈希连接操作无法在内存中完成转而使用磁盘临时表空间会造成大量的direct path read/write temp等待同时排序和哈希运算本身也消耗CPU。cursor_sharing设置为FORCE或SIMILAR有时可以缓解硬解析问题但也可能导致执行计划不优增加CPU消耗。需要结合具体场景分析。5.2 识别内部争用Latch和MutexOracle使用闩锁Latch和互斥量Mutex来保护其共享内存结构如Buffer Cache、Library Cache的并发访问。当大量进程试图同时访问同一个受保护的结构时就会发生争用。进程会进入“自旋”spin状态在CPU上空转反复尝试获取锁这会导致CPU使用率飙升而实际工作进展缓慢。常见的相关等待事件包括latch: shared poollatch: library cachelatch: cache buffers chainsmutex waits查询V$LATCH或V$LATCHHOLDER视图可以查看闩锁争用情况。在AWR报告的“Wait Events”部分如果看到上述等待事件排名靠前并且平均等待时间很短说明进程很快通过自旋获得了锁但自旋消耗了CPU那么闩锁争用就很可能是高CPU的元凶。解决方案思路Shared Pool争用可能源于过多的硬解析。考虑使用绑定变量、调整shared_pool_size、刷新共享池谨慎操作或应用cursor_sharing。Cache Buffers Chains争用通常是因为热点块Hot Block。可能是某个索引的根块或分支块或者一个小表被频繁全表扫描。解决方法包括优化SQL减少逻辑读、使用反向键索引打散热点、考虑分区等。5.3 后台进程异常不要忽略Oracle的后台进程。例如CKPT检查点进程如果数据库有大量脏块需要写入检查点活动会加剧。DBWn数据库写进程同样频繁的写脏块会增加I/O和CPU。LGWR日志写进程如果提交非常频繁log file sync等待和LGWR的写活动也会增加。MMON/MMNL管理监控进程负责AWR快照和告警通常开销不大但异常时也需检查。可以通过top命令观察名为ora_开头的后台进程的CPU使用情况或者查询V$BGPROCESS视图。6. 系统性性能优化与根治策略找到并解决一个高CPU问题后更重要的是建立长效机制防止问题复发。这需要从开发、运维和架构多个层面入手。6.1 SQL审核与绑定变量强制使用很多CPU问题源于低效的SQL。建立严格的SQL审核机制在上线前对SQL进行评审和执行计划检查。在应用端强制使用绑定变量是减少硬解析、降低Library Cache Latch争用的最有效手段。对于Java应用确保使用PreparedStatement对于PL/SQL直接使用绑定变量语法。6.2 统计信息管理自动化与策略优化过时或缺失的统计信息是错误执行计划的罪魁祸首。确保对核心表、频繁变更的表设置合理的自动统计信息收集策略。Oracle默认的自动收集任务GATHER_STATS_JOB通常在维护窗口运行对于24小时运营的系统可能需要调整窗口时间或对关键表使用增量统计、并发收集等高级特性。对于超大规模的表可以考虑使用基于比例的估算ESTIMATE_PERCENT或仅收集关键列的统计信息以平衡准确性和收集开销。6.3 资源管理Resource Manager对于混合负载OLTP和报表并存的环境可以使用Oracle资源管理器Resource Manager来限制某些用户组或会话的资源使用。例如你可以创建一个“报表用户”消费组限制其最大并行度、CPU使用率或活动会话数防止其资源密集型查询拖垮整个OLTP系统。6.4 容量规划与监控告警CPU持续100%可能是一个单纯的容量问题。业务量增长了但硬件资源没有跟上。需要建立长期的性能容量规划监控CPU、内存、I/O的使用趋势在资源使用率达到警戒线如70%之前就提前扩容。建立完善的监控告警体系不仅监控CPU整体使用率更要监控关键指标数据库层面的每秒逻辑读Logical Reads、解析次数Parse Count、硬解析次数Hard Parses。等待事件中的CPU used when call started和其他TOP等待事件。设置针对单条SQL的CPU_TIME或BUFFER_GETS的阈值告警以便在问题扩大化之前就捕获到“坏”SQL。6.5 定期健康检查与AWR基线比对定期如每周或每月生成AWR报告并与一个“健康”时期的基线报告进行比对。关注关键指标的变化趋势如CPU时间占比、逻辑读/物理读比率、TOP SQL的变化等。这种趋势分析往往能提前发现潜在的性能退化问题。我自己在维护核心系统时会建立一个“黄金基线”即系统在业务平稳期、性能最佳时的一套AWR数据。之后任何时期的报告都会与之对比任何指标的显著恶化比如同一SQL的CPU时间增长50%都会触发深入调查。这种主动式的管理让我在用户抱怨之前就解决了很多性能隐患。排查Oracle的CPU高占用问题是一个从外到内、由表及里的系统性工程。它考验的不仅是DBA对Oracle内部机制的理解深度更是其结构化思维和问题分解的能力。从操作系统的进程观察到数据库会话和SQL的定位再到参数、争用等系统级原因的深挖每一步都需要严谨的分析和验证。记住没有“银弹”最有效的工具是你的经验和对系统行为的好奇心。每一次成功的排障不仅是解决问题的过程更是加深你对这个复杂而精密的数据库系统理解的过程。
