运行数据库statspack一天分析（备忘）

数据库大小3.26TB，RAC IBM P690，忘记copy该报表的头了：（

statspack一天分析

第一项 work load
Load Profile
~~~~~~~~~~~~                            Per Second       Per Transaction
                                   ---------------       ---------------
                  Redo size:            633,097.62              4,579.16
              Logical reads:            152,840.78              1,105.49
              Block changes:              3,837.74                 27.76
             Physical reads:              5,644.98                 40.83
            Physical writes:                216.61                  1.57
                 User calls:              1,950.98                 14.11
                     Parses:                899.92                  6.51
                Hard parses:                  5.45                  0.04
                      Sorts:                254.00                  1.84
                     Logons:                  5.93                  0.04
                   Executes:              1,616.24                 11.69
               Transactions:                138.26
  % Blocks changed per Read:    2.51    Recursive Call %:    20.05
 Rollback per transaction %:    2.60       Rows per Sort:    23.04              
对比了一个星期的数据库的statspace报告，发现work load很平稳，每天各项指标变化幅度很小，因此选用了13日的进行分析
上面几项指标对性能有参考价值的为：
逻辑读和物理读的对比:152840.78/5644.98=27意味着每27个block中有一个需要从磁盘读取，  ok
编译和硬编译对比：899.92/5.45=165.12意味着每165次编译sql中只有一次是硬编译  ok
% Blocks changed per Read:2.5表示每100个block读入数据库其中只有2.5个block发生变化 ok
Recursive Call %:20.05 表示用于管理空间回收释放和其他的数据字典管理的调用（也包含pl-sql)占20% ok
Rollback per transaction %:2.60表示100个事务有2个回滚      ok

其他各项标志着数据库的工作量情况，代表着业务量和机器的繁忙程度。

psdb1实例的效率分析
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            Buffer Nowait %:   99.96       Redo NoWait %:  100.00
            Buffer  Hit   %:   96.33    In-memory Sort %:  100.00
            Library Hit   %:   99.61        Soft Parse %:   99.39
         Execute to Parse %:   44.32         Latch Hit %:  101.21
Parse CPU to Parse Elapsd %:   91.90     % Non-Parse CPU:   99.11

所有指标都很让人满意，综合对比了一个星期的数值，都很稳定在90%以上
Execute to Parse %:44.32该项指标表示一个sql执行次数和编译该sql的次数的百分比，和应用是密切相关的。
一个sql被编译然后被执行，之后永远不被执行，该项指标就会为0。tom解释说该值低跟应用的本身情况相关。
就我们自身的系统，还有部分程序没有使用绑定变量。

select substrb(sql_text,1,120),count(1)  from v$sqlarea group by  substrb(sql_text,1,120) having count(1)>100 order by count(1) desc;
从上面sql可以看到有些sql前120个字节完全相同的sql在内存中有2万多和1万多，增加了share pool的开销
SELECT A.hxd_no,A.wgj_state,A.hg_state,A.deal_state,A.provide_date FROM CUR_HXD_DATA A, cur_gpe_head B WHERE b.appr_no =     20732
SELECT A.seq_no,A.hxd_no,A.wgj_code,A.ENT_CODE,A.wgj_state,A.reason_code,A.provide_date,A.provide_name,A.oper_date,A.ope     12237
SELECT A.hxd_no,A.wgj_state,A.hg_state,A.deal_state,A.port_code FROM CUR_HXD_DATA A WHERE A.wgj_state='0' and a.hg_state      5757
SELECT A.SEQ_NO,A.PRE_ENTRY_ID,A.TRADE_CODE,A.STATE,A.ENT_CODE,A.MOD_NUM FROM CUR_GPI_STATE A WHERE (A.state in ('0000',      1995
SELECT B.seq_no,B.APPLY_DATE,B.APPLY_IC_CARD,B.ENT_CODE,B.HXD_NUM FROM CUR_RAS_ENT_OPER_INFO A,pre_hxd_apply B WHERE A.S      1914
SELECT hxd_no,wgj_state,hg_state,deal_state,port_code FROM CUR_HXD_DATA A WHERE A.wgj_state='0' and a.hg_state='0' and a      1408
SELECT DISTINCT A.SEQ_NO,A.ENTRY_ID,A.AGENT_CODE,A.I_E_DATE FROM PRE_E_STAT A,PRE_E_SIGN B WHERE A.SEQ_NO=B.SEQ_NO AND (      1393
SELECT DISTINCT A.SEQ_NO,A.ENTRY_ID,A.AGENT_CODE,A.I_E_DATE FROM PRE_I_STAT A,PRE_I_SIGN B WHERE A.SEQ_NO=B.SEQ_NO AND (      1069

psdb1共享池效率分析
 Shared Pool Statistics        Begin   End
                               ------  ------
             Memory Usage %:   92.08   91.76
    % SQL with executions>1:   35.25   35.84
  % Memory for SQL w/exec>1:   31.44   32.03

Memory Usage %oracle建议该项指标在70%到90%超过90%则有可能被age out,鉴于一个星期内该项指标一直稳定保持在90%左右认为ok
% SQL with executions>1: 35.25表示sql语句的执行次数大于一次的占到35%，这是由于没有使用绑定变量造成
 % Memory for SQL w/exec表示执行次数大于1的sql在内存中占用的比例，同上。
 
 
 Top 5 Timed Events
~~~~~~~~~~~~~~~~~~                                                     % Total
Event                                               Waits    Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
CPU time                                                      161,671    41.93
db file sequential read                        38,235,522     149,108    38.67
db file scattered read                         10,003,053      32,606     8.46
global cache cr request                        92,213,834      13,939     3.62
db file parallel read                           1,377,844      11,265     2.92

CPU time不属于等待事件
db file sequential read 表示读索引所引起的等待，占38% 说明我们的系统索引的使用率很高，good
db file scattered read  表示全表扫描所引起的等待占8%也可以令人满意/
global cache cr request 表示2个节点之间使用全局cache所引起的通信等待，ok
db file parallel read 表示恢复或者预读buffer时发生的等待， ok