删除表时碰到lms flush message acks等待事件

        最近和bug干上了，每过十天半个月总会碰上一两个bug，郁闷。今天碰到的是DELETE或者TRUNCATE表时速度很慢的bug。

        因为需要对一些无用的表空间进行清理，腾出系统空间，表空间大概有100G。首先想到的是把几个10多G的大表先truncate，然后再drop所有的表，最后再删除表空间。可是TRUNCATE一个表慢的要死，干脆cancel了，然后直接drop这个表，这次倒很快，可是想想，表肯定放在了recyclebin中了，一看，果然在那里，那就接着purge recyclebin吧，结果等了半个小时，还不见结果，慢的要死，看着表空间已使用空间一分钟才减少了100M，这要搞倒啥时候啊。干脆直接drop tablespace吧。

        于是开始直接drop tablespace，等了一个多小时，不耐烦了，因为在测试环境删除这么大的表空间才花了20分钟不到，看来要想点办法了。查找v$session_wait表，一看，这家伙在等一个咚咚，很陌生的一个等待事件lms flush message acks，一看lms就知道肯定是和rac有关了，仔细看等待的时间却每次都会等，但等待的时间却很短。这等待事件也不认识，上metalink查查吧。

        唉，原来又是个bug，metalink描述如下：
Subject: Bug 4151363 - Drop / truncate slow in RAC

Affects:
Range of versions believed to be affected Versions >= 10.2 but < 11
Versions confirmed as being affected 10.2.0.1 10.2.0.2

Platforms affected Generic (all / most platforms affected)

Fixed:
This issue is fixed in 10.2.0.3 (Server Patch Set)
11g (Future version)

Symptoms: Related To:
Performance Of Certain Operations Affected
Waits for "lms flush message acks"

Description
Drop / truncate table operations can be slow in a RAC environment
in 10.2 with lots of time waiting on "lms flush message acks".

        想看看这个bug有没有解决的办法呢?结果它还是个unpublished的bug，接着等吧，经过3个多小时的漫长等待，终于把它干掉了。

        最后说一句，数据库版本是10.2.0.2，看来要在rac环境下删除表或者表空间，要做好长期作战的心理准备拉