数据库cpu很高,io很低的问题分析

发布时间:2021-01-18编辑:脚本学堂
问题:
项目上线后,日常情况下每天大约有8万的业务量,这时候oracle数据库主机的cpu大约为30%左右,但是当有批量业务的时候,比如一小时有20万的业务量的时候,数据库主机的cpu就达到99%左右了...

问题:
项目上线后,日常情况下每天大约有8万的业务量,这时候oracle数据库主机的cpu大约为30%左右,但是当有批量业务的时候,比如一小时有20万的业务量的时候,数据库主机的cpu就达到99%左右了,但是io的大小却只有平时的1/7左右,表里面都建索引了,会进行很多insert、update、select操作,现在小弟想通过一个sql语句查询出查询出到底是程序中哪个sql语句消耗的cpu过多,同时请各位高手帮忙分析下数据库本身的哪些参数设置会对cpu的使用率影响较大?数据库cpu很高,io很低 是什么问题?

cpu高估计还是sql语句有问题,以下内容可以供大家参考。

1、检查系统  sar -u 5 5 

2、看谁在用CPU 
topas  ps -ef |grep ora
#检查第四列,C的大小(unit,100 per cpu) 

3、检查CPU数量
/usr/sbin/bindprocessor -q lsattr El proc0    

4、2种可能:    
1) A Background (instance) process      
2) An oracle (user) process #此种可能最大。    

5、如果是用户进程:
那么高CPU的主要原因有:    
Large Queries, Procedure compilation or execution, Space management and Sorting    

5.1、查看每个Session的CPU利用情况:   
select ss.sid,se.command,ss.value CPU ,se.username,se.program from v$sesstat ss, v$session se where ss.statistic# in (select statistic# from v$statname    where name = 'CPU used by this session') and se.sid=ss.sid and ss.sid>6 order by ss.sid;

5.2、比较上述Session,看那个session的CPU使用时间最多,然后查看该Session的具体情况:select s.sid, w.event, w.wait_time, w.seq#, q.sql_text from v$session_wait w, v$session s, v$process p, v$sqlarea q where s.paddr=p.addr and s.sid=&p and s.sql_address=q.address;

5.3、得到上述信息后,查看相应操作是否有hash joins 和 full table scans。如果有hash joins 和 full table scans那么必须创建相应的Index或者检查Index是否有效。
另外必须检查是否有并行的查询存在和同一时刻有多个用户在执行相同的SQL语句,如果有必须关闭并行的查询和任何类型的并行提示(hints);如果查询使用intermedia数据,那么为了减少总的Index大小,必须限制使用Intermedia的Worldlist。(try restricting the wordlist that intermedia uses to help reduce the total indexsize)。

6、上述方案只能根据已经运行完成的操作,对于正在执行的长时间操作只能等操作完成后才能检测得到。因此我们可以通过另外一个很好的工具来检测正在运行的长时间操作语句。v$session_longops,这个视图显示那些操作正在被运行,或者已经完成。每个process完成后会刷新本视图的信息。

7、怎样寻找集中使用CPU的Process:
很多时候会发现有N个Process在平均分享着CPU的利用率,这种情况唯一的可能性就是这些Process在执行着相同的Package或者Query.

这种情况:建议通过statspack,在CPU高利用率额时候运行几个快照,然后根据这些快照检查Statspack报告,检查报告中最TOP的 Query。然后使用 sql_trace and tkprof 工具去跟踪一下。同时检查buffer cache 的命中率是否大雨95%。

同时在报告中还需要检查一下table scans (long tables),看是否在报告生成期间有存在全表扫描。

8、另外还有一些不是特别重要的,但是也必须关心检查的参数可能消耗CPU。