TechFAQ

Developing an Audit Plan
Database auditing is the monitoring and recording of activities occurring within a database. Usually there are two main reasons for auditing:
·    Security auditing ? to determine if someone is attempting to break into your system
·    Performance auditing ? to determine why the system is slow

When it is determined that auditing is needed, the next step is to decide where the audit information will be stored. The operating system usually can support an audit trail stored outside the database. Two INIT.ORA parameters control the auditing actions: AUDIT_FILE_DEST that specifies the location of the audit trail file, and AUDIT_TRAIL that is an audit enabled/disabled flag. In addition, the system-wide auditing can be enabled; in this case the results will be stored in the SYS.AUD$ table in the SYS schema of the database. Oracle supplies several views against the SYS.AUD$ table to make viewing of the audit information easier. In Oracle 8.0.4, there are 121 separate types of auditing that can be performed. The DBA can run the query ?select * from AUDIT_ACTIONS? to display the complete list of audit actions. The default auditing options that can be taken against an object are normally activated with the clause WHENEVER SUCCESSFUL or WHENEVER UNSUCCESSFUL. For example, the command to enable auditing when the user mary successfully modifies a value in a table would look like this:
    
AUDIT UPDATE BY mary BY SESSION WHENEVER SUCCESSFUL;

It is obvious that Oracle provides many ways to track information about modifications that have been made to the database objects ? at the object level. However it is usually not easy to keep track of actions that have been performed on specific rows within a table. For this, a customized, trigger-based application needs to be developed.