CHAPTER THREE

3. Database Integrity, Security and Recovery

Learning Objectives: After completing this chapter, you will be able to familiar with the
following concepts:
• Integrity concept
• Database security threats
• Countermeasures to database security threats
• Database security
• Implementing and Administering User Security in Oracle

3.1. Overview of Database Integrity, Security and Recovery

Database security is the mechanisms that protect the database against intentional or
accidental threats. Database security includes hardware, software, people and data in multi-
user database system. Database security and integrity is about protecting the database from
being inconsistent and being disrupted. Database misuse could be intentional or accidental,
where accidental misuse is easier to handle than intentional misuse. Accidental inconsistency
could occur due to: system crash during transaction processing, logical errors, anomalies due
to redundancy and concurrent access. Intentional misuse could be: unauthorized reading of
data, unauthorized modification of data and unauthorized destruction of data.
3.2. Database Integrity
Integrity refers to ensuring the authenticity of information that information is not altered or
modified, and that the source of the information is genuine. Database integrity refers to the
accuracy and correctness of data in the database. Imagine that you have a website and you
sell products on that site. Now imagine that an attacker can shop on your web site and
maliciously alter the prices of your products, so that they can buy anything for whatever price
they choose. That would be a failure of integrity, because your information in this case, the
price of a product has been altered and you didn't authorize this alteration.
3.2.1. Database Integrity Constraints
Database Integrity constraints contribute to maintaining a secure database system by
preventing data from becoming invalid and hence giving or incorrect results. These are:
• Domain Integrity: means that each column in any table will have set of allowed values
and cannot assume any value other than the one specified in the domain.

1
 • Entity Integrity: in each table the primary key (which may be composite) satisfies both
the unique and contains no null values.
• Referential Integrity: In primary key foreign key relationship, the insert, update and
delete operations should be consistent in all tables.
• Key constraints: in a relational database, key constraints (primary key, candidate key,
foreign key, and etc.) used to maintain the integrity of the database.
• Enterprise Constraint: means some business rules set by the enterprise on how to use,
manage and control the data and the database.
• User-defined integrity: It enforces some specific business rules that are defined by
users. These rules are different from entity, domain or referential integrity.
3.2.2. Types of Constraints
Constraints ensures the accuracy and reliability of the data in the table. Constraints can be
column level or table level. Column level constraints apply to a column, and table level
constraints apply to the whole table. The following constraints are commonly used in SQL:
• Not Null: Ensures that a column cannot have a null value
• Unique: Ensures that all values in a column are different
• Primary Key: A combination of not null & unique to uniquely identify each row in a table
• Foreign Key: Uniquely identifies a row/record in another table
• Check: Ensures that all values in a column satisfies a specific condition
• Default: Sets a default value for a column when no value is specified
• Index: Used to create and retrieve data from the database very quickly

3.3. Database Security Threats

Threat is any situation or event, whether intentional or accidental, that may adversely affect
a system or database and consequently the organization. Threats to databases are: Loss of
integrity, Loss of privacy, Loss of availability, Loss of confidentiality and Theft and fraud.
A threat may be caused by a situation or event involving a person, action, or circumstance
that is likely to bring harm to an organization. The harm may be tangible, such as loss of
hardware, software, or data, or intangible, such as loss of credibility or client confidence. So,
as a minimum an organization should invest time and effort in identifying the most serious
threats.

2
 3.3.1. Countermeasures to Database Security Threats
The types of countermeasures to threats on computer systems range from physical controls
to administrative procedures. The following are computer-based security controls for a
multi-user environment:
1. Authorization: The granting of a right or privilege that enables a subject to have
legitimate access to a system or a system’s object. The process of authorization involves
authentication of subjects (i.e., a user or program) requesting access to objects (i.e., a
database table, view, trigger, or any other object that can be created within the system).
2. Authentication: Authentication is the process of checking whether the user is the one
with the privilege for the access level. All users of the database will have different access
levels and permission for different data objects.
3. Views: A view is the dynamic result of one or more relational operations on the base
relations to produce another relation. A view is a virtual relation that does not actually
exist in the database, but is produced upon request by a particular user. The view
mechanism provides a powerful and flexible security mechanism by hiding parts of the
database from certain users.
4. Backup and Recovery: Backup is the process of periodically taking a copy of the
database and log file (and possibly programs) on to offline storage media. Database
recovery is the process of restoring the database to a correct state in the event of a failure.
Journaling is the process of keeping and maintaining a log file (or journal) of all changes
made to the database to enable recovery to be undertaken effectively in the event of a
failure. If no journaling is enabled on a failed system, the only means of recovery is to
restore the database using the latest backup version of the database. However, without a
log file, any changes made after the last backup to the database will be lost.
5. Integrity: Integrity of information refers to protecting information from being modified
by unauthorized parties. For example, if you were sending an online money transfer for
birr 1000, but the information was tampered in such a way that you actually sent birr
10,000, it could prove to be very costly for you.
6. Encryption: Encryption is a method of protecting data from people you don’t want to
see it. For example, when you use your credit card on Amazon, your computer encrypts
that information so that others can’t steal your personal data as its being transferred.

3
 Similarly, if you have a file on your computer you want to keep secret only for yourself,
