帮忙看看这个 statspack report (CPU 100%, OSS目前也解决不了的问题(2 days)

xzh2000 · 发表于 2005-2-19 13:55

[php]
Cache Sizes (end)
~~~~~~~~~~~~~~~~~
            Buffer Cache:    832M    Std Block Size:       8K
         Shared Pool Size:    576M       Log Buffer: 10,240K

Load Profile
~~~~~~~~~~~~                         Per Second    Per Transaction
                                 ---------------    ---------------
               Redo size:          241,769.38          20,792.40
            Logical reads:          209,431.98          18,011.35
            Block changes:             1,748.77             150.40
         Physical reads:             4,756.15             409.03
         Physical writes:                92.83                7.98
               User calls:             591.19                50.84
                  Parses:             297.18                25.56
            Hard parses:                4.79                0.41
                  Sorts:             222.24                19.11
                  Logons:                1.12                0.10
               Executes:             1,560.57             134.21
            Transactions:                11.63

  % Blocks changed per Read: 0.84 Recursive Call %: 86.42
Rollback per transaction %: 7.84    Rows per Sort: 33.77

Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         Buffer Nowait %:  100.00    Redo NoWait %:  100.00
         Buffer  Hit %: 97.79 In-memory Sort %:  100.00
         Library Hit %: 99.64       Soft Parse %: 98.39
      Execute to Parse %: 80.96       Latch Hit %: 99.22
Parse CPU to Parse Elapsd %: 21.25    % Non-Parse CPU: 88.96

你的每秒事务才11,但每秒的物理读/逻辑读都很大，而且你的
机器配置很棒哦，如果再慢的话只能从数据库方面找原因，优
化SQL及实现业务才是最重要的。讲一下你是什么业务？为什
么重做为那么大.Redo size虽然是byte为单位，每秒这么大对
DISK IO的压力也挺大的。

ache Sizes (end)
~~~~~~~~~~~~~~~~~
            Buffer Cache:    1,104M    Std Block Size:
      8K
         Shared Pool Size:    128M       Log Buffer:
1,024K

Load Profile
~~~~~~~~~~~~                         Per Second    Per Transaction
                                 ---------------    ---------------
               Redo size:          22,398.53             625.20
            Logical reads:          32,427.22             905.12
            Block changes:             146.24                4.08
         Physical reads:                66.92                1.87
         Physical writes:                10.01                0.28
               User calls:             835.13                23.31
                  Parses:             223.08                6.23
            Hard parses:                0.43                0.01
                  Sorts:             114.35                3.19
                  Logons:                10.68                0.30
               Executes:             226.47                6.32
            Transactions:                35.83

  % Blocks changed per Read: 0.45 Recursive Call %:             40.93
Rollback per transaction %: 88.64    Rows per Sort:             46.83

Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         Buffer Nowait %:  100.00    Redo NoWait %:             99.99
         Buffer  Hit %: 99.79 In-memory Sort %:             100.00
         Library Hit %: 99.84       Soft Parse %:             99.81
      Execute to Parse %: 1.50       Latch Hit %:             99.96
Parse CPU to Parse Elapsd %: 91.28    % Non-Parse CPU:             95.43

Shared Pool Statistics       Begin End
                           ------  ------
         Memory Usage %: 89.50 90.38
% SQL with executions>1: 70.25 87.20
  % Memory for SQL w/exec>1: 83.98 90.94

Top 5 Timed Events
~~~~~~~~~~~~~~~~~~                                                    % Total
Event                                              Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
CPU time                                                    25,371 94.94
db file sequential read                      2,809,251       654    2.45
log file sync                                  199,416       343    1.28
ARCH wait on SENDREQ                               1,916       183    .69
latch free                                        46,923       88    .33
control file parallel write                      15,709       37    .14
enqueue                                              62       18    .07
log file switch completion                         234          8    .03
db file scattered read                            14,737          5    .02
SQL*Net more data to client                      234,995          4    .02

看看偶的这部分报表。

[/php]

actnow222 · 发表于 2005-2-19 18:00

感谢！！！

尤其感谢 xzh2000 的详细解析!!!

Yong Huang · 发表于 2005-2-20 14:04

最初由 rollingpig 发布
[B]
run the sql below to find out the hot objects in buffer cache
[php]
select *  from (
SELECT  o.owner, o.object_name, o.object_type
   ,  COUNT(1) buffers
   ,  sum(b.tch) total_touches
  FROM  sys.x$bh b, dba_objects o
WHERE  b.obj = o.Object_Id
GROUP  BY o.owner, o.object_name, o.object_type
order by 5 desc
)
where rownum < 10
/
[/php] [/B]

I suggest you change o.Object_Id to o.data_object_id in case those two numbers differ (as in the case where you MOVE'd or TRUNCATE'd a table).

Yong Huang

rollingpig · 发表于 2005-2-21 12:39

I suggest you change o.Object_Id to o.data_object_id in case those two numbers differ (as in the case where you MOVE'd or TRUNCATE'd a table).

Yong Huang

呵呵，这个倒不清楚，谢了先。

to actnow222:
1.增加db_cache_size 到1.5G,shared_pool_size到640M

2。logon代表new session login 到DB的数量，你的DB每秒钟有1.12个new session,因为new_session进来时，会spawn new server process,还要分配内存等资源，所以logon是一个很费资源的动作，尽可能的少有利于性能。
长连接，相对于短连接而言。短连接就是application连到DB,做了一个transatcion或者几个qurey就断开连接了，而长连接在application做完事情后并不断开和DB的连结，会等待下一个与DB的交互。java里的连接池就是典型的长连结的例子。长连结会减少大量的logon，从而有利于DB的性能。
3。cache buffers chains 是对同一个db_block的重复读取引起的，这导致了wait,等于是增加了response time.
4.既然你们不能自己调SQL,那就找“Oracle Application “的提供商调吧，那个最大的SQL肯定是有问题的。
另外，那条SQL里包含HINT,好像是调整过的。有可能是加的HINT导致了SQL的狠差的执行计划。你可以在测试机器上试着run那条SQL，在测试环境中进行调整。

actnow222 · 发表于 2005-3-1 12:21

最初由 rollingpig 发布
[B]
呵呵，这个倒不清楚，谢了先。

to actnow222:
1.增加db_cache_size 到1.5G,shared_pool_size到640M

2。logon代表new session login 到DB的数量，你的DB每秒钟有1.12个new session,因为new_session进来时，会spawn new server process,还要分配内存等资源，所以logon是一个很费资源的动作，尽可能的少有利于性能。
长连接，相对于短连接而言。短连接就是application连到DB,做了一个transatcion或者几个qurey就断开连接了，而长连接在application做完事情后并不断开和DB的连结，会等待下一个与DB的交互。java里的连接池就是典型的长连结的例子。长连结会减少大量的logon，从而有利于DB的性能。
3。cache buffers chains 是对同一个db_block的重复读取引起的，这导致了wait,等于是增加了response time.
4.既然你们不能自己调SQL,那就找“Oracle Application “的提供商调吧，那个最大的SQL肯定是有问题的。
另外，那条SQL里包含HINT,好像是调整过的。有可能是加的HINT导致了SQL的狠差的执行计划。你可以在测试机器上试着run那条SQL，在测试环境中进行调整。 [/B]

谢谢，不愧为高手！

我已经调整过那条SQL。之后 OSS方面调整了 java 部分，又调整了open_cursor参数（减少了其值）和SGA，系统性能有了提高。
23号当时由于系统稳定了一天，之后俺就放假了，过两天回公司看看具体情况，但听老大讲出了问题，然后OSS最后找出了BUG,现已正常。

Yong Huang · 发表于 2005-3-1 12:55

最初由 actnow222 发布
[B]
...
然后OSS最后找出了BUG,现已正常。 [/B]

An Oracle bug? What's the bug number? How was it fixed or worked around?

Yong Huang

foreverlee · 发表于 2005-3-1 13:09

sql部分问题很多啊
Gets per Exec都不小