statspack报告的问题！

Fenng

最初由 chenxi_033 发布
[B]

我进行优化的原因，主要是，系统在运行时，界面会出现抖动（在不断向前移动的过程中）。 [/B]

什么意思?

chenxi_033

最初由 Fenng 发布
[B]


什么意思? [/B]

因为在这个系统中不仅有属性数据，还有空间数据，所谓的抖动就是我在显示空间数据，并进行操作时会时慢时快！

chenxi_033

传上刚做的一个report
其中：
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            Buffer Nowait %:   99.99       Redo NoWait %:   99.90
            Buffer  Hit   %:   91.93    In-memory Sort %:   99.97
            Library Hit   %:   99.93        Soft Parse %:   98.65
         Execute to Parse %: -554.76 [/COLOR]         Latch Hit %:   98.98
Parse CPU to Parse Elapsd %:    0.00[/COLOR]      % Non-Parse CPU:   99.99

Shared Pool Statistics        Begin   End
                               ------  ------
             Memory Usage %:   40.81   87.09
    % SQL with executions>1:   63.50   46.79
  % Memory for SQL w/exec>1:   60.58   42.51

如果是shared_pool_size的设置问题，我刚计算了
SQL> select sum(reloads)/sum(pins)*100 from v$librarycache;

SUM(RELOADS)/SUM(PINS)*100                                                      
--------------------------                                                      
                .000115672                                                      

SQL> select sum(gets) "gets",sum(getmisses) "getmisses",sum(getmisses)/sum(gets)*100 "rate" from v$rowcache;

      gets  getmisses       rate                                                
---------- ---------- ----------                                                
121032152       1478 .001221163

LoveWinter

这个调整需要捕获SQL语句，然后调整索引扫描为全表扫描，这一步还没有进行调整
--------------------------------------
什么叫 "调整索引扫描为全表扫描" ?  不懂.

LoveWinter

1.  share pool(200M) 和large pool(50M) 都太大
   
  从共享池的使用统计来看，似乎用不了这么多.  

   Shared Pool Statistics        Begin   End
                                                             ------  ------
         Memory Usage %:   22.03   59.93
         % SQL with executions>1:   56.69   56.49
        % Memory for SQL w/exec>1:   53.93   52.88

2. 等待LATCH的时间比较多, 有无contention ?  查询
  v$latch视图
   

最初由 chenxi_033 发布
[B]这是我最先开始得到的一个statspack报告 [/B]

eygle

还有这样几个问题需要确认:

你的机器有多少CPU?
多少内存?

并行查询是否真的必要?

eygle

在Top 5等待事件中

[php]
Top 5 Wait Events
~~~~~~~~~~~~~~~~~                                             Wait     % Total
Event                                               Waits  Time (cs)   Wt Time
-------------------------------------------- ------------ ------------ -------
PX Deq: Execution Msg                              39,014      302,961   44.50
PX qref latch                                       3,588      232,580   34.17
PX Deq: Execute Reply                              16,885      117,946   17.33
db file sequential read                            57,542       14,041    2.06
PX Deq: Parse Reply                                 5,441        8,674    1.27
          -------------------------------------------------------------
.
[/php]

PX Deq: Execution Msg
PX Deq: Execute Reply

是空闲等待，可以忽略
[php]
PX qref latch                                       3,588      232,580   34.17
db file sequential read                            57,542       14,041    2.06
PX Deq: Parse Reply                                 5,441        8,674    1.27
..
[/php]
这三个事件值得关注

而Execute to Parse %: -554.76 过低
正和PX Deq: Parse Reply相关

你的全表扫描并不多
考虑你的并行是否必要.

eygle

注意到你还设置了

mts_dispatchers               (PROTOCOL=TCP)(PRE=oracle.aurora.

如不是特别设置，不要用MTS模式

chenxi_033

最初由 eygle 发布
[B]注意到你还设置了

mts_dispatchers               (PROTOCOL=TCP)(PRE=oracle.aurora.

如不是特别设置，不要用MTS模式 [/B]

parallel_max_servers和mts_dispatchers这两个参数的设置都是数据库创建时的默认值

对于第一个参数：查看了ask tom 上的建议，1个CPU，2G内存，可是设置parallel_max_servers=2；

对于第二个参数：应该并没有用MTS模式，完整的参数设置语句是：mts_dispatchers = "(PROTOCOL=TCP)(PRE=oracle.aurora.server.SGiopServer)"

对于Execute to Parse的问题，应该是说每执行一次，需要解析5次以上，但是软解析次数还是占总解析次数的95%以上，，就是不知道，什么原因，解析次数比执行次数多好几倍

执行次数和解析次数都来源于STATS$SYSSTAT表，不是很清楚该表的数据收集来源

eygle

最初由 chenxi_033 发布
[B]
parallel_max_servers和mts_dispatchers这两个参数的设置都是数据库创建时的默认值

对于第一个参数：查看了ask tom 上的建议，1个CPU，2G内存，可是设置parallel_max_servers=2；

对于第二个参数：应该并没有用MTS模式，完整的参数设置语句是：mts_dispatchers = "(PROTOCOL=TCP)(PRE=oracle.aurora.server.SGiopServer)"

对于Execute to Parse的问题，应该是说每执行一次，需要解析5次以上，但是软解析次数还是占总解析次数的95%以上，，就是不知道，什么原因，解析次数比执行次数多好几倍

执行次数和解析次数都来源于STATS$SYSSTAT表，不是很清楚该表的数据收集来源 [/B]

STATS$SYSSTAT数据来自 v$sysstat啊

100 * (1 - Parses/Executions) = 100*(1- 366818/56023)

SQL> select 100*(1- 366818/56023) from dual;

100*(1-366818/56023)
--------------------
          -554.76322

对于并行查询QC进程分割传递给slave进程

PX Deq: Parse Reply等待就是指Slave进程parse sql，在salve进程中
只有一个进程hard parse，其他进程都是soft parse

所以你的软解析率仍然很高