Oracle Unleashed- P9

% sqlplus rhett
Password: ........
SQL> create table bonnie
2> (
3> pony_column varchar2(15)
4> )
5> tablespace users;
Table created.
SQL> grant select, insert, update on bonnie to scarlett;
Grant succeeded.
SQL> connect scarlett
Enter password: ......
SQL> select count(*) from rhett.bonnie;
COUNT(*)
----------
0
SQL> connect rhett
Enter password: ........
Connected.
SQL> drop table bonnie;
Table dropped.
SQL> create table bonnie
2> (
3> pony_column varchar2(15)
4> )
5> tablespace users;
Table created.
SQL> connect scarlett
Enter password: ......
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Connected.

SQL> select count(*) from rhett.bonnie;
Error at line 1:
ORA-00942: table or view does not exist
RHETT owns the table BONNIE, and he has granted SCARLETT access to the table. If BONNIE is dropped by RHETT
and recreated with the same object name, SCARLETT no longer has access to the table. This is true until RHETT makes
the grant again. If there were multiple grants, each grant must be made for each user on each database object. This can be
quite cumbersome.
The WITH GRANT OPTION Option
In many environments, it is beneficial to have users other than the DBA perform grants. For example, the DBA might
want to allow a project leader to grant rights on database objects to people working on his project. Thus, the DBA has to
do the grants only once; then it falls to the project leader to make further grants as necessary.
Oracle provides a mechanism for doing this: GRANT OPTION of the grant SQL command. With it, a user can issue
grant commands just as though he were the actual owner of the database object. For example,
% sqlplus aimee
Password: ........
Connected.
SQL> grant select on order to jason with grant option;
Grant succeeded.
SQL> connect jason
Enter password: ........
Connected.
SQL> grant select on aimee.order to lucinda;
Grant succeeded.
A database user who has received a grant with the ALL privilege does not receive GRANT OPTION automatically; it
must be explicitly granted. As specified with object privileges above, GRANT OPTION remains in effect only until an
object is dropped.
SCARLETT owns a view of another database view called GEORGIA. This view is based on a table owned by
another user, RHETT, and is called CHARLESTON. SCARLETT must have WITH GRANT OPTION on GEORGIA. If
this is not done, grants of this view to other users will not work properly.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

Resolving Object Synonyms
A synonym is simply a designation for a database object that enables it to be referenced by another name. There are two
types of these synonyms: private and public. A private synonym is a synonym created by the user that only he uses; no
one other than the user who created the synonym can use it. A public synonym is accessible to all users in the database.
Suppose, for example, that a user, TAL, has a table named HOCKEY for which two synonyms exist"ICE, a private
synonym, and SPORT, a public synonym. This gives five distinct methods for accessing this particular table:
●
As TAL, using the actual table name, HOCKEY.
●
As TAL, using the private synonym name, ICE.
●
As TAL, using the public synonym name, SPORT.
●
As another user, using the database object owner and object name, TAL.HOCKEY.
●
As another user, using the public synonym name, SPORT.
This example assumes that the appropriate grants have been made on the HOCKEY table to permit access. In dealing
with synonyms, it is important to understand the order in which the database resolves naming. This is important when
you test programs for which there is a global table and a local table. Consider the following SQL statement:
select * from emp;
When it attempts to resolve this statement, the database first checks whether a database object "such as a table, view, or
database link"exists and is owned by the current database user. If it finds a match, it stops. If a match does not exist, it
checks for a private synonym that will direct it to a specific database object. If no private synonym exists, it checks for a
public synonym that will point it toward an existing database object. If no resolution is found, if the database objects
referenced by the synonyms do not exist, or if the user has no privileges on the object in question, an error condition
occurs.
System Security
Whereas object privilege deals with what a user can do to database objects, system privilege deals with what actions a
user can perform against the database itself. The actions include connecting to the database, creating database tables, and
dropping an entire tablespace (with all the database objects in it). The functionality of Oracle7 makes the system

