一份被怀疑的awr报告

Leo_Mu

本人新人一个，看到客户这里的awr报告后总是怀疑他的节点2有问题，大家就用ml教的方法帮某家看一眼吧。这是一份下午热点时段的awr报告，此时数据库会被频繁进行insert语句。可是除了这个以外，我还怀疑他的其他语句有问题。诸位大神帮看一眼吧！

Maclean Liu(刘相兵

AWR请压缩后上传，上海 3g 流量不便宜

Leo_Mu

下不为例

Maclean Liu(刘相兵

Wait Class        Waits        %Time -outs        Total Wait Time (s)        Avg wait (ms)        Waits /txn
System I/O        584,140        0.00        7,077        12        1.17
Commit        333,595        3.06        2,720        8        0.67
User I/O        585,238        0.00        2,137        4        1.17
Cluster        3,762,094        0.00        2,114        1        7.52
Network        2,252,230        0.00        318        0        4.50
Other        253,610        63.02        283        1        0.51
Configuration        4,223        0.21        134        32        0.01
Concurrency        37,403        0.20        25        1        0.07
Application        228        0.00        0        1        0.00




==> Log archive I/O、log file parallel write 的系统Io等待较多，这说明IO写的能力不是非常好 是瓶颈之一


CPU Time (s)        Elapsed Time (s)        Executions        CPU per Exec (s)        % Total DB Time         SQL Id        SQL Module        SQL Text
8,694        10,455        4,634        1.88        19.29        0a427kdru2y2z                  select upper(trim(Contra...
8,610        10,526        4,635        1.86        19.43        7qfa96rjvwpn7                  select upper(trim(Contra...
8,376        10,306        4,662        1.80        19.02        9fkdpsxmxuuuc                  select sum(tradeFee) as ...
5,535        6,796        4,604        1.20        12.54        cufhzatnw3p2q                  select trim(c1.contractid)...

这4个语句消费了大约70%的DB TIME 单次运行 约为2s

1. select upper(trim(ContractID)) as ContractID,
   
2.        trim(exchangeid) as exchangeid,
   
3.        min(trim(TradeSeq)) as TradeSeq,
   
4.        upper(trim(BSTag)) as BSTag,
   
5.        upper(trim(VHFlag)) as VHFlag,
   
6.        Price,
   
7.        sum(Volumn) as Volumn,
   
8.        sum(Amount) as Amount,
   
9.        upper(trim(OCTag)) as OCTag,
   
10.        sum(TradeFee) as TradeFee,
    
11.        sum(CloseProfitByTrade) as CloseProfitByTrade,
    
12.        sum(CloseProfit) as CloseProfit
    
13.   from H_CompClientTrade
    
14. where clientid = :1
    
15.    and TradeDate = :2
    
16. group by ContractID, exchangeid, BSTag, VHFlag, Price, OCTag
    
17. order by upper(trim(ContractID))
    

复制代码

Maclean Liu(刘相兵

table fetch continued row        5,993,628        835.24        11.98 ==>可能有链式行
user commits        324,109        45.17        0.65
redo wastage        197,026,048        27,456.62        393.72   ==> 每秒commit 45次 commit的速度在这里是瓶颈了。

Leo_Mu

受教了，多谢！

stevendba

Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class
CPU time   39,854   73.6   
Log archive I/O 40,270 3,502 87 6.5 System I/O
log file sync 333,595 2,720 8 5.0 Commit
db file sequential read 519,767 1,916 4 3.5 User I/O
log file parallel write 334,079 1,702 5 3.1 System I/O

可以看到有三个等待事件与redo有关，说明redo写有问题，建议把redo log文件单独出来，放到一个IO比较快的机器上。

前三条SQL语句是操作一个表，你可以看到执行的次数非常接近，可以找开发确认下是否有循环调用的问题，现在由于框架的封装，即便他写了循环调用，也可能不知道。

foxhuntwang

redo log 的日志量有点大啊 ，算一算 一小时 要写 20G 啊

Leo_Mu

多谢多谢。