AQ导致不能drop user cascade

由于工程割接,在新数据库上测试imp一个用户需要多少时间,在把imp的报错慢慢修正后,再一次drop user进行重新导入,却发现不能drop user了:

但是在当前用户下查询user_query_tables会发现没有记录:

既然没有query table,那为什么在drop user的时候,还会报错需要用DBMS_AQADM.DROP_QUEUE_TABLE 去手工清除query table?难道是发生了数据字典不一致的问题?而且,究竟哪些表是query table?

根据现网的生产数据库查询:

确实发现了2个query table。

忽然发现这2个表之前在做imp的时候,由于如下类似的报错(相关案例见这里):

于是在imp的时候就加上了TOID_NOVALID的参数:TOID_NOVALIDATE=\(SYS.AQ\$_JMS_MESSAGE,SYS.AQ\$_JMS_USERPROPARRAY,SYS.AQ\$_JMS_TEXT_MESSAGE\)

而且发现这2个表相关的表,在imp的报错中也是出现过的:

会不会是因为用了TOID_NOVALIDATE没有进行校验,所以实际的query table和数据字典user_query_tables中的情况不一致了?
如果是这样,那么手工清除这2个query table之后就应该能drop user了。

在为上线的新数据库上:

相关文章

2条评论

  1. re 小熊:
    其实在处理的时候,我们可以不必去现网查看是哪些queue table,可以利用errorstack level 1去trace到是哪些queue table。
    这个方法是在群里面讨论的时候,阿虚告诉我的。
    这个方法很妙,不仅可以解决这个问题,对于ora-942 table or view does not exsist的报错,仅仅知道有表或视图不存在,但是不知道是哪个,也可以用这个方法trace出来表名或者视图名。
    另外对于exp的报错,也可以用这个来trace,这边也有一个处理的案例。http://www.oracleblog.org/working-case/using-errorstack-to-solve-exp-problem/

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据