privileges far more scaleable than in Oracle6.
Under Oracle6, the Oracle RDBMS resembled UNIX in its overall security scheme. UNIX maintains that an account is
either the root user or a regular user. Admittedly, UNIX has evolved to enable a greater deal of scalability by using
things such as access control lists (ACLs) and root set userid (suid) programs. Oracle6 is set up so that all users are either
the DBA or not the DBA. With the release of Oracle7, Oracle moves away from this methodology. It is possible now to
grant specific privileges to non-DBA users, thereby enabling them to perform certain applications without giving them
full DBA access.
Defined System Privileges
In Oracle6, three system privileges are available. Over 80 system privileges are available in Oracle7. The following is a
partial list of the database system privileges. The information comes from the Oracle7 Server Administrator's Guide, an
excellent reference that describes the capabilities of each privilege.
ALTER DATABASE
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
ALTER PROFILE
ALTER RESOURCE COST
ALTER ROLLBACK SEGMENT
ALTER SESSION
ALTER SYSTEM
ALTER TABLESPACE
ALTER USER
AUDIT SYSTEM
BECOME USER
CREATE CLUSTER
CREATE DATABASE LINK
CREATE PROCEDURE
CREATE PROFILE
CREATE PUBLIC DATABASE LINK
CREATE PUBLIC SYNONYM
CREATE ROLE
CREATE ROLLBACK SEGMENT

CREATE SESSION
CREATE SEQUENCE
CREATE SNAPSHOT
CREATE SYNONYM
CREATE TABLE
CREATE TABLESPACE
CREATE TRIGGER
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CREATE USER
CREATE VIEW
DROP PROFILE
DROP PUBLIC DATABASE LINK
DROP PUBLIC SYNONYM
DROP ROLLBACK SEGMENT
DROP TABLESPACE
DROP USER
FORCE TRANSACTION
MANAGE TABLESPACE
READUP
RESTRICTED SESSION
UNLIMITED TABLESPACE
Like object privileges, system privileges are given to users through the grant SQL command. The following code
segment demonstrates how a system privilege grant is done:
% sqlplus system
Password: ........
Connected.
SQL> grant create session, alter session to anna;
Grant succeeded.
The revoke SQL command takes away system or object privileges that were given through the grant command. It is
important to note that revoking a privilege does not destroy a database object. In the following example, the table

remains even though the privilege to create new tables has been revoked:
% sqlplus fred
Password: ......
Connected.
SQL> select * from cat;
TABLE_NAME TABLE_TYPE
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
------------------------------ -----------
SPORTS TABLE
1 rows selected.
SQL> connect system
Enter password: ........
Connected.
SQL> revoke create table from fred;
Revoke succeeded.
SQL> connect fred
Enter password: ........
Connected.
SQL> select * from cat;
TABLE_NAME TABLE_TYPE
------------------------------ -----------
SPORTS TABLE
1 rows selected.
The WITH ADMIN OPTION Option
WITH ADMIN OPTION is to database system privileges what WITH GRANT OPTION is to database object privileges.
By making a grant WITH ADMIN OPTION, the DBA enables a user to grant the system privilege to another user. For
example,
% sqlplus system
Password: ........
SQL> grant create user to helpdesk with admin option;

Grant succeeded.
ANY Privileges
The ANY privileges are a special class of privileges within the database system privileges. They are enhanced system
privileges that grant the user the ability to perform specified actions without restrictions. If a user has these system
privileges, he can override normal default security. Therefore, he has access to other database objects, regardless of
whether an object-level grant is made. The following is a list of the ANY privileges. They are described in detail in the
Oracle7 Server Administrator's Guide.
ALTER ANY CLUSTER
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
ALTER ANY INDEX
ALTER ANY PROCEDURE
ALTER ANY ROLE
ALTER ANY SEQUENCE
ALTER ANY SNAPSHOT
ALTER ANY TABLE
ALTER ANY TRIGGER
BACKUP ANY TABLE
COMMENT ANY TABLE
CREATE ANY CLUSTER
CREATE ANY INDEX
CREATE ANY PROCEDURE
CREATE ANY SEQUENCE
CREATE ANY SNAPSHOT
CREATE ANY SYNONYM
CREATE ANY TABLE
CREATE ANY TRIGGER
CREATE ANY VIEW
DELETE ANY TABLE
DROP ANY CLUSTER
DROP ANY INDEX

