帮忙一起看一份OLTP 电信营帐系统的AWR报告，有什么问题

foxhuntwang

帮忙一起看一份OLTP 电信营帐系统的AWR报告，有什么问题。

项目人员报告 用户充值 总 超时。

huang_tg

报告的时间跨度有点大，给几个小一点的！

foxhuntwang

huang_tg 发表于 2013-3-29 09:39
报告的时间跨度有点大，给几个小一点的！

已传 帮忙看下

foxhuntwang

一个奇怪的问题，sys$USERS 怎么消耗了绝大部分 DBTIME 。有问题吧：

Teddy.huang

时间跨度还是大，第二份晚上8点到12点的，营帐系统都是这个时候高峰期吗？
一个小时最好

stevendba

      看一下SQL ordered by Elapsed Time，可以看到Elapsed Time 远远高于CPU Time。Elapsed Time =CPU Time +wait time 。做一个小时以内的awr，可以看到到底是哪个等待事件。
    不过如果你大概知道什么时候慢，可以在当时做一个ASH，也可以看到。

低调小马哥

c1cgc2w6pat1r这个语句是充值语句么，感觉这个表ACCT_BOOK的物理读很多，插入数据也是这个表，db file sequential read占了大半dbtime，估计优化这个表及相关的语句，但具体怎么优化，还请大神来支招，期待！

不了峰

附件没有压缩，刘大不看

不太清楚 “电信营帐系统” ，感觉主机的配置应该很差，特别是IO 这一话，
我认为楼主的awr报告可能问题 出现在
1. IO方面。存储配置很差
2.  有比较大的硬解析
3. shared pool可能可以加大一些
4.  对应的一些sql应该可调 一下
大的逻辑读
5gxk7c8nk1d08 的 where 子句对时间的处理应该是有问题

gmgstyn706km7对表
acct_book的查询和设计应该是有问题  

出在read by other session ，应该可调 一下 逻辑读与物理读高的sql
（异步IO没有打开？ 什么操作系统、）

foxhuntwang

不了峰 发表于 2013-3-29 14:10
附件没有压缩，刘大不看

不太清楚 “电信营帐系统” ，感觉主机的配置应该很差，特别是IO 这一话，

异步IO打开了，AIX 操作系统

背向天堂

跑ocs应用的？ 选取一下充值失败比较多的时间段，或者负载比较高的时间段的报告，这2个时间有点长， 都不是典型时间段了。

这么长时间段平均下来，都没有多少事务了。

热点对象，2个报告里面基本都是 CHANGE_NOTIF、 ACCT_BOOK、 CHANGE_NOTIF

这几个sql_id对应的语句开销偏大
5gxk7c8nk1d08
8hapcfq7jgc5r
73vvk3pn1pka9

           AND TO_CHAR(SYSDATE, 'HH24:MI:SS') > =
               DECODE(B.EFF_TIME, NULL, '00:00:00', TO_CHAR(B.EFF_TIME, 'HH24:MI:SS'))
           AND TO_CHAR(SYSDATE, 'HH24:MI:SS') < =
               DECODE(B.EXP_TIME, NULL, '23:59:59', TO_CHAR(B.EXP_TIME, 'HH24:MI:SS'))
           AND (SYSDATE - T.CREATED_DATE) * 24 * 3600 > NVL(B.DELAY_TIME, 0))

这种sql写的挺够呛的。 检查下开销比较大的几个语句的执行计划吧。

foxhuntwang

背向天堂 发表于 2013-3-29 16:15
跑ocs应用的？ 选取一下充值失败比较多的时间段，或者负载比较高的时间段的报告，这2个时间有点长， 都不是 ...

CHANGE_NOTIF 的问题已经解决，由于这个表频繁的插入删除 ，表中碎片太多 ，整理后 与之相关的 问题SQL 已经消失。ACCT_BOOK 还没有好的方法

Maclean Liu(刘相兵

Event        Waits        Time(s)        Avg Wait(ms)        % Total Call Time        Wait Class
db file sequential read         1,092,833         25,244         23         61.7        User I/O
CPU time                  13,063                  31.9         
log file sync         340,682         1,888         6         4.6        Commit
read by other session         18,303         1,038         57         2.5        User I/O
log file parallel write         341,301         531         2         1.3        System I/O


单块读 ==》8k 平均 23ms ， 副作用是read by other session

Physical Reads        Executions        Reads per Exec        %Total        CPU Time (s)        Elapsed Time (s)         SQL Id        SQL Module        SQL Text
989,886        1        989,886.00        45.60        31.02        120.31        gbakb1ufph8pp         PL/SQL Developer        select * from acct_book a wher...

物理读最高的语句 执行一次  从PL/SQL DEVELOPER中来，姑且认为他不是正常的应用语句， 但也该 预防在业务高峰 运行这种消耗大量物理读的语句

foxhuntwang

Maclean Liu(刘相兵 发表于 2013-3-30 16:24
Event        Waits        Time(s)        Avg Wait(ms)        % Total Call Time        Wait Class
db file sequential read         1,092,833         25 ...

刘大，为什么进行了表碎片的整理后， sql的逻辑读就下降了，碎片影响的是物理读吧

Maclean Liu(刘相兵

foxhuntwang 发表于 2013-4-3 06:03
刘大，为什么进行了表碎片的整理后， sql的逻辑读就下降了，碎片影响的是物理读吧
...

谁告诉你 "碎片"只影响物理读的？

好比一个 1g的表，被delete清空 未下降高水位，且该表keep在buffer中，难道 清理 "碎片"前后 他的全表逻辑读 无变化吗？

digdeep

从“看热闹”的角度说，觉得系统的物理磁盘性能太差了。

foxhuntwang

digdeep 发表于 2013-4-3 18:58
从“看热闹”的角度说，觉得系统的物理磁盘性能太差了。

确实是，当时安装人员没有做磁盘条带化