oracle 在线表分析报告,Oracle 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
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.負載間檔
該部分提供每秒和每個事物的統計信息，是監控系統吞吐量和負載變化的重要部分。
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.實例命中率
該部分可以提前找出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%，這是很好的，說明計算機執行的大部分工作是執行查詢的工作，而不是分析查詢的工作。
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%。這是一個受觀察之間持續時間影響的統計數字。可以期望它隨觀察之間的時間長度增大而增大。
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: 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
-------------------------------------------------------------
創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎總結
以上是生活随笔為你收集整理的oracle 在线表分析报告,Oracle Statspack分析报告详解（一）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： php stdin是什么意思,php：/
- 下一篇： oracle的parse是什么意思,Or