晶晶實驗十二 相關重做的等待事件
一，下面共描述了12個直接相關日誌的等待事件，但只有前面幾個是值得注意的.
1,log file parallel write
當日誌快取到日誌檔案時,這是乙個主要的等待事件.雖然這個時間的名字中有"並行"(parallel)字樣,但即使日誌快取並沒有使用並行寫,因日誌快取的寫出而造成的等待仍然是此等待事件.
我們可以通過v$system_event來了解下某乙個階段內,此等待事件的平均等待時間.通過此時間值,來評估我們的日誌i/o是否正常.有資料介紹當log file parallel write的平均等待時間大於10毫秒時.有可能就表明著日誌的吞吐量緩慢.我認為這只是乙個參考值,在不同的系統上要根據不同的情況來決定.記錄一些在正常情況下log file parallel write等待事件的平均等待時間,當出現問題後,以此時間作為是否有問題的標準.這種方法也是可取的.
當日誌i/o確實有問題時,減少重做產生的數量,確實能夠緩解log file parallel write的等待時間.但有時,重做資訊的數量是無法減少的.根據情況,將日誌i/o轉移到更快速的磁碟上,也是解決問題的方法之一.
日誌快取的大小,有時候也會對此等待事件產生影響.如果你的日誌快取更大,會降低lgwr重新整理快取到磁碟的次數,增大日誌的快取,也會有助於緩解此等待事件.但過大的日誌快取,有可能會造成lgwr間歇性的擁堵.因為lgwr被觸發的條件之一是日誌快取滿1/3,如果日誌快取過大,1/3的日誌快取數量可能過多,每次lgwr被觸發,不得不寫大量資料,這造成lgwr間歇性的停頓與擁堵,這也會增加此等待事件的等待時間.我們可以通過設定隱藏引數_log_io_size來改變日誌快取滿1/3才觸發lgwr的闕值.通過設定此引數,我們即可以擁有較大的日誌快取,又避免了lgwr間歇性的停頓或擁堵.
我沒有在生產庫中使用過這個引數,因為他畢竟是乙個隱藏引數.雖然據說他不會帶來什麼bug.在我的測試機上,通過調節這個引數,確實可以對效能略有提公升.但這些都是為資料庫的"微調".不可能帶來大幅度的效能提公升.
lgwr 在重新整理快取時,需要redo allocation和redo writing閂,並且lgwr需要等待一些redo copy 閂的完成.因此,如果這些閂的爭用較高,則不要減少_log_io_size此隱藏引數,因為減少它,將會使lgwr更為頻繁的重新整理快取.這會進一步加劇這3個閂的爭用.減緩lgwr完成工作的速度.
**小小結:日誌快取到底應該設定為多大??_log_io_size引數的值應該定為多少??這沒有乙個統一的標準,只有通過多做測試才能決定.
2,log file sync
此等待事件使用者發出提交或回滾宣告後,等待提交完成的事件,提交命令會去做日誌同步,也就是寫日誌快取到日誌檔案， 在提交命令未完成前,使用者將會看見此等待事件,注意,它專指因提交,回滾而造成的寫快取到日誌檔案的等待.當發生此等待事件時,有時也會伴隨log file parallel write.因為此等待事件將會寫日誌快取，如果日誌的i/o系統較為緩慢的話,這必將造成log file parallel write 等待.當發生log file sync等待後,判斷是否由於緩慢的日誌i/o造成的,可以檢視兩個等待事件的等待時間,如果比較接近,就證明日誌i/o比較緩慢或重做日誌過多,這時,造成log file sync的原因是因為log file parallel write,可以參考解決log file parallel write的方法解決問題,如果log file sync的等待時間很高,而log file parallel write的等待時間並不高,這意味著log file sync的原因並不是緩慢的日誌i/o,而是應用程式過多的提交造成的.
3,log buffer space
伺服器程序生成重做記錄的速度快過lgwr寫出重做記錄的速度,因而發生等待.日誌i/o緩慢是log buffer space等待的主要原因之一.還有一點,如果日誌快取區過小,也容易出現此等待事件.將日誌快取設定的大一些,對於緩解此事件的等待會有幫助.但是,過大的日誌快取,又會降低lgwr重新整理快取的頻率,這可能會使提交時必須重新整理的快取數量增多.從而造成log file sync等待.日誌快取具體應該設定為多大,這就多進行測試咯.不同的環境下,不可能有乙個標準.為了緩解log buffer space等待事件,將日誌快取調節的比較大之後,可以通過_log_io_size引數來提高lgwr重新整理快取的頻率.這樣做既可以減少log buffer space的等待,也可以減少log file sync等待.但這樣的隱藏引數 應該小心使用.
4,log file switch(checkpoint incomplete)
在日誌切換時,會完成乙個檢查點操作,如果此檢查點完成的過於緩慢,就會造成此事件的等待,檢查點為什麼會緩慢呢?可能是buffer cache太大因此容納的髒塊太多,dbwr程序太少,調整檢查點頻率的引數設定頻率太低等原因造成的.
5,log file switch(archiving needed)
在日誌切換時,下一日誌檔案還沒被歸檔完成,此時所有的資料庫dml操作都停止下來,等待下一日誌檔案可用,至於原因,很簡單,歸檔程序太慢或日誌切換太快,再問為什麼切換太快?日誌檔案太小或生成的重做太多.
6,log file switch(clearing log file)
這發生在dba發布alter system clear log file命令.且lgwr正需要切換到被清空的日誌檔案.等待時間是1秒.
7,log file switch completion
當乙個日誌檔案滿了,oracle要開啟另乙個日誌檔案,寫完上一日誌檔案,準備好下一日誌檔案,這之間的等待就是此等待事件了,簡單點說,就是為了完成日誌檔案切換而發生的等待.
8,switch log file command
執行日誌檔案切換命令的時候等待日誌檔案切換完成.超時時間為5秒.
9,log switch/archive
當dba手動輸入命令alter system archive log change時,可能會等待此事件.
10,log file sequential read
等待從日誌檔案中讀,一般arc程序會遭遇此事件,如果p3引數為1,證明等待發生在讀日誌檔案頭,否則,p3代表要讀出的日誌塊的數量.
11,log file single write
日誌檔案寫等待,注意,這裡所指的寫,並不是從日誌快取寫到日誌檔案,這裡的寫並不涉及日誌快取,此事件只代表寫日誌檔案頭時發生的等待.有兩種情況日誌檔案頭被寫:當新增新的成員檔案或日誌序列號增加.應對日誌檔案盡量使用裸裝置.或避免將日誌檔案放在同一磁碟上,以減少此事件產生的可能.
12,lgwr wait for redo copy
lgwr將要寫一組日誌塊,但它必須等待直到伺服器程序完成任意當前的拷貝操作,這些拷貝操作影響將要被寫出的快取.
gc 等相關等待事件描述
gc current cr request 這些等待事件僅在 cr或者當前緩衝區的 gc請求正在進行時才相關 該請求完成之前，這些事件充當佔位符 gc current cr 2 3 way 請求當前塊或者 cr塊，然後在經過兩三個網路中繼段後收到這些塊 當塊不忙或者未堵塞時，會立即處理請求 gc c...
等待事件之日誌等待事件解決的方法
我堅持每天看3套rac的awr，總結了一下。查詢日誌等待事件的sql 9i select from v event name where name like log 大概14個左右 10g select name,wait class from v event name where name lik...
重做日誌相關查詢
聯機日誌檔案又叫重做日誌檔案，記錄了對資料庫修改的資訊，包括使用者對資料修改和資料庫管理員對資料庫結構的修改。它主要用於在發生故障的時候和資料庫備份檔案配合恢復資料庫，一般發生故障有 2個情況 乙個是介質損壞另外乙個是使用者誤操作。每個資料庫至少有兩個日誌檔案組，每組至少包含 1個或者多個日誌成員，...