you can encrypt it so that no one can open that file without the password. It’s great for
everything from sending sensitive information to securing your email, keeping your
cloud storage safe, and even hiding your entire operating system.
7. RAID (Redundant Array of Independent Disks) Technology: RAID works on having
a large disk array comprising an arrangement of several independent disks that are
organized to improve reliability and at same time increase performance. Performance is
increased through data striping. Data striping is the data is segmented into equal size
partitions (the striping unit) which are transparently distributed across multiple disks.
RAID consists an array of disk in which multiple disks are connected together to achieve
different goals. RAID levels define the use of disk arrays.
3.4. Database Security
Database security is a protection of information contained in the database against
unauthorized access, modification or destruction. Database security issues are often lumped
together with data integrity issues, but the two concepts are really quite distinct. Security
means protecting the data against unauthorized users from disclosure, alteration, or
destruction. The person responsible for security of the database is usually database
administrator (DBA). DBAs create authorization rules that define who can access what parts
of database for what operations. A good database security management system has not
only the characteristics of data independence, shared access, minimal redundancy, and data
consistency but also the characteristics of privacy, integrity, and availability.
• Privacy signifies that an unauthorized user cannot disclose data.
• Integrity ensures that an unauthorized user cannot modify data.
• Availability ensures that data be made available to the authorized user unfailingly.
• Copyright ensures the native rights of individuals as a creator of information.
• Validity ensures activities to be accountable by law.
3.4.1. Need for Database Security
In the case of shared data, multiple users try to access the data at the same time. In order to
maintain the consistency of the data in the database, database security is needed. Due to the
advancement of internet, data are accessed through World Wide Web, to protect the data
against hackers and crackers, database security is needed.

4
• The plastic money (Credit card) is more popular. The money transaction has to be safe.
• Confidentiality (privacy): Data are only accessible by authorized subjects (users or
processes).
• To ensure data integrity which means data can only be modified by authorized subjects.
• Availability (denial of service). Data are avaliable to authorized subjects.
3.4.2. Security at Different Levels of Data
Almost all RDBMSs provide security at different levels and formats of data. This includes:
• Relation Level: permission to have access to a specific relation.
• View Level: permission to data included in the view and not in the named relations
• Hybrid (Relation/View): the case where only part of a single relation is made available
to users through View.
Any database access request will have the following three major components:
• Requested operation: what kind of operation is requested by a specific query?
• Requested object: on which resource or data of the database is the operation required to
be applied?
• Requesting user: who is the user requesting the operation on the specified object?
3.4.3. Role of Database Administrator in Database Security
The database administrator is responsible to make the database to be as secure as possible.
The DBA is responsible for the overall security of the database system. For this the DBA
should have the most powerful privilege than every other user. The in major
responsibilities of DBA relation to authorization of users are:
Account Creation: involves creating different accounts for different users as well as user
groups.
Security Level Assignment: involves in assigning different users at different categories of
access levels.
Privilege Grant: involves giving different levels of privileges for different users and user
groups.
Privilege Revocation: involves denying or canceling previously granted privileges for users
due to various reasons.
Account Deletion: involves in deleting an existing account of users or user groups. It is
similar with denying all privileges of users on the database.

5
 3.4.3.1. User Authorization Forms
There are different forms of user authorization on the resource of the database. These forms
are privileges on what operations are allowed on a specific data object. User authorization
on the data extension:
Read Authorization: the user with this privilege is allowed only to read the content of the
data object.
Insert Authorization: the user with this privilege is allowed only to insert new records or
items to the data object.
Update Authorization: users with this privilege are allowed to modify content of attributes
but are not authorized to delete the records.
Delete Authorization: users with this privilege are only allowed to delete a record and not
anything else.
Different users, depending on the power of the user, can have one or the combination of the
above forms of authorization on different data objects. User authorization on the database
schema:
Index Authorization: deals with permission to create and delete an index table for relation.
Resource Authorization: deals with permission to add/create a new relation in the database.
Alteration Authorization: deals with permission to add as well as delete attribute.
Drop Authorization: deals with permission to delete and existing relation.
3.4.4. Levels of Database Security
The database security can be broadly classified into physical and logical security. Physical
security is the security of the hardware associated with the system and the protection of the
site where the computer resides. Logical security is the security measures residing in the
operating system or the DBMS designed to handle threats to the data. Database security
levels are:
1. Physical Level: concerned with securing the site containing the computer system should
be physically secured. The backup systems should also be physically protected from
access except for authorized users.
2. Human Level: concerned with authorization of database users for access the content at
different levels and privileges.

6
3. Operating System: concerned with the weakness and strength of the operating system
security on data files. Weakness may serve as a means of unauthorized access to the
database. This also includes protection of data in primary and secondary memory from
unauthorized access.
4. Database System: concerned with data access limit enforced by the database system.
Access limit like password, isolated transaction and etc.
3.4.4.1. Database Security at Design Level
It is necessary to take care of the database security at the stage of database design. Few
guidelines to build the most secure system are:
• The database design should be simple. If the database is simple and easier to use, then
the possibility that the data being corrupted by the authorized user is less.
• The database has to be normalized. The normalized database is almost free from update
anomalies.
• The designer of the database should decide the privilege for each group of users.
• Create unique view for each user or group of users, because VIEW promotes security by
restricting user access to data.
3.4.4.2. Database Security Through Access Control
A database for an enterprise contains a great deal of information and usually has several
groups of users. Most users need to access only a small portion of the database which is
allocated to them. Allowing users unrestricted access to all the data can be undesirable, and
a DBMS should provide mechanisms to access the data. Especially, it is a way to control the
data accessible by a given user. The security mechanism of a DBMS must include provisions
for restricting access to the database as a whole this function is called access control and is
handled by creating user accounts and passwords to control login process by the DBMS.
Two main mechanisms of access control at the DBMS level are: Discretionary access
control and Mandatory access control.
Discretionary Access Control: Discretionary access control regulates all user access to
named objects through privileges, based on the concept of access rights or privileges for
objects (tables and views), and mechanisms for giving users’ privileges (and revoking
privileges). A privilege allows a user to access some data object in a manner (to read or
modify). Creator of a table or a view automatically gets all privileges on it. DBMS keeps

