Using Oracle8is Auditing Features

25
C H A P T E R

In This Chapter
Understanding Oracle8i auditing concepts Implementing Oracle8i auditing Managing the Oracle8i audit trail Using Triggers to implement auditing

n todays high-data-transaction environments, there is always a requirement to monitor what is going on within a system. You must know more than who is connected, and from which host. You may need to gather statistics, monitor data access, or watch for potentially suspicious activity. You can do all of these things using Oracle8is auditing features. Oracle8is auditing features allow you to track access to tables, the use of privileges, and the use of specific SQL statements. In addition, because the Internet has become a popular method of implementing a three-tier system, Oracle8i now provides a way to track middle-tier connections made on behalf of end users. This chapter provides a detailed exploration of Oracle8is auditing concepts and audit implementation techniques.

Oracle8i Auditing Concepts

With all the auditing features available in Oracle8i, it is easy to get carried away auditing too much. The result can be an overwhelmingly detailed audit log, one so detailed that you never bother to look at it. When considering a database audit, first clarify the reason or reasons for the audit in conjunction with the types of auditing facilitated by the Oracle8i server. Then, limit your auditing effort to the minimum required to achieve your goals.

668

Part VI Advanced Topics

Why audit a database?

Auditing a database involves the recording and analysis of information, which is based on selected database operations executed by users. The motives for auditing user activity fall into two main categories: Monitoring errant or unauthorized user activity. Organizational data is the backbone of any company. If you modify data or drop tables important to the operation of internal systems, the database provides erroneous results. The database security administrator must provide solutions to such scenarios, and without a database audit trail, the root of such situations could remain a mystery. Monitoring database statistics. Auditing certain database operations provides an essential understanding of how the database is used. These statistics enable database designers to enhance the databases physical design or even answer some database root-cause analysis problems. The amount of information gathered from such monitoring feeds the data/information/knowledge cycle.

Auditing options offered by Oracle8i

Oracle8i permits three types of auditing: statement, privilege, and schema object. These types provide a flexible approach to implementing any auditing scenario. All three types of auditing are implemented using various forms of the AUDIT statement.

Statement Auditing
Statement auditing allows you to audit specific SQL statements executed by users. It offers no provision for tracking the schema objects referenced by those statements. The basic syntax for this kind of auditing command follows:
AUDIT option, option, [BY [ username | proxy_name [ ON BEHALF OF [ ANY | username ] ] ] ] [BY [ SESSION | ACCESS]] [WHENEVER [NOT] SUCCESSFUL]

Use statement auditing on these two groups of SQL statements: DDL statements, with respect to specific database object types, not specific objects. For example, the following audit command audits all CREATE TABLE and DROP TABLE statements:
AUDIT TABLE;

DML statements, with respect to a particular type of database object operation, but not specifically an operation on a named object. For example, the following audit command initiates auditing for all SELECT FROM TABLE statements, irrespective of the table on which the SQL statement executes:
AUDIT SELECT TABLE;

Chapter 25 Using Oracle8is Auditing Features

669

Statement auditing can be broad or focused in scope; use statement auditing to audit activities of all users or a selected subset of users.

Privilege Auditing
Privilege auditing audits the use of system privileges such as CREATE TABLE or SELECT ANY TABLE. You can audit the use of any system privilege. The general syntax for this form of auditing is as follows:
AUDIT [option | ALL ] ON [username.]objectname [BY [SESSION|ACCESS]] [WHENEVER [NOT] SUCCESSFUL]

Privilege auditing is more focused than statement auditing because each option audits only specific types of system privileges, not a related set of statements. For example, the statement audit option AUDIT TABLE audits the CREATE TABLE, DROP TABLE, and ALTER TABLE SQL statements, while the privilege audit option CREATE TABLE audits only CREATE TABLE SQL statements. The privilege audit option for monitoring the creation of all tables follows:
AUDIT CREATE TABLE;
Note

If similar statement and privilege audit options are set for example, the AUDIT TABLE statement audit option and the AUDIT CREATE TABLE privilege audit option only a single record is generated in the audit trail when an event falls into both categories.

You can set privilege auditing to audit system privilege activities of a selected user or all users of a database.

Schema Object Auditing

