statspack安裝使用 和 report 分析

http://blog.csdn.net/tianlesoftware/article/details/4682329

一. Statspack 安裝

statspack 是Oracle 9i 以前使用的一個數據庫收集工具。經過該工具的分析能夠清楚的看到數據庫的信息。statspack 的安裝過程以下：

1. 安裝statspack.

在oracle_home/rdmbs/admin/目錄下運行：

SQL>@spcreate.sql

若建立失敗則在同一目錄下運行： @spdrop.sql

2. 測試:

SQL>execute statspack.snap

PL/SQL procedure successfully completed.

SQL>execute statspack.snap

PL/SQL procedure successfully completed.

SQL>@spreport.sql

exec statspack.snap; -- 進行信息收集統計，每次運行都將產生一個快照號，得到快照號，必需要有兩個以上的快照，才能生成報表

查選快照信息：

SQL>select SNAP_ID, SNAP_TIME from STATS$SNAPSHOT;

獲取statspack 報告：

@spreport.sql -- 輸入須要查看的開始快照號與結束快照號

其餘相關腳本:

spauto.sql：利用dbms_job提交一個做業，自動的進行STATPACK的信息收集統計

sppurge.sql ：清除一段範圍內的統計信息，須要提供開始快照與結束快照號

sptrunc.sql ：清除(truncate)全部統計信息

二. 查看Statspack 生成源代碼

在oracle 9i裏面，咱們能夠經過查看statspack 生成腳原本幫助咱們理解report，可是10g的AWR是經過dbms_workload_repository 包來實現AWR的。包把代碼都封裝了起來，咱們沒法查看。

statspack的生成腳本位置：$ORACLE_HOME/rdbms/admin/sprepins.sql

代碼很長，不過看懂了，能幫助咱們理解statspack中各個數據的意義。

三. statspack report 分析

3.1 調整的前後次序

1. Tune the design. -- Application designers

2. Tune the application. -- Application developers

3. Tune memory.

4. Tune I/O.

5. Tune contention.

6. Tune the operating system.

3.2 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

3.2.1.報表頭信息

數據庫實例相關信息，包括數據庫名稱、ID、版本號及主機等信息。

STATSPACK report for

DB Name DB Id Instance Inst Num Release Cluster Host

BLISSDB 4196236801 blissdb 1 9.2.0.4.0 NO BLISS

Snap Id Snap Time Sessions Curs/Sess Comment

Begin Snap: 4 23-6月 -05 17:43:32 10 3.3

End Snap: 5 23-6月 -05 18:01:32 12 6.1

Elapsed: 18.00 (mins)

Cache Sizes (end)

Buffer Cache: 24M Std Block Size: 8K

Shared Pool Size: 48M Log Buffer: 512K

3.2.2.負載間檔

該部分提供每秒和每一個事物的統計信息，是監控系統吞吐量和負載變化的重要部分。

Load Profile

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

Per Second Per Transaction

Redo size: 431,200.16 18,627,847.04z

Logical reads: 4,150.76 179,312.72

Block changes: 2,252.52 97,309.00

Physical reads: 23.93 1,033.56

Physical writes: 68.08 2,941.04

User calls: 0.96 41.36

Parses: 1.12 48.44

Hard parses: 0.04 1.92

Sorts: 0.77 33.28

Logons: 0.00 0.20

Executes: 2.36 102.12

Transactions: 0.02

其中參數說明：

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.2.3.實例命中率

該部分能夠提早找出ORACLE潛在將要發生的性能問題，很重要。

Instance Efficiency Percentages (Target 100%)

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

Buffer Nowait %: 100.00 Redo NoWait %: 100.00

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

Library Hit %: 98.11 Soft Parse %: 96.04

Execute to Parse %: 52.57 Latch Hit %: 100.00

Parse CPU to Parse Elapsd %: 11.40 % Non-Parse CPU: 99.55

參數說明：

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%，這是很好的，說明計算機執行的大部分工做是執行查詢的工做，而不是分析查詢的工做。

3.2.4.Shared Pool相關統計數據

Shared Pool Statistics Begin End

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

Memory Usage %: 60.45 62.42

% SQL with executions>1: 81.38 78.64

% Memory for SQL w/exec>1: 70.36 68.02

參數說明：

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%。這是一個受觀察之間持續時間影響的統計數字。能夠指望它隨觀察之間的時間長度增大而增大。

3.2.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: 等待時間包括日誌緩衝的寫入和發送操做。

