oracle修改第五条数据,top 5第一条是db cpu的awr报告分析

从AWR上主要看出以下问题：

1.Parse CPU to Parse Elapsd %:　０　　这里有点古怪，现在具体不清楚要进一步查询才知道。

2.AWR的TOP　5以DB CPU为比72.95　表示你的SQL语句执行时的等待时间不长。

3.从看其它事件等待，初步评估，并发量比较大，如果你可以监查当时的实际会话数就更好。另外AWR的开始与结束时的会话数是300多，参考意义不大。

4.查看按CPU　TIME排序的SQL，发现以下语句，在一小时内执行了三次，共占用了42.15%的CPU。

select *

from (select '$queryEntityId$' as column1_1298_0_,

this_.RECID as RECID1298_0_,

this_.POSTLEVEL as POSTLEVEL1298_0_,

this_.SENDEMPID as SENDEMPID1298_0_,

this_.TITLE as TITLE1298_0_,

this_.ATTCHEMENTNAME as ATTCHEME6_1298_0_,

this_.PDATE as PDATE1298_0_,

this_.DEGREE as DEGREE1298_0_,

this_.CONTENT as CONTENT1298_0_,

this_.LISTSTATE as LISTSTATE1298_0_,

this_.RECEEMPID as RECEEMPID1298_0_,

this_.RECEETYPE as RECEETYPE1298_0_,

this_.LINKSTATE as LINKSTATE1298_0_,

this_.EMPNAME as EMPNAME1298_0_,

this_.ACEPTNAME as ACEPTNAME1298_0_,

this_.POSTNAME as POSTNAME1298_0_,

this_.ORGNAME as ORGNAME1298_0_

from (select tt.recid,

tt.postlevel,

tt.sendempid,

tt.title,

tt.attchementname,

tt.pdate,

tt.degree,

tt.content,

tt.state as liststate,

to_orgname(tt.orgcode) orgname,

tk.receempid,

tk.receetype,

tk.state as linkstate,

to_empname(tt.sendempid) empname,

'' as aceptname,

'' as postname

from t_post_list tt, t_post_link tk

where tt.recid = tk.postid

and tt.state <> 2

and tk.state <> 3) this_

where this_.LINKSTATE = :1

order by this_.DEGREE asc, this_.POSTLEVEL desc, this_.PDATE desc)

where rownum <= :2

6.看segment statistics，存在热块的可能不大。

诊断结果：

初步判断，该故障主要由于SQL语句造成。把该SQL语句进行优化，应该可以大量降低你的CPU占用。

还有在AWR发现一潜在风险，9112na5jyq09b        被执行了2,152,345次，这个会容易造成热快。现在虽然不是主因，但也要开始防范。