Schema object auditing audits specific DML statements on a specified schema object. You can audit SQL statements that reference the following object types: tables, views, sequences, stored procedures, functions, and packages. Schema object auditing is implemented using the following syntax:
AUDIT [option | ALL ] ON [username.]objectname [BY [SESSION|ACCESS]] [WHENEVER [NOT] SUCCESSFUL]

The following list shows the DML statements that will be recorded as the result of schema object auditing:
ALTER AUDIT COMMENT DELETE EXECUTE

670

Part VI Advanced Topics

GRANT INDEX INSERT LOCK RENAME SELECT UPDATE

For example, AUDIT SELECT ON tablename audits all SQL SELECT statements executed against the specified table. If objects are indirectly referenced by synonyms, clusters, or indexes, they can be audited by setting schema object audit statements on their respective base tables.
Note

If schema object auditing is set on a table and its view, a SELECT operation on the view generates two audit records.

Because it only audits a specific DML statement on a schema object, schema object auditing is very focused. Schema object auditing always applies to all users of the database.

Focusing the Auditing Options

Oracle8i enables you to focus statement, privilege, and schema object auditing with the following techniques: You may limit your auditing to successful SQL statement executions, unsuccessful SQL statement executions, or both. You may specify that SQL statement executions are recorded once per user session or every time the SQL statement is executed.

Auditing successful or unsuccessful SQL execution

This type of constraint focuses the Oracle8i auditing efforts on SQL operations that are successful, unsuccessful, or both. An unsuccessful SQL operation is a valid SQL statement that fails due to a lack of permissions to execute completely or a reference to a nonexistent schema object. The syntax for implementing this audit focus strategy involves using one of the two following clauses with your AUDIT command:
WHENEVER SUCCESSFUL WHENEVER NOT SUCCESSFUL

If neither line is mentioned in the audit syntax, both successful and unsuccessful SQL statement executions are audited.

Session and access auditing

The BY SESSION and BY ACCESS auditing type constraints dictate when audit records should be generated. The BY SESSION constraint setting inserts only one audit record in the audit trail for each audit option execution during the users session.

Chapter 25 Using Oracle8is Auditing Features

671

For example, the following auditing command audits SELECT commands for the BOOKS_LOANED table:
AUDIT SELECT ON AMY.BOOKS_LOANED BY SESSION;

User TONY connects to the database and executes five SELECT statements on the BOOKS_LOANED table. Oracle8i generates only one audit record because you specified the BY SESSION option. The BY ACCESS constraint setting generates an audit record into the audit trail for each audit option execution. For example, if you set BY ACCESS for the previous example, TONY generates five audit records into the audit trail. You can only set the following audit operations using the BY ACCESS audit option constraint: All statement audit options that audit DDL operations All privilege audit options that audit DDL statements For all other audit options, BY SESSION is the default.

Auditing by user
Statement and privilege auditing options permit auditing on SQL statements issued by a specific or general user in a database. You can use the BY USER auditing constraint to minimize the number of audit records generated. For example, use the following syntax to enforce the statement auditing option on the SELECT statement by the users TONY and KRISTY:
AUDIT SELECT TABLE by TONY, KRISTY

Schema object auditing options cannot be constrained to specific users.

Auditing by proxy
A new feature of Oracle8i is the ability to audit by proxy. A proxy is a new feature of Oracle8i that allows middleware (such as an application server) to log on as a user without passing the users password to the database. Sending passwords to the database is a possible security leak, especially if the transaction is done across the Internet. Before you can audit by proxy, you must set up a user and the middleware with a proxy relationship. The ALTER USER command has a new parameter for this. The syntax is as follows:
ALTER USER user_name GRANT CONNECT THROUGH proxy_name [ WITH ROLE [ALL EXCEPT ] role_name ]

The user_name is the end user. The proxy_name parameter specifies the name of the Oracle user with which the middleware (application server) logs on to the database. Omitting the WITH ROLE clause gives the proxy the same roles as the user.

672

Part VI Advanced Topics

For example, a Web-database application server logs on as WEBAPP. The end user named JOHN logs on to the Web application and queries the database. The application server queries the database as the proxy of JOHN. As the proxy, the application is able to query all the tables that JOHN is allowed to query. To tell the database to use WEBAPP as JOHNs proxy, issue the following command:
ALTER USER JOHN GRANT CONNECT THROUGH WEBAPP;