更多內容參考：

Oracle 常見的33個等待事件

http://blog.csdn.net/tianlesoftware/archive/2010/08/12/5807800.aspx

3.2.6.數據庫用戶程序發生的全部等待事件

Wait Events for DB: BLISSDB Instance: blissdb Snaps: 4 -5

-> 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

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

db file sequential read 22,154 0 259 12 886.2

log file parallel write 2,439 2,012 26 11 97.6

db file parallel write 400 0 22 55 16.0

SQL*Net message from dblink 4,575 0 15 3 183.0

SQL*Net more data from dblin 64,490 0 13 0 2,579.6

control file parallel write 416 0 5 13 16.6

db file scattered read 456 0 5 11 18.2

write complete waits 9 0 5 568 0.4

control file sequential read 370 0 5 13 14.8

log buffer space 126 0 4 34 5.0

free buffer waits 11 1 3 313 0.4

log file switch completion 13 0 2 188 0.5

log file sync 90 0 1 8 3.6

log file sequential read 10 0 0 16 0.4

latch free 17 6 0 8 0.7

direct path read 56 0 0 1 2.2

direct path write 56 0 0 1 2.2

SQL*Net more data to client 173 0 0 0 6.9

SQL*Net message to dblink 4,575 0 0 0 183.0

LGWR wait for redo copy 8 0 0 1 0.3

log file single write 10 0 0 1 0.4

db file single write 5 0 0 0 0.2

SQL*Net break/reset to clien 5 0 0 0 0.2

async disk IO 15 0 0 0 0.6

SQL*Net message from client 789 0 3,290 4170 31.6

virtual circuit status 36 36 1,082 30069 1.4

wakeup time manager 34 34 1,034 30403 1.4

SQL*Net message to client 791 0 0 0 31.6

SQL*Net more data from clien 30 0 0 0 1.2

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

3.2.7.數據庫後臺進程發生的等待事件

Background Wait Events for DB: BLISSDB Instance: blissdb Snaps: 4 -5

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

Avg

Total Wait wait Waits

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

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

log file parallel write 2,439 2,012 26 11 97.6

db file parallel write 400 0 22 55 16.0

control file parallel write 406 0 5 13 16.2

control file sequential read 258 0 4 16 10.3

db file sequential read 19 0 1 51 0.8

log buffer space 24 0 0 9 1.0

log file sequential read 10 0 0 16 0.4

latch free 14 6 0 9 0.6

db file scattered read 6 0 0 14 0.2

direct path read 56 0 0 1 2.2

direct path write 56 0 0 1 2.2

LGWR wait for redo copy 8 0 0 1 0.3

log file single write 10 0 0 1 0.4

rdbms ipc message 7,339 3,337 3,172 432 293.6

pmon timer 373 373 1,083 2903 14.9

smon timer 3 3 924 ###### 0.1

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

3.2.8.TOP SQL

調整首要的25個緩衝區讀操做和首要的25個磁盤讀操做作的查詢，將可對系統性能產生5%到5000%的增益。

SQL ordered by Gets for DB: BLISSDB Instance: blissdb Snaps: 4 -5

-> 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

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

1,230,745 1 1,230,745.0 27.5 16.39 60.69 1574310682

Module: PL/SQL Developer

insert into city_day_cal select * from rptuser.city_day_cal@db15

1

143,702 1 143,702.0 3.2 1.75 18.66 3978122706

Module: PL/SQL Developer

insert into city_day_cal select * from rptuser.city_day_cal@db15

