哈库拉玛塔塔——tjitty

记录下网络上的精品测试技术文章 and 生活

统计

留言簿(8)

积分与排名

阅读排行榜

评论排行榜

statspack 分析报告详解

statspack 输出结果中必须查看的十项内容

  1、负载间档(Load profile) 

  2、实例效率点击率(Instance efficiency hit ratios) 

  3、首要的5个等待事件(Top 5 wait events) 

  4、等待事件(Wait events) 

  5、闩锁等待 

  6、首要的SQL(Top sql) 

  7、实例活动(Instance activity) 

  8、文件I/O(File I/O) 

  9、内存分配(Memory allocation) 

  10、缓冲区等待(Buffer waits

 

1.报表头信息

数据库实例相关信息,包括数据库名称、ID、版本号及主机等信息。

STATSPACK report for 

DB Name         DB Id    Instance     Inst Num Release     Cluster Host

------------ ----------- ------------ -------- ----------- ------- ------------

GDTJ          3127284842 gdtj                1 9.2.0.6.0   NO      S1TJ

              Snap Id     Snap Time      Sessions Curs/Sess Comment

            --------- ------------------ -------- --------- -------------------

Begin Snap:         5 26-Feb-08 15:43:03      163      14.4

  End Snap:         6 03-Mar-08 15:20:29      162       1.8

   Elapsed:            8,617.43 (mins)

Cache Sizes (end)

~~~~~~~~~~~~~~~Buffer Cache:     4,000M      Std Block Size:          8K

           Shared Pool Size:       400M          Log Buffer:        768K

 

2.负载间档

该部分提供每秒和每个事物的统计信息,是监控系统吞吐量和负载变化的重要部分。

Load Profile

~~~~~~~~~~~~                            Per Second       Per Transaction

                                   ---------------       ---------------

                  Redo size:                114.04              2,917.88

              Logical reads:                261.82              6,698.89

              Block changes:                  0.89                 22.82

             Physical reads:                  4.53                115.88

            Physical writes:                  0.07                  1.88

                 User calls:                  0.86                 22.09

                     Parses:                  0.31                  7.88

                Hard parses:                  0.02                  0.44

                      Sorts:                  0.35                  8.92

                     Logons:                  0.04                  0.99

                   Executes:                  1.36                 34.74

               Transactions:                  0.04

Redo size:每秒产生的重做日志大小(单位字节),可标志数据变更频率, 数据库任务的繁重与否。

本例中平均每秒产生了430K左右的重做,每个事务品均产生了18M的重做。

Logical reads:平次每秒产生的逻辑读,单位是block。

block changes:每秒block变化数量,数据库事物带来改变的块数量。

Physical reads:平均每秒数据库从磁盘读取的block数。

Logical reads和Physical reads比较:大约有0.55%的逻辑读导致了物理I/O,平均每个事务执行了大约18万个逻辑读,在这个例子中,有一些大的事务被执行,因此很高的读取数目是可以接受的。

Physical writes:平均每秒数据库写磁盘的block数。

User calls:每秒用户call次数。

Parses和Hard parses:每秒大约1.12个解析,其中有4%为硬解析,系统每25秒分析一些SQL,都还不错。对于优化好的系统,运行了好几天后,这一列应该达到0,所有的sql在一段时间后都应该在共享池中。

Sorts:每秒产生的排序次数。

Executes:每秒执行次数。

Transactions:每秒产生的事务数,反映数据库任务繁重与否。

% Blocks changed per Read: 54.27 Recursive Call %: 86.94

Rollback per transaction %: 12.00 Rows per Sort: 32.59 

% Blocks changed per Read:说明46%的逻辑读是用于那些只读的而不是可修改的块,该系统只更新54%的块。

Rollback per transaction %:事务回滚的百分比。计算公式为:Round(User rollbacks / (user commits + user rollbacks) ,4)* 100%。本例中每8.33个事务导致一个回滚。如果回滚率过高,可能说明数据库经历了太多的无效操作。过多的回滚可能还会带来Undo Block的竞争。

 

3.实例命中率

该部分可以提前找出ORACLE潜在将要发生的性能问题,很重要。

Instance Efficiency Percentages (Target 100%)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

            Buffer Nowait %:   96.47       Redo NoWait %:    100.00

            Buffer  Hit   %:   98.27    In-memory Sort %:    100.00

            Library Hit   %:   99.13        Soft Parse %:     94.46

         Execute to Parse %:   77.32         Latch Hit %:     96.67

Parse CPU to Parse Elapsd %:   24.43     % Non-Parse CPU:     99.14

Buffer Nowait %:在缓冲区中获取Buffer的未等待比率,Buffer Nowait<99%说明,有可能是有热块(查找x$bh的 tch和v$latch_children的cache buffers chains)。

Redo NoWait %:在Redo缓冲区获取Buffer的未等待比率。

Buffer Hit %:数据块在数据缓冲区中的命中率,通常应在90%以上,否则,小于95%,需要调整重要的参数,小于90%可能是要加db_cache_size,但是大量的非选择的索引也会造成该值很高(大量的db file sequential read)。如果一个经常访问的列上的索引被删除,可能会造成buffer hit 显著下降。如果增加了索引,但是它影响了ORACLE正确的选择表连接时的驱动顺序,那么可能会导致buffer hit 显著增高。如果命中率变化幅度很大,说明需要改变SQL模式。

In-memory Sort %:在内存中的排序率。

Library Hit %:主要代表sql在共享区的命中率,通常在95%以上,否则需要要考虑加大共享池,绑定变量,修改cursor_sharing等参数。

Soft Parse %:近似看作sql在共享区的命中率,小于<95%,需要考虑到绑定,如果低于80%,那么就可能sql基本没有被重用。

Execute to Parse %:一个语句执行和分析了多少次的度量。在一个分析,然后执行语句,且再也不在同一个会话中执行它的系统中,这个比值为0。计算公式为:Execute to Parse =100 * (1 - Parses/Executions)。所以如果系统Parses > Executions,就可能出现该比率小于0的情况。本例中,对于每个分析来说大约执行了2.1次。该值<0通常说明shared pool设置或效率存在问题,造成反复解析,reparse可能较严重,或者可是同snapshot有关,如果该值为负值或者极低,通常说明数据库性能存在问题。

Latch Hit %:要确保>99%,否则存在严重的性能问题,比如绑定等会影响该参数。

Parse CPU to Parse Elapsd %:计算公式为:Parse CPU to Parse Elapsd %= 100*(parse time cpu / parse time elapsed)。即:解析实际运行时间/(解析实际运行时间+解析中等待资源时间)。此处为11.4%,非常低,用于解析花费的每个CPU秒花费了大约8.77秒的wall clock时间,这说明花了很多时间等待一个资源。如果该比率为100%,意味着CPU时间等于经过的时间,没有任何等待。

% Non-Parse CPU:计算公式为:% Non-Parse CPU =round(100*1-PARSE_CPU/TOT_CPU),2)。太低表示解析消耗时间过多。与PARSE_CPU相比,如果TOT_CPU很高,这个比值将接近100%,这是很好的,说明计算机执行的大部分工作是执行查询的工作,而不是分析查询的工作。

 

