主頁 > 知識庫 > oracle 常見等待事件及處理方法

oracle 常見等待事件及處理方法

熱門標(biāo)簽:地圖標(biāo)注原件 語音電話機(jī)器人缺點(diǎn) 廣州市400電話辦理 宜賓外呼系統(tǒng)廠家 修改高德地圖標(biāo)注 淮安自動外呼系統(tǒng)開發(fā) 南通防封外呼系統(tǒng)運(yùn)營商 百變地圖標(biāo)注 語音電話機(jī)器人營銷方案
看書筆記db file scattered read DB ,db file sequential read DB,free buffer waits,log buffer space,log file switch,log file sync
我們可以通過視圖v$session_wait來查看系統(tǒng)當(dāng)前的等待事件,以及與等待事件相對應(yīng)的資源的相關(guān)信息,從而可確定出產(chǎn)生瓶頸的類型及其對象。v$session_wait的p1、p2、p3告訴我們等待事件的具體含義,根據(jù)事件不同其內(nèi)容也不相同,下面就一些常見的等待事件如何處理以及如何定位熱點(diǎn)對象和阻塞會話作一些介紹。
1> db file scattered read DB 文件分散讀取 (太多索引讀,全表掃描-----調(diào)整代碼,將小表放入內(nèi)存)
這種情況通常顯示與全表掃描相關(guān)的等待。當(dāng)全表掃描被限制在內(nèi)存時,它們很少會進(jìn)入連續(xù)的緩沖區(qū)內(nèi),而是分散于整個緩沖存儲器中。如果這個數(shù)目很大,就表明該表找不到索引,或者只能找到有限的索引。盡管在特定條件下執(zhí)行全表掃描可能比索引掃描更有效,但如果出現(xiàn)這種等待時,最好檢查一下這些全表掃描是否必要。因?yàn)槿頀呙璞恢糜贚RU(Least Recently Used,最近最少適用)列表的冷端(cold end),所以應(yīng)盡量存儲較小的表,以避免一次又一次地重復(fù)讀取它們。
==================================================
該類事件的p1text=file#,p1是file_id,p2是block_id,通過dba_extents即可確定出熱點(diǎn)對象(表或索引)
select owner,segment_name,segment_type
from dba_extents
where file_id = file_id
and block_id between block_id and block_id + blocks - 1;
==================================================
2> db file sequential read DB 文件順序讀取 (表連接順序不佳-----調(diào)整代碼,特別是表連接)
這一事件通常顯示單個塊的讀取(如索引讀取)。這種等待的數(shù)目很多時,可能顯示表的連接順序不佳,或者不加選擇地進(jìn)行索引。對于大量事務(wù)處理、調(diào)整良好的系統(tǒng),這一數(shù)值大多是很正常的,但在某些情況下,它可能暗示著系統(tǒng)中存在問題。你應(yīng)當(dāng)將這一等待統(tǒng)計(jì)量與Statspack 報告中的已知問題(如效率較低的SQL)聯(lián)系起來。檢查索引掃描,以保證每個掃描都是必要的,并檢查多表連接的連接順序。DB_CACHE_SIZE 也是這些等待出現(xiàn)頻率的決定因素。有問題的散列區(qū)域(Hash-area)連接應(yīng)當(dāng)出現(xiàn)在PGA 內(nèi)存中,但它們也會消耗大量內(nèi)存,從而在順序讀取時導(dǎo)致大量等待。它們也可能以直接路徑讀/寫等待的形式出現(xiàn)。
===================================================
該類事件的p1text=file#,p1是file_id,p2是block_id,通過dba_extents即可確定出熱點(diǎn)對象(表或索引)
select owner,segment_name,segment_type
from dba_extents
where file_id = file_id
and block_id between block_id and block_id + blocks - 1;
==================================================
3> free buffer waits 釋放緩沖區(qū)等待 (增大DB_CACHE_SIZE,加速檢查點(diǎn),調(diào)整代碼)
這種等待表明系統(tǒng)正在等待內(nèi)存中的緩沖,因?yàn)閮?nèi)存中已經(jīng)沒有可用的緩沖空間了。如果所有SQL 都得到了調(diào)優(yōu),這種等待可能表示你需要增大DB_BUFFER_CACHE。釋放緩沖區(qū)等待也可能表示不加選擇的SQL 導(dǎo)致數(shù)據(jù)溢出了帶有索引塊的緩沖存儲器,沒有為等待系統(tǒng)處理的特定語句留有緩沖區(qū)。這種情況通常表示正在執(zhí)行相當(dāng)多數(shù)量的DML(插入/更新/刪除),并且數(shù)據(jù)庫書寫器(DBWR)寫的速度不夠快,緩沖存儲器可能充滿了相同緩沖器的多個版本,從而導(dǎo)致效率非常低。為了解決這個問題,可能需要考慮增加檢查點(diǎn)、利用更多的DBWR 進(jìn)程,或者增加物理磁盤的數(shù)量。
4> buffer busy waits 緩沖區(qū)忙等待 (BUFFER熱塊)
這是為了等待一個以非共享方式使用的緩沖區(qū),或者正在被讀入緩沖存儲器的緩沖區(qū)。緩沖區(qū)忙等待不應(yīng)大于1%。檢查緩沖等待統(tǒng)計(jì)部分(或V$WAITSTAT):
A、如果等待處于字段頭部,應(yīng)增加自由列表(freelist)的組數(shù),或者增加pctused到pctfree之間的距離。
B、如果等待處于回退段(undo)頭部塊,可以通過增加回滾段(rollback segment)來解決緩沖區(qū)的問題;
C、如果等待處于回退段(undo)非頭部塊上,就需要降低驅(qū)動一致讀取的表中的數(shù)據(jù)密度,或者增大DB_CACHE_SIZE;
D、如果等待處于數(shù)據(jù)塊,可以將數(shù)據(jù)移到另一數(shù)據(jù)塊以避開這個"熱"數(shù)據(jù)塊、增加表中的自由列表或使用LMT表空間;
E、如果等待處于索引塊,應(yīng)該重建索引、分割索引或使用反向鍵索引。
為了防止與數(shù)據(jù)塊相關(guān)的緩沖忙等待,也可以使用較小的塊:在這種情況下,單個塊中的記錄就較少,所以這個塊就不是那么"繁忙"。在執(zhí)行DML(插入/更新/刪除)時,Oracle DBWR就向塊中寫入信息,包括所有對塊狀態(tài)"感興趣"的用戶(感興趣的事務(wù)表,ITL)。為減少這一區(qū)域的等待,可以增加initrans,這樣會在塊中創(chuàng)建空間,從而使你能夠使用多個ITL槽。你也可以增加該塊所在表中的pctfree(當(dāng)根據(jù)指定的initrans 建立的槽數(shù)量不足時,這樣可以使ITL 信息數(shù)量達(dá)到maxtrans 指定的數(shù)量)。
6> enqueue
enqueue 是一種保護(hù)共享資源的鎖定機(jī)制。該鎖定機(jī)制保護(hù)共享資源,如記錄中的數(shù)據(jù),以避免兩個人在同一時間更新同一數(shù)據(jù)。enqueue 包括一個排隊(duì)機(jī)制,即FIFO(先進(jìn)先出)排隊(duì)機(jī)制。注意:Oracle 的latch 機(jī)制不是FIFO。Enqueue 等待通常指的是ST enqueue、HW enqueue、TX4 enqueue 和TM enqueue。
A、ST enqueue 用于空間管理和字典管理的表空間的分配。利用LMT,或者試圖對區(qū)域進(jìn)行預(yù)分配,或者至少使下一個區(qū)域大于有問題的字典管理的表空間。
B、HW enqueue 與段的高水位標(biāo)記一起使用;手動分配區(qū)域可以避免這一等待。
C、TX4 enqueue是最常見的enqueue 等待,通常是以下三個問題之一產(chǎn)生的結(jié)果:
第一個問題是唯一索引中的重復(fù)索引,需要執(zhí)行提交(commit)/回滾(rollback)操作來釋放enqueue。
第二個問題是對同一位圖索引段的多次更新。因?yàn)閱蝹€位圖段可能包含多個行地址(rowid),所以當(dāng)多個用戶試圖更新同一段時,你需要執(zhí)行提交或回滾操作,以釋放enqueue。
第三個問題,也是最可能發(fā)生的問題是多個用戶同時更新同一個塊。如果沒有自由的ITL槽,就會發(fā)生塊級鎖定。通過增大initrans 和/或maxtrans以允許使用多個ITL槽,或者增大表上的pctfree 值,就可以很輕松地避免這種情況。
D、TM enqueue 在DML 期間產(chǎn)生,以避免對受影響的對象使用DDL。如果有外來關(guān)鍵字,一定要對它們進(jìn)行索引,以避免這種常見的鎖定問題。
7> log buffer space 日志緩沖空間 (寫REDO慢-----增大log_buffer,redo log file放到快速磁盤上)
當(dāng)日志緩沖(log buffer)寫入重做日志(redo log)的速度比LGWR 的寫入速度慢,或者是當(dāng)日志轉(zhuǎn)換(log switch)太慢時,就會發(fā)生這種等待。為解決這個問題,可以增大日志文件的大小,或者增加日志緩沖器的大小,或者使用寫入速度更快的磁盤。甚至可以考慮使用固態(tài)磁盤,因?yàn)樗鼈兊乃俣群芨摺?
8> log file switch 日志文件轉(zhuǎn)換 (歸檔慢-----增加或者擴(kuò)大重做日志)
有兩種情況:
A、log file switch (archiving needed)
當(dāng)日志切換的時候由于日志組循環(huán)使用了一圈但日志歸檔還沒有完成,通常是io有嚴(yán)重問題,可增大日志文件和增加日志組,調(diào)整log_archive_max_processes
B、log file switch (checkpoint incomplete)
當(dāng)日志切換的時候由于日志組循環(huán)使用了一圈但將被使用的日志組中的checkpoint還沒有完成造成,通常是io有嚴(yán)重問題,可增大日志文件和增加日志組
9> log file sync 日志文件同步 (提交太頻繁----批量提交)
當(dāng)用戶commit的時候通知lgwr寫日志但lwgr正忙,造成的可能原因是commit太頻繁或者lgwr一次寫日志時間太長(可能是因?yàn)橐淮蝜og io size 太大),可調(diào)整 _log_io_size,結(jié)合log_buffer,使得 (_log_io_size*db_block_size)*n = log_buffer,這樣可避免和增大log_buffer引起沖突;放置日志文件于高速磁盤上
10> library cache pin
該事件通常是發(fā)生在先有會話在運(yùn)行PL/SQL,VIEW,TYPES等object時,又有另外的會話執(zhí)行重新編譯這些object,即先給對象加上了一個共享鎖,然后又給它加排它鎖,這樣在加排它鎖的會話上就會出現(xiàn)這個等待。P1,P2可與x$kglpn和x$kglob表相關(guān)
X$KGLOB (Kernel Generic Library Cache Manager Object)
X$KGLPN (Kernel Generic Library Cache Manager Object Pins)
-- 查詢X$KGLOB,可找到相關(guān)的object,其SQL語句如下
(即把V$SESSION_WAIT中的P1raw與X$KGLOB中的KGLHDADR相關(guān)連)
select kglnaown,kglnaobj from X$KGLOB
where KGLHDADR =(select p1raw from v$session_wait
where event='library cache pin')
-- 查出引起該等待事件的阻塞者的sid
select sid from x$kglpn , v$session
where KGLPNHDL in
(select p1raw from v$session_wait
where wait_time=0 and event like 'library cache pin%')
and KGLPNMOD > 0
and v$session.saddr=x$kglpn.kglpnuse
-- 查出阻塞者正執(zhí)行的SQL語句
select sid,sql_text
from v$session, v$sqlarea
where v$session.sql_address=v$sqlarea.address
and sid=阻塞者的sid>
這樣,就可找到"library cache pin"等待的根源,從而解決由此引起的性能問題。
11> library cache lock
該事件通常是由于執(zhí)行多個DDL操作導(dǎo)致的,即在library cache object上添加一個排它鎖后,又從另一個會話給它添加一個排它鎖,這樣在第二個會話就會生成等待??赏ㄟ^到基表x$kgllk中查找其對應(yīng)的對象。
-- 查詢引起該等待事件的阻塞者的sid、會話用戶、鎖住的對象
select b.sid,a.user_name,a.kglnaobj
from x$kgllk a , v$session b
where a.kgllkhdl in
(select p1raw from v$session_wait
where wait_time=0 and event = 'library cache lock')
and a.kgllkmod > 0
and b.saddr=a.kgllkuse
當(dāng)然也可以直接從v$locked_objects中查看,但沒有上面語句直觀根據(jù)sid可以到v$process中查出pid,然后將其kill或者其它處理。
5> latch free (等待LATCH FREE)
latch是一種低級排隊(duì)機(jī)制(它們被準(zhǔn)確地稱為相互排斥機(jī)制),用于保護(hù)系統(tǒng)全局區(qū)域(SGA)中共享內(nèi)存結(jié)構(gòu)。latch 就像是一種快速地被獲取和釋放的內(nèi)存鎖。latch 用于防止共享內(nèi)存結(jié)構(gòu)被多個用戶同時訪問。如果latch 不可用,就會記錄latch 釋放失敗。大多數(shù)latch 問題都與以下操作相關(guān):不能使用邦定變量(庫緩存latch)、重復(fù)生成問題(重復(fù)分配latch)、緩沖存儲器競爭問題(緩沖器存儲LRU 鏈),以及緩沖存儲器中的"熱"塊(緩沖存儲器鏈)。也有一些latch 等待與bug(程序錯誤)有關(guān),如果懷疑是這種情況,可以檢查MetaLink 上的bug 報告。
該事件的熱點(diǎn)對象可通過以下語句查找,其中2值是v$session_wait中的P1RAW,x$bh中的字段Hladdr表示該block buffer在哪個cache buffer chain latch 上,可以通過v$latch_children定位哪些segment是熱點(diǎn)塊。
===================================================
select a.hladdr, a.file#, a.dbablk, a.tch, a.obj, b.object_name
from x$bh a, dba_objects b
where (a.obj = b.object_id or a.obj = b.data_object_id)
and a.hladdr = 2
union
select hladdr, file#, dbablk, tch, obj, null
from x$bh
where obj in
(select obj from x$bh
where hladdr = 2
minus
select object_id from dba_objects
minus
select data_object_id from dba_objects)
and hladdr = 2
order by 4;
====================================================
***Latch 問題及可能解決辦法
------------------------------
* Library Cache and Shared Pool (未綁定變量---綁定變量,調(diào)整shared_pool_size)
每當(dāng)執(zhí)行SQL或PL/SQL存儲過程,包,函數(shù)和觸發(fā)器時,這個Latch即被用到.Parse操作中此Latch也會被頻繁使用.
* Redo Copy (增大_LOG_SIMULTANEOUS_COPIES參數(shù))
重做拷貝Latch用來從PGA向重做日志緩沖區(qū)拷貝重做記錄.
* Redo Allocation (最小化REDO生成,避免不必要提交)
此Latch用來分配重做日志緩沖區(qū)中的空間,可以用NOLOGGING來減緩競爭.
* Row Cache Objects (增大共享池)
數(shù)據(jù)字典競爭.過度parsing.
* Cache Buffers Chains (_DB_BLOCK_HASH_BUCKETS應(yīng)增大或設(shè)為質(zhì)數(shù))
"過熱"數(shù)據(jù)塊造成了內(nèi)存緩沖鏈Latch競爭.
* Cache Buffers Lru Chain (調(diào)整SQL,設(shè)置DB_BLOCK_LRU_LATCHES,或使用多個緩沖區(qū)池)
掃描全部內(nèi)存緩沖區(qū)塊的LRU(最近最少使用)鏈時要用到內(nèi)存緩沖區(qū)LRU鏈Latch.太小內(nèi)存緩沖區(qū)、過大的內(nèi)存緩沖區(qū)吞吐量、過多的內(nèi)存中進(jìn)行的排序操作、DBWR速度跟不上工作負(fù)載等會引起此Latch競爭。
12> db file parallel write
與DBWR進(jìn)程相關(guān)的等待,一般代表了I/O能力出現(xiàn)了問題. 通常與配置的多個DBWR進(jìn)程或者DBWU的I/O slaves個數(shù)有關(guān).當(dāng)然也可能意味著設(shè)備上存在著I/O競爭
13> db file single write
表示在檢查點(diǎn)發(fā)生時與文件頭寫操作相關(guān)的等待.通常與檢查點(diǎn)同步數(shù)據(jù)文件頭時文件號的紊亂有關(guān).
14> direct path read 和 direct path write
表示與直接I/O讀相關(guān)的等待.當(dāng)直接讀數(shù)據(jù)到PGA內(nèi)存時,direct path read 出現(xiàn).這種類型的讀請求典型地作為:排序IO(為排序不能在內(nèi)存中完成的時候),并行Slave查詢或者預(yù)先讀請求等. 通常這種等待與I/O能力或者I/O競爭有關(guān).
15> free buffer inspected
表示在將數(shù)據(jù)讀入數(shù)據(jù)調(diào)整緩存區(qū)的時候等待進(jìn)程找到足夠大的內(nèi)在空間通常這類等待表示數(shù)據(jù)調(diào)整緩存區(qū)偏小.
16> library cache load lock
表示在將對象裝載到庫高速緩存時出現(xiàn)了等待.這種事件通常代表著發(fā)生了負(fù)荷爾蒙很重的語句重載或者裝載,可能由于SQL語句沒有共享或者共享池區(qū)域編小造成的.
17> log file parallel write
表示等待LGWR向操作系統(tǒng)請求I/O開始直到完成IO.在觸發(fā)LGWR寫的情況下如3秒、1/3、1MB、DBWR寫之前可能發(fā)生.這種事件發(fā)生通常表示日志文件發(fā)生了I/O競爭或者文件所在的驅(qū)動器較慢
18> log file single write
表示寫日志文件頭塊時出現(xiàn)了等待.一般都是發(fā)生在檢查點(diǎn)發(fā)生時.
19> transaction
表示發(fā)生了一個阻塞回滾操作的等待
20> undo segment extension
表示在等待回滾段的動態(tài)擴(kuò)展.這表示可能事務(wù)量過大,同時也意味著可能回滾段的寢大小不是最優(yōu),MINEXTENTS設(shè)置得偏小.考慮減少事務(wù),或者使用最小區(qū)數(shù)更大的回滾段.
您可能感興趣的文章:
  • Oracle外鍵不加索引引起死鎖示例
  • Oracle 插入超4000字節(jié)的CLOB字段的處理方法
  • Oracle 數(shù)據(jù)庫 臨時數(shù)據(jù)的處理方法
  • Oracle數(shù)據(jù)庫系統(tǒng)緊急故障處理方法
  • Oracle7.X 回滾表空間數(shù)據(jù)文件誤刪除處理方法
  • Oracle7.X 回滾表空間數(shù)據(jù)文件誤刪除處理方法
  • Oracle7.X 回滾表空間數(shù)據(jù)文件誤刪除處理方法
  • Oracle對于死鎖的處理方法

標(biāo)簽:池州 南平 嘉峪關(guān) 通化 南平 聊城 股票投資 襄陽

巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《oracle 常見等待事件及處理方法》,本文關(guān)鍵詞  oracle,常見,等待,事件,及,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請?zhí)峁┫嚓P(guān)信息告之我們,我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。
  • 相關(guān)文章
  • 下面列出與本文章《oracle 常見等待事件及處理方法》相關(guān)的同類信息!
  • 本頁收集關(guān)于oracle 常見等待事件及處理方法的相關(guān)信息資訊供網(wǎng)民參考!
  • 推薦文章