1 where curtime between to_date('200501','yyyymm') and to_date('

200502','yyyymm')-1

在報表的這一部分，經過Buffer Gets對SQL語句進行排序，即經過它執行了多少個邏輯I/O來排序。頂端的註釋代表一個PL/SQL單元的緩存得到(Buffer Gets)包括被這個代碼塊執行的全部SQL語句的Buffer Gets。所以將常常在這個列表的頂端看到PL/SQL過程，由於存儲過程執行的單獨的語句的數目被總計出來。

SQL ordered by Reads for DB: BLISSDB Instance: blissdb Snaps: 4 -5

-> End Disk Reads Threshold: 1000

CPU Elapsd

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

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

3,587 1 3,587.0 13.9 0.17 5.13 3342983569

Module: PL/SQL Developer

select min(curtime),max(curtime) from city_day_cal

1,575 1 1,575.0 6.1 1.75 18.66 3978122706

Module: PL/SQL Developer

insert into city_day_cal select * from rptuser.city_day_cal@db15

1 where curtime between to_date('200501','yyyymm') and to_date('

200502','yyyymm')-1

這部分經過物理讀對SQL語句進行排序。這顯示引發大部分對這個系統進行讀取活動的SQL，即物理I/O。

SQL ordered by Executions for DB: BLISSDB Instance: blissdb Snaps: 4 -5

-> End Executions Threshold: 100

CPU per Elap per

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

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

748 748 1.0 0.00 0.00 3371479671

select t.name, (select owner_instance from sys.aq$_queue_table_

affinities where table_objno = t.objno) from system.aq$_queue

_tables t where t.name = :1 and t.schema = :2 for update skip lo

cked

442 1,142 2.6 0.00 0.00 1749333492

select position#,sequence#,level#,argument,type#,charsetid,chars

etform,properties,nvl(length, 0), nvl(precision#, 0),nvl(scale,

0),nvl(radix, 0), type_owner,type_name,type_subname,type_linknam

e,pls_type from argument$ where obj#=:1 and procedure#=:2 order

by sequence# desc

這部分告訴咱們在這段時間中執行最多的SQL語句。爲了隔離某些頻繁執行的查詢，以觀察是否有某些更改邏輯的方法以免必須如此頻繁的執行這些查詢，這多是頗有用的。或許一個查詢正在一個循環的內部執行，並且它可能在循環的外部執行一次，能夠設計簡單的算法更改以減小必須執行這個查詢的次數。即便它運行的飛快，任何被執行幾百萬次的操做都將開始耗盡大量的時間。

3.2.9.實例活動

Instance Activity Stats for DB: BLISSDB Instance: blissdb Snaps: 4 -5

Statistic Total per Second per Trans

CPU used by this session 4,870 4.5 194.8

CPU used when call started 4,870 4.5 194.8

CR blocks created 45 0.0 1.8

DBWR buffers scanned 24,589 22.8 983.6

DBWR checkpoint buffers written 14,013 13.0 560.5

DBWR checkpoints 5 0.0 0.2

……

dirty buffers inspected 38,834 36.0 1,553.4 --髒緩衝的個數

free buffer inspected 40,463 37.5 1,618.5 --若是數量很大,說明緩衝區太小

……

3.2.10.I/O

下面兩個報表是面向I/O的。一般，在這裏指望在各設備上的讀取和寫入操做是均勻分佈的。要找出什麼文件可能很是「熱」。一旦DBA瞭解瞭如何讀取和寫入這些數據，他們也許可以經過磁盤間更均勻的分配I/O而獲得某些性能提高。

Tablespace IO Stats for DB: BLISSDB Instance: blissdb Snaps: 4 -5

->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)

BLISS_DATA

17,649 16 12.3 1.2 44,134 41 0 0.0

UNDOTBS1

4,484 4 9.6 1.0 29,228 27 0 0.0

SYSTEM

340 0 31.0 1.1 36 0 0 0.0

File IO Stats for DB: BLISSDB Instance: blissdb Snaps: 4 -5

->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)

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

BLISS_DATA D:ORACLEORADATABLISSDBBLISS01.DBF

5,779 5 12.0 1.2 14,454 13 0

D:ORACLEORADATABLISSDBBLISS02.DBF

5,889 5 12.1 1.2 14,772 14 0

D:ORACLEORADATABLISSDBBLISS03.DBF

5,981 6 12.6 1.2 14,908 14 0

3.2.11.緩衝池

Buffer Pool Statistics for DB: BLISSDB Instance: blissdb Snaps: 4 -5

-> 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 3,000 99.4 4,482,816 25,756 73,470 11 9 0

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

若是咱們使用多緩衝池的功能，上面的報表會告訴咱們緩衝池引發的使用故障。實際上這只是咱們在報表的開頭看到的信息的重複。

3.2.12．回滾段活動

Instance Recovery Stats for DB: BLISSDB Instance: blissdb Snaps: 4 -5

-> 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 37 17 169 4012 3453 184320 3453

E 37 32 1385 57132 184320 184320 436361

通常指望活動在各回滾段間(除了SYSTEM回滾段外)均勻分佈。在檢查報表的這一部分時，報表標題也具備須要記住的最有用信息。尤爲是，若是徹底使用最佳設置時關於Optmal比Avg Active更大的建議。由於這是與DBA最有關的活動(I/O和回滾段信息)。