因为需要对一些无用的表空间进行清理,腾出系统空间,表空间大概有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环境下删除表或者表空间,要做好长期作战的心理准备拉
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/25016/viewspace-995710/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/25016/viewspace-995710/