刪除表時碰到lms flush message acks等待事件

最近和bug幹上了，每過十天半個月總會碰上一兩個bug，鬱悶。今天碰到的是DELETE或者TRUNCATE表時速度很慢的bug。[@more@]

因為需要對一些無用的表空間進行清理，騰出系統空間，表空間大概有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環境下刪除表或者表空間，要做好長期作戰的心理準備拉