enq : MS – contenti ORA-600 [529]

enq : MS – contention等待事件
該等待事件是在物化視圖refresh操作中才會出現的，在refresh的過程中，負責refresh 的進程會頻繁的鎖定物化視圖日誌表SYS.MLOG$以同步物化視圖與基表的數據，此期間如果有會話嘗試修改物化視圖所依賴的基表，也會嘗試修改物化視圖日誌表，就會產生等待Enq：MS – contention，由於這個等待事件是一個enqueue類型，所以在大量並發的對基表進行dml操作時，等待就會越劇烈，等待時間也會加長。
而這個操作流程，正是聯機重定義的基本工作原理，臨時表就是一個物化視圖，而DBMS_REDEFINITION.SYNC_INTERIM_TABLE操作正是對物化視圖進行refresh的操作，在此期間，由於sync操作會頻繁的索引物化視圖日誌，導致了對原表進行dml操作的會話產生了大量的enq: MS – contention等待。
以下是對MS enqueue的官方解釋：Monitoring Locks During Materialized View Refreshes (Doc ID 258258.1)
MS is a special type of enqueue that is introduced with Oracle9. This enqueue is obtained during setup on the master table associated with the snapshot being refreshed.
For example:
Resource Holder State
Enq MS-00004071-00000000 300: waiting for ‘PL/SQL lock timer‘
Enq TX-00380019-00AAC396 366: 366: is waiting for 300:
Enq TX-00830016-002216EE 375: 375: is waiting for 300:
?
And from the SYSTEMSTATE DUMP, you may see something like:
waiting for ‘enq: MS - contention‘ blocking sess=0x17c048eaf0 seq=9657 wait_time=0 seconds since wait started=20
因此可以知道，數據庫出現大量enq : MS – contention等待事件，與對原表的dml操作有關，而導致該等待事件的嚴重程度，與dml操作的並發量有關。

ORA-600 [529]
數據庫實例1執行expdp時觸發ORA-600 [529], [0x700000000035E20], [Memory Queue Subscriber]，在RAC2上導出成功該問題是由於執行expdp時觸發了BUG 22022679(Base Bug 16619152)導致的，創建“Memory Queue Subscriber”子latch時,由於達到了子latch的最大限制值而失敗。 解決辦法（1）Oracle在實例級別維護子latch的創建與釋放, 臨時方案是可以通過重啟實例清理有問題的latch。（2）應用補丁程序16619152。

根據問題現象和call stack搜索MOS資料庫, 可以匹配到Bug 22022679 : ORA-600[529] [0X14B27D620] [MEMORY QUEUE SUBSCRIBER] OCCURED EXECUTING EXPDP.
Bug22022679的Base Bug為16619152,在AIX平臺,11.2.0.3數據庫版本存在patch.
Base BUG 16619152對該問題的描述, 即: 在ksl layer創建或回收子latch時會強制持有父latch,在kgqm和kqqbt layer創建或回收子latch時不會持有父latch,這就可能導致這個問題.根據call stack調用的函數來看執行expdp時調用了kgqm layer的latch.

5 Oracle問題整理