Auditing Database Changes with DDL
Oracle provides
DDL triggers
to audit all schema changes and can report the exact change, when it
was made and by which user. There are several ways to audit within
Oracle, and it is important to take DDL auditing needs into
consideration when
designing the Oracle system to include auditing.
For Oracle, the following auditing tools are provided:
- SQL audit command (for DML)
- Auditing with object triggers (DML auditing)
- Auditing with system-level triggers (DML and DDL)
- Auditing with LogMiner (DML and DDL)
- Fine-grained auditing (select auditing)
Oracle System Event Trigger Auditing with DDL Triggers
Using the
System Event DDL trigger, the Oracle DBA can automatically track
all changes to the database including changes to tables, indexes,
and constraints. The data from this trigger is especially useful for
change control and auditing changes to the production environment.
This is especially important for Oracle databases that are certified
by government agencies.
When Oracle first provided the functionality for these DDL
triggers, it was not clear how they could be used in order to track
system-wide usage. Initially, the implementation of system level
triggers for end-user tracking was so new, curious Oracle shops
tried it and found it a bit lacking in robust functionality.
Auditing with User Log on/off Triggers
The user log on/log off triggers was a great example of the
limits on functionality. While the user log on/off trigger
will accurately capture the time of the user log on and user log
off, it does not capture any additional information regarding the
specific tasks that were performed during the user's session. In the
event that users are not issued their own unique Oracle User ID,
this DLL trigger may not be particularly useful as Oracle cannot
then timestamp each individual users.
From Oracle guru and Rampant TechPress author, Laurent Schneider, we
get the answer to the following questions:
-
Is there any
alternative DDL scripting for DDL auditing?
-
What is the
time offset
for the current time in Unix?
Using
enable_ddl_logging as a DDL Log Auditing Alternative
Laurent Schneider adds this regarding a new and cool alternative
offered in Oracle 11g. This option involves the use of
enable_ddl_logging.
Setting enable_ddl_logging will allow the tracking of all ddl's
in the alert log using the following:
ALTER SYSTEM SET enable_ddl_logging=TRUE
Later, you issue create table:
t(x number)
and you see in the alertLSC01.log:
Tue Apr 05 14:43:32
2011
create table
t(x number)
Wait, that’s not really verbose !?
Remember the alert log is just there for backward compatibility,
it is time you start looking in the xml file:
<msg time='2011-04-05T14:43:42.210+02:00' org_id='oracle' comp_id='rdbms'
msg_id='opiexe:3937:4222333111' client_id='' type='NOTIFICATION'group='schema_ddl'
level='16' host_id='srv01'
host_addr='192.168.0.141' module='TOAD Beta 11.0.0.52'
pid='2777799'>
<txt>create table t(x number)
</txt>
</msg>
There is not really much more there but the module, which indeed
reveals someone is using TOAD to access my database !
Unfortunately for many shops, enable_ddl_logging is an
additional cost feature available only to Enterprise Edition users.
 |
|
Get the Complete
Oracle SQL Tuning Information
The landmark book
"Advanced Oracle
SQL Tuning The Definitive Reference" is
filled with valuable information on Oracle SQL Tuning.
This book includes scripts and tools to hypercharge Oracle 11g
performance and you can
buy it
for 30% off directly from the publisher.
|
