Oracle Statspack報告中各項指標含義詳解

今天在ITPUB看到介紹Statspack文章，還不錯，現在轉載下

轉載之：http://www.itpub.net/thread-1368543-1-1.html

 

Oracle Statspack報告中各項指標含義詳解

Data Buffer Hit Ratio#資料塊在資料緩衝區中的命中率，通常應該在90%以上，否則考慮加大 db_block_buffers(9i 以上可是db_cache_size)

Buffer Nowait Ratio#
在緩衝區中獲取buffer 的未等待比率

Library Hit Ratio#

主要代表著sql在共享區的命中率，通常在98%以上

In Memory Sort Ratio#
如果過低說明有大量的排序在臨時表空間中進行，可嘗試增加sort_area_size

Redo Nowait Ratio#
寫日誌的不等待比率,太低可調整log_buffer(增加)和 _log_io_size(減小，預設為1/3*log_buffer/log_block_size,使得 _log_io_size 為合適的值，比如128k/log_block_size)

Soft Parse Ratio#

近似當作sql在共享區的命中率，通常高代表使用了繫結變數,太低需要調整應用使用繫結變數，或者參考cursor_sharing = force (9i 中增加了 similar )

Latch Hit Ratio#
內部結構維護鎖命中率，高於99%,通常低是因為shared_pool_size過大和沒有使用繫結變數導致硬解析過多，可參考 _spin_count 引數設定

Percent Non-Parse CPU#
查詢實際執行時間/(查詢實際執行時間+sql解析時間)，太低表示解析消耗時間過長

Percent Parse CPU to Parse Elapsed#

解析實際所用時間/(解析實際所用時間+解析中等待資源時間),越高越好

Execute to Parse Percent#
該值越高表示一次解析後被重複執行的次數越多，如果過低可以考慮設定
session_cached_cursors > 0

Memory Usage Percent#

共享池的使用率，應該穩定在75%--90%之間，太小浪費記憶體，太大則顯記憶體不足

Percent of SQLs with Execution>1#

執行次數大於1的sql的比率（若太小可能是沒有使用繫結變數）

Percent of Memory for SQl with Execution>1#
執行次數大於1的sql消耗記憶體/(所有sql消耗記憶體)

Instance Load Profile Redo Size/Sec#>#100000#  

每秒產生的日誌大小（單位位元組），可標誌資料庫任務的繁重與否

Redo Size/Tx#>#0#  

平均每個事務的日誌生成量

Logical Reads/Sec(邏輯讀)#>#0#

平均每秒產生的邏輯讀,單位是block

Logical Reads/Tx#>#0#

平均每個事務產生的邏輯讀,單位是block

Block Changes/Sec#>#100#  

每秒block變化數量，資料庫事務帶來改變的塊數量

Block Changes/Tx#>#0#  

平均每個事務所導致的改變的塊數

Physical Reads/Sec#>#100#  

平均每秒資料庫從磁碟讀取的block數

Physical Reads/Tx#>#0#  

平均每個事務從磁碟讀取的block數

Physical Write/Sec#>#50#  

平均每秒寫磁碟的block數

Physical Write/Tx#>#0#  

平均每個事務寫磁碟的block數

User Calls/Sec#>#0#  

每秒使用者call次數

User Calls/Tx#>#0#

每事務使用者call次數

Parses/Sec#>#100#  

每秒解析次數，近似反應了每秒語句的執行次數

Parses/Tx#>#0#  

每事務產生的解析次數

Hard Parses/Sec#>#10#  

每秒產生的硬解析次數

Hard Parses/Tx#>#0#  

每事務產生的硬解析次數

Sorts/Sec#>#20#  

每秒產生的排序次數

Sorts/Tx#>#5#

每事務產生的排序次數

Transactions/Sec#>#0#  

每秒產生的事務數

Rows/Sort#>#0#

每次排序所涉及到的行數

Percent of Block Changed/Read#>#0#

發生變化的塊數/讀次數，變化的塊需要從回滾段來資料

Recursive Call Percent#>#0#  

遞迴操作佔所有操作的比率

Rollback/Tx Percent#>#5#  

事務回滾率（回滾開銷很大）

Executes/Sec#>#0#

每秒執行次數

Execute/Tx#>#0#  

每個事務執行次數

Logons/Sec --46: Logons/Tx  

I/O Statistics(I/O統計資料) Table Space I/O#>#0#
表示各表空間在IO上的分佈，若出現嚴重不均衡，則要重新考慮物件的儲存規劃和資料檔案的磁碟規劃


Datafile I/O#>#0#  

表示各資料檔案的IO分佈，若不均衡則需要重新考慮物件的儲存規劃

Table I/O（表I/O）#>#0#

對這些IO很大的表，要考慮放置在高速磁碟上，並且儘可能的分佈在不同的磁碟上

TOP SQL Top SQL with High Buffer Gets#>#0#  

這類sql進行了大量的block的讀，要檢查該sql是否用到了索引，或者說表上是否存在合理的索引，對於必須全表掃描的大表可以考慮recycle buffer ,對於頻繁進行全表掃描的小表可以考慮keep buffer，還有一種需要注意的情況就是如果通過索引獲取資料比例佔表資料比例過大，比如20%(舉例資料)，就能導致buffer gets過大

Top SQL with High Physical Reads#>#0#

這類sql導致了大量的從磁碟獲取資料，可能因為資料緩衝區太小，也可能是過多的全表掃描，需要考察索引是否合理，是否用到索引

Top SQL with High Execution Count#>#0#

這類sql是需要重點關注的，也許這些sql本身一次執行並沒有消耗大量的時間或者空間，但由於頻繁的執行對系統影響極大，所以只要有優化的可能到要對這些sql進行優化。還有另外一些情況，就是某些程式中可能大量頻繁地使用dual表來獲取一些資訊(比如時間的計算等)，儘可能的使這類sql轉化為應用本地能解決的函式，或者還存在一些由於設計上的缺陷導致不必要的查詢，都要在設計的角度避免這些查詢

Top SQL with High Shared Memory#>#0#  

這類sql使用了大量的記憶體，不一定執行的頻繁，但是它可能把執行的頻繁的sql涉及的一些資料擠出緩衝區，這同樣將導致很多問題，所以也需要從儘可能的優化

Top SQL with High Version Count#>#20#  

表示多個使用者的sql在字面上是一樣的，或者sql雖然一樣但是session的一些引數發生了改變（比如sort_area_size發生了變化）

Wait Events(等待事件) alter system set mts_dispatcher#>#0#  

當會話決定執行"ALTER SYSTEM SET MTS_DISPATCHERS = "的時候等待DISPATCHERS的啟動

BFILE check if exists#>#0#  

檢查外部的bfile檔案是否存在

BFILE check if open#>#0#  

檢查外部的bfile檔案是否已經open

BFILE closure#>#0#

等待關閉外部bfile檔案

BFILE get length#>#0#

獲得外部bfile檔案的大小

BFILE get name object#>#0#

得到外部bfile檔案的名字

BFILE get path object#>#0#  

得到外部bfile檔案的路徑

BFILE internal seek#>#0#  

BFILE open#>#0#
等待外部bfile被開啟

BFILE read#>#0#  

等待外部bfile檔案讀取完畢

buffer busy due to global cache#>#0#  

buffer busy waits#>#0#

block正被讀入緩衝區或者緩衝區正被其他session使用,出現此情況通常可能通過幾種方式調整:增大data buffer,增加freelist，減小pctused,增加回滾段數目，增大initrans,考慮使用LMT

buffer deadlock#>#0#  

由於系統緩慢所產生而非應用產生了死鎖

buffer latch#>#0#

會話等待'buffer hash chain latch'

buffer read retry#>#0#  

OPS下讀buffer的過程中內容發生了變化於是重新讀取

Cache simulator heap#>#0#  

checkpoint completed#>#0#
等待檢查點的完成，通常出現這個問題的原因是IO問題嚴重，可調整跟檢查點相關引數log_checkpoint_interval,log_checkpoint_timeout,db_block_max_dirty_target,fast_start_io_target 等，可間接的增大日誌檔案大小和增加日誌檔案組數

Contacting SCN server or SCN lock master#>#0#  

control file parallel write#>#0#  

等待寫所有控制檔案的完成，可將控制檔案分散在不同的磁碟上

control file sequential read#>#0#  

讀控制檔案，在備份控制檔案、OPS等情況下產生

control file single write#>#0#  

OPS下同一時刻只允許一個session將共享資訊寫入磁碟

conversion file read#>#0#  

db file parallel read#>#0#  

做恢復的並行從資料檔案獲取資料

db file parallel write#>#0#  

當多個IO可以同時發生時(多磁碟)，DBWR可並行寫入，DBWR等待最後一個IO的完成

db file scattered read#>#0#  

一次獲取的block被分散在buffer的不連續空間中，通常表示全表掃描過多，可檢查應用程式是否合理的使用了索引，資料庫是否合理的建立了索引

db file sequential read#>#0#  

通常暗示著通過索引獲取資料量比較大（比如通過索引進行範圍掃描獲取表資料百分比過大），多表連線的時候連線順序不當，hash join時hash_area_size無法容納hash table

db file single write#>#0#  

更新資料檔案頭出現等待

debugger command#>#0#  

DFS db file lock#>#0#  

OPS下每個例項在資料檔案上有一個共享的全域性鎖，當要offline資料檔案的時候等候其他例項同步檔案

DFS lock handle#>#0#

會話等待一個全域性鎖請求

direct path read#>#0#

通常發生在臨時表空間排序、並行查詢中

direct path read (lob) #>#0#

direct path write#>#0#  

direct方式匯入資料(sqlldr,CTAS)、PDML、臨時表空間排序

direct path write (lob)#>#0#  

dispatcher listen timer#>#0#  

dispatcher shutdown#>#0#  

dispatcher timer#>#0#  

DLM generic wait event#>#0#  

dupl. cluster key#>#0#  

enqueue#>#0#

對共享資源的獲取要求一種排隊(FIFO)的機制以保護共享資源，
ST enqueue表示空間分配或者釋放導致的問題可採用LMT表空間來避免，
TX enqueue主要產生於唯一索引重複、bitmap index 的頻繁更新、initrans太小或者pctfree過小

file identify#>#0#

file open#>#0#  

free buffer waits#>#0#  

在緩衝區中尋找可用buffer出現等待，可能資料緩衝區太小，也可能檢查點間隔太長，也可能頻繁的DML而IO成為瓶頸

free global transaction table entry#>#0#

分散式資料庫中會話等待一個全域性事務槽

free process state object#>#0#  

global cache bg acks#>#0#  

global cache cr request#>#0#  

global cache freelist wait#>#0#  

global cache lock busy#>#0#

會話等待將一個buffer從當前共享狀態轉換為當前獨佔狀態

global cache lock cleanup#>#0#  

global cache lock null to s#>#0#  


global cache lock null to x#>#0#  

global cache lock open s#>#0#  

global cache lock open x#>#0#  

global cache lock s to x#>#0#  

global cache multiple locks#>#0#

global cache pending ast#>#0#  

global cache pending asts#>#0#  

global cache retry prepare#>#0#

global cache retry request#>#0#  

imm op#>#0#  

inactive session#>#0#  

inactive transaction branch#>#0#  

index block split#>#0#

當在索引中查詢一個key的時候如果發現該索引block正在裂變則等待裂變完成

io done#>#0#

會話等待IO的完成

KSIM GDS request cancel#>#0#  

latch activity#>#0#  

latch free#>#0#  

latch是一種維護記憶體的鎖，不採用排隊機制，快速的獲取然後很快釋放，造成的原因通常有程式沒有使用繫結變數、shared_pool_size設定過大（比如1G）、LRU競爭、某些塊過熱（訪問太頻繁）

LGWR wait for redo copy#>#0#

表示等待redo allocation and redo copy latches,可增加 _log_simulteneous_copies(預設為 2*CPUs)，但同時也容易引入redo allocation latch contention,所以需要慎重

library cache load lock#>#0#

library cache lock#>#0#  

library cache pin#>#0#  

listen endpoint status#>#0#  

LMON wait for LMD to inherit communication channels#>#0#

local write wait#>#0#  

lock manager wait for dlmd to shutdown#>#0#  

lock manager wait for remote message#>#0#  

log buffer space#>#0#

生成日誌等待lgwr趕快寫檔案而騰出log buffer,可在init引數檔案中增大 log_buffer,置日誌檔案於高速磁碟上

log file parallel write#>#0#  

當lgwr寫日誌檔案的過程中出現等待，這個等待通常會導致 log file sync事件,放置日誌檔案於高速磁碟上

log file sequential read#>#0#  

log file single write#>#0#  

log file switch (archiving needed)#>#0#

當日志切換的時候由於日誌組迴圈使用了一圈但日誌歸檔還沒有完成，通常是io有嚴重問題，可增大日誌檔案和增加日誌組，調整log_archive_max_processes

log file switch (checkpoint incomplete)#>#0#

當日志切換的時候由於日誌組迴圈使用了一圈但將被使用的日誌組中的checkpoint還沒有完成造成，通常是io有嚴重問題，可增大日誌檔案和增加日誌組

log file switch (clearing log file)#>#0#  

log file switch completion#>#0#  

write complete waits#>#0#

使用者等候buffer被寫進檔案，暗示著寫資料檔案等待

log file sync#>#0#

當使用者commit的時候通知lgwr寫日誌但lwgr正忙，造成的可能原因是commit太頻繁或者lgwr一次寫日誌時間太長（可能是因為一次log io size 太大），可調整 _log_io_size，結合log_buffer,使得(_log_io_size*db_block_size)*n = log_buffer,這樣可避免和增大log_buffer引起衝突;置日誌檔案於高速磁碟上

log file sync
： 當某個因素導致需要寫 redo 進 file的時候（通常是commit發生），發現 lgwr 正在寫，而產生等待 造成的因素： 1： commit 太頻繁（這個道理的解釋可以說比如我們去食堂帶飯，一次帶一盒跟一次帶2合），雖然2合可能多消耗一點力氣，但這個來回的準備動作可以看做程式之間的通訊、磁頭的控制權的獲取等等硬體因素，所以不是簡單的1次寫100k等於50k寫2次,一次寫100的代價會小於2次寫50k，但問題在於如果有在剛開始寫之後有其他commit發生，該commit可能在第一次50k寫完之後就開始寫入，這樣只等待50k的時間而不用等待100k的寫時間。這是很微小的發生在commit不頻繁但是大事務經常存在的時候的現象。這個時候調整_log_io_size 或許能產生效果 2： 但若一次寫的太多也可能導致該等待事件的出現3： 從IO本身的快慢來講，更容易造成該事件，所以我們在IO方面來考慮更直接有效

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/8183550/viewspace-678197/，如需轉載，請註明出處，否則將追究法律責任。