How to resolve ORA-24005 when drop tablespace

SQL> drop tablespace EXAMPLE INCLUDING CONTENTS;
drop tablespace EXAMPLE INCLUDING CONTENTS
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-24005: must use DBMS_AQADM.DROP_QUEUE_TABLE to drop queue tables

EXAMPLE表空间是Oracle的示例表空间,通常保存着诸如OE, SH, IX, HR等示例用户的表数据,在尝试删除这个表空间的时候遇到上述的错误。

实际上错误是由于IX用户下的高级队列表对象引起的,高级队列表对象无法使用常规的drop命令删除,无论是删除包含AQ的表空间还是用户,都会报ORA-24005错误。

SQL> drop user IX cascade;
drop user IX cascade
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-24005: must use DBMS_AQADM.DROP_QUEUE_TABLE to drop queue tables

SQL> select table_name,tablespace_name  from dba_tables where owner='IX';

TABLE_NAME                     TABLESPACE_NAME
------------------------------ ------------------------------
SYS_IOT_OVER_53828             EXAMPLE
AQ_ORDERS_QUEUETABLE_S        EXAMPLE
SYS_IOT_OVER_53842             EXAMPLE
AQ_STREAMS_QUEUE_TABLE_S      EXAMPLE
ORDERS_QUEUETABLE              EXAMPLE
STREAMS_QUEUE_TABLE            EXAMPLE
AQ_STREAMS_QUEUE_TABLE_T
AQ_STREAMS_QUEUE_TABLE_I
AQ_STREAMS_QUEUE_TABLE_H
AQ_STREAMS_QUEUE_TABLE_G
AQ_STREAMS_QUEUE_TABLE_C
AQ_ORDERS_QUEUETABLE_T
AQ_ORDERS_QUEUETABLE_I
AQ_ORDERS_QUEUETABLE_H
AQ$_ORDERS_QUEUETABLE_G

常规的方法是按照提示,使用DBMS_AQADM.DROP_QUEUE_TABLE存储过程来完成。

SQL> conn ix/ix
SQL> exec DBMS_AQADM.DROP_QUEUE_TABLE('ORDERS_QUEUETABLE',true);
SQL> exec DBMS_AQADM.DROP_QUEUE_TABLE('STREAMS_QUEUE_TABLE',true);

在某些时候运行完上述存储过程,用户下仍然还会存在一些AQ$表,此时仍然无法正常删除用户或者表空间。

SQL> select table_name,tablespace_name  from dba_tables where owner='IX';

TABLE_NAME                     TABLESPACE_NAME
------------------------------ ------------------------------
AQ$_STREAMS_QUEUE_TABLE_C

此时需要通过10851 event来进行手工删除,操作顺序如下,更加详细的步骤可以参看Metalink Note 203225.1。

SQL> conn ix/ix
SQL> SELECT object_name, object_type FROM user_objects WHERE object_name like '%STREAMS_QUEUE_TABLE%';

OBJECT_NAME                              OBJECT_TYPE
---------------------------------------- -------------------
AQ_STREAMS_QUEUE_TABLE_C                TABLE
AQ_STREAMS_QUEUE_TABLE_Y                INDEX

SQL> ALTER SESSION SET EVENTS '10851 trace name context forever, level 2';

Session altered

SQL> DROP TABLE AQ$_STREAMS_QUEUE_TABLE_C cascade constraints;

Table dropped

SQL> SELECT object_name, object_type FROM user_objects WHERE object_name like '%STREAMS_QUEUE_TABLE%';

OBJECT_NAME                              OBJECT_TYPE
---------------------------------------- -------------------

SQL> drop user ix cascade;

User dropped

SQL> drop tablespace example;

Tablespace dropped

runfixup.sh – Oracle11gR2 Installation New Feature

Oracle11gR2的安装界面跟之前版本比较起来有很大的不同,整体界面更加清新,更加简洁了,比较引人注意的是新的fixup脚本,在安装过程中,安装程序将会检查推荐的操作系统内核参数设置以及必须的软件包,对于不符合要求的部分将会自动生成runfixup.sh,安装人员只需要手动以root用户运行该脚本即可,不再需要像以前那样按照安装手册去自行调整了。