7
track of who subsequently gains and loses privileges, and ensures that only requests from
users who have the necessary privileges (at the time the request is issued) are allowed.
• Grant different privileges to different users and user groups on various data objects
• The privilege is to access different data objects. The mode of the privilege could be: read,
insert, delete, update records or fields.
• It is more flexible
• One user can have A but not B and another user can have B but not A.
The typical method of enforcing discretionary access control in a database system is based
on the granting and revoking privileges. Types of Discretionary Privileges:
• The account level: At this level, the DBA specifies the particular privileges that each
account holds independently of the relations in the database. Account level privileges:
o CREATE SCHEMA or CREATE TABLE privilege, to create a schema or relation;
o CREATE VIEW privilege;
o ALTER privilege, to apply schema changes such adding or removing attributes;
o DROP privilege, to delete relations or views;
o MODIFY privilege, to insert, delete, or update tuples;
o SELECT privilege, to retrieve information from the database by using a select query.
• The relation level (or table level): At this level, the DBA can control the privilege to
access each individual relation or view in the database. The second level of privileges
applies to the relation level this includes base relations and virtual (view) relations.
o The granting and revoking of privileges generally follow an authorization model for
discretionary privileges known as the access matrix model were.
o The rows of a matrix M represent subjects (users, accounts, programs).
o The columns represent objects (relations, records, columns, views, operations).
o Each position M(i,j) in the matrix represents the types of privileges (read, write,
update) that subject i holds on object j.
Example: Suppose that the DBA creates four accounts A1, A2, A3, and A4. And wants only
A1 to be able to create base relations. Then the DBA must issue the following GRANT
command in SQL:
• GRANT CREATE TABLE TO A1;

8
In SQL the same effect can be accomplished by having the DBA issue a CREATE
SCHEMA command as follows:
• CREATE SCHAMA EXAMPLE AUTHORIZATION A1;
User account A1 can create tables under the schema called EXAMPLE.
Suppose that A1 creates the two base relations EMPLOYEE and DEPARTMENT and A1
is then owner of these two relations and hence all the relation privileges on each of them.
Suppose that A1 wants to grant A2 the privilege to insert and delete tuples in both of these
relations, but A1 does not want A2 to be able to propagate these privileges to additional
accounts:
• GRANT INSERT, DELETE ON EMPLOYEE, DEPARTMENT TO A2;
Suppose that A1 wants to allow A3 to retrieve information from either of the two tables and
also to be able to propagate the SELECT privilege to other accounts. A1 can issue the
command:
• GRANT SELECT ON EMPLOYEE, DEPARTMENT TO A3 WITH GRANT OPTION;
A3 can grant the SELECT privilege on the EMPLOYEE relation to A4 by issuing:
• GRANT SELECT ON EMPLOYEE TO A4;
Notice that A4 can’t propagate the SELECT privilege because GRANT OPTION was not
given to A4. Suppose that A1 decides to revoke the SELECT privilege on the EMPLOYEE
relation from A3; A1 can issue:
• REVOKE SELECT ON EMPLOYEE FROM A3;
The DBMS must now automatically revoke the SELECT privilege on EMPLOYEE from
A4, too, because A3 granted that privilege to A4 and A3 does not have the privilege any
more. Suppose that A1 wants to give back to A3 a limited capability to SELECT from the
EMPLOYEE relation and wants to allow A3 to be able to propagate the privilege. The
limitation is to retrieve only the NAME, BDATE, and ADDRESS attributes and only for the
tuples with DNO=5. A1 then create the view:
• CREATE VIEW A3EMPLOYEE AS SELECT NAME, BDATE, ADDRESS FROM
EMPLOYEE WHERE DNO = 5;
After the view is created, A1 can grant SELECT on the view A3EMPLOYEE to A3 as
follows:
• GRANT SELECT ON A3EMPLOYEE TO A3WITH GRANT OPTION;

9
Finally, suppose that A1 wants to allow A4 to update only the SALARY attribute of
EMPLOYEE;
A1 can issue:
• GRANT UPDATE ON EMPLOYEE (SALARY) TO A4;
The UPDATE or INSERT privilege can specify particular attributes that may be updated
or inserted in a relation. Other privileges (SELECT, DELETE) are not attribute specific.
Mandatory Access Control: Enforce multilevel security. Classifying data and users into
various security classes (or levels) and implementing the appropriate security policy of the
organization. Each data object will have certain classification level. Each user is given
certain clearance level. Only users who can pass the clearance level can access the data
object. It is comparatively not-flexible/rigid. If one user can have A but not B, then B is
accessed by users with higher privilege and we cannot have B but not A.
Comparing Discretionary Access Control and Mandatory Access Control
Discretionary Access Control (DAC) policies are characterized by a high degree of
flexibility, which makes them suitable for a large variety of application domains. The main
drawback of DAC models is their vulnerability to malicious attacks, such as Trojan horses
embedded in application programs. By contrast, mandatory policies ensure a high degree of
protection in a way, they prevent any illegal flow of information. Mandatory policies have
the drawback of being too rigid and they are only applicable in limited environments. In
many practical situations, discretionary policies are preferred because they offer a better
trade-off between security and applicability.

3.5. Implementing and Administering User Security in Oracle

3.5.1. Database Administrator Responsibilities in Oracle
• Selecting the server hardware on which the database software will run.
• Installing and configuring the Oracle Database software on the server hardware.
• Deciding to use Oracle Database Container or a traditional single database
• Creating Oracle Database.
• Creating and managing the tables and other objects used to manage the application data.
• Creating and managing database users.
• Establishing reliable backup and recovery procedure for the database.
• Monitoring and tuning database performance.

10
• Analyzing trends and forecasting resource and storage requirements.
3.5.2. Oracle Database Architecture
The Oracle server architecture can be described in three categories:
• Server processes that communicate with user’s processes and interact with an Oracle
instance to fulfill requests.
• Logical memory structures that are collectively called an Oracle instance.
• Physical file structures that are collectively called a database.
In Oracle, the term database represents the physical files that store data. An instance is
composed of the memory structures and background processes. Each database should have
at least one instance associated with it. The key database components are memory structures,
process structures, and storage structures. Process and memory structures together are called
an instance; the storage structure is called a database. Taken together, the instance and the
database are called an Oracle server.

Figure: The Oracle Database architecture.

11
Each Oracle database consists of several schemas that reside in tablespaces. Tablespace is a
logical storage structure at the highest level in the database. Each tablespace consists of one
or more data files. The database has user data and overhead, such as database dictionary,
memory, control files, archived log files, flashback files, etc. Oracle Database allows
multitenancy, meaning, you can have more than one database in a structure called a container
database. The database overhead will be shared by all the databases in the container database.
The databases in the container database are called pluggable databases.

Figure: Oracle Database multitenancy

3.5.3. Interacting with Oracle Database
SQL*Plus is the primary tool for an Oracle DBA to administer the database using SQL
commands. SQL Developer is a GUI database-development tool to explore and manage the
database using predefined menu actions and SQL statements. With SQL Developer, you can
create and view the database objects, make changes to the objects, run SQL statements, run
PL/SQL programs, create and edit PL/SQL programs, and perform PL/SQL debugging. SQL
Developer also includes a migration utility to migrate Microsoft Access and Microsoft SQL
Server databases to Oracle Database.

12
 3.5.4. Creating and Managing User Accounts
Create user account with unique username and authentication method. The username must
adhere to the database object-naming convention. It must begin with a letter, have no more
than 30 characters, and be comprised of only letters, numbers, and $, #, _.
3.5.4.1. Configuring Authentication
Authentication involves validating the identity of the user and confirming that the user has
the authority to use the database. Oracle offers three authentication methods:
• Password-Authenticated User (the most common)
• External Authenticated User
• Global Authenticated User
Password-Authenticated User: Password-authenticated user accounts are the most
common and are sometimes referred to as database-authenticated accounts. With a password-
authenticated account, the database stores the encrypted password in the data dictionary. The
keyword IDENTIFIED BY informs that the user uses password authentication. For example,
to create a password authenticated user named Tomas with a password of tomas, you
execute the following: SQL> CREATE USER Tomas IDENTIFIED BY tomas;
The keywords IDENTIFIED BY password (in this case, the password is tomas) tell the
database that this user account is a password-authenticated account. In oracle password is
case sensitive.
Externally Authenticated User: When an externally identified user attempts to connect to
the database, the database verifies that the username is a valid database account and trusts
that the operating system has performed authentication. Externally authenticated user
accounts do not store or validate passwords in the database. These accounts are sometimes
referred to as OPS$ accounts. Including Oracle Database, you can configure this
OS_AUTHENT_PREFIX in the initialization file or spfile. For example, to create an
externally authenticated user named oracle using the default OS_AUTHENT_PREFIX, you
would execute the following:
SQL>CREATE USER ops$oracle IDENTIFIED EXTERNALLY;
The keywords IDENTIFIED EXTERNALLY tell the database that this user account is an
externally authenticated account. If you log in to the server as user oracle, you can log in to
the database without providing a username or password.

13
Globally Authenticated User: When a globally identified user attempts to connect to the
database, the database verifies that the username is valid and passes the connection
information to the advanced security option for authentication. The advanced security option
supports several mechanisms for authentication, including biometrics, X.509 certificates,
Kerberos, and RADIUS. Globally authenticated user accounts do not store or validate
passwords in the database. These accounts rely on authentication provided by a service
supported through the advanced security option. Here is an example:
SQL>CREATE USER spy_master IDENTIFIED GLOBALLY AS 'CN=spy_master,
OU=tier2, O=security, C=US';
3.5.5. Assigning Tablespaces and Quotas
When a user creates tables or indexes, they are created on the tablespace specified by the
TABLESPACE clause. If the TABLESPACE clause is not provided, the segments will be
created on the user’s default tablespace. If you execute a CREATE TABLE statement and
do not explicitly specify a tablespace, the database uses default SYSTEM tablespace.
SYSTEM default tablespace stores the data dictionary tables and PL/SQL code. If the
database was created using DBCA, the default tablespace would be USERS. SYSAUX
default tablespace stores segments used for database options such as the Automatic Workload
Repository, Online Analytical Processing (OLAP), and Spatial. TEMP temporary
tablesapace used for performing large sort operations. TEMP is required when the SYSTEM
tablespace is created as a locally managed tablespace; otherwise, it is optional.
SQL>CREATE USER Tomas IDENTIFIED BY tomas DEFAULT TABLESPACE users;
SQL>ALTER USER Tomas DEFAULT TABLESPACE users;
To change the database default tablespace (the value that users inherit if no default tablespace
is provided), use the ALTER DATABASE statement, like this: ALTER DATABASE
DEFAULT TABLESPACE users;
Assigning a Temporary Tablespace: Every user is assigned a temporary tablespace in
which the database stores temporary segments. Temporary segments are created during large
sorting operations, such as ORDER BY, GROUP BY, SELECT DISTINCT, MERGE JOIN,
or CREATE INDEX. The database creates and drops temporary segments transparently to
the user. Because of the transitory nature of temporary segments, you must use a dedicated
tablespace of type TEMPORARY for your user’s temporary tablespace setting.

