statspack report分析

joelau

雖然不完整,但看看還是很有好處的,關(guān)鍵是中文滴:em11:

(1) 調(diào)整的先后次序

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.



Statspack分析報告詳解：

statspack 輸出結(jié)果中必須查看的十項內(nèi)容

　　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、內(nèi)存分配(Memory allocation)
　　10、緩沖區(qū)等待(Buffer waits



1.報表頭信息
數(shù)據(jù)庫實例相關(guān)信息，包括數(shù)據(jù)庫名稱、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

2.負載間檔
該部分提供每秒和每個事物的統(tǒng)計信息，是監(jiān)控系統(tǒng)吞吐量和負載變化的重要部分。
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：每秒產(chǎn)生的重做日志大小(單位字節(jié))，可標(biāo)志數(shù)據(jù)變更頻率, 數(shù)據(jù)庫任務(wù)的繁重與否。本例中平均每秒產(chǎn)生了430K左右的重做，每個事務(wù)品均產(chǎn)生了18M的重做。
Logical reads：平次每秒產(chǎn)生的邏輯讀，單位是block。
block changes：每秒block變化數(shù)量，數(shù)據(jù)庫事物帶來改變的塊數(shù)量。
Physical reads：平均每秒數(shù)據(jù)庫從磁盤讀取的block數(shù)。
Logical reads和Physical reads比較：大約有0.55%的邏輯讀導(dǎo)致了物理I/O，平均每個事務(wù)執(zhí)行了大約18萬個邏輯讀，在這個例子中，有一些大的事務(wù)被執(zhí)行，因此很高的讀取數(shù)目是可以接受的。
Physical writes：平均每秒數(shù)據(jù)庫寫磁盤的block數(shù)。
User calls：每秒用戶call次數(shù)。
Parses和Hard parses：每秒大約1.12個解析，其中有4%為硬解析，系統(tǒng)每25秒分析一些SQL，都還不錯。對于優(yōu)化好的系統(tǒng)，運行了好幾天后，這一列應(yīng)該達到0，所有的sql在一段時間后都應(yīng)該在共享池中。
Sorts：每秒產(chǎn)生的排序次數(shù)。
Executes：每秒執(zhí)行次數(shù)。
Transactions：每秒產(chǎn)生的事務(wù)數(shù)，反映數(shù)據(jù)庫任務(wù)繁重與否。
% 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%的邏輯讀是用于那些只讀的而不是可修改的塊，該系統(tǒng)只更新54%的塊。
Rollback per transaction %：事務(wù)回滾的百分比。計算公式為：Round(User rollbacks / (user commits + user rollbacks) ,4)* 100%。本例中每8.33個事務(wù)導(dǎo)致一個回滾。如果回滾率過高，可能說明數(shù)據(jù)庫經(jīng)歷了太多的無效操作。過多的回滾可能還會帶來Undo Block的競爭。
3.實例命中率
該部分可以提前找出ORACLE潛在將要發(fā)生的性能問題，很重要。
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 %：在緩沖區(qū)中獲取Buffer的未等待比率，Buffer Nowait<99%說明，有可能是有熱塊(查找x$bh的 tch和v$latch_children的cache buffers chains)。
Redo NoWait %：在Redo緩沖區(qū)獲取Buffer的未等待比率。
Buffer Hit %：數(shù)據(jù)塊在數(shù)據(jù)緩沖區(qū)中的命中率，通常應(yīng)在90%以上，否則，小于95%，需要調(diào)整重要的參數(shù)，小于90%可能是要加db_cache_size，但是大量的非選擇的索引也會造成該值很高（大量的db file sequential read）。如果一個經(jīng)常訪問的列上的索引被刪除，可能會造成buffer hit 顯著下降。如果增加了索引，但是它影響了ORACLE正確的選擇表連接時的驅(qū)動順序，那么可能會導(dǎo)致buffer hit 顯著增高。如果命中率變化幅度很大，說明需要改變SQL模式。
In-memory Sort %：在內(nèi)存中的排序率。
Library Hit %：主要代表sql在共享區(qū)的命中率，通常在95%以上，否則需要要考慮加大共享池，綁定變量，修改cursor_sharing等參數(shù)。
Soft Parse %：近似看作sql在共享區(qū)的命中率，小于<95%,需要考慮到綁定，如果低于80%，那么就可能sql基本沒有被重用。
Execute to Parse %：一個語句執(zhí)行和分析了多少次的度量。在一個分析，然后執(zhí)行語句，且再也不在同一個會話中執(zhí)行它的系統(tǒng)中，這個比值為0。計算公式為：Execute to Parse =100 * (1 - Parses/Executions)。所以如果系統(tǒng)Parses > Executions，就可能出現(xiàn)該比率小于0的情況。本例中，對于每個分析來說大約執(zhí)行了2.1次。該值<0通常說明shared pool設(shè)置或效率存在問題，造成反復(fù)解析，reparse可能較嚴(yán)重,或者可是同snapshot有關(guān)，如果該值為負值或者極低，通常說明數(shù)據(jù)庫性能存在問題。
Latch Hit %：要確保>99%，否則存在嚴(yán)重的性能問題，比如綁定等會影響該參數(shù)。
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時間等于經(jīng)過的時間，沒有任何等待。
% Non-Parse CPU：計算公式為：% Non-Parse CPU =round(100*1-PARSE_CPU/TOT_CPU),2)。太低表示解析消耗時間過多。與PARSE_CPU相比，如果TOT_CPU很高，這個比值將接近100%，這是很好的，說明計算機執(zhí)行的大部分工作是執(zhí)行查詢的工作，而不是分析查詢的工作。
4.Shared Pool相關(guān)統(tǒng)計數(shù)據(jù)
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 %：正在使用的共享池的百分率。這個數(shù)字應(yīng)該長時間穩(wěn)定在75%～90%。如果這個百分率太低，就浪費內(nèi)存。如果這個百分率太高，會使共享池外部的組件老化，如果SQL語句被再次執(zhí)行，這將使得SQL語句被硬解析。在一個大小合適的系統(tǒng)中，共享池的使用率將處于75%到略低于90%的范圍內(nèi)。
% SQL with executions>1：這是在共享池中有多少個執(zhí)行次數(shù)大于一次的SQL語句的度量。在一個趨向于循環(huán)運行的系統(tǒng)中，必須認(rèn)真考慮這個數(shù)字。在這個循環(huán)系統(tǒng)中，在一天中相對于另一部分時間的部分時間里執(zhí)行了一組不同的SQL語句。在共享池中，在觀察期間將有一組未被執(zhí)行過的SQL語句，這僅僅是因為要執(zhí)行它們的語句在觀察期間沒有運行。只有系統(tǒng)連續(xù)運行相同的SQL語句組，這個數(shù)字才會接近100%。這里顯示，在這個共享池中幾乎有80%的SQL語句在18分鐘的觀察窗口中運行次數(shù)多于一次。剩下的20%的語句可能已經(jīng)在那里了--系統(tǒng)只是沒有理由去執(zhí)行它。
% Memory for SQL w/exec>1：這是與不頻繁使用的SQL語句相比，頻繁使用的SQL語句消耗內(nèi)存多少的一個度量。這個數(shù)字將在總體上與% SQL with executions>1非常接近，除非有某些查詢?nèi)蝿?wù)消耗的內(nèi)存沒有規(guī)律。
在穩(wěn)定狀態(tài)下，總體上會看見隨著時間的推移大約有75%～85%的共享池被使用。如果Statspack報表的時間窗口足夠大到覆蓋所有的周期，執(zhí)行次數(shù)大于一次的SQL語句的百分率應(yīng)該接近于100%。這是一個受觀察之間持續(xù)時間影響的統(tǒng)計數(shù)字。可以期望它隨觀察之間的時間長度增大而增大。
5.首要等待事件
常見等待事件說明：
oracle等待事件是衡量oracle運行狀況的重要依據(jù)及指示，主要有空閑等待事件和非空閑等待事件。
TIMED_STATISTICS：=TRUE，等待事件按等待的時間排序，= FALSE，等待事件按等待的數(shù)量排序。
運行statspack期間必須session上設(shè)置TIMED_STATISTICS = TRUE。
空閑等待事件是oracle正等待某種工作，在診斷和優(yōu)化數(shù)據(jù)庫時候，不用過多注意這部分事件，非空閑等待事件專門針對oracle的活動，指數(shù)據(jù)庫任務(wù)或應(yīng)用程序運行過程中發(fā)生的等待，這些等待事件是我們在調(diào)整數(shù)據(jù)庫應(yīng)該關(guān)注的。
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：該事件通常與全表掃描有關(guān)。因為全表掃描是被放入內(nèi)存中進行的進行的，通常情況下它不可能被放入連續(xù)的緩沖區(qū)中，所以就散布在緩沖區(qū)的緩存中。該指數(shù)的數(shù)量過大說明缺少索引或者限制了索引的使用(也可以調(diào)整optimizer_index_cost_adj)。這種情況也可能是正常的，因為執(zhí)行全表掃描可能比索引掃描效率更高。當(dāng)系統(tǒng)存在這些等待時，需要通過檢查來確定全表掃描是否必需的來調(diào)整。如果經(jīng)常必須進行全表掃描，而且表比較小，把該表存人keep池。如果是大表經(jīng)常進行全表掃描，那么應(yīng)該是OLAP系統(tǒng)，而不是OLTP的。
db file sequential read：該事件說明在單個數(shù)據(jù)塊上大量等待，該值過高通常是由于表間連接順序很糟糕，或者使用了非選擇性索引。通過將這種等待與statspack報表中已知其它問題聯(lián)系起來(如效率不高的sql),通過檢查確保索引掃描是必須的，并確保多表連接的連接順序來調(diào)整, DB_CACHE_SIZE可以決定該事件出現(xiàn)的頻率。
db file sequential read：該事件說明在單個數(shù)據(jù)塊上大量等待，該值過高通常是由于表間連接順序很糟糕，或者使用了非選擇性索引。通過將這種等待與statspack報表中已知其它問題聯(lián)系起來（如效率不高的sql），通過檢查確保索引掃描是必須的，并確保多表連接的連接順序來調(diào)整，DB_CACHE_SIZE可以決定該事件出現(xiàn)的頻率。
buffer busy wait：當(dāng)緩沖區(qū)以一種非共享方式或者如正在被讀入到緩沖時，就會出現(xiàn)該等待。該值不應(yīng)該大于1%，確認(rèn)是不是由于熱點塊造成（如果是可以用反轉(zhuǎn)索引，或者用更小塊大�。�。
latch free：常跟應(yīng)用沒有很好的應(yīng)用綁定有關(guān)。閂鎖是底層的隊列機制（更加準(zhǔn)確的名稱應(yīng)該是互斥機制），用于保護系統(tǒng)全局區(qū)（SGA）共享內(nèi)存結(jié)構(gòu)閂鎖用于防止對內(nèi)存結(jié)構(gòu)的并行訪問。如果閂鎖不可用，就會記錄一次閂鎖丟失。絕大多數(shù)得閂鎖問題都與使用綁定變量失敗（庫緩存閂鎖）、生成重作問題（重執(zhí)行分配閂鎖）、緩存的爭用問題(緩存LRU鏈) 以及緩存的熱數(shù)據(jù)寬塊(緩存鏈)有關(guān)。當(dāng)閂鎖丟失率高于0.5%時，需要調(diào)整這個問題。
log buffer space：日志緩沖區(qū)寫的速度快于LGWR寫REDOFILE的速度，可以增大日志文件大小，增加日志緩沖區(qū)的大小，或者使用更快的磁盤來寫數(shù)據(jù)。
logfile switch：通常是因為歸檔速度不夠快，需要增大重做日志。
log file sync：當(dāng)一個用戶提交或回滾數(shù)據(jù)時，LGWR將會話得重做操作從日志緩沖區(qū)填充到日志文件中，用戶的進程必須等待這個填充工作完成。在每次提交時都出現(xiàn)，如果這個等待事件影響到數(shù)據(jù)庫性能，那么就需要修改應(yīng)用程序的提交頻率, 為減少這個等待事件，須一次提交更多記錄，或者將重做日志REDO LOG文件訪在不同的物理磁盤上。
Wait time: 等待時間包括日志緩沖的寫入和發(fā)送操作。
6.數(shù)據(jù)庫用戶程序發(fā)生的所有等待事件
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
-------------------------------------------------------------

