Focus Statement, Privilege, and Schema Object Auditing

process the event; for example, the audit event handler could send an alert page to the administrator.

See Also: Oracle9i Application Developer’s Guide - Fundamentals

Focus Statement, Privilege, and Schema Object Auditing

Oracle lets you focus statement, privilege, and schema object auditing in three areas:

Successful and unsuccessful executions of the audited SQL statement

BY SESSION and BY ACCESS auditing

For specific users or for all users in the database (statement and privilege auditing only)

Successful and Unsuccessful Statement Executions Auditing

For statement, privilege, and schema object auditing, Oracle allows the selective auditing of successful executions of statements, unsuccessful attempts to execute statements, or both. Therefore, you can monitor actions even if the audited statements do not complete successfully.

You can audit an unsuccessful statement execution only if a valid SQL statement is issued but fails because of lack of proper authorization or because it references a nonexistent schema object. Statements that failed to execute because they simply were not valid cannot be audited. For example, an enabled privilege auditing option set to audit unsuccessful statement executions audits statements that use the target system privilege but have failed for other reasons (such as when CREATE TABLE is set but a CREATE TABLE statement fails due to lack of quota for the specified tablespace).

Using either form of the AUDIT statement, you can include:

The WHENEVER SUCCESSFUL clause, to audit only successful executions of the audited statement

The WHENEVER NOT SUCCESSFUL clause, to audit only unsuccessful executions of the audited statement

Neither of the previous clauses, to audit both successful and unsuccessful executions of the audited statement

24-10 Oracle9i Database Concepts

Focus Statement, Privilege, and Schema Object Auditing

BY SESSION and BY ACCESS Clauses of Audit Statement

Most auditing options can be set to indicate how audit records should be generated if the audited statement is issued multiple times in a single user session. This section describes the distinction between the BY SESSION and BY ACCESS clauses of the AUDIT statement.

See Also: Oracle9i SQL Reference

BY SESSION

For any type of audit (schema object, statement, or privilege), BY SESSION inserts only one audit record in the audit trail, for each user and schema object, during the session that includes an audited action.

A session is the time between when a user connects to and disconnects from an Oracle database.

BY SESSION Example 1 Assume the following:

The SELECT TABLE statement auditing option is set BY SESSION.

JWARD connects to the database and issues five SELECT statements against the table named departments and then disconnects from the database.

SWILLIAMS connects to the database and issues three SELECT statements against the table employees and then disconnects from the database.

In this case, the audit trail contains two audit records for the eight SELECT statements— one for each session that issued a SELECT statement.

BY SESSION Example 2 Alternatively, assume the following:

The SELECT TABLE statement auditing option is set BY SESSION.

JWARD connects to the database and issues five SELECT statements against the table named departments, and three SELECT statements against the table employees, and then disconnects from the database.

In this case, the audit trail contains two records—one for each schema object against which the user issued a SELECT statement in a session.

Auditing 24-11

Focus Statement, Privilege, and Schema Object Auditing

Note: If you use the BY SESSION clause when directing audit records to the operating system audit trail, Oracle generates and stores an audit record each time an access is made. Therefore, in this auditing configuration, BY SESSION is equivalent to BY ACCESS.

BY ACCESS

Setting audit BY ACCESS inserts one audit record into the audit trail for each execution of an auditable operation within a cursor. Events that cause cursors to be reused include the following:

An application, such as Oracle Forms, holding a cursor open for reuse

Subsequent execution of a cursor using new bind variables

Statements executed within PL/SQL loops where the PL/SQL engine optimizes the statements to reuse a single cursor

Note that auditing is not affected by whether a cursor is shared. Each user creates her or his own audit trail records on first execution of the cursor.

For example, assume that:

The SELECT TABLE statement auditing option is set BY ACCESS.

JWARD connects to the database and issues five SELECT statements against the table named departments and then disconnects from the database.

SWILLIAMS connects to the database and issues three SELECT statements against the table departments and then disconnects from the database.

The single audit trail contains eight records for the eight SELECT statements.

Defaults and Excluded Operations

The AUDIT statement lets you specify either BY SESSION or BY ACCESS. However, several audit options can be set only BY ACCESS, including:

For all other audit options, BY SESSION is used by default.

24-12 Oracle9i Database Concepts