DROP ANY PROCEDURE
DROP ANY ROLE
DROP ANY SEQUENCE
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
DROP ANY SNAPSHOT
DROP ANY SYNONYM
DROP ANY TABLE
DROP ANY TRIGGER
DROP ANY VIEW
EXECUTE ANY PROCEDURE
FORCE ANY TRANSACTION
GRANT ANY PRIVILEGE
GRANT ANY ROLE
INSERT ANY TABLE
LOCK ANY TABLE
SELECT ANY SEQUENCE
SELECT ANY TABLE
UPDATE ANY TABLE
The DBA should be careful when granting system privileges, especially the ANY class of privileges. Some of them are
not meant for public use. They put too much power in the hands of users if they are not adequately managed. Although
the privileges are more scaleable than under previous Oracle versions, the DBA should treat them as mini-DBA
privileges when determining who should receive them.
A final issue regarding protecting system privileges is what effect these privileges have within a secure database. In most
databases, some tables contain information that should not be distributed to the general public, such as payroll
information. A user with the some of the ANY privileges, such as SELECT ANY or UPDATE ANY, has access to the
tables even without an explicit grant.
Grants to PUBLIC
It is possible to make grants on both system and object privileges to PUBLIC. This is a special Oracle account to which
all other accounts have access. Any grant made to PUBLIC is accessible by any database user. For example,
% sqlplus system

Password: ........
Connected.
SQL> grant select on hr.emp_name to public;
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Grant succeeded.
The DBA can use the PUBLIC account to set up a common set of grants "such as the CREATE SESSION privilege,
which permits connection to the database" and grant them to PUBLIC. In doing this, the DBA removes the need to make
explicit grants to every user when a new account is added.
The DBA can use PUBLIC to lock groups of users out of the database without having to restart the
instance in RESTRICT mode. For example, he can grant CREATE SESSION to PUBLIC and make explicit CREATE
SESSION grants to key users, such as IS personnel. In the event that activity needs to be done on the database, the
following command can be executed from SQL*Plus or Oracle Server*Manager:
revoke create session from public;
This command effectively locks out everyone except the IS users after all the users have logged off the database. The
grants can be reinstated as follows:
grant create session to public;
Object Security Model
The DBA must consider other factors when setting up a security plan. Not only should the setup of the database users be
considered, but also the ownership of the database objects. Although there is no right or wrong way to go about this, the
following sections outline some of the concerns faced by the DBA when setting up object ownership models.
Protected Object Ownership Schema
One security model implemented by many sites is the protected schema "sometimes called the pure schema. Under this
model, the DBA sets up an account that is not associated with any specific database user. This account is used as an
ownership account for all the database objects"tables, views, and so on. Public synonyms are set up for each database
object, and grants are made to each user for each database object. Therefore, a single user owns the objects, but the
account can be restricted by not issuing passwords to any users except those who perform database object maintenance.
There is nothing incredibly mystical about this setup. The object owner exists as just another account within the
database. Depending on the environment, the DBA can configure the database to have only connection or resource
privileges during maintenance windows and then revoke those privileges when completed. Thus, access to the object
owner account can be given to other users "who might, for example, want to look at the contents of the CAT or

USER_TABLES table" without enabling them to make changes to the database objects themselves.
One important note here is that the DBA or person responsible for database object maintenance should maintain a build
script for the object. Although this information can be obtained from the Oracle Data Dictionary, it is important to have
this information accessible in emergency situations.
Capacity Planning Requirements
In dealing with database objects, one of the key elements for which the DBA is responsible is the capacity planning
requirements of the database. Many sites hold to the philosophy that the creation and maintenance of the database
objects responsibilities separate from overall database maintenance; most of these sites still agree that capacity planning
is a responsibility of the DBA. Everything in the database is stored physically in database files.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Volumes have been written concerning the best ways to optimize the capacity planning of database objects within
tablespaces. The main concern of capacity planning in this chapter is on security. Because users other than the DBA
might be involved in creating database objects, he should stay abreast of modifications as they occur. For example, it
takes only a typographical error in the STORAGE clause to inadvertently fill up a tablespace "1,000K and 10,000K are
different by just one zero. When no further space is available to expand the tablespace, this can bring production
databases to a screeching halt. By the same token, if the next extent sizes are set wrong forgetting the K in 512K makes
it 512 bytes " a database object can quickly reach its MAXEXTENTS. When this happens, the only option is to rebuild
the object with proper extent sizes. Depending on how much data is stored, this might be no small feat.
The bottom line on capacity planning requirements from a database security standpoint is to be certain that
accountability exists. Object creations should generally be limited to developers or analysts who have the technical
knowledge to understand what object creation entails. It should not be necessary to hold anyone's hand. Likewise, they
should not be given a blank check.
Avoiding Tablespace Fragmentation Issues
Given the prevalence of tools like Defrag by ARIS and TSReorg by Platinum Technology, tablespace fragmentation is
an obvious problem for most DBAs. Tablespace fragmentation, illustrated in Figure 16.1, occurs when free space is
available in a tablespace, but when the blocks of free space are not group in contiguous blocks. That is, they are not
together. Although the amount of fragmentation in Oracle7 is much better than in Oracle6, it remains a persistent
problem.
Figure 16.1. Tablespace fragmentation.
Many DBAs might wonder what tablespace fragmentation has to do with database security. The answer is simple: Steps