7.數(shù)據(jù)庫后臺進程發(fā)生的等待事件
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
-------------------------------------------------------------

8.TOP SQL
調(diào)整首要的25個緩沖區(qū)讀操作和首要的25個磁盤讀操作做的查詢，將可對系統(tǒng)性能產(chǎn)生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語句進行排序，即通過它執(zhí)行了多少個邏輯I/O來排序。頂端的注釋表明一個PL/SQL單元的緩存獲得(Buffer Gets)包括被這個代碼塊執(zhí)行的所有SQL語句的Buffer Gets。因此將經(jīng)常在這個列表的頂端看到PL/SQL過程，因為存儲過程執(zhí)行的單獨的語句的數(shù)目被總計出來。
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語句進行排序。這顯示引起大部分對這個系統(tǒng)進行讀取活動的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

這部分告訴我們在這段時間中執(zhí)行最多的SQL語句。為了隔離某些頻繁執(zhí)行的查詢，以觀察是否有某些更改邏輯的方法以避免必須如此頻繁的執(zhí)行這些查詢，這可能是很有用的。或許一個查詢正在一個循環(huán)的內(nèi)部執(zhí)行，而且它可能在循環(huán)的外部執(zhí)行一次，可以設(shè)計簡單的算法更改以減少必須執(zhí)行這個查詢的次數(shù)。即使它運行的飛快，任何被執(zhí)行幾百萬次的操作都將開始耗盡大量的時間。
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 --臟緩沖的個數(shù)
free buffer inspected 40,463 37.5 1,618.5 --如果數(shù)量很大,說明緩沖區(qū)過小
……