The middleware verifies the users identity by requiring a name and password, or any other sort of validation it wants. It then acts as the users proxy (or representative) when accessing the database. The database validates the identity of the middleware and assumes that the middleware is a familiar and trustworthy entry point into the database. Even though the user logged on to Oracle is named WEBAPP, Oracle knows that it is really JOHN on the other side of the application. The application has many end users for which it is a proxy. The auditing thread between the end user and the database activity would be lost without new functionality to take proxies into account. Oracle8i has added the BY PROXY clause into the AUDIT command for handling these new forms of activity. The syntax is as follows:
AUDIT option BY PROXY [ ON BAHALF OF [ ANY | user_name ] ];

Continuing with our example, lets say you want to audit all the query activity that user JOHN has done through the WEBAPP proxy. The command for auditing would be as follows:
AUDIT SELECT TABLE BY WEBAPP ON BEHALF OF JOHN;

To stop the auditing, use the NOAUDIT command, as shown here:

NOAUDIT SELECT TABLE BY WEBAPP ON BEHALF OF JOHN;

To end the proxy relationship between the proxy and the user, use the ALTER USER command, as follows:
ALTER USER JOHN REVOKE CONNECT THROUGH WEBAPP;

Implementing Oracle8i Auditing

Now that you have seen the basics of Oracle8i auditing concepts, lets implement auditing in an Oracle8i database. Implementing Oracle8i auditing involves enabling auditing at the database level using an initialization parameter. Then you begin enabling and disabling auditing options on statements, privileges, or schema objects. The statement, privilege, and schema object auditing options can be enabled or disabled using the AUDIT command.

Chapter 25 Using Oracle8is Auditing Features

673

Enabling Oracle8i auditing

To enable auditing, you must modify the AUDIT_TRAIL initialization parameter in the database parameter file. This modification controls whether Oracle8i generates audit records into the audit trail, regardless of whether statement, privilege, and schema object auditing have been defined. By default, auditing is completely disabled and the parameter is set to NONE. The following list contains valid AUDIT_TRAIL parameter values: DB Enables database auditing and directs all audit records to the database audit trail OS Enables database auditing by directing audit records to the operating system audit trail NONE Disables auditing (the default value)

Enabling auditing options

Use the AUDIT command to enable statement, privilege, and schema object auditing. To set statement and privilege audit options, you must have the AUDIT SYSTEM system privilege. To set auditing for schema object auditing, you must own the object or have the AUDIT ANY system privilege. You can use the following audit constraints in conjunction with the AUDIT command to limit the audit scope:
WHENEVER SUCCESSFUL/ WHENEVER NOT SUCCESSFUL BY SESSION/BY ACCESS

When a session is created, the current auditing options are retrieved from the data dictionary. These auditing options exist for the life of the session. Setting or modifying audit options causes all subsequent sessions to use the new options, while existing sessions still continue to use the audit options in place at their creation. In contrast, changes to schema object audit options are immediately effective for current sessions.
Note

The AUDIT command only activates auditing options; it does not enable Oracle8i auditing as a whole.

To audit all unsuccessful connections to the database BY SESSION, regardless of user, use the following command:
AUDIT SESSION WHENEVER NOT SUCCESSFUL;

To audit all unsuccessful connections to the database by a specified user (TONY), use the following command:
AUDIT SESSION BY TONY WHENEVER NOT SUCCESSFUL;

674

Part VI Advanced Topics

To audit all unsuccessful INSERT, DELETE, and DROP ANY TABLE system privileges on all tables, use BY ACCESS, which requires two statements, as follows:
AUDIT INSERT TABLE, DELETE TABLE BY ACCESS WHENEVER NOT SUCCESSFUL; AUDIT DROP ANY TABLE BY ACCESS WHENEVER NOT SUCCESSFUL;

To audit all successful DELETE commands on the STUDENTS table, use BY ACCESS as follows:
AUDIT DELETE ON AMY.STUDENTS BY ACCESS WHENEVER SUCCESSFUL;

Disabling audit options

The NOAUDIT command disables existing enabled auditing options. It can include the BY USER constraint to disable auditing of certain users selectively. You can also use the constraint WHENEVER to limit the disable scope to the constraint not the entire audit option. Some examples of the NOAUDIT command follow:
NOAUDIT SESSION; NOAUDIT DELETE ANY TABLE; NOAUDIT DELETE ON AMY.STUDENTS WHENEVER NOT SUCCESSFUL;

The Oracle8i Audit Trail