4.Shared Pool相关统计数据

Shared Pool Statistics        Begin   End

                               ------  ------

             Memory Usage %:   52.66   63.76

    % SQL with executions>1:   48.79   48.57

  % Memory for SQL w/exec>1:   51.62   51.26

Memory Usage %:正在使用的共享池的百分率。这个数字应该长时间稳定在75%~90%。如果这个百分率太低,就浪费内存。如果这个百分率太高,会使共享池外部的组件老化,如果SQL语句被再次执行,这将使得SQL语句被硬解析。在一个大小合适的系统中,共享池的使用率将处于75%到略低于90%的范围内。

% SQL with executions>1:这是在共享池中有多少个执行次数大于一次的SQL语句的度量。在一个趋向于循环运行的系统中,必须认真考虑这个数字。在这个循环系统中,在一天中相对于另一部分时间的部分时间里执行了一组不同的SQL语句。在共享池中,在观察期间将有一组未被执行过的SQL语句,这仅仅是因为要执行它们的语句在观察期间没有运行。只有系统连续运行相同的SQL语句组,这个数字才会接近100%。这里显示,在这个共享池中几乎有80%的SQL语句在18分钟的观察窗口中运行次数多于一次。剩下的20%的语句可能已经在那里了--系统只是没有理由去执行它。

% Memory for SQL w/exec>1:这是与不频繁使用的SQL语句相比,频繁使用的SQL语句消耗内存多少的一个度量。这个数字将在总体上与% SQL with executions>1非常接近,除非有某些查询任务消耗的内存没有规律。

