1021
Oracle 12c的一些新等待事件
編輯手記：本文介紹12C中一些新的等待事件，大家有更多發現或者總結的歡迎留言或者在大講堂群交流討論。
作者簡介：何劍敏
Oracle ACS華南區售後團隊，首席技術工程師。多年從事第一線的數據庫運維工作，有豐富項目經驗、維護經驗和調優經驗，專注於數據庫的整體運維。
今天用swingbench加載數據的時候，發現了一些之前沒有看過的等待事件，列舉一下：
（1）LGWR worker group idle
這是因為12c默認是以adaptive方式啟用scalable lgwr，即會在自動的在 single<-->scalable 之間進行切換，參考文章末尾的知識補充。
設置 alter system set “_use_single_log_writer”=true scope=spfile; 之後，即可恢複到12c之前的模式，從而不再有LGWR worker group idle等待。
（2）lreg timer
12c有一個新的進程LREG：
LREG (Listener Registration Process) Registers the instance with the listeners。在12c之前，是有pmon將數據庫注冊到listener中（動態注冊，大約需要60秒的時間才會注冊進去，除非alter system register）。
而在12c之後，將有lreg進程來做這個事情。當instance啟動的時候，lrge進程會輪詢listener是否已經啟動，如果已經啟動就將數據庫的信息注冊到listener中。如果listner還沒有啟動，輪詢就會間隔大約每3000毫秒檢查一次。strace的結果可以看到：epoll_wait(7, {}, 1024, 3000)
注：還會去讀/proc/loadavg，猜測可能在資源消耗高的情況下，延緩注冊database到listener：
也還會讀/etc/hosts文件（所以如果hosts配置不正確，也會無法實現動態注冊）
oracle把listener動態注冊從pmon獨立出來，讓新進程lreg來做動態注冊這個事情，我們可以看到：
（3）heartbeat redo informer1. 動態注冊的時間短了，原來60秒，現在3秒
2. pmon減輕了壓力，注冊的事情有lreg進程來完成。
官方文檔的描述如下：
可以看到，原來在11g中，有arch進程來做dataguard的heartbeat檢測，在12c中，也多出來TMON和TTnn進程來做dataguard之間的gap檢測和心跳檢測。
但是這個進程，不管是否啟用dataguard，都會存在。當沒有dataguard的時候，他就處於heartbeat redo informer這個空閑等待了
注：TMON進程是Redo Transport Process monitor，是async模式下用來監控redolog和standby redolog之間的同步關係，TTnn是TMON派生出來的slave進程
參考：
New Idle Events are Erroneously Listed in STATSPACK Report (Doc ID 1998538.1)
New Background Processes In 12c (Doc ID 1625912.1)
補充知識
在12c之前的行為，LGWR主線程負責redo strand的讀取，而由spawn出來的thread來模擬異步IO進行redo的寫入，然後由main thread通知FG進程而結束log file sync的等待。（可以看到第0個lwp的CPU占據比其他幾個lwp稍高。）
12c中有了scalable lgwr的功能，LGWR作為主進程做協調工作，具體的事情有slave進程LGnn來做。LGWR負責保證redo是按照順序寫入的，而slave LGnn根據LGWR的指示來進行redo strand的讀取和redo的磁盤寫入，並且由LGnn來直接通知FG進程寫入完成而結束log file sync的等待。
1. lgwr的子進程lgnn，適用在多CPU的係統中，Oracle由參數_use_single_log_writer控製，（默認值是adaptive，另外還有true和false），當設置為默認值adaptive，會根據係統負載，自動的調節是single log writer還是scalable log writer。調節的時候，在lgwr的trace文件中可以看到：
2. LGnn的最多個數，有_max_outstanding_log_writes決定。
3. Dataguard的SYNC模式不能用到multiple LGWR屬性
LGnn (Log Writer Worker) On multiprocessor systems, LGWR creates worker processes to improve the performance of writing to the redo log.
LGWR workers are not used when there is a SYNC standby destination. Possible processes include LG00-LG99.
參考：New Background Processes In 12c (Doc ID 1625912.1)
4. 存在 scheduling delay for the slaves。
在single instance中，high priority和highest priority都沒有放LGWR；在RAC中，high priority中有放LGWR，但是沒有LG*，可能會導致LGWR雖然有較高優先級，但是子進程沒有較高優先級。所以，可能需要設置和lgwr一樣priority的lgwr slave進程 。
參考Bug 20055279 : RAC PERF: LGWR CHOOSES TO USE SCALABLE LGWR BUT SINGLE LGWR PERFORMS BETTER
5. multiple LGWR適合多CPU的係統，特別是CPU高於64個以上的係統。
我個人猜測是一方麵在scalable lgwr情況下，lgwr起到協調者的作用，協調的時候需要消耗CPU進行計算。另外一方麵，多個子進程之間也需要CPU資源進行同步信息，以保證其寫的順序。
LGWR workers are used when using a single LGWR would perform better. This applies to small systems (<= 64 cpus).
參考Bug 20055279 : RAC PERF: LGWR CHOOSES TO USE SCALABLE LGWR BUT SINGLE LGWR PERFORMS BETTER
6. LGnn進程之間會進行同步.
我想這也是為什麼能保證寫redo log的時候，保證其一致性的原因。有的時候，LGnn之間不必要的同步，會導致性能變慢。 This means there will be unneeded LGWR slaves in each group and we will incur intra group synchronization costs for these.
參考 Bug 18683889 : SIGNIFICANT WAIT ON ''LGWR INTRA GROUP SYNC" WITH SCALABLE LGWR
7. 在AIX和HPIA環境中，啟用scalable lgwr還可能導致數據庫起不來，需要提前打好patch 21915719(注：打完patch 21915719之後，_use_single_log_writer=true就自動設置好了。)
參考 ALERT: Bug 21915719 Database hang or may fail to OPEN in 12c IBM AIX or HPUX Itanium - ORA-742, DEADLOCK or ORA-600 [kcrfrgv_nextlwn_scn] ORA-600 [krr_process_read_error_2] (Doc ID 1957710.1)
注意，這個文檔已經變成ALERT類型，說明已經發生過比較多的問題。一般ALERT文檔都是值得注意的預警性文檔。
文章轉自數據和雲公眾號，原文鏈接
最後更新：2017-07-18 11:04:03