10.I/O
下面兩個報表是面向I/O的。通常，在這里期望在各設(shè)備上的讀取和寫入操作是均勻分布的。要找出什么文件可能非常“熱”。一旦DBA了解了如何讀取和寫入這些數(shù)據(jù)，他們也許能夠通過磁盤間更均勻的分配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

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

如果我們使用多緩沖池的功能，上面的報表會告訴我們緩沖池引起的使用故障。實際上這只是我們在報表的開頭看到的信息的重復(fù)。
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回滾段外)均勻分布。在檢查報表的這一部分時，報表標(biāo)題也具有需要記住的最有用信息。尤其是，如果完全使用最佳設(shè)置時關(guān)于Optmal比Avg Active更大的建議。因為這是與DBA最有關(guān)的活動(I/O和回滾段信息)。

[ 本帖最后由 joelau 于 2007-3-27 10:50 編輯 ]

joelau

有耐心的就再看一些吧


數(shù)據(jù)庫的等待事件，發(fā)現(xiàn)前幾名是：
log file parallel write

db file scattered read

log file sync

db file sequential read

SQL*Net more data to client

發(fā)現(xiàn)前面的4項都是影響到數(shù)據(jù)庫性能的問題：

log file sync：

這個等待時間是指等待oracle的前臺的commit和rollback操作進程完成，有時候這個等待時間也會包括等待LGWR進程把一個會話事務(wù)的日志記錄信息從日志緩沖區(qū)中寫到磁盤上的重做日志文件中。因此當(dāng)前臺進程在等待這個事件的時候，LGWR進程同時也在等待事件log file parallel write。