Audit records can be stored in the database, in a table owned by the user SYS, or in an operating system file. The Oracle8i audit trail table is the table named AUD$ in the SYS schema of each Oracle8i database. Several views allow you to query and report on this information. The generation and insertion of an audit trail record is independent of a users transaction. If a user rolls back a transaction, the audit record is still generated and committed. Audit records are never generated by sessions established for the user SYS or as INTERNAL. The following events are always audited, and are logged on the database alert log, regardless of whether Oracle8i auditing is enabled: instance startup, instance shutdown, and administrative connections. Each audit trail record can contain different types of information, depending on the DML and DDL SQL operations audited and the auditing constraints set. The following information is always recorded: The users name The session identifier

Chapter 25 Using Oracle8is Auditing Features

675

The terminal identifier The name of the schema object accessed The operation performed or attempted The completion code of the operation The date and timestamp The system privileges used Either Oracle8i or the operating system (OS) audit trail can store all the database audit records. Lets look at the advantages of using each audit storage mechanism.

Operating system audit trail

The OS audit trails enable you to consolidate auditing information from your environment and other applications, not just from Oracle8i. This consolidation can provide a bigger picture of the system operations under observation. However, you may need to write custom software to report on it. The following codes are encoded in an operating system audit trail and need to be decoded for interpretation: Action Code describes the operation performed. The AUDIT_ACTIONS data dictionary table contains a list of codes and their respective descriptions. Privileges Used describes system privileges used to perform an action. The table SYSTEM_PRIVILEGE_MAP lists all of these codes and their respective descriptions. Completion Code describes the result of an attempted operation. A successful operation returns a value of 0, while unsuccessful operations return the respective Oracle8i error code describing why the operation was unsuccessful.

The database audit trail

With the database audit trail, Oracle8i provides several predefined views that allow Oracle8i to report audit information in many ways. You can use database tools such as Oracle Reports, PowerBuilder, or even SQL*Plus to generate custom audit reports.
Note

The database audit trail does not store information about data values that may have been changed by a SQL statement.

Implementing the Oracle8i Audit Trail Views

Oracle8i provides several predefined views to interpret the audited information back to users in a more meaningful way. To implement these views, connect to the Oracle8i database as the SYS user and run the CATAUDIT.SQL script with the SQL*Plus or the Oracle SQLPlus Worksheet tools. Executing the CATAUDIT.SQL script creates the views shown in Listing 25-1. For those views that are the most useful to you, a short description follows the view name.

676

Part VI Advanced Topics

Listing 25-1: Views created by running the CATAUDIT.SQL script

ALL_DEF_AUDIT_OPTS AUDIT_ACTIONS A list of code numbers and their meaning. The codes appear in the AUD$ table. DBA_AUDIT_EXISTS DBA_AUDIT_OBJECT Audit trail for objects. DBA_AUDIT_SESSION Audit trail for user sessions. DBA_AUDIT_STATEMENT Audit trail for statements. DBA_AUDIT_TRAIL All audit trail records. DBA_OBJ_AUDIT_OPTS Current auditing settings for objects. DBA_STMT_AUDIT_OPTS Current auditing settings for DML and DDL statements STMT_AUDIT_OPTION_MAP. USER_AUDIT_OBJECT USER_AUDIT_SESSION USER_AUDIT_SESSION USER_AUDIT_STATEMENT USER_AUDIT_TRAIL audit trail for a user. USER_OBJ_AUDIT_OPTS USER_TAB_AUDIT_OPTS

Querying the Oracle8i Audit Trail Views

Using the views listed above and the SYS.AUD$ and SYS.AUDIT_OPTIONS tables, you should be able to report on any portion of the audit trail you need. For example, if you want to look at the audit trail for the user named PREM, you can use the query shown in Figure 25-1, which illustrates the results set produced from executing a SELECT statement on the USER_AUDIT_TRAIL view during an audit of the BOOKS_LOANED table. Access the views by executing SQL statements against them in the SQL*Plus or Oracle SQL Worksheet tools.

