一. 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 [email protected]
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 [email protected]
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 [email protected]
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和復原段資訊)。
![【MySQL資料庫】資料庫索引事務1.索引2.事務[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)