First things first:
Thou shalt not explicitly set AQ_TM_PROCESSES=0 !
Unless, of course, you want to disable the Queue Manager Process (QMNC in Oracle 11.x). Which you may want to do during database upgrades to prevent Streams or Advanced Queueing from interfering with the upgrade process.
However, if you don’t reset this parameter afterwards, you might run into the following scenario the next time you do a Data Pump export or import:
Just the other day I hit the unpublished Bug 16445132: DBMS_SCHEDULER PROBLEM WITH DATABASE MIGRATION VIA EXPDP/IMPDP.
It affects Scheduler Jobs that were created to end with a corresponding Scheduler Window.
Here’s an excerpt of a Data Pump Logfile:
ORA-39083: Object type PROCOBJ failed to create with error:
ORA-27469: STOP_ON_WINDOW_EXIT is not a valid job attribute
Actually, the correct attribute name for this procedure would be “stop_on_window_CLOSE” instead of “stop_on_window_EXIT”. The latter is an attribute of the JOB_DEFINITION object type which in my eyes is inconsistently named in respect to the SET_ATTRIBUTE procedure.
The bug is fixed, but as of Nov. 2014 there is no one-off patch for version 126.96.36.199. The existing workaround is to ignore the error and recreate the job after the import .
If you run into this bug and it bugs you a lot, the other option is to ask for a patch for this issue.
Oracle’s “Security Alert Advisory for CVE-2012-3132” issued a warning about an attack vector that once again was discovered by security expert David Litchfield. The vulnerability allows to execute SQL code with SYS privileges by using object names containing quotation marks, if the attacker
- has authorized access to the database,
- has CREATE TABLE and CREATE PROCEDURE privileges and
- is allowed to execute DBMS_STATS.
A fix for this issue was published in July 2012 but there’s also Oracle’s advisory on how to cope with the threat without patching the RDBMS. This recommendation, however, has implications when such a database is recovered or cloned: