您的位置: 首页  >  文章  >  Oracle数据库CPU使用率过高问题处理

Oracle数据库CPU使用率过高问题处理

分类: 文章 • 2025-04-09 21:27:22

1.下载Process Explorer

2.打开Process Explorer，查看CPU使用情况最高的进程

Oracle数据库CPU使用率过高问题处理

3.双击该进程，查看详情

Oracle数据库CPU使用率过高问题处理\

4.    获取cpu使用最好的线程tid

5.    查询sql_id

[sql] view plain copy
  1. select sql_id from v$session  
  2.   where paddr in(  
  3.     select addr from v$process  
  4.     where spid in('16796','11972','9812','11652','5484')  
  5.  )  

6.根据5中的sql_id查询具体执行占用CPU过高的sql语句

[sql] view plain copy
  1. select * from v$sqlarea where sql_id in(sql_id1,sql_id2,sql_id3...);  

7.查询sid和serial#

[sql] view plain copy
  1. SELECT sid,serial#,sql_id from v$session where sql_id in(sql_id1,sql_id2,sql_id3...)  

8.杀掉进程

[sql] view plain copy
  1. alter system kill session 'sid,serial#';  

或批量杀进程

[sql] view plain copy
  1. SELECT 'alter system kill session '''||sid||','||serial#||''';' from v$session where sql_id in(sql_id);  

 

9.分析SQL进行优化



一、问题描述

运行在Windows上的Oracle开发库的oracle进程CPU使用率保持在99%，服务器和数据库均反应缓慢。


二、排查思路

可能造成CPU使用率高的情况有：大量排序、大量SQL解析、全表扫描、Oracle Bug等。因此希望找到占用CPU较高的进程ID（UNIX或LINUX）或线程ID（Windows）来找到对应的SQL语句，以分析问题的原因。


三、处理步骤

1. 下载process explorer工具，用于查看Windows环境下的进程和线程信息。

Oracle数据库CPU使用率过高问题处理

2. 双击oracle.exe进程，查看oracle的线程信息，按照CPU使用率倒序排序，找到占用CPU较高的TID。（如在UNIX或LINUX系统中，使用top命令即可获得占用CPU较高的进程ID，使用进程ID去数据库中查找对应信息即可）

Oracle数据库CPU使用率过高问题处理

3. 使用上面找到的TID代入下面的SQL查询对应的SQL语句或会话信息。

[sql] view plain copy
  1. SELECT sql_text FROM v$sqltext a WHERE (a.hash_value, a.address) IN (SELECT DECODE(sql_hash_value, 0, prev_hash_value, sql_hash_value),DECODE(sql_hash_value, 0, prev_sql_addr, sql_address) FROM v$session b WHERE b.paddr =(SELECT addr FROM v$process c WHERE c.spid = '&pid')) ORDER BY piece ASC;  

[sql] view plain copy
  1. select id,serial# ,username,osuser,machine,program,process,to_char(logon_time,'yyyy-mm-dd hh24:mi:ss') logon from v$session where paddr in ( select addr from v$process where spid in('&pid'));  

4. kill掉查出的会话，记录查出的SQL语句待后续分析。


四、总结：

在进行第三步的时候遇到状况：使用找出的TID在数据库中查不到对应的SQL和会话信息。为先恢复数据库服务，直接kill了占用CPU较高的几个线程，后续通过分析AWR和ASH报告推测本次故障与数据库中几个涉及临时表创建和操作的存储过程有关，在存储过程执行中有大量的全表扫描和直接路径读并伴随大量的物理读操作。

相关推荐