在稳定状态下,总体上会看见随着时间的推移大约有75%~85%的共享池被使用。如果Statspack报表的时间窗口足够大到覆盖所有的周期,执行次数大于一次的SQL语句的百分率应该接近于100%。这是一个受观察之间持续时间影响的统计数字。可以期望它随观察之间的时间长度增大而增大。

 

5.首要等待事件

常见等待事件说明:

oracle等待事件是衡量oracle运行状况的重要依据及指示,主要有空闲等待事件和非空闲等待事件。

TIMED_STATISTICS:=TRUE,等待事件按等待的时间排序,= FALSE,等待事件按等待的数量排序。

运行statspack期间必须session上设置TIMED_STATISTICS = TRUE。

空闲等待事件是oracle正等待某种工作,在诊断和优化数据库时候,不用过多注意这部分事件,非空闲等待事件专门针对oracle的活动,指数据库任务或应用程序运行过程中发生的等待,这些等待事件是我们在调整数据库应该关注的。

Top 5 Timed Events

~~~~~~~~~~~~~~~~~~                                                     % Total

Event                                               Waits    Time (s) Ela Time

-------------------------------------------- ------------ ----------- --------

db file sequential read                            22,154         259    62.14

CPU time                                                           49    11.67

log file parallel write                             2,439          26     6.30

db file parallel write                                400          22     5.32

SQL*Net message from dblink                         4,575          15     3.71

这里是比其他任何事件都能使速度减慢的事件。比较影响性能的常见等待事件:

db file scattered read:该事件通常与全表扫描有关。因为全表扫描是被放入内存中进行的进行的,通常情况下它不可能被放入连续的缓冲区中,所以就散布在缓冲区的缓存中。该指数的数量过大说明缺少索引或者限制了索引的使用(也可以调整optimizer_index_cost_adj)。这种情况也可能是正常的,因为执行全表扫描可能比索引扫描效率更高。当系统存在这些等待时,需要通过检查来确定全表扫描是否必需的来调整。如果经常必须进行全表扫描,而且表比较小,把该表存人keep池。如果是大表经常进行全表扫描,那么应该是OLAP系统,而不是OLTP的。

db file sequential read:该事件说明在单个数据块上大量等待,该值过高通常是由于表间连接顺序很糟糕,或者使用了非选择性索引。通过将这种等待与statspack报表中已知其它问题联系起来(如效率不高的sql),通过检查确保索引扫描是必须的,并确保多表连接的连接顺序来调整, DB_CACHE_SIZE可以决定该事件出现的频率。

db file sequential read:该事件说明在单个数据块上大量等待,该值过高通常是由于表间连接顺序很糟糕,或者使用了非选择性索引。通过将这种等待与statspack报表中已知其它问题联系起来(如效率不高的sql),通过检查确保索引扫描是必须的,并确保多表连接的连接顺序来调整,DB_CACHE_SIZE可以决定该事件出现的频率。

buffer busy wait:当缓冲区以一种非共享方式或者如正在被读入到缓冲时,就会出现该等待。该值不应该大于1%,确认是不是由于热点块造成(如果是可以用反转索引,或者用更小块大小)。

latch free:常跟应用没有很好的应用绑定有关。闩锁是底层的队列机制(更加准确的名称应该是互斥机制),用于保护系统全局区(SGA)共享内存结构闩锁用于防止对内存结构的并行访问。如果闩锁不可用,就会记录一次闩锁丢失。绝大多数得闩锁问题都与使用绑定变量失败(库缓存闩锁)、生成重作问题(重执行分配闩锁)、缓存的争用问题(缓存LRU链) 以及缓存的热数据宽块(缓存链)有关。当闩锁丢失率高于0.5%时,需要调整这个问题。

log buffer space:日志缓冲区写的速度快于LGWR写REDOFILE的速度,可以增大日志文件大小,增加日志缓冲区的大小,或者使用更快的磁盘来写数据。

logfile switch:通常是因为归档速度不够快,需要增大重做日志。

log file sync:当一个用户提交或回滚数据时,LGWR将会话得重做操作从日志缓冲区填充到日志文件中,用户的进程必须等待这个填充工作完成。在每次提交时都出现,如果这个等待事件影响到数据库性能,那么就需要修改应用程序的提交频率, 为减少这个等待事件,须一次提交更多记录,或者将重做日志REDO LOG文件访在不同的物理磁盘上。

Wait time: 等待时间包括日志缓冲的写入和发送操作。

 

6.数据库用户程序发生的所有等待事件

