2.2  对statspack报告的分析
从上面的描述可以看出，产生一个statspack报告是比较简单的，但是如何读懂statspack报告却不是那么容易，需要对Oracle的体系架构、内存结构、等待事件以及应用系统有充分的了解，加上不断的实践，才能基本读懂statspack报告并且从报告中找到调整优化Oracle的途径。
下面接合一个实际的statspack报告，大致分析一下。

2.2.1  基本信息分析
DB Name         DB Id    Instance     Inst Num Release     OPS Host
------------ ----------- ------------ --------          ----------- ---      ---------  ---
RES           2749170756 res                 1  8.1.7.0.0   NO  res

                Snap Id     Snap Time      Sessions
                ------- ------------------ --------
 Begin Snap:          2 26-Jul-03 16:37:08       38
   End Snap:          3 26-Jul-03 17:03:23       38
    Elapsed:                  26.25 (mins)

Statspack报告首先描述了数据库的基本情况，比如数据库名、实例名、实例个数、oracle版本号等等；然后是该报告的开始快照和结束快照的信息，包括 snap id , snap time 等等；最后是该报告经过的时间跨度，单位是分钟(mins)。

Cache Sizes
~~~~~~~~~~~
db_block_buffers:      61440          log_buffer:     163840
db_block_size:         8192     shared_pool_size:   52428800

然后描述了Oracle内存结构中几个重要的参数。

2.2.2  内存信息分析
Load Profile
~~~~~~~~~~~~                       Per Second       Per Transaction
                                   ---------------       ---------------
              Redo size:              4,834.87             11,116.67
          Logical reads:                405.53                932.43
          Block changes:                 60.03                138.02
          Physical reads:                138.63                318.75
          Physical writes:                 54.27                124.79
          User calls:                     62.69                144.13
          Parses:                        19.14                 44.00
          Hard parses:                    2.26                  5.20
                  Sorts:                  1.83                  4.20
                 Logons:                  0.21                  0.47
               Executes:                 21.10                 48.50
            Transactions:                  0.43

  % Blocks changed per Read:   14.80    Recursive Call %:   34.45
 Rollback per transaction %:    0.00       Rows per Sort:   20.57

Redo size: 是日志的生成量，分为每秒和每事务所产生的，通常在很繁忙的系统中日志生成量可能达到上百k，甚至几百k；

Logical reads: 逻辑读实际上就是logical IO=buffer gets表示的含义，我们可以这样认为，block在内存中，我们每一次读一块内存，就相当于一次逻辑读；

Parses 和 Hard parses:  Parse 和 hard parse通常是很容易出问题的部分，80%的系统的慢都是由于这个原因所导致的。
所谓parse分soft parse 和hard parse，soft parse是当一条sql传进来后，需要在shared pool中找是否有相同的sql，如果找到了，那就是soft parse，如果没有找着，那就开始hard parse，实际上hard parse主要是检查该sql所涉及到的所有的对象是否有效以及权限等关系，hard parse之后才根据rule/cost模式生成执行计划，再执行sql。
而hard parse的根源，基本都是由于不使用bind var所导致的，不使用bind var违背了oracle的shared pool的设计的原则，违背了这个设计用来共享的思想，这样导致shared_pool_size里面命中率下降。因此不使用bind var，将导致cpu使用率的问题，极有使得性能急剧下降。
还有就是为了维护internal structure，需要使用latch，latch是一种Oracle低级结构,用于保护内存资源，是一种内部生命周期很短的lock，大量使用latch将消耗大量的cpu资源。

Sorts: 表示排序的数量；

Executes: 表示执行次数；

Transactions: 表示事务数量；

Rollback per transaction %: 表示数据库中事务的回退率。如果不是因为业务本身的原因，通常应该小于10%为好，回退是一个很消耗资源的操作。

Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           Buffer Nowait %:  100.00       Redo NoWait %:   99.98
           Buffer  Hit   %:   65.82    In-memory Sort %:   99.65
           Library Hit   %:   91.32        Soft Parse %:   88.18
         Execute to Parse %:    9.28         Latch Hit %:   99.99
Parse CPU to Parse Elapsd %:   94.61     % Non-Parse CPU:   99.90

Buffer Hit %: 数据缓冲区命中率，通常应该大于90%；

Library Hit %: libaray cache的命中率，通常应该大于98%；

In-memory Sort %: 排序在内存的比例，如果这个比例过小，可以考虑增大sort_area_size，使得排序在内存中进行而不是在temp表空间中进行；

Soft Parse %: 软解析的百分比，这个百分比也应该很大才好，因为我们要尽量减少hard parse。 soft parse 百分比=soft/(soft+hard)；

Execute to Parse %: 这个数字也应该是越大越好，接近100%最好。有些报告中这个值是负的，看上去很奇怪。事实上这表示一个问题，sql如果被age out的话就可能出现这种情况，也就是sql老化，或执行alter system flush shared_pool等。

Shared Pool Statistics          Begin   End
                             ------   ------
         Memory Usage %:    90.63   87.19
   % SQL with executions>1:   71.53   75.39
 % Memory for SQL w/exec>1:  59.45   65.17

% SQL with executions>1: 这个表示SQL被执行次数多于一次的比率，也应该大为好，小则表示很多sql只被执行了一次，说明没有使用bind var；

2.2.3  等待事件分析
接下来，statspack报告中描述的是等待事件（Wait Events），这是Oracle中比较复杂难懂的概念。
Oracle 的等待事件是衡量Oracle 运行状况的重要依据及指标。
等待事件的概念是在Oracle7.0.1.2 中引入的，大致有100 个等待事件。在Oracle 8.0 中这个数目增加到了大约150 个，在Oracle8i 中大约有200 个事件,在Oracle9i 中大约有360 个等待事件。
主要有两种类别的等待事件，即空闲（idle）等待事件和非空闲（non-idle）等待事件。
空闲事件指Oracle 正等待某种工作,在诊断和优化数据库的时候,我们不用过多注意这部分事件。
常见的空闲事件有:
? dispatcher timer
? lock element cleanup
? Null event
? parallel query dequeue wait
? parallel query idle wait - Slaves
? pipe get
? PL/SQL lock timer
? pmon timer- pmon
? rdbms ipc message
? slave wait
? smon timer
? SQL*Net break/reset to client
? SQL*Net message from client
? SQL*Net message to client
? SQL*Net m

上一页  [1] [2] [3] [4] [5] [6] [7]  下一页