理解什么造成這個等待事件的關(guān)鍵在于：對比這個等待事件和log file parallel write等待事件的平均等待時間：

l 如果他們的等待時間差不多，那么就是重做日志文件的I/O引起了這個等待事件，則需要調(diào)整重做日志文件的I/O，

l 如果log file parallel write等待事件的平均等待時間明顯小于log file sync等待事件的等待時間，那么就是一些其他寫日志的機制在commit和rollback操作時引起的等待，而不是I/O引起的等待。例如重做日志文件的latch競爭，會伴隨出現(xiàn)latch free或者LGWR wait for redo copy等待事件

在V$SESSION_WAIT中，這個等待事件有3個參數(shù)：

P1
代表在日志緩沖區(qū)中需要被寫入到重做日志文件中的緩存數(shù)量，寫入的同時會確認(rèn)事務(wù)是否已經(jīng)被提交，并且保留提交信息到實例意外中斷前，因此必須等待LGWR將P1數(shù)量的緩存寫入重做日志文件為止。

P2
無用

P3
無用


如果這個等待事件在整個等待事件中占了比較大的比重，可以從3個方面來進行調(diào)整

1. 調(diào)整LGWR進程時期具有更好的磁盤I/O吞吐量，例如不要將日志文件放在RAID5的磁盤上

