Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We're running Oracle on RHEL 5.4 64-bit. We recently did an upgrade from to Many errors were generated during the upgrade (sample listed below from trace.log) but during application testing afterward everything seemed fine (clean EXP, inserts, updates, deletes, etc.). The errors look like they are all related to Advanced Queuing tables and views. We are not using replication at all, this is a simple single instance db.

ORA-24002: QUEUE_TABLE SYS.AQ_EVENT_TABLE does not exist
ORA-24032: object AQ$_AQ_SRVNTFN_TABLE_T exists, index could not be created
ORA-24032: object AQ$_ALERT_QT_S exists, index could not be created for queue
ORA-06512: at "SYS.DBMS_AQADM_SYSCALLS", line 117
ORA-06512: at "SYS.DBMS_AQADM_SYS", line 5116

Is this worth worrying about, and if so, how do I go about cleaning up/recreating the corrupted and/or missing objects?

share|improve this question
Yes, we saw ORA-600's and the alert logging was emitting errors due to AQ tables not being available every 5 minutes. I read up on the data pump AQ dependencies and we decided to do a complete wipe/reinstall on the database. We exported all our schemas using EXP, which complained about invalid statistics. We then wiped out Oracle (a couple rm commands on linux), reinstalled, repatched, recreated the old users/tablespaces, then IMP'd the dumpfiles with FROMUSER=x TOUSER=x STATISTICS=RECALCULATE. After the reinstall we have no more errors in the log and data pump works fine. – hurfdurf Apr 13 '10 at 18:37
up vote 2 down vote accepted

My suggestion is to not ignore it.

I recently had AQ related issues after changing from Interpreted PL/SQL to Native Compiled PL/SQL. My AQ tables where munged and we had some data dictionary corruption. We do not explicitly use any AQ features for our products, but it looks like Oracle does use it for some of their feaures.

The main issue for us is that we were not able to use DataPump exports as they bombed out with AQ related errors. Also OEM access to this one database was very flaky. All user operations seemed to work OK.

If you check your alert log you may be getting some weird ORA-600's due to AQ subsystem not being available.

My suggestion is to open an SR with Oracle and go from there. They have an unpublished procedure they can give you that drops and recreates the AQ tables. If you don't have any data dictionary corruption it should be something simple... but make sure you have ability to absorb some downtime as their procedure can not be run while users are logged on. Also make sure you have some good backups - we ended up having to roll back 1 week because of all this (luckily just a Dev database).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.