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.