14
SQL>CREATE USER Tomas IDENTIFIED BY tomas DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp; //or to an existing user via an ALTER USER
statement:
SQL>ALTER USER Tomas TEMPORARY TABLESPACE temp;
If the SYSTEM tablespace is locally managed at the time of database creation, you’re
required to provide a non-SYSTEM temporary-type tablespace as the database default
temporary tablespace. To change the database, default temporary tablespace, use the ALTER
DATABASE statement, like this:
SQL>ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp;
Assigning Space Quotas by Default: Tablespace quotas limit the amount of disk space a
user can consume. By default, Oracle Database does not allocate a space quota in any
tablespace when the user is created. To create segments (tables, indexes, and so on) in any
tablespace, the user must have a quota of space allotted on the tablespace.
SQL>CREATE USER TomasA IDENTIFIED BY "Tom21!3" QUOTA 100M ON USERS;
Or you can assign the quota after the user has been created. Just use the ALTER USER
statement:
SQL>ALTER USER Tom QUOTA UNLIMTED ON USERS;
The special keyword UNLIMITED tells the database that the user should not have a preset
limit on the amount of space their objects can consume. Here is an example to show this
scenario: user Tomas is created with database defaults (default permanent tablespace,
temporary tablespace, profile) and granted privileges in one statement. Tomas is able to
create the table, but is not able to insert a row, because at row insert, the segment is created
in the tablespace and has no quota.
SQL> GRANT CREATE SESSION, CREATE TABLE to Tomas IDENTIFIED BY
tomaspwd; Grant succeeded.
SQL> CONNECT Tomas/tomaspwd;
SQL> CREATE TABLE Staff (ID NUMBER);
SQL> INSERT INTO staff VALUES (4); //* ERROR at line 1: ORA-01950: no privileges
on tablespace 'USERS'.
3.5.6. Assigning a Profile and Account Settings
A profile serves two purposes:

15
1. It can limit the usage of some resources.
2. It can enforce password-management rules.
In addition to default and temporary tablespaces, every user is assigned a profile. The default
profile is appropriately named default. To explicitly assign a profile to a user, include the
keywords PROFILE profile_name in the CREATE USER or ALTER USER statement. If
you want users to change their passwords the first time they log in to the database, you can
set the PASSWORD EXPIRE option. Every user will be forced to change their password at
the first login. Here is an example of creating a user with an expired password:
SQL> CREATE USER Nathan IDENTIFIED BY Nathan PASSWORD EXPIRE;
SQL> GRANT CONNECT TO Nathan;
SQL> connect Nathan/Nathan; --ERROR: ORA-28001: the password has expired
Changing password for Nathan
New password:
Retype new password:
SQL> SHOW user
SQL> USER is "NATHAN"
By default, the user account is unlocked at creation. To lock the user account, use the
ACCOUNT LOCK option.
3.5.7. Removing a User from the Database
The DROP USER statement removes a user from the database. We can optionally include
the keyword CASCADE to tell the database to recursively drop all objects owned by that user.
SQL>DROP USER Nathan CASCADE;
If a user is currently connected to the database, the user cannot be dropped. Dropping a
user implicitly drops any object privileges (but not role or system privileges) for which the
user was the grantor.
3.5.8. Managing Default User Accounts
The SYS and SYSTEM user accounts are always created when an Oracle database is created.
Other special accounts can be created to support installed products, such as Recovery
Manager (RMAN) or XMLDB. When created via the DBCA, these special accounts are
locked and expired, leaving only SYS and SYSTEM open. The SYS and SYSTEM accounts
are the data dictionary owner and an administrative account, respectively. You expire and

16
lock an account using the ALTER USER statement like this: ALTER USER username
PASSWORD EXPIRE ACCOUNT LOCK;
3.5.9. Granting and Revoking Privileges
Privileges allow a user to access database objects or execute stored programs that are owned
by another user. Privileges also enable a user to perform system-level operations, such as
connecting to the database, creating a table, or altering the database. There are three types of
privileges supported by oracle:
• Object Privileges: permissions on schema objects such as tables, views, sequences,
procedures, and packages.
• System Privileges: permissions on database-level operations, such as connecting to the
database, creating users, altering the database, consuming unlimited amounts of
tablespace, and querying all tables in the database.
• Role Privileges: permissions granted to a user by way of a role. A role is a named group
of privileges. Object and system privileges can be granted to a role.
3.5.9.1. Granting Object Privileges
Table Object Privileges: Oracle Database provides several object privileges for tables.
These privileges give the table owner considerable flexibility in controlling how schema
objects are used and by whom. Commonly Granted Privileges are:
• SELECT: The table owner permits the grantee to query the specified table.
• INSERT: This permits the grantee to create new rows in the specified table.
• UPDATE: This permits the grantee to modify existing rows in the specified table.
• DELETE: This permits the grantee to remove rows from the specified table.
View Object Privileges: Oracle Database offers a smaller set of object privileges for views
than it does for tables:

• SELECT: the most commonly used privilege the view owner permits the grantee to query
the view.
• INSERT: permits the grantee to execute an INSERT statement on the specified view.
• UPDATE: This permits the grantee to modify existing rows in the specified view.
• DELETE: Permits the grantee to execute a DELETE statement on the specified view.
• DEBUG: This permits the grantee to access, via a debugger, the PL/SQL code in the
body of any trigger on this view.

17
• REFERENCES: permits the grantee to create foreign key constraints on the specified view.

Sequence Object Privileges: Sequence numbers are serial numbers incremented with a
specific interval. Sequences are often used for artificial keys or to order rows that otherwise
have no order. Sequences exist only in the data dictionary, and they do not take up any special
storage space as tables. Sequences are created with the CREATE SEQUENCE statement.
SQL> CREATE SEQUENCE hr.employee_identity START WITH 2001;
SELECT: This permits the grantee to access the current and next values (CURRVAL and
NEXTVAL) of the specified sequence.
ALTER: This lets the grantee change the attributes of the specified sequence.
Stored Functions, Procedures, Packages, and Java Object Privileges: Stored functions
are PL/SQL programs that can be used to create user-defined functions to return a value.
Stored procedures are PL/SQL programs to define a business process. A package is a
collection of procedures, functions, and other program constructs. A package is a grouping
of related PL/SQL objects.
DEBUG: This permits the grantee to access, via a debugger, all the public and private
variables and types declared in the specified program.
EXECUTE: This permits the grantee to execute the specified program.
How to Grant Object Privileges?
You use the GRANT statement to confer object privileges on either a user or a role. The
optional keywords WITH GRANT OPTION additionally allow the grantee to confer these
privileges on other users and roles. For example, to give SELECT, INSERT, UPDATE, and
DELETE privileges on the table STAFF to the role ADMIN.
SQL>GRANT SELECT, INSERT, UPDATE, DELETE ON Staff TO Admin;
If you grant privileges to the special user PUBLIC, you make them available to all current
and future database users.
SQL>GRANT SELECT ON customer TO public;
When you extend a privilege to another user or role, you can also extend the ability for that
grantee to turn around and grant the privilege to others. To extend this extra option, include
the keywords WITH GRANT OPTION in the GRANT statement. For example, to give the
SELECT privilege on table SALES.CUSTOMERS to the user SALES_ADMIN together

18
with the permission for SALES_ADMIN to grant the SELECT privilege to others, execute
the following:
SQL>GRANT SELECT ON sales.customers TO sales_admin WITH GRANT OPTION;
You can include the WITH GRANT OPTION keywords only when the grantee is a user or the
special account PUBLIC. You cannot use WITH GRANT OPTION when the grantee is a role.
3.5.9.2. Granting System Privileges
System privileges permit the grantee to execute Data Definition Language (DDL) statements
such as CREATE, ALTER, and DROP. The following groups of system privileges are
available. Oracle Database gives you the following system privileges:
Database: It is a collection of well-organized objects.
ALTER DATABASE: This permits the grantee to execute the alter database statement.
ALTER SYSTEM: This permits the grantee to execute the ALTER SYSTEM statement.
AUDIT SYSTEM: This permits the grantee to execute AUDIT and NOAUDIT statements
to perform statement auditing.
AUDIT ANY: This permits the grantee to execute AUDIT and NOAUDIT statements to
perform object auditing on objects in any schema.
CREATE PLUGGABLE DATABASE: This permits the grantee to create pluggable
databases in a multitenant database.
Indexes: An index is an optional structure that is useful for fetching data faster.
CREATE ANY INDEX: This permits the grantee to create an index in any schema.
ALTER ANY INDEX: This permits the grantee to alter indexes in any schema.
DROP ANY INDEX: This permits the grantee to drop indexes from any schema.
Procedures: A procedure is a PL/SQL programmatic construct. Stored procedures are
PL/SQL programs to define a business process.
CREATE PROCEDURE: This permits the grantee to create procedures in their own schema.
CREATE ANY PROCEDURE: This permits the grantee to create procedures in any schema.
ALTER ANY PROCEDURE: permits the grantee to recompile any procedure in the database.
DROP ANY PROCEDURE: permits the grantee to remove procedures from any schema.
EXECUTE ANY PROCEDURE: This permits the grantee to run any procedure in any schema.