SQLWKS> SELEC OWNER,OBJ_NAME 2> ACTION, ACTION_NAME, SESSIONID, ENTRYID, RETURNCODE 3> FROM SYS.USER_AUDIT_TRAIL 4>WHEREOBJ_NAME='BOOKS_LOANED' 5> OS_USERNAME USERNAME TERMINAL TIMESTAMP OWNER OBJ_NAME Sulaco Sulaco Sulaco Sulaco Sulaco Sulaco Sulaco 7 rows selected PREM PREM PREM PREM PREM PREM PREM SULACO SULACO SULACO SULACO SULACO SULACO SULACO 29-Oct-97 29-Oct-97 29-Oct-97 29-Oct-97 29-Oct-97 29-Oct-97 29-Oct-97 PREM PREM PREM PREM PREM PREM PREM

ACTION ACTION_NAME SESSIONID ENTRYID RETURNCODE 2 2 2 2 2 7 4 INSERT INSERT INSERT INSERT INSERT DELETE DELETE 132 137 137 137 137 138 138 1 1 2 3 4 2 3 2291 0 0 0 0 0 0

BOOKS_LOANED BOOKS_LOANED BOOKS_LOANED BOOKS_LOANED BOOKS_LOANED BOOKS_LOANED BOOKS_LOANED

Figure 25-1: Audit trail records contain user, session, object, and other identifiers.

Chapter 25 Using Oracle8is Auditing Features

677

