Last updated on DECEMBER 06, 2016
Applies to:Oracle Database - Enterprise Edition - Version 10.1.0.2 and later
Information in this document applies to any platform.
***Checked for relevance on 04-May-2012***
You have a trigger created to audit DDL changes within the production database. The trigger uses the AFTER DDL ON DATABASE clause. SYS creates both the trigger and a table ddl_events to store data about the DDL event.
The trigger inserts the data into the ddl_events table with data from built-in functions such as ora_dict_obj_owner, ora_sysevent, ora_dict_obj_type, and ora_dict_obj_name.
You have a problem to audit dropping a table from a schema user. If SYS creates a table that contains n columns with NOT NULL constraint, then drop the table, the trigger inserts one row with sysevent “Drop” into the ddl_events table. This is what we want.
However if any schema user creates the same table that contains n columns with NOT NULL constraint, then drop the table. The trigger inserts n rows with sysevent “Alter” to rename the constraints to “BIN$xxx” and plus one row with sysevent “Alter” to rename the table to “BIN$xxx” and plus one row with sysevent “Drop”. So we see there are n+2 rows in the audit table and may receive n+2 emails (if we set up email notification for the DDL auditing) for one DDL event to drop a table.
These event logs and emails are really confusing. Since auditing DDL changes is critical in your production databases, you need only one clear row of drop event recorded in the table and one email sent out for auditing a schema user to drop a table.
So, the questions here are:
- Why does the trigger get different event records by SYS and a schema user as described above.
- How can we exclude these Alter events from the trigger, at least from the email, for dropping a table by a schema user?
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
Million Knowledge Articles and hundreds of Community platforms