请大家帮看下statspack的几个问题

xlife

有几个问题请教一下（报告其余部分看附件）：
oracle9.2.0.1，跑在sun890上,8CPU+32G内存+sun3510阵列，默认statspack设置，没开归档
1、请看一下有没有什么明显不对，需要调整的地方？
２、事务是不是太多太小了？我看Transactions:31.23，而且redo write time才２１９，redo writes有913,274，是否可以说明事务太多太小？该如何调整？减少commit？
３、报告里的Buffer Cache就是db_cache_size吧？
４、Shared Pool是不是要增加，我看Memory Usage %: 91.42
５、log file sync 的Waits 是什么意思？Time(s)怎么可能达到414,057s（8*3600*10=288,000，都超过总CPU可用时间了？)，还有log file parallel write也很高？什么原因造成的呢？我redo log是５组，每组3个文件，每个100M，五个日志组一般都是二个ACTIVE，二个INACTIVE，每秒的数据量并不大，至少对阵列3510来说（最高每秒写>40M），最大的疑问，请指点
6、BEGIN statspack.snap;竟然排在SQL ordered by Reads for DB第一位！这是为什么？

问题有点多，还请大家一定指点，万分感谢！



报告前部分，后面的在附件里
            Snap Id     Snap Time      Sessions Curs/Sess Comment
            ------- ------------------ -------- --------- -------------------
Begin Snap:      17 24-Apr-07 08:00:05       84       2.8
  End Snap:      27 24-Apr-07 18:00:02       85       3.6
   Elapsed:              599.95 (mins)

Cache Sizes (end)
~~~~~~~~~~~~~~~~~
               Buffer Cache:     3,072M      Std Block Size:         8K
           Shared Pool Size:       672M          Log Buffer:     2,048K

Load Profile
~~~~~~~~~~~~                            Per Second       Per Transaction
                                   ---------------       ---------------
                  Redo size:             66,909.21              2,142.53
              Logical reads:             11,643.15                372.83
              Block changes:              2,444.15                 78.27
             Physical reads:                  6.14                  0.20
            Physical writes:                 47.56                  1.52
                 User calls:                 81.78                  2.62
                     Parses:                 48.08                  1.54
                Hard parses:                  0.30                  0.01
                      Sorts:                 24.49                  0.78
                     Logons:                  0.03                  0.00
                   Executes:                 68.75                  2.20
               Transactions:                 31.23

  % Blocks changed per Read:   20.99    Recursive Call %:    58.48
Rollback per transaction %:    0.00       Rows per Sort:    19.17

Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            Buffer Nowait %:  100.00       Redo NoWait %:   99.93
            Buffer  Hit   %:  100.00    In-memory Sort %:   99.97
            Library Hit   %:   99.72        Soft Parse %:   99.38
         Execute to Parse %:   30.06         Latch Hit %:   99.97
Parse CPU to Parse Elapsd %:   97.96     % Non-Parse CPU:   97.74

Shared Pool Statistics        Begin   End
                               ------  ------
             Memory Usage %:   91.42   91.39
    % SQL with executions>1:   82.48   87.23
  % Memory for SQL w/exec>1:   84.32   87.95

Top 5 Timed Events
~~~~~~~~~~~~~~~~~~                                                     % Total
Event                                               Waits    Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
log file sync                                   1,488,801     414,057    69.73
log buffer space                                   52,075      44,260     7.45
row cache lock                                     10,444      30,602     5.15
buffer busy waits                                  20,327      29,895     5.03
log file switch (checkpoint incomplete)            29,590      29,679     5.00

joelau

上面还有其他的应用吗？

xlife

目前没有，都是oracle应用（基本都是perl程序），以后可能装个informix，所以我内存没给oracle太多，而且从需求看也没必要

joelau

Top 5 Timed Events
~~~~~~~~~~~~~~~~~~                                                     % Total
Event                                               Waits    Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
log file sync                                   1,488,801     414,057    69.73  提交的记录太频繁，放日志的磁盘太慢，不要放在raid5上 raw device不错

log buffer space                                   52,075      44,260     7.45 redo log buffer太小

row cache lock                                     10,444      30,602     5.15
buffer busy waits                                  20,327      29,895     5.03
log file switch (checkpoint incomplete)            29,590      29,679     5.00  增加日志数量或加大尺寸

xlife

谢谢joelau 回复，我的想法如下，有不对请指出：
１、磁盘不慢的，是3510做的raid0+1。
２、log buffer space我观察出现的不多，我不想redo log buffer太大，否则每次lgwr时间太长，反而造成更严重的log file sync
３、增加日志数量不是问题，但我觉得现在已经不少了，而且５组，一般都有２组以上INACTIVE，所以应该是足够的。

rollingpig

Top 5 Event 很清楚的显示了你的瓶颈在于 log file sync. 显然是有太多的 commit了。

Recursive Call %:    58.48 说明你大量使用 pl/sql.

那么，考虑在你的pl/sql中进行批量 commit , 而不是每次update/insert都作commit, 相信会有很高的性能提升。

当然，在程序的其他部分也考虑尽量使用 批量 commit。

另外，如果可能的话，使用bulk insert , 有可能会大幅下降你的redo size. 试试看吧……

对了，log_buffer 可以再大点……

joelau

你可以先根据上面的改一下  看wait有没有降下来

现在有什么问题吗？响应很慢还是匝地。  后面的大概看了一下应用写的效率还不错。

rollingpig

还有，保证log file不在raid 5上

6。  BEGIN statspack.snap;竟然排在SQL ordered by Reads for DB第一位！这是为什么？
这个的原因，很显然是因为你的pga_aggregate_target给得太小了，造成访问 v$sqlarea时需要做大量磁盘排序（direct path read）,反映在了 physical read上了。
pga_aggregate_target=2G，不算多。

最后，还有很重要的一点，可以的话，还是开归档吧，数据安全很重要哦

joelau

nod   你的系统还是比较忙的 归档一定要

numenhuang

1. pga_aggregate_target设置太小，根据你的v$pga_target_advice，至少要调整到64M以上，现在才16m
2. log file sync，log buffer space，log file switch (checkpoint incomplete) ，可以看出系统的transactions数量很大，小事务commit过于频繁。redo log和其他data tablespace是不是在同组磁盘上，有瓶颈。
3. 如果数据重要还是设置archivelog mode。