19
Profiles: Profiles let you set limits for several resources, including CPU time, memory, and
the number of logical reads performed during a user session or database call. Profiles can
enforce the following:
• The “lifetime” of your password, which determines how frequently you must change it
• The grace period following your password’s “expiration date” during which you can
change the password
• The number of consecutives failed connect attempts allowed before the account is
automatically “locked”
• The number of days the account will remain locked
• The number of days that must pass before you can reuse a password
• The number of password changes that must take place before you can reuse a password.
CREATE PROFILE: This permits the grantee to create profiles.
ALTER PROFILE: This permits the grantee to modify existing profiles.
DROP PROFILE: This permits the grantee to drop profiles from the database.
Roles: A role is a tool for administering privileges. Privileges can be granted to a role, and
then that role can be granted to other roles and users. Role privileges confer on the grantee a
group of system, object, and other role privileges.
CREATE ROLE: This permits the grantee to create new roles.
ALTER ANY ROLE: permits the grantee to change the password for any role in the database.
DROP ANY ROLE: This permits the grantee to remove any role from the database.
GRANT ANY ROLE: This permits the grantee to grant any role to any user or revoke any
role from any user or role.
Sessions: Session is the point from which you are connected to the database until you
disconnect.
CREATE SESSION: This permits the grantee to connect to the database.
ALTER SESSION: This permits the grantee to execute
ALTER SESSION: statements to enable and disable SQL_TRACE.
ALTER RESOURCE COST: This permits the grantee to change the way Oracle calculates
resource cost for resource restrictions in a profile.
RESTRICTED SESSION: This permits the grantee to connect when the database has been
opened in RESTRICTED SESSION mode, typically for administrative purposes.

20
Tables: A table is the basic form of data storage.
CREATE TABLE: This permits the grantee to create new tables in their own schema.
CREATE ANY TABLE: This permits the grantee to create new tables in any schema.
ALTER ANY TABLE: This permits the grantee to alter existing tables in any schema.
DROP ANY TABLE: This permits the grantee to drop tables from any schema.
SELECT ANY TABLE: This permits the grantee to query any table or view in any schema.
INSERT ANY TABLE: permits the grantee to insert new rows into any table in any schema.
UPDATE ANY TABLE: permits the grantee to modify rows in any table in any schema.
DELETE ANY TABLE: This permits the grantee to delete rows from tables in any schema.

Tablespaces: The database is logically divided into smaller units at the highest level, called
tablespaces. A tablespace has a direct relationship to the physical structure a data file can
belong to one and only one tablespace. A segment is a set of extents allocated for logical
structures such as tables, indexes, clusters, table partitions, materialized views, and so on.
Extents is the next level of logical grouping. A tablespace could have more than one data
file associated with it. A block is the smallest unit of storage in Oracle. A schema is a logical
structure that groups the database objects.

CREATE TABLESPACE: This permits the grantee to create new tablespaces.

ALTER TABLESPACE: This permits the grantee to alter existing tablespaces.

21
DROP TABLESPACE: This permits the grantee to delete tablespaces from the database.
MANAGE TABLESPACE: This permits the grantee to alter a tablespace with the ONLINE,
OFFLINE, BEGIN BACKUP, or END BACKUP command.
UNLIMITED TABLESPACE: This permits the grantee to consume unlimited disk space in
any tablespace.
Triggers: A trigger is a stored PL/SQL program that is executed when a specified condition
occurs. A trigger can be defined on a table to “fire” when an insert, update, or delete operation
occurs on the table.
CREATE TRIGGER: permits the grantee to create new triggers on tables in their own schema.
CREATE ANY TRIGGER: permits the grantee to create new triggers on tables in any schema.
ALTER ANY TRIGGER: This permits the grantee to enable, disable, or compile existing
triggers on tables in any schema.
DROP ANY TRIGGER: permits the grantee to remove triggers from tables in any schema.
ADMINISTER DATABASE TRIGGER: This permits the grantee to create new ON
DATABASE triggers. The grantee must also have the CREATE TRIGGER or CREATE
ANY TRIGGER privilege before they can create an on-database trigger.
Users: A user is the account you use to connect to a database.
CREATE USER: This permits the grantee to create new database users.
ALTER USER: This permits the grantee to change the authentication or password and assign
quotas, temporary tablespaces, default tablespaces, or profiles for any user in the database.
DROP USER: This permits the grantee to remove users together with any objects they own
from a database.
Views: A view is a stored query. No data-storage space is occupied for view data. Note that
some of these privileges include the word TABLE and not VIEW. These privileges apply to
either tables or views.
CREATE VIEW: This permits the grantee to create new views in their own schema.
CREATE ANY VIEW: This permits the grantee to create new views in any schema.
DROP ANY VIEW: This permits the grantee to remove views from any schema.
Administrative Privileges

22
The administrative privileges are “special” system privileges in those administrators who are
granted these privileges can access a database instance even if the database is not open and
perform administrative operations without having any other privileges.
SYSDBA: this permits the grantee to create, alter, drop, start up, or shut down databases;
enable ARCHIVELOG and NOARCHIVELOG mode; recover a database; and create an
spfile; in addition to having all the system privileges the database has to offer, including
RESTRICTED SESSION. When this privilege is used, the user connected to the database is
SYS.
SYSOPER: Only slightly less powerful than SYSDBA, this privilege permits the grantee to
start up, shut down, alter, mount, back up, and recover a database. The grantee can create or
alter an spfile and enter restricted session mode. When this privilege is used, the user
connected to the database is PUBLIC.

SYSBACKUP: Use this privilege to perform RMAN backup and recovery operations from
RMAN or through SQL. This privilege also gives the grantee the ability to start and stop the
database instance, create an spfile, create or drop a database, and create control files. When
this privilege is used, the user connected to the database is SYSBACKUP.

SYSDG: The SYSDG administrative privilege allows the grantee to perform Data Guard
operations with Data Guard Broker or the DGMGRL command-line interface. When this
privilege is used, the user connected to the database is SYSDG

SYSKM: The SYSKM administrative privilege allows the grantee to manage transparent
data encryption wallet operations. When this privilege is used, the user connected to the
database is SYSKM.