2. 如果存在很多執(zhí)行時間很短的事務(wù)，可以考慮將這些事務(wù)合并成一個批量事務(wù)以減少提交的次數(shù)，因為每次提交都需要確認(rèn)相關(guān)的日志寫入重做日志文件，因此使用批量事務(wù)來減少提交的次數(shù)是一種非常行之有效的減少I/O的方法

3. 產(chǎn)看是否有一些操作可以安全的使用NOLOGGING或者UNRECOVERABLE選項，這樣可以減少日志文件的產(chǎn)生

Log file parallel write

這個等待事件出現(xiàn)在黨LGWR后臺進程從日志緩沖區(qū)寫日志信息到磁盤上的重做日志文件的時候。只有啟用了異步I/O的時候，LGWR進程才會并行寫當(dāng)前日志組內(nèi)的充作日志文件，否則LGWR指揮循環(huán)順序逐個的寫當(dāng)前日志組重做日志文件。LGWR進程不得不等待當(dāng)前日志組所有的重做日志文件成員全部寫完，因此，決定這個等待事件的等待時間長短的主要因素是重做日志文件所在磁盤的I/O讀寫速度。

如果是當(dāng)前LGWR進程寫的速度不夠快導(dǎo)致這個等待事件，可以通過查看一些和重做日志相關(guān)的統(tǒng)計值來判定當(dāng)前的LGWR進程是否效率低下，具體的可以看 redo writes, redo blocks written, redo write time, rdo wastage, redo size等統(tǒng)計值，這些都是和LGWR進程性能直接相關(guān)的一些統(tǒng)計值。

在V$SESSION_WAIT中，這個等待事件的3個參數(shù)：

P1
代表正在被寫入的重做日志文件組中的重做日志文件號

P2
代表需要寫入重做日志組中每個重做日志文件的重做日志block數(shù)量

P3
代表I/O請求次數(shù)，需要被寫入的block會被分成多次分別請求


如果這個等待事件占用比較多的時間，可以做如下調(diào)整

1． 采用UNRECOVERABLE/NOLOGGING操作盡量減少重做日志的產(chǎn)生

2． 在保證不會同時對市重做日志文件的前提下，盡量減少重做日志組中的成員個數(shù)，減少每次寫重做日志文件的時間

3． 除非在備份情況下，否則不要在江表空間置于熱備份的模式下，因為在表空間處于熱備的模式下會產(chǎn)生更多的重做日志文件

4． 對于使用LogMiner、Logical Standby或者Streams，在能夠滿足要求功能的前提下，盡量使用最低級別的追加日志以減少重做日志的產(chǎn)生

5． 盡量將同一個日志組內(nèi)的重做日志文件分散到不同的硬盤上，減少并行寫重做日志文件時產(chǎn)生的I/O競爭

6． 不要將重做日志文件置于RAID5的磁盤上，最好放在裸設(shè)備上。

7． 如果設(shè)置了歸檔模式，不要將歸檔日志的目的地設(shè)置為存放重做日志的磁盤上，避免引起I/O競爭

關(guān)于Log的這2個問題的總結(jié)

通過上述對Log這2個問題的描述，以及產(chǎn)生的原因，除了Log file sync可能有其他方面的因素引起的（Latch），主要還是磁盤和使用習(xí)慣

1． 磁盤由于這些都是寫磁盤所引起的，所以只有從減少寫磁盤（指數(shù)據(jù)庫本身的角度，和下列提到的用戶操作習(xí)慣不一樣）和加快寫磁盤來減少這些等待時間

a) 盡量不要在RAID5的磁盤上保存重做日志文件，RAID5寫的速度屬于比較慢的

b) 在安全性保證的基礎(chǔ)上，減少重做日志組成員的個數(shù)

c) 同一個日志組中的不同成員放在不同的磁盤上，加速寫的速度。

d) 對可以采用NOLOGGING/UNRECOVERABLE的操作，使用這些選項減少log的產(chǎn)生

e) 有歸檔的，不要將歸檔的和在線重做日志放在一個磁盤上

2． 使用習(xí)慣如果用戶不斷的進行commit或者rollback，這樣必定引起一次log日志的寫操作。因此可以通過一些統(tǒng)計信息判斷是否每次的日志的寫操作數(shù)據(jù)量很小，這樣通過調(diào)節(jié)用戶的操作，將大量的數(shù)據(jù)更新合并到一個事務(wù)中來，這樣增加每次日志的操作量，減少對日志的不斷調(diào)用，提高LGWR的寫的效率。

db file scattered read

這是一個非常常見的等待時間。當(dāng)oracle從磁盤上讀取多個block到不連續(xù)的高速緩存區(qū)的緩存中就會發(fā)生這個等待事件，Oracle一次最多能夠讀入的block數(shù)量由初始化參數(shù)DB_FILE_MULTIBLOCK_READ_COUND決定，這個時間一般伴隨著全表掃描或者Fast Full Index 掃描一起出現(xiàn)。

在V$SESSION_WAIT中，這個等待事件的幾個參數(shù)：

P1
代表oracle的文件號

P2
代表從這個文件中開始讀取的block號

P3
代表從這個block開始需要讀取的block數(shù)量


一般從這個3個參數(shù)，就可以回頭查詢到是在讀取數(shù)據(jù)庫的哪個對象，然后分析對這個對象的操作來進行優(yōu)化Sql語句。

如果這個等待事件占的比重比較厲害，可以通過以下方法來調(diào)整

方法一

找出執(zhí)行全表掃描或者Fast Full index掃描的Sql語句，判斷這些掃描是否是必要的，是否導(dǎo)致了比較差的執(zhí)行計劃，進行調(diào)整。

從oracle9i開始，提供了一個視圖V$SQL_PLAN，可以通過它幫助我們找到那些全表掃描或者Fast Full Index掃描的Sql語句：

查找全表掃描的SQL語句

Select sql_text from v$sqltext t, v$sql_plan p

Where t.hash_value=p.hash_value

And p.operation=’TABLE ACCESS’

And p.option=’FULL’

Order by p.hash-value, t.piece;


查找Fast Full index 掃描的Sql語句可以這樣；

Select sql_text from v$sqltext t, v$sql_plan p

Where t.hash_value=p.hash_value

And p.operation=’INDEX’

And p.option=’FULL SCAN’

Order by p.hash-value, t.piece;


如果是Oracle8i的數(shù)據(jù)庫，可以通過v$session_event視圖中找到關(guān)于這個等待事件的進程sid，然后根據(jù)這個sid來跟蹤相應(yīng)會話的SQL

Select sid, event from v$session_event

Where event=’db file sequential read’


或者可以通過查看物理讀取最多的SQL語句的執(zhí)行計劃，看是否里面包含了全表掃描和Fast Full Index掃描，可以通過以下語句獲取物理讀取最多的SQL語句

Select sql_text from

Select *from v$sqlarea

Order by disk_reads)

Where rownum<10


方法二：

有時候執(zhí)行計劃很好也會出現(xiàn)多block掃描的情況，這個時候可以通過調(diào)整Oracle數(shù)據(jù)庫的多block的I/O，來設(shè)置一個合理的DB_FILE_MULTIBLOCK_READ_COUNT,使得盡量滿足；

Db_block_size * DB_FILE_MULTIBLOCK_READ_COUNT = max io size of system

這個參數(shù)也不是設(shè)置的越大越好，設(shè)置這個參數(shù)之前需要了解一下應(yīng)用的類型，如果是OLTP類型的，一般來說全表掃描較少，這個時候如果設(shè)置了比較大反而會降低數(shù)據(jù)庫的性能，因為CBO在某些情況下會因為多block讀取導(dǎo)致COST比較低從而錯誤的選用了全表掃描。

其他方法

還可以采用對表和索引使用分區(qū)、將緩存區(qū)的LRU末端的全表掃描和FastFullIndex掃描的block放入到Keep緩存池等方法來進行調(diào)節(jié)。

db file sequential read

秋風(fēng)No.1

是原創(chuàng)嘛?

好帖啊!

llei2008

學(xué)習(xí)中...

kaka_wang

頂了，好東東，看看！

OCPHUI

好貼﹐當(dāng)然要頂!

yiyaya2000

樓主辛苦.回帖是好習(xí)慣!

algol

好，頂

netsure

謝謝！

tianshezi

要求給LZ加精