在我的安装中,使用的是Oracle Enterprise Linux 5 U3,安装完操作系统之后,没有做任何修改的检查结果如下图。

mwsnap446

点击”Fix & Check Again”按钮之后,弹出的窗口显示了runfixup.sh的生成位置。

mwsnap447

在以root用户运行runfixup.sh。

[root@dbserver CVU_11.2.0.1.0_oracle]# ./runfixup.sh 
Response file being used is :./fixup.response
Enable file being used is :./fixup.enable
Log file location: ./orarun.log
Setting Kernel Parameters...
kernel.sem = 250 32000 100 128
fs.file-max = 6815744
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default = 262144
net.core.wmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_max = 1048576
fs.aio-max-nr = 1048576
uid=501(oracle) gid=501(dba) groups=501(dba)

之后点击上面窗口的“OK”按钮,安装程序重新检查后的结果。

mwsnap449

这些可以忽略,点击“Ignore All”之后,继续安装,一直到包括创建数据库,都不会出现任何问题。

How to resolve ORA-600 [kghfrf1]

客户的数据库系统在下午突然报错,作为报表系统的数据是从主生产库通过物化视图刷新的方式定期更新的,但是在错误发生以后,每次物化视图的快速刷新都会产生ORA-600错误。

ORA-12012: error on auto execute of job 467
ORA-20999: HD_GT_DEXM_HYMX refresh failed:-600
ORA-00600: internal error code, arguments: [kghfrf1], [0x000000000], [], [], [], [], [], []
ORA-06512: at "user.REFRESH_ALL_SNAPSHOT", line 31
ORA-06512: at line 1

在Metalink中搜索[kghfrf1],虽然有相关文章,但是浏览之后发现跟客户的情况都不匹配。首先是症状不相同,并没有任何一个案例是在物化视图刷新的时候报错的;其次是数据库版本不同,客户数据库为Oracle 9208 RAC,在这个版本中并没有任何已知的未修复的bug会导致ORA-600 [kghfrf1]错误;最后通过查看客户trace文件中堆栈信息,也跟Metalink文章中并不匹配。

对于此ORA-600错误的解释是:

@ We are attempting to free a freeable chunk of space and generate this
@ exception trying to free a NULL pointer.
@
@ This is a memory corruption with no data corruption

在系统不繁忙期,让客户尝试执行以下命令用以清理Shared Pool。

ALTER SYSTEM FLUSH SHARED_POOL;

幸运的是,执行完这条命令之后一切错误都消失了。

实际上本文重点不在于解决这个问题的方法,而是试图梳理一下普遍的解决Oracle数据库故障的流程。
1. 检查alertlog,以及发生ORA-600错误时候产生的trace文件,在trace文件中查看是否有Current SQL记录(查找Current SQL statement for this session字样),对过比对确认具体是什么操作引起了ORA-600错误。在本例中,显示为物化视图刷新。

begin dbms_mview.refresh('HD_GT_DEXM_HYMX','f');end;

2. 查询Metalink,明确发生该错误的原因以及可能有的解决方法,在解决方法不确定的时候,继续查看是否有类似的bug,每一份bug报告里面通常都有stack信息,跟trace文件中“—– Call Stack Trace —– ”部分做比较,如果堆栈信息完全匹配,那么基本上可以认定是相同的bug,之后再继续查看该bug是否有解决方法或者是相应的Patch。

3. 如果找不到相应的bug或者是解决方法,那么根据ORA-600的错误原因,运用自己的troubleshooting知识来尝试几种方法,比如本例中清理共享池的提议。或者,重启数据库也是值得尝试的。

4. 仍然无法解决,那么首先需要在Metalink中提交一份SR,别管有用没用,别管响应时间有多长,至少做了该做的本份,其次是寻求Oracle官方支持,如果客户足够大牌,那么可能可以要求Oracle单独为此客户发布一个补丁。

4. 如果都不行,此错误也无可避免,而该错误又将严重影响到生产系统,并且错误发生频率还不低,那么这恐怕是该升级数据库版本的时机了,11gR2,不错的选择。