that can be built into the security plan of the database that help minimize some of the main causes of database
fragmentation.
Suppose, for example, that a developer calls and complains that he cannot create a new table in tablespace XYZ.
Whenever he tries to issue the CREATE TABLE command from SQL, he receives this error message:
cannot allocate extent of size 99 in tablespace XYZ
A quick check of the view DBA_FREE_SPACE shows the amount of free space available in the tablespace, so it is
possible to calculate the total amount of free space capable of holding the table. The first question that the DBA should
pose to the developer is, ÒHow often are you dropping tables and indexes?Ó This is the most common cause of
tablespace fragmentation, especially for tablespaces to which developers have access. As a rule, developers perform
CREATE TABLE/INDEX and DROP TABLE/INDEX operations on a regular basis, which inevitably leads to
problems.
It is a good idea to limit or eliminate access to the tablespaces on which production objects reside. You can do this by
using tablespace quotas and by not giving anyone other than the protected schema access to the tablespaces. Generally, a
special work tablespace called WORK or MISC is created. Developers can perform adds and drops on it. If this
tablespace fragments, it can be defragmented at the DBA's discretion. If many people have access to the schema
ownership account, it is often a good idea to revoke quotas on the tablespace from the schema until such a time as
needed. This depends largely on the user community that is using the account.
By limiting the amount of access to production tablespaces, the DBA can help reduce "although not eliminate"
tablespace fragmentation. This helps eliminate the amount of crisis mode management that a DBA must undertake.
Defining Database Roles
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
In versions of Oracle prior to Oracle7, explicit grants from the system and the object privilege level are the rule. At first,
this was not much of a hindrance because of the size of most databases. Large databases were the exception; small
databases were the rule. As databases grew in size, many DBAs began to see how cumbersome and difficult that method
of access grants was. For example, in a database system with 40 database tables and views and 100 database users, over
4,000 separate grants must be processed. This is a relatively small database, so it is easy to see the cumulative effects of
adding users and objects on larger databases systems. Likewise, if a change in privilege needs to be made or a table is
recreated, all the privileges must be made again.
Most DBAs found avenues around this problem by creating SQL scripts or by writing programs that handle the
cumbersome grant process. Oracle responded to this problem by providing its user community with database roles.

At the simplest level, roles are simply groups of system or object privileges that can be assigned to database users.
Grants on the desired privileges, such as CREATE SESSION or SELECT ON SCOTT.EMP, are made to a role. This
role is then granted to a user. The database user has all the privileges that have been assigned to the role. There is no
limit to the number of people who can have the role assigned to them, and changes are replicated to all the database users
by making a change in the grants to the role.
Creating Roles
Aside from defining the privileges necessary for each role and selecting appropriately descriptive names, the process of
creating a role is simple. The syntax is similar to creating a database user. For example,
% sqlplus system
Password: ........
Connected.
SQL> create role global_mis;
Role created.
Modifying Roles
Making changes to database roles consists of changing the database privileges "object or system" to which the role has
access. This is done through standard SQL grant and revoke statements. For example,
% sqlplus system
Password: ........
Connected.
SQL> alter role global_mis identified by universe;
Role altered.
It is not necessary to replicate the change for each database user. Once the grant or revoke is successfully performed on
the role, it immediately takes effect for all the database users who have the role assigned to them. There are no special
steps or cumbersome processes. In the example database, only 100 grants "the total number of users" must be performed,
unless multiple roles are assigned to a single user. For example, if the DBA needs to change access on a table from
UPDATE to SELECT, he would issue the appropriate revoke command on the role. The change takes effect on all the
database users with that role.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Although it is possible to grant roles to other roles "which is called nesting" there is a limit to the number of
active roles that can be in effect for a single user at any one time. This is determined by the value of the INIT.ORA

