|
Oracle Statspack報(bào)告中各項(xiàng)指標(biāo)含義詳解~~學(xué)習(xí)性能必看?。。?/strong> Data Buffer Hit Ratio#<#90# 數(shù)據(jù)塊在數(shù)據(jù)緩沖區(qū)中的命中率,，通常應(yīng)該在90%以上,，否則考慮加大 db_block_buffers(9i 以上可是db_cache_size) Buffer Nowait Ratio#<#99# 在緩沖區(qū)中獲取buffer 的未等待比率 Library Hit Ratio#<#98# 主要代表著sql在共享區(qū)的命中率，通常在98%以上 In Memory Sort Ratio#<#0# 如果過(guò)低說(shuō)明有大量的排序在臨時(shí)表空間中進(jìn)行，可嘗試增加sort_area_size Redo Nowait Ratio#<#98# 寫日志的不等待比率,太低可調(diào)整log_buffer(增加)和 _log_io_size(減小,，默認(rèn)為1/3*log_buffer/log_block_size,使得 _log_io_size 為合適的值，比如128k/log_block_size) Soft Parse Ratio#<#90# 近似當(dāng)作sql在共享區(qū)的命中率,，通常高代表使用了綁定變量,太低需要調(diào)整應(yīng)用使用綁定變量,，或者參考cursor_sharing = force (9i 中增加了 similar ) Latch Hit Ratio#<#99# 內(nèi)部結(jié)構(gòu)維護(hù)鎖命中率，高于99%,通常低是因?yàn)閟hared_pool_size過(guò)大和沒(méi)有使用綁定變量導(dǎo)致硬解析過(guò)多,，可參考 _spin_count 參數(shù)設(shè)置 Percent Non-Parse CPU#<#95# 查詢實(shí)際運(yùn)行時(shí)間/(查詢實(shí)際運(yùn)行時(shí)間+sql解析時(shí)間),，太低表示解析消耗時(shí)間過(guò)長(zhǎng) Percent Parse CPU to Parse Elapsed#<#90# 解析實(shí)際所用時(shí)間/(解析實(shí)際所用時(shí)間+解析中等待資源時(shí)間),越高越好 Execute to Parse Percent#<#10# 該值越高表示一次解析后被重復(fù)執(zhí)行的次數(shù)越多，如果過(guò)低可以考慮設(shè)置 session_cached_cursors > 0 Memory Usage Percent#<#75# 共享池的使用率,，應(yīng)該穩(wěn)定在75%--90%之間,，太小浪費(fèi)內(nèi)存，太大則顯內(nèi)存不足 Percent of SQLs with Execution>1#<#40# 執(zhí)行次數(shù)大于1的sql的比率（若太小可能是沒(méi)有使用綁定變量） Percent of Memory for SQl with Execution>1#<#0# 執(zhí)行次數(shù)大于1的sql消耗內(nèi)存/(所有sql消耗內(nèi)存) Instance Load Profile Redo Size/Sec#>#100000# 每秒產(chǎn)生的日志大?。▎挝蛔止?jié)），可標(biāo)志數(shù)據(jù)庫(kù)任務(wù)的繁重與否 Redo Size/Tx#>#0# 平均每個(gè)事務(wù)的日志生成量 Logical Reads/Sec(邏輯讀)#>#0# 平均每秒產(chǎn)生的邏輯讀,單位是block Logical Reads/Tx#>#0# 平均每個(gè)事務(wù)產(chǎn)生的邏輯讀,單位是block Block Changes/Sec#>#100# 每秒block變化數(shù)量,，數(shù)據(jù)庫(kù)事務(wù)帶來(lái)改變的塊數(shù)量 Block Changes/Tx#>#0# 平均每個(gè)事務(wù)所導(dǎo)致的改變的塊數(shù) Physical Reads/Sec#>#100# 平均每秒數(shù)據(jù)庫(kù)從磁盤讀取的block數(shù) Physical Reads/Tx#>#0# 平均每個(gè)事務(wù)從磁盤讀取的block數(shù) Physical Write/Sec#>#50# 平均每秒寫磁盤的block數(shù) Physical Write/Tx#>#0# 平均每個(gè)事務(wù)寫磁盤的block數(shù) User Calls/Sec#>#0# 每秒用戶call次數(shù) User Calls/Tx#>#0# 每事務(wù)用戶call次數(shù) Parses/Sec#>#100# 每秒解析次數(shù),，近似反應(yīng)了每秒語(yǔ)句的執(zhí)行次數(shù) Parses/Tx#>#0# 每事務(wù)產(chǎn)生的解析次數(shù) Hard Parses/Sec#>#10# 每秒產(chǎn)生的硬解析次數(shù) Hard Parses/Tx#>#0# 每事務(wù)產(chǎn)生的硬解析次數(shù) Sorts/Sec#>#20# 每秒產(chǎn)生的排序次數(shù) Sorts/Tx#>#5# 每事務(wù)產(chǎn)生的排序次數(shù) Transactions/Sec#>#0# 每秒產(chǎn)生的事務(wù)數(shù) Rows/Sort#>#0# 每次排序所涉及到的行數(shù) Percent of Block Changed/Read#>#0# 發(fā)生變化的塊數(shù)/讀次數(shù)，變化的塊需要從回滾段來(lái)數(shù)據(jù) Recursive Call Percent#>#0# 遞歸操作占所有操作的比率 Rollback/Tx Percent#>#5# 事務(wù)回滾率（回滾開(kāi)銷很大） Executes/Sec#>#0# 每秒執(zhí)行次數(shù) Execute/Tx#>#0# 每個(gè)事務(wù)執(zhí)行次數(shù) Logons/Sec --46: Logons/Tx I/O Statistics(I/O統(tǒng)計(jì)數(shù)據(jù)) Table Space I/O#>#0# 表示各表空間在IO上的分布,，若出現(xiàn)嚴(yán)重不均衡,，則要重新考慮對(duì)象的存儲(chǔ)規(guī)劃和數(shù)據(jù)文件的磁盤規(guī)劃 Datafile I/O#>#0# 表示各數(shù)據(jù)文件的IO分布，若不均衡則需要重新考慮對(duì)象的存儲(chǔ)規(guī)劃 Table I/O（表I/O）#>#0# 對(duì)這些IO很大的表,，要考慮放置在高速磁盤上,，并且盡可能的分布在不同的磁盤上 TOP SQL Top SQL with High Buffer Gets#>#0# 這類sql進(jìn)行了大量的block的讀，要檢查該sql是否用到了索引,，或者說(shuō)表上是否存在合理的索引,，對(duì)于必須全表掃描的大表可以考慮recycle buffer ,對(duì)于頻繁進(jìn)行全表掃描的小表可以考慮keep buffer，還有一種需要注意的情況就是如果通過(guò)索引獲取數(shù)據(jù)比例占表數(shù)據(jù)比例過(guò)大,，比如20%(舉例數(shù)據(jù)),，就能導(dǎo)致buffer gets過(guò)大 Top SQL with High Physical Reads#>#0# 這類sql導(dǎo)致了大量的從磁盤獲取數(shù)據(jù)，可能因?yàn)閿?shù)據(jù)緩沖區(qū)太小,，也可能是過(guò)多的全表掃描,，需要考察索引是否合理，是否用到索引 Top SQL with High Execution Count#>#0# 這類sql是需要重點(diǎn)關(guān)注的,，也許這些sql本身一次執(zhí)行并沒(méi)有消耗大量的時(shí)間或者空間,，但由于頻繁的執(zhí)行對(duì)系統(tǒng)影響極大，所以只要有優(yōu)化的可能到要對(duì)這些sql進(jìn)行優(yōu)化,。還有另外一些情況,，就是某些程序中可能大量頻繁地使用dual表來(lái)獲取一些信息(比如時(shí)間的計(jì)算等)，盡可能的使這類sql轉(zhuǎn)化為應(yīng)用本地能解決的函數(shù),，或者還存在一些由于設(shè)計(jì)上的缺陷導(dǎo)致不必要的查詢,，都要在設(shè)計(jì)的角度避免這些查詢 Top SQL with High Shared Memory#>#0# 這類sql使用了大量的內(nèi)存,，不一定執(zhí)行的頻繁，但是它可能把執(zhí)行的頻繁的sql涉及的一些數(shù)據(jù)擠出緩沖區(qū),，這同樣將導(dǎo)致很多問(wèn)題,，所以也需要從盡可能的優(yōu)化 Top SQL with High Version Count#>#20# 表示多個(gè)用戶的sql在字面上是一樣的，或者sql雖然一樣但是session的一些參數(shù)發(fā)生了改變（比如sort_area_size發(fā)生了變化） Wait Events(等待事件) alter system set mts_dispatcher#>#0# 當(dāng)會(huì)話決定執(zhí)行"ALTER SYSTEM SET MTS_DISPATCHERS = <string> "的時(shí)候等待DISPATCHERS的啟動(dòng) BFILE check if exists#>#0# 檢查外部的bfile文件是否存在 BFILE check if open#>#0# 檢查外部的bfile文件是否已經(jīng)open BFILE closure#>#0# 等待關(guān)閉外部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被打開(kāi) BFILE read#>#0# 等待外部bfile文件讀取完畢 buffer busy due to global cache#>#0# buffer busy waits#>#0# block正被讀入緩沖區(qū)或者緩沖區(qū)正被其他session使用,出現(xiàn)此情況通?？赡芡ㄟ^(guò)幾種方式調(diào)整:增大data buffer,增加freelist,，減小pctused,增加回滾段數(shù)目，增大initrans,考慮使用LMT buffer deadlock#>#0# 由于系統(tǒng)緩慢所產(chǎn)生而非應(yīng)用產(chǎn)生了死鎖 buffer latch#>#0# 會(huì)話等待'buffer hash chain latch' buffer read retry#>#0# OPS下讀buffer的過(guò)程中內(nèi)容發(fā)生了變化于是重新讀取 Cache simulator heap#>#0# checkpoint completed#>#0# 等待檢查點(diǎn)的完成,，通常出現(xiàn)這個(gè)問(wèn)題的原因是IO問(wèn)題嚴(yán)重,，可調(diào)整跟檢查點(diǎn)相關(guān)參數(shù)log_checkpoint_interval,log_checkpoint_timeout,db_block_max_dirty_target,fast_start_io_target 等，可間接的增大日志文件大小和增加日志文件組數(shù) Contacting SCN server or SCN lock master#>#0# control file parallel write#>#0# 等待寫所有控制文件的完成,，可將控制文件分散在不同的磁盤上 control file sequential read#>#0# 讀控制文件,，在備份控制文件、OPS等情況下產(chǎn)生 control file single write#>#0# OPS下同一時(shí)刻只允許一個(gè)session將共享信息寫入磁盤 conversion file read#>#0# db file parallel read#>#0# 做恢復(fù)的并行從數(shù)據(jù)文件獲取數(shù)據(jù) db file parallel write#>#0# 當(dāng)多個(gè)IO可以同時(shí)發(fā)生時(shí)(多磁盤),，DBWR可并行寫入,，DBWR等待最后一個(gè)IO的完成 db file scattered read#>#0# 一次獲取的block被分散在buffer的不連續(xù)空間中，通常表示全表掃描過(guò)多,，可檢查應(yīng)用程序是否合理的使用了索引,，數(shù)據(jù)庫(kù)是否合理的創(chuàng)建了索引 db file sequential read#>#0# 通常暗示著通過(guò)索引獲取數(shù)據(jù)量比較大（比如通過(guò)索引進(jìn)行范圍掃描獲取表數(shù)據(jù)百分比過(guò)大），多表連接的時(shí)候連接順序不當(dāng),，hash join時(shí)hash_area_size無(wú)法容納hash table db file single write#>#0# 更新數(shù)據(jù)文件頭出現(xiàn)等待 debugger command#>#0# DFS db file lock#>#0# OPS下每個(gè)實(shí)例在數(shù)據(jù)文件上有一個(gè)共享的全局鎖,，當(dāng)要offline數(shù)據(jù)文件的時(shí)候等候其他實(shí)例同步文件 DFS lock handle#>#0# 會(huì)話等待一個(gè)全局鎖請(qǐng)求 direct path read#>#0# 通常發(fā)生在臨時(shí)表空間排序、并行查詢中 direct path read (lob) #>#0# direct path write#>#0# direct方式導(dǎo)入數(shù)據(jù)(sqlldr,CTAS),、PDML,、臨時(shí)表空間排序 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# 對(duì)共享資源的獲取要求一種排隊(duì)(FIFO)的機(jī)制以保護(hù)共享資源， ST enqueue表示空間分配或者釋放導(dǎo)致的問(wèn)題可采用LMT表空間來(lái)避免,， TX enqueue主要產(chǎn)生于唯一索引重復(fù),、bitmap index 的頻繁更新、initrans太小或者pctfree過(guò)小 file identify#>#0# file open#>#0# free buffer waits#>#0# 在緩沖區(qū)中尋找可用buffer出現(xiàn)等待,，可能數(shù)據(jù)緩沖區(qū)太小,，也可能檢查點(diǎn)間隔太長(zhǎng)，也可能頻繁的DML而IO成為瓶頸 free global transaction table entry#>#0# 分布式數(shù)據(jù)庫(kù)中會(huì)話等待一個(gè)全局事務(wù)槽 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# 會(huì)話等待將一個(gè)buffer從當(dāng)前共享狀態(tài)轉(zhuǎn)換為當(dāng)前獨(dú)占狀態(tài) 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# 當(dāng)在索引中查找一個(gè)key的時(shí)候如果發(fā)現(xiàn)該索引block正在裂變則等待裂變完成 io done#>#0# 會(huì)話等待IO的完成 KSIM GDS request cancel#>#0# latch activity#>#0# latch free#>#0# latch是一種維護(hù)內(nèi)存的鎖,，不采用排隊(duì)機(jī)制,，快速的獲取然后很快釋放，造成的原因通常有程序沒(méi)有使用綁定變量,、shared_pool_size設(shè)置過(guò)大（比如1G）,、LRU競(jìng)爭(zhēng)、某些塊過(guò)熱（訪問(wèn)太頻繁） LGWR wait for redo copy#>#0# 表示等待redo allocation and redo copy latches,可增加 _log_simulteneous_copies(默認(rèn)為 2*CPUs)，但同時(shí)也容易引入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參數(shù)文件中增大 log_buffer,置日志文件于高速磁盤上 log file parallel write#>#0# 當(dāng)lgwr寫日志文件的過(guò)程中出現(xiàn)等待,，這個(gè)等待通常會(huì)導(dǎo)致 log file sync事件,放置日志文件于高速磁盤上 log file sequential read#>#0# log file single write#>#0# log file switch (archiving needed)#>#0# 當(dāng)日志切換的時(shí)候由于日志組循環(huán)使用了一圈但日志歸檔還沒(méi)有完成,，通常是io有嚴(yán)重問(wèn)題，可增大日志文件和增加日志組,，調(diào)整log_archive_max_processes log file switch (checkpoint incomplete)#>#0# 當(dāng)日志切換的時(shí)候由于日志組循環(huán)使用了一圈但將被使用的日志組中的checkpoint還沒(méi)有完成造成,，通常是io有嚴(yán)重問(wèn)題，可增大日志文件和增加日志組 log file switch (clearing log file)#>#0# log file switch completion#>#0# write complete waits#>#0# 用戶等候buffer被寫進(jìn)文件,，暗示著寫數(shù)據(jù)文件等待 log file sync#>#0# 當(dāng)用戶commit的時(shí)候通知lgwr寫日志但lwgr正忙,，造成的可能原因是commit太頻繁或者lgwr一次寫日志時(shí)間太長(zhǎng)（可能是因?yàn)橐淮蝜og io size 太大），可調(diào)整 _log_io_size,，結(jié)合log_buffer,使得(_log_io_size*db_block_size)*n = log_buffer,這樣可避免和增大log_buffer引起沖突;置日志文件于高速磁盤上 log file sync ： 當(dāng)某個(gè)因素導(dǎo)致需要寫 redo 進(jìn) file的時(shí)候（通常是commit發(fā)生）,，發(fā)現(xiàn) lgwr 正在寫，而產(chǎn)生等待 造成的因素： 1： commit 太頻繁（這個(gè)道理的解釋可以說(shuō)比如我們?nèi)ナ程脦э?，一次帶一盒跟一次?合）,，雖然2合可能多消耗一點(diǎn)力氣，但這個(gè)來(lái)回的準(zhǔn)備動(dòng)作可以看做進(jìn)程之間的通信,、磁頭的控制權(quán)的獲取等等硬件因素,，所以不是簡(jiǎn)單的1次寫100k等于50k寫2次,一次寫100的代價(jià)會(huì)小于2次寫50k，但問(wèn)題在于如果有在剛開(kāi)始寫之后有其他commit發(fā)生,，該commit可能在第一次50k寫完之后就開(kāi)始寫入，這樣只等待50k的時(shí)間而不用等待100k的寫時(shí)間,。這是很微小的發(fā)生在commit不頻繁但是大事務(wù)經(jīng)常存在的時(shí)候的現(xiàn)象,。這個(gè)時(shí)候調(diào)整_log_io_size 或許能產(chǎn)生效果 2： 但若一次寫的太多也可能導(dǎo)致該等待事件的出現(xiàn)3： 從IO本身的快慢來(lái)講，更容易造成該事件,，所以我們?cè)贗O方面來(lái)考慮更直接有效 [ 本帖最后由 mfkqwyc86 于 2010-12-5 15:28 編輯 ] |
|
|
來(lái)自： 浸心閣 > 《statspack》