The following query looks at all your auditing records, listing them in descending order by date and time:
SELECT TO_CHAR(TIMESTAMP#,MM/DD/YY HH:MI:SS) TIMESTAMP, USERID, AA.NAME ACTION, OBJ$CREATOR||.||OBJ$NAME OBJECT_NAME FROM SYS.AUD$ AT, SYS.AUDIT_ACTIONS AA WHERE AT.ACTION# = AA.ACTION ORDER BY TIMESTAMP# DESC;

If you disable Oracle8i auditing as a whole, you can use the CATNOAUD.SQL script to remove the preceding audit views.

Managing the audit trail

Although the whole auditing process is relatively inexpensive, strictly follow these audit guidelines to avoid fragmented auditing and uncontrolled growth of the system tablespace: 1. Audit generally and then audit specifically. The accumulation of some foundation information provides a better framework for auditing options and constraints. 2. Archive audit records and purge the audit trails to stop the SYSTEM tablespace from filling up. 3. Turn off unrequired audit options to focus the audit, or try other audit options.

Controlling the Growth of the Audit Trail

If the audit trail becomes completely full and no more audit records can be inserted, audited statements cannot successfully execute until you purge the audit trail. The database security administrator must control the growth of the database audit trail. The database audit trail grows in accordance with two factors: The number of audit options turned on (such as BY SESSION or BY ACCESS) The frequency of executed audited statements The maximum size of the audit trails is predetermined at the time of database creation. To maintain the SYS.AUD$ table, you cannot move it to another tablespace as a means of controlling growth. You can modify the initial storage parameter accordingly, however.

Purging the Audit Records from the Audit Trail

To free the SYSTEM tablespace and manage the audit trail, you need to purge the SYS.AUD$ table at set times in respect to its growth pattern. There are several ways to purge audit records, as described here. To delete all audit trail records, execute the following command:
DELETE FROM SYS.AUD$;

678

Part VI Advanced Topics

You can also delete specific records, such as all records for the STUDENTS table, as follows:
DELETE FROM SYS.AUD$ WHERE objname = STUDENTS;

You can also archive the audit records by exporting them to an operating system file or using the following statement:
INSERT INTO audit_temp SELECT * FROM SYS.AUD$;
Note

Only the SYS user, who holds the DELETE ANY TABLE system privilege, and any user granted the DELETE privilege on SYS.AUD$ by the user SYS can delete records.

If the audit trail fills and an auditing option is enabled BY SESSION, users will not be able to connect to the database. In this situation, the SYS user must connect and delete the records. The SYS user is not audited and can make space available.

Reducing the Size of the Audit Trails

As with any database table, used extents remain after records are deleted from the audit trail, thus causing the SYS.AUD$ to show an incorrect size. The following procedures enable you to reduce the size of the SYS.AUD$ table and provide better management of the audit trail: 1. Copy or export the data out of the SYS.AUD$ table. 2. Connect to the database with administrative privileges. 3. Truncate the SYS.AUD$ table using the TRUNCATE TABLE command. 4. Reload the archived audit trail records into the SYS.AUD$ table.
Note

SYS.AUD$ is the only SYS schema object you can modify directly.

Protecting the Audit Trail

To protect the integrity of the audit records and guarantee accuracy of the audit trail, put the following procedures in place: Grant the DELETE ANY TABLE system privilege to system administrators only. Audit changes to the audit trail by using the following:
AUDIT INSERT, UPDATE, DELETE ON SYS.AUD$ BY ACCESS;

Chapter 25 Using Oracle8is Auditing Features

679

Using Triggers to Implement Auditing

You can use triggers to supplement Oracle8is auditing features. Triggers record detailed information about the data used in the SQL statements, and triggers give you more control over what gets audited. Triggers are most useful when you need to audit changes to the data in a table, because triggers allow you to record both the before and after images of rows that are changed. You cant do that using Oracles built-in auditing features. Generally, when using triggers to audit changes to data, you should use AFTER triggers. That way you dont waste time and I/O resources recording changes, only to have them rolled back in the event that the triggering statement fails.

Setting up trigger auditing

Conduct the following tasks before creating a trigger for auditing: 1. Identify the data values that need to be audited constrained by the preceding points. 2. Create a table to contain the audit trail based on the data values modified by the audit trigger.
Note

Create the audit trail table in a different schema to allow better tablespace management and data segregation from the audited tables.

You have to set the triggering event on the audit trigger appropriately to capture the necessary actions on the audited table.

Creating audit triggers by example

Lets use the preceding framework to implement trigger auditing on the BOOKS_ LOANED table owned by the user AMY. The following data columns need to be audited in the BOOKS_LOANED table: BL_BOOK_ID BL_STUDENT_ID BL_LOAN_DATE BL_FINE

680

Part VI Advanced Topics

Create a table to contain the BOOKS_LOANED audit data using the following command:
CREATE TABLE AUDIT_BOOKS_LOANED ( AUDIT_ID NUMBER(5) PRIMARY KEY, AUDIT_BOOK_ID NUMBER(5) , AUDIT_STUDENT_ID NUMBER(5) , AUDIT_LOAN_DATE DATE , AUDIT_BOOK_FINE NUMBER(5,2), AUDIT_ACTION VARCHAR2(10), AUDIT_DATE DATE DEFAULT (SYSDATE));

Now, create a trigger that will record INSERT, UPDATE, and DELETE operations on the BOOKS_LOANED table, as shown in Listing 25-2.

Listing 25-2: Creating a trigger to record operations on the BOOKS_LOANED table

CREATE OR REPLACE TRIGGER rt_Audit_books_loaned BEFORE INSERT OR UPDATE OR DELETE ON BOOKS_LOANED FOR EACH ROW DECLARE Trigger_action VARCHAR2(10); BEGIN IF UPDATING THEN Trigger_action:= Update; INSERT INTO AUDIT_BOOKS_LOANED VALUES (AUDIT_BOOKS_LOANED_SEQ.nextval,:old.BL_BOOK_ID, :old.BL_STUDENT_ID,:old.BL_LOAN_DATE,:new.BL_FINE, Trigger_action, SYSDATE); END IF; IF DELETING THEN Trigger_action:= Delete; INSERT INTO AUDIT_BOOKS_LOANED VALUES (AUDIT_BOOKS_LOANED_SEQ.nextval,:old.BL_BOOK_ID,:old.BL_ STUDENT_ID, :old.BL_LOAN_DATE,:old.BL_FINE,Trigger_action, SYSDATE); END IF; IF INSERTING THEN Trigger_action:= Insert; INSERT INTO AUDIT_BOOKS_LOANED VALUES (AUDIT_BOOKS_LOANED_SEQ.nextval,:new.BL_BOOK_ID,:new.BL_ STUDENT_ID, :new.BL_LOAN_DATE,:new.BL_FINE, Trigger_action, SYSDATE); END IF; END;

Chapter 25 Using Oracle8is Auditing Features

681

Summary
In this chapter, you learned: The audit feature within Oracle8i can monitor potentially suspicious user activity as well as provide statistics on how the database is being accessed and used. Oracle8i can audit database operations at the following levels: SQL statement, system privilege, and schema object. You can narrow the focus of Oracle8i auditing by capturing only successful events or only unsuccessful events. You can also choose between having audited SQL statements recorded once per session or once per use. You can further focus your auditing efforts by auditing specific users rather than all users. The audit trail can be accessed through a number of views using the AUD$ system table. The AUD$ table requires growth management and should be archived and purged at regular intervals. Triggers provide a way to capture changes to the data in a table something you cant do using the built-in auditing features of Oracle8i.