parameter MAX_ENABLED_ROLES. The database does not permit more than the limit set by this value to be enabled.
Deleting Roles
The DBA can delete a role from the database. This operation removes information pertaining to the role from all the
users and roles currently in existence. As with revoking a system privilege, deleting a role does not affect existing
database objects. For example,
% sqlplus system
Password: ........
Connected.
SQL> drop role admin;
Role dropped.
Setting and Changing the Default Role
Whenever a role is granted to a user, the privileges within the role do not take effect until the role has been set as the
default role. The default role tells the database that it is the role whose privileges are currently being used. The default
role determines which database role the user uses when he first connects to the database.. For example,
% sqlplus system
Password: ........
Connected.
SQL> alter user amy default role admin;
Statement processed.
The user or the DBA can also change the current default role. At the discretion of the DBA, every role assigned to a user
can be set as the default role. In this way, a user does not have to switch between roles. Instead, he can benefit from the
system and object privileges of all of the active roles at a given time without being forced to change default roles each
time. For example,
% sqlplus system
Password: .......
Connected.
SQL> alter user logan default role all;
Statement processed.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
The DBA should carefully evaluate the ramifications of setting all the roles as default roles before he institutes this

option.
Password Protecting Roles
At some sites, users are grouped into different privilege levels that require a decision before they perform a certain task.
Take, for example, a user in an OLTP system who has three roles "ORD_ENTRY, MANAGER, and SUPERUSER.
Each level might have different levels of privileges. MANAGER might have SELECT, INSERT, UPDATE, and
DELETE capabilities on key tables that are not accessible to ORD_ENTR. MANAGER might lack certain system
privileges that belong to SUPERUSER. Whatever the case, the DBA might require a password for each level.
This password helps protect the privilege levels by keeping others out of the role, and it also forces the user to know
what role he is currently using. In theory, he would remember which password he most recently entered. Likewise, the
password enables the DBA to keep users out of certain privilege groups by changing the password associated with the
role.
Switching between roles is the same as switching between roles that have no passwords. The sole difference is that a
correct password must be given before Oracle will accept the role change. For example,
% sqlplus jordan
Password: ........
Connected.
SQL> set role lawyer;
Enter password: ........
Statement processed.
Defining Roles at Operating System Level
It is possible to grant roles dynamically at the operating system level. For this to take place, a few additional steps must
be performed when the roles are created. The benefit is that roles are always identified at the operating system level "in /
etc/groups in UNIX, for example. They can easily be changed by someone who has privilege to make modifications"
usually the system administrator.
Using operating system authenticated roles should be considered only at sites where the DBA can make changes
to the appropriate file. If the DBA lacks this authority, the entire process entails too much overhead to be useful. Grants
should be performed at the database level instead.
One of the first steps in creating an operating system authenticated role is to make certain that the parameter OS_ROLES
in the INIT.ORA parameter file is set to TRUE. This parameter enables the DBA to enable or disable the use of
operating system authenticated roles.

