db_time超高的awr,及disks read也很高

不了峰

请大家能不能帮忙分析一下 awrrpt_1_19654_19655.html 这个报告中的db_time超高的原因？
另SQL ordered by Reads为什么没有捕捉到top read的sql ? 这是什么原因

awrrpt_1_19655_19656.html是后一个时间点的awr,  awrdiff是两个时间的比对


谢谢.
另这是一个两节点的 RAC,另一个节点上的db_time是正常，所以就不有上传另一个节点的awr

[ 本帖最后由 不了峰 于 2012-2-15 16:21 编辑 ]

kevinlin.ora

从SQL信息来看，区别不大。
CPU的使用主要区别是Service Statistics部分中的SYS$USERS。

可以从v$services和V$active_session_history(或者dba_hist_active_sess_history)查找相关时间段有哪些program属于SYS$USERS，猜测就是rman备份。

Maclean Liu(刘相兵

分析 awrddrpt 性能比较快照可以发现， 主要区别在于CPU TIME





但是 主要AWR捕捉到的主要消耗CPU的语句 不管是单次的cpu time 还是执行总数也好 都只是微小的差别：






Load Profile 中除了 physical read 有较大差别外， 其他差别远不到一个数量级






就Time model statistics来看， 仍是SQL Execute elapsed Time 使用了主要的CPU TIME， 而RMAN 使用的CPU TIME很少280s 左右。

Maclean Liu(刘相兵

就Time model statistics来看， 仍是SQL Execute elapsed Time 使用了主要的CPU TIME， 而RMAN 使用的CPU TIME很少280s 左右。
仍需要 ASH 和 ADDM 以继续分析。

目前所能做的猜测是  在快照1 中某些SQL语句 占用了大量的CPU TIME， 但是因为某种原因 AWR 报告没有捕捉到这个SQL的文本，  考虑是否在快照1 过程中有 刷新过 共享池， 导致该 SQL 丢失capture。

不了峰

根据你的建议，在视图中，才到引起物理读的sql语句。其中一个sql语句体现在 23:00~24:00这一时间段的awr报告中。
见附件awr2。

谢谢!。但是还有是些疑问。。

不了峰

没有刷过共享池。。
通过    SELECT * FROM v$sga_resize_ops; 那天出现 内存抖动的现象

不了峰

通过 dba_hist_active_sess_history 中的snap_id=19655查询
SELECT program
      ,session_type
      ,session_state
      ,COUNT(*)
  FROM dba_hist_active_sess_history
WHERE instance_number = 1
   AND snap_id = 19655
   AND service_hash = 3427055676   --="SYS$USERS"
GROUP BY program
         ,session_type
         ,session_state
ORDER BY sample_time



(2)通过下面找到sql_id
SELECT  sql_id,count(*)      FROM dba_hist_active_sess_history where instance_number=1
and snap_id=19655 and service_hash=3427055676
and program like 'oracle@kvamdb1%'
group by sql_id ;
-------
null                      18
3r6bjxp0ypms3    186
db78fxqxwxt7r    1
5rb1h41pb4bvy    1
0uhtw808mztuv    2

--(3)发现 3r6bjxp0ypms3 这个 sql在附件awr2.rar中即23:00~24:00的快照中有出现。
   3.1 这个sql 语句是update 一个600MB的表，全表扫描  update 其中的两条记录  -
   3.2  另一个0uhtw808mztuv  是一个查询900MB的表。求最大的时间..全表扫描.

总结，可能是由于这两个sql产生了大量的物理读？？
   这是否是db_time的根本原因？？

不了峰

可是，有我点不认同 变大的物理读就是db_time上升的原凶。

因为 3r6bjxp0ypms3 这语句从23:00开始，就有在update rep_fz_wap_terminalaccess表的数据，从oper_time    = SYSDATE 来看，表的每天钟update的条数 基本是差不多的。那么就是从可能他们生成的物理读是差不多的。
那么还是问到时哪里多出了物理读，
什么是引起db_time上升的原因？





[ 本帖最后由 不了峰 于 2012-2-15 16:38 编辑 ]

不了峰

注意 上面的-0:30之后到1:07分钟都更新数据 ，，

难道数据这时就卡这边。于是db_time上升 ??

Maclean Liu(刘相兵

我并没有说 physical read 是元凶， 是SQL 执行 消耗了大量的 CPU_TIME = > DB_TIME。 但是问题在于AWR中未反应出这部分的SQL语句 ， 可能是 部分进程在执行SQL时 hang住， 也有可能MMON进程因为某些原因未能捕捉到这些SQL的执行情况。

不了峰

呵呵，我没有说你有说 物理读是元凶。

我只是在分析这个awr时，找不到合理的理由去解释 db_time上升的原因。
所以很牵强的认认，可能是物理读造成了db_time的急剧上升。

是我个人问题。

teapot

把 SQL ordered by Gets里的SQL先优化了吧，
逻辑读高是影响CPU的一个典型

teapot

注意设计，别有事没事用这种CPU杀手
lower(key.key_name) = lower(cic.name)

不了峰

原帖由 teapot 于 2012-2-15 22:19 发表
注意设计，别有事没事用这种CPU杀手
lower(key.key_name) = lower(cic.name)

谢谢!
这个SQL是查当前告警版的未恢复 记录(在前面的  osc.clearedtime = to_date('4001-1-1', 'yyyy-mm-dd')) 。这些未恢复的数据量理论上应该 少，最多几十条。
所以就不去考虑
但是，告警量一多，就不好。

我很认同逻辑读是cpu高的一个大原因。当是从awr看不是这次的逻辑读变大了。
我还没有监控看cpu的负载中  user高，还是sys高。

谢谢你!