Wait Events for DB: GDTJ  Instance: gdtj  Snaps: 5 -6

-> s  - second

-> cs - centisecond -     100th of a second

-> ms - millisecond -    1000th of a second

-> us - microsecond - 1000000th of a second

-> ordered by wait time desc, waits desc (idle events last)        Avg

                                                     Total Wait   wait    Waits

Event                               Waits   Timeouts   Time (s)   (ms)     /txn

---------------------------- ------------ ---------- ---------- ------ --------

buffer busy waits               4,808,775          0     12,998      3    238.0

PX Deq Credit: send blkd            5,490      5,385     10,614   1933      0.3

db file sequential read         1,046,194          0      3,496      3     51.8

latch free                      2,052,371          0      2,405      1    101.6

db file scattered read            245,055          0        883      4     12.1

wait list latch free               39,017          0        630     16      1.9

control file parallel write       171,892          0        165      1      8.5

control file sequential read      121,100          0         29      0      6.0

log file parallel write            81,563          0         21      0      4.0

control file single write              40          0          4     93      0.0

SQL*Net break/reset to clien       15,069          0          3      0      0.7

log file sync                       1,894          0          1      1      0.1

library cache pin                       6          0          0     60      0.0

process startup                         5          0          0     34      0.0

LGWR wait for redo copy             1,942          2          0      0      0.1

db file parallel read                   2          0          0     46      0.0

SQL*Net more data to client         3,496          0          0      0      0.2

log file switch completion              1          0          0     64      0.0

enqueue                                25          0          0      2      0.0

db file single write                    7          0          0      6      0.0

PX Deq: Execute Reply                  11          0          0      3      0.0

local write wait                        7          0          0      4      0.0

log file sequential read                2          0          0      5      0.0

PX Deq: Join ACK                       18          0          0      0      0.0

PX Deq: Signal ACK                     18          0          0      0      0.0

PX Deq: Msg Fragment                   70          0          0      0      0.0

PX Deq: Parse Reply                    25          0          0      0      0.0

log file single write                   2          0          0      0      0.0

direct path read                      143          0          0      0      0.0

direct path write                     144          0          0      0      0.0

async disk IO                         141          0          0      0      0.0

SQL*Net message from client       430,786          0  6,823,206  15839     21.3

wakeup time manager                17,184     17,183    486,427  28307      0.9

PX Idle Wait                        1,537      1,496      2,945   1916      0.1

SQL*Net more data from clien           99          0          1      5      0.0

SQL*Net message to client         430,792          0          0      0     21.3

PX Deq: Execution Msg                  70          0          0      0      0.0

 

7.数据库后台进程发生的等待事件

Background Wait Events for DB: GDTJ  Instance: gdtj  Snaps: 5 -6

-> ordered by wait time desc, waits desc (idle events last)

                                                                   Avg

                                                     Total Wait   wait    Waits

Event                               Waits   Timeouts   Time (s)   (ms)     /txn

---------------------------- ------------ ---------- ---------- ------ --------

control file parallel write       171,788          0        165      1      8.5

control file sequential read      120,487          0         28      0      6.0

log file parallel write            81,563          0         21      0      4.0

latch free                             21          0          1     30      0.0

LGWR wait for redo copy             1,942          2          0      0      0.1

buffer busy waits                      38          0          0      2      0.0

rdbms ipc reply                       136          0          0      0      0.0

log file sequential read                2          0          0      5      0.0

log file single write                   2          0          0      0      0.0

db file sequential read                 1          0          0      0      0.0

direct path read                       13          0          0      0      0.0

direct path write                      13          0          0      0      0.0

rdbms ipc message                 568,123    525,915  2,903,717   5111     28.1

pmon timer                        173,305    173,304    504,690   2912      8.6

smon timer                          2,259      1,676    487,246 ######      0.1

 

8.TOP SQL

调整首要的25个缓冲区读操作和首要的25个磁盘读操作做的查询,将可对系统性能产生5%到5000%的增益。

SQL ordered by Gets for DB: GDTJ  Instance: gdtj  Snaps: 5 -6

-> End Buffer Gets Threshold:     10000

-> Note that resources reported for PL/SQL includes the resources used by

   all SQL statements called within the PL/SQL code.  As individual SQL

   statements are also reported, it is possible and valid for the summed

   total % to exceed 100

                                                     CPU      Elapsd

  Buffer Gets    Executions  Gets per Exec  %Total Time (s)  Time (s) Hash Value