To prevent possible breaches of security, a default role cannot be authenticated at the operating system level
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
when Oracle's Multi-Thread Server is running. If breaches of security are not a concern, you can enable them for multi-
thread sites by setting the value of REMOTE_OS_ROLES to TRUE. Consider this carefully.
Operating system authenticated roles, like operating system authenticated accounts, must be created at the database level.
As with user accounts, this is done by identifying them EXTERNALLY. For example,
% sqlplus system
Password: ........
Connected.
SQL> create role manager identified externally;
Role created.
Each role to be used by the Oracle database instance must be defined as being identified externally in the database. It
must also be defined at the operating system. The role always has the prefix ora_, following by the Oracle SID of the
instance and the name of the role. It can also have the suffix d (if it is a default role) or a (if the user has ADMIN
OPTION on the role).
In the following example, a role named manager is set up in the norm instance:
ora_norm_manager_ad:*:512:larry,daryl,o_daryl
The users larry, daryl, and o_daryl have manager as their default role, with ADMIN OPTION on it. Assuming that the
role has been created "that is, identified externally" within the database and that the database has been restarted with
OS_ROLES set to TRUE, this is all that is required to authenticate an account at the operating system level. Modifying
this role is a matter of simply adding a user to the group at the UNIX level. Note that operating system authentication is
not available on all platforms.
System Privilege Roles
Oracle6 has only three system privileges. The privileges are
●
connect, which enables the user to connect to the database
●
resource, which enables the user to create objects in database tablespaces
●
dba, which gives the user full system rights on the database

Oracle7 provides for backward compatibility by giving combination privileges that simulate the same functionality as
their Oracle6 counterparts. It uses roles of system privileges to accomplish this task.
The Oracle7 CONNECT privileges that are assigned to a user by means of system privilege roles are
ALTER SESSION
CREATE CLUSTER
CREATE DATABASE LINK
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CREATE SEQUENCE
CREATE SESSION
CREATE SYNONYM
CREATE TABLE
CREATE VIEW
The Oracle7 RESOURCE privileges that are assigned to a user by means of system privilege roles are
CREATE CLUSTER
CREATE PROCEDURE
CREATE SEQUENCE
CREATE TABLE
CREATE TRIGGER
UNLIMITED TABLESPACE
UNLIMITED TABLESPACE is normally not available as part of a role. Oracle enables it specifically to deal with
backward compatibility.
The Oracle7 EXP_FULL_DATABASE privileges that are assigned to a user by means of system privilege roles are
SELECT ANY TABLE
BACKUP ANY TABLE
INSERT, UPDATE, and DELETE on SYS.INCEXP
INSERT, UPDATE, and DELETE on SYS.INCVID
INSERT, UPDATE, and DELETE on SYS.INCFIL
The Oracle7 IMP_FULL_DATABASE privileges that are assigned to a user by means of system privilege roles are
BECOME USER
The Oracle7 DBA privileges that are assigned to a user by means of system privilege roles are

ALL PRIVILEGES WITH ADMIN OPTION
EXP_FULL_DATABASE
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
IMP_FULL_DATABASE
There have been rumors that these system roles have been provided only for backward compatibility with previous
versions of Oracle and that future releases will not support them. Although this seems unlikely given the amount of
software that that relies on these privileges, you should be aware of it. After all, Oracle undertook drastic changes when
it moved from Oracle6 to Oracle7.
Database Auditing
This section on database auditing is the one that really causes the Mission: Impossible soundtrack to play louder.
Auditing gives the DBA the ability to track information within the database. It provides information on who performed a
certain operation and when it was performed. This is a powerful security feature of the Oracle RDBMS, but it comes
with a price.
Auditing is a reactive function. It gives the DBA information about an activity only after it has already occurred. This
reactive information provides a snapshot of what occurred, depending on the level of detail being audited. It gives the
DBA a basis for tracking changes within the database.
Because auditing causes additional rows to be added to the database for each operation, it is important to balance the
auditing being done against constraints such as performance overhead and physical storage requirements. Unless site-
specific reasons require otherwise, the DBA should limit the amount of information being audited. It is not uncommon
for DBAs to run continuous high-level audit trails that track which users are connecting to the database, for example. It
is much more uncommon for the database to track all SQL statements being issued by all users at all times. As a rule of
thumb, the DBA should introduce only lower levels of auditing when he suspects inappropriate activity, and he should
be specific about whom the audit is directed against.
To activate auditing for a database instance, the DBA must make certain that the AUDIT_TRAIL parameter of the INIT.
ORA parameter file is set to DB or OS to indicate where the audit trail should be written. The default value for this
parameter is NONE.
Statement Level Auditing
Auditing that occurs at the statement level "sometimes called the privilege level" has a wide scope. With this level of
auditing, an audit record is written for each specific SQL statement that is issued. It is possible to limit it to a specific
user "such as all CREATE TABLE commands issued by DAVE" or to all users "such as any ALTER TABLE command

issued by any user. Depending on how specific the DBA makes this level of auditing, the audit information generated
can be substantial.
In the following example, two audit options are set. One option logs CREATE TABLE activity within the database. The
other option logs all CREATE SESSION activity done by BETO.
% sqlplus system
Password: ........
Connected.
SQL> audit create table by access whenever successful;
Statement processed.
SQL> audit create session by beto by access whenever successful;
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Statement processed.
Two important parameters appear in every SQL audit command:
●
BY SESSION/BY ACCESS
●
WHENEVER SUCCESSFUL/WHENEVER NOT SUCCESSFUL
BY SESSION/BY ACCESS determines how often audit records should be written. In a BY SESSION audit, the
database writes a single audit record that sums all the times that an action took place during a given session. In a BY
ACCESS audit, the database writes a single audit record for each SQL statement that was issued.
WHENEVER SUCCESSFUL/WHENEVER NOT SUCCESSFUL determines the conditions under which the audit
records should be written. Audits that are WHENEVER SUCCESSFUL have information written only if they succeed.
WHENEVER NOT SUCCESSFUL audits are written only if they do not succeed.
System-level roles can be used to implement auditing, so that only a single SQL statement is required to audit several
different operations. Consult the Oracle7 Server Administrator's Guide for more information.
The CLUSTER statement audits:
CREATE CLUSTER
ALTER CLUSTER
DROP CLUSTER
TRUNCATE CLUSTER

The DATABASE LINK statement audits:
CREATE DATABASE LINK
DROP DATABASE LINK
The INDEX statement audits:
CREATE INDEX
ALTER INDEX
DROP INDEX
The EXISTS statement indicates a failure because a value currently exists in the database. This is a feature of Trusted
Oracle7 only.
The NOT EXISTS statement indicates a failure because database objects do not exist.
The PROCEDURE statement audits:
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CREATE FUNCTION
CREATE PACKAGE
CREATE PACKAGE BODY
CREATE PROCEDURE
DROP FUNCTION
DROP PACKAGE
DROP PROCEDURE
The PROFILE statement audits:
CREATE PROFILE
ALTER PROFILE
DROP PROFILE
The PUBLIC DATABASE LINK statement audits:
CREATE PUBLIC DATABASE LINK
DROP PUBLIC DATABASE LINK
The PUBLIC SYNONYM statement audits:
CREATE PUBLIC SYNONYM
DROP PUBLIC SYNONYM
The ROLE statement audits:

CREATE ROLE
ALTER ROLE
DROP ROLE
SET ROLE
The ROLLBACK SEGMENT statement audits:
CREATE ROLLBACK SEGMENT
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
ALTER ROLLBACK SEGMENT
DROP ROLLBACK SEGMENT
The SEQUENCE statement audits:
CREATE SEQUENCE
DROP SEQUENCE
The SESSION statement audits database connections and disconnections.
The SYNONYM statement audits:
CREATE SYNONYM
DROP SYNONYM
The SYSTEM AUDIT statement audits:
AUDIT
NOAUDIT
The SYSTEM GRANT statement audits:
GRANT on system privileges and roles
REVOKE on system privileges and roles
The TABLE statement audits:
CREATE TABLE
DROP TABLE
TRUNCATE TABLE
The TABLESPACE statement audits:
CREATE TABLESPACE
ALTER TABLESPACE
DROP TABLESPACE

The TRIGGER statement audits:
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CREATE TRIGGER
ALTER TRIGGER ENABLE/DISABLE
DROP TRIGGER
ALTER TABLE with the ENABLE/DISABLE option
The USER statement audits:
CREATE USER
ALTER USER
DROP USER
The VIEW statement audits:
CREATE VIEW
DROP VIEW
Object Level Auditing
It is possible to audit database information at the database object level, which enables you to trap operations done on a
specific database object. The syntax is essentially the same as that for a statement level audit:
% sqlplus system
Password: ........
Connected.
SQL> audit delete on hr.payroll;
Statement processed.
The statement audit specifies a class of statements and, optionally, which user to audit for these statements. The object
audit, on the other hand, points to a type of object operation and the name of an object.
The types of object level operations that can be performed are
ALTER
AUDIT
COMMENT
DELETE
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.