How to Grant System Privileges? As with object privileges, you use the GRANT statement
to confer system privileges on either a user or a role. Unlike object privileges, the optional
keywords WITH ADMIN OPTION are required to additionally allow the grantee to confer
these privileges on other users and roles. For example, to give the CREATE USER, ALTER
USER, and DROP USER privileges to the role APPL_DBA, you execute the following
statement:

SQL> GRANT create user, alter user, drop user TO appl_dba;

23
To give the INDEX ANY TABLE privilege to the role APPL_DBA, together with the
permission to allow anyone with the role APPL_DBA to grant this privilege to others,
execute the following: GRANT index any table TO appl_dba WITH ADMIN OPTION;
3.5.9.3. Role Privileges
Creating and Managing Roles: A role is a tool for administering privileges. Privileges can be
granted to a role, and then that role can be granted to other roles and users. Users can,
therefore, inherit privileges via roles. Roles serve o administer privileges.
SQL>CREATE ROLE appl_dba;
To enable a role, execute a SET ROLE statement, like this:
SQL>SET ROLE appl_dba IDENTIFIED BY seekwrit;
How to Grant Role Privileges? Use the GRANT statement to confer role privileges on
either a user or another role. Also, like system privileges, the optional keywords WITH
ADMIN OPTION allow the grantee to confer these privileges on other users and roles.
GRANT oem_monitor TO Tomas;
As with the other privileges, you can grant role privileges to the special user PUBLIC. This
allows anyone with a database account to exercise the granted privilege.
SQL>GRANT plustrace TO public;
Enabling Roles: Roles can be enabled or disabled, for that matter selectively in each
database session. If you have two concurrent sessions, the roles in effect for each session can
be different.
Default Database Roles
CONNECT: This role has only one privilege, CREATE SESSION.
RESOURCE: This role has the privileges required to create common objects in the user’s
schema.
DBA: This is the most powerful role in the database. Only database administrators should
be given this role. This role has all the system privileges and several administrative
privileges.
3.5.10. Auditing Database Activity
Auditing involves monitoring and recording specific database activity. Oracle Database
Traditional Auditing supports four levels of auditing: Statement, Privilege Object and
Fine-grained access. You tell the Oracle Database where to record audit-trail records by

24
setting the initialization parameter audit_trail. AUDIT_TRAIL=DB, EXTENDED tells the
database to record audit records in the database together with bind variables(SQLBIND) and
the SQL statement triggering the audit entry(SQLTEXT). AUDIT_TRAIL=OS tells the
database to record audit records in operating-system files.
You cannot change this parameter in memory, only in your pfile or spfile.
Managing Statement Auditing: Statement auditing involves monitoring and recording the
execution of specific types of SQL statements.
Enabling Statement Auditing: SQL>ADUIT Table;
You enable auditing of specific SQL statements with an AUDIT statement. To record audit
entries for specific users only, include a BY USER clause in the AUDIT statement. SQL>
AUDIT table by TOMAS;
Managing Privilege Auditing: Privilege auditing involves monitoring and recording the
execution of SQL statements that require a specific system privilege, such as SELECT ANY
TABLE or GRANT ANY PRIVILEGE. Enabling Privilege Auditing:
You enable privilege auditing with an AUDIT statement, specifying the system privilege that
you want to monitor. SQL>AUDIT CREATE ANY TABLE;
To record audit entries for specific users only:
SQL>AUDIT CREATE ANY TABLE by Tomas;
Managing Object Auditing: Object auditing involves monitoring and recording the
execution of SQL statements that require a specific object privilege, such as SELECT,
INSERT, UPDATE, DELETE, or EXECUTE.Unlike either statement or system privilege
auditing, schema object auditing cannot be restricted to specific users - it is enabled for all
users or no users. SQL> AUDIT SELECT ON hr.Employees;
Purging the Audit Trail: Database audit records for statement, privilege, and object
auditing are stored in the SYS.AUD$ table. Depending on how extensive your auditing and
retention policies are, you will need to periodically delete old audit records from this table.
To purge audit records older than 90 days, execute the following as user SYS:
SQL>Delete from SYS.ADU$ where timstamp# < SYSDATE -90;
Only the user SYS, a user with the DELETE ANY TABLE privilege, or a user to whom SYS
granted the DELETE privilege on SYS.AUD$ can delete the audit-trail records from the
SYS.AUD$ table. Oracle Database audits all DML statements against the SYS.AUD$ table.

25
The INSERT, UPDATE, MERGE, and DELETE statements against the SYS.AUD$ table
are not deleted from the SYS.AUD$ table. You have to truncate the SYS.AUD$ table to
remove such records.
Managing Fine-Grained Auditing: Fine-grained auditing (FGA) lets you monitor and
record data access based on the content of the data. With FGA, you define an audit policy on
a table and optionally a column. When the specified condition evaluates to TRUE, an audit
record is created, and an optional event-handler program is called. To create a new FGA
policy, use the packaged procedure DBMS_FGA.ADD_POLICY.
Review Questions
1. What is the purpose of database security?
2. If you’re logged in to Oracle, how can you determine which privileges are currently
available to your account?
3. What types of privileges are available in Oracle? Define each type.
4. What is the purpose of a role in Oracle, MySQL and SQL Server?
5. How can you assign a password to a role?
6. What happens if you revoke an object privilege that was granted with the WITH GRANT
OPTION?

26