--------------- ------------ -------------- ------ -------- --------- ----------

      2,396,917            1    2,396,917.0    1.8    13.97     16.67  268671591

Module: GSM@S1TJ (TNS V1-V3)

select a.Equipno, a.Bindequipno, b.Cardtype, b.status, a.Status,

to_char(a.Outdate, 'YYYYMMDD') from equipst a, digit_assist b wh

ere trim(a.equipno) = trim(substr(b.sm_no,1,11)) and a.kind='0'

 and a.userid = '166136378'

在报表的这一部分,通过Buffer Gets对SQL语句进行排序,即通过它执行了多少个逻辑I/O来排序。顶端的注释表明一个PL/SQL单元的缓存获得(Buffer Gets)包括被这个代码块执行的所有SQL语句的Buffer Gets。因此将经常在这个列表的顶端看到PL/SQL过程,因为存储过程执行的单独的语句的数目被总计出来。

 

SQL ordered by Reads for DB: GDTJ  Instance: gdtj  Snaps: 5 -6

-> End Disk Reads Threshold:      1000

                                                     CPU      Elapsd

 Physical Reads  Executions  Reads per Exec %Total Time (s)  Time (s) Hash Value

--------------- ------------ -------------- ------ -------- --------- ----------

        169,780            5       33,956.0    7.3    10.09     28.71 1906014368

Module: PL/SQL Developer

select * from fpstr WHERE serialno = 'GZ_KZGB001000002'

         96,416           16        6,026.0    4.1    93.18    263.96   62902751

Module: GSM@S1TJ (TNS V1-V3)

select keyno ,to_char(optime,'yyyy-mm-dd') ,split(split(stoparea

,':',1),'^',2) ,split(split(stoparea,':',1),'^',3) ,payway ,subs

tr(bufs,3,(length(bufs)-3)) ,serialno  from feeindex where (user

id=:b0 and permark=:b1)

这部分通过物理读对SQL语句进行排序。这显示引起大部分对这个系统进行读取活动的SQL,即物理I/O。

 

SQL ordered by Executions for DB: GDTJ  Instance: gdtj  Snaps: 5 -6

-> End Executions Threshold:       100

                                                CPU per    Elap per

 Executions   Rows Processed   Rows per Exec    Exec (s)   Exec (s)  Hash Value

------------ --------------- ---------------- ----------- ---------- ----------

     155,513         154,849              1.0       0.00        0.00 1656858116

Module: GSM@S1TJ (TNS V1-V3)

SELECT RTRIM(PLACE) FROM AREARELA WHERE SCOPE = RPAD(:B3 ,8,' ')

 AND PERMARK = :B2 AND TYPE = :B1

这部分告诉我们在这段时间中执行最多的SQL语句。为了隔离某些频繁执行的查询,以观察是否有某些更改逻辑的方法以避免必须如此频繁的执行这些查询,这可能是很有用的。或许一个查询正在一个循环的内部执行,而且它可能在循环的外部执行一次,可以设计简单的算法更改以减少必须执行这个查询的次数。即使它运行的飞快,任何被执行几百万次的操作都将开始耗尽大量的时间。

 

9.实例活动

Instance Activity Stats for DB: GDTJ  Instance: gdtj  Snaps: 5 -6

 

Statistic                                      Total     per Second    per Trans

--------------------------------- ------------------ -------------- ------------

CPU used by this session                     178,737            0.4          8.8

CPU used when call started                   180,056            0.4          8.9

CR blocks created                             17,195            0.0          0.9

DBWR checkpoint buffers written               13,398            0.0          0.7

DBWR checkpoints                                   5            0.0          0.0

DBWR transaction table writes                  5,115            0.0          0.3

DBWR undo block writes                         6,144            0.0          0.3

……

deferred (CURRENT) block cleanout             54,306            0.1          2.7

 --脏缓冲的个数

dirty buffers inspected                            1            0.0          0.0

 --如果数量很大,说明缓冲区过小

…… 

 

10.I/O

下面两个报表是面向I/O的。通常,在这里期望在各设备上的读取和写入操作是均匀分布的。要找出什么文件可能非常 。一旦DBA了解了如何读取和写入这些数据,他们也许能够通过磁盘间更均匀的分配I/O而得到某些性能提升。

Tablespace IO Stats for DB: GDTJ  Instance: gdtj  Snaps: 5 -6

->ordered by IOs (Reads + Writes) desc

Tablespace

------------------------------

                 Av      Av     Av                    Av        Buffer Av Buf

         Reads Reads/s Rd(ms) Blks/Rd       Writes Writes/s      Waits Wt(ms)

-------------- ------- ------ ------- ------------ -------- ---------- ------

TESTOSS

     1,291,082       2    3.5     1.8          489        0  4,786,112    2.8

SYSTEM

           115       0    7.4     1.1        1,237        0          0    0.0

TEMP

            78       0    7.6    15.0        1,008        0          3    0.0

USERS

             1       0   10.0     1.0          222        0          0    0.0

ZBOSSTBS

             3       0    6.7     1.0          170        0          0    0.0

TESTUSER

           135       0    2.8     5.6           10        0          0    0.0

 

File IO Stats for DB: GDTJ  Instance: gdtj  Snaps: 5 -6

->ordered by Tablespace, File

Tablespace               Filename

------------------------ ----------------------------------------------------

                 Av      Av     Av                    Av        Buffer Av Buf

         Reads Reads/s Rd(ms) Blks/Rd       Writes Writes/s      Waits Wt(ms)

-------------- ------- ------ ------- ------------ -------- ---------- ------

SYSTEM                   /oracle/oradata/gdtj_raw_system.dbf

           115       0    7.4     1.1        1,237        0          0

TEMP                     /oracle/oradata/gdtj_raw_temp.dbf

            78       0    7.6    15.0        1,008        0          3    0.0

TESTOSS                  /oracle/oradata/gdtj_raw_oss01.dbf

       456,264       1    3.1     1.8          196        0  1,573,308    2.5

                         /oracle/oradata/gdtj_raw_oss02.dbf

       421,540       1    3.7     1.8          149        0  1,630,853    2.9

                         /oracle/oradata/gdtj_raw_oss03.dbf

       413,278       1    3.7     1.8          144        0  1,581,951    3.0

TESTUSER                 /oracle/oradata/gdtj_raw_testuser01.dbf

           135       0    2.8     5.6           10        0          0

USERS                    /oracle/oradata/gdtj_raw_users.dbf

             1       0   10.0     1.0          222        0          0

ZBOSSTBS                 /oracle/oradata/zboss01.dbf

             1       0    0.0     1.0           25        0          0

                         /oracle/oradata/zboss02.dbf

             1       0    0.0     1.0          119        0          0

                         /oracle/oradata/zboss03.dbf

             1       0   20.0     1.0           26        0          0

 

11.缓冲池

Buffer Pool Statistics for DB: GDTJ  Instance: gdtj  Snaps: 5 -6

-> Standard block size Pools  D: default,  K: keep,  R: recycle

-> Default Pools for other block sizes: 2k, 4k, 8k, 16k, 32k

                                                           Free    Write  Buffer

     Number of Cache      Buffer    Physical   Physical  Buffer Complete    Busy

P      Buffers Hit %        Gets       Reads     Writes   Waits    Waits   Waits

--- ---------- ----- ----------- ----------- ---------- ------- --------  ------

D      496,250  98.3 135,193,196   2,339,453     13,406       0        0########

如果我们使用多缓冲池的功能,上面的报表会告诉我们缓冲池引起的使用故障。实际上这只是我们在报表的开头看到的信息的重复。

 

12.回滚段活动

Instance Recovery Stats for DB: GDTJ  Instance: gdtj  Snaps: 5 -6

-> B: Begin snapshot,  E: End snapshot

  Targt Estd                                    Log File   Log Ckpt   Log Ckpt

  MTTR  MTTR   Recovery    Actual     Target      Size     Timeout    Interval

   (s)   (s)   Estd IOs  Redo Blks  Redo Blks  Redo Blks  Redo Blks  Redo Blks

- ----- ----- ---------- ---------- ---------- ---------- ---------- ----------

B   300    20        583       1624       1287      92160       1287

E   300    19        263        706        332      92160        332

一般期望活动在各回滚段间(除了SYSTEM回滚段外)均匀分布。在检查报表的这一部分时,报表标题也具有需要记住的最有用信息。尤其是,如果完全使用最佳设置时关于Optmal比Avg Active更大的建议。因为这是与DBA最有关的活动(I/O和回滚段信息)。

 

posted on 2008-03-17 10:13 tjitty 阅读(793) 评论(0)  编辑 收藏 引用 所属分类: ORACLE

只有注册用户登录后才能发表评论。