User Management:

The fastest database in existence would have one control file, two redo log groups with
one member each, and no users.

If that sentence didn't catch your eye the first time, read it again.

A database must have users. Without them, there is no profit. But having users
connecting to your database presents a whole range of potential problems. You, the DBA,
must give privileges to access other objects on the database. An open database is a hack
able database.

There are three levels of users in the average Oracle system:

• Administrators
• Developers
• End users/ Vendors/ Customers/ Viewers

The article you are reading now is stored in a database, and is being delivered by a web
application to your computer screen. At this moment, you are an end user. When you go
to the bank and use an ATM, you are a user of a database. The act of putting your ATM
card into a system and entering your PIN is your login to the application. From there, you
are a customer and viewer, able to select (view balance), insert (make a transaction), and
update (deposit/withdraw).

The main thing that you, the DBA must apply to your users is the principle of least
privilege. Here are some ideas for making this principle work:

• Do not give your users more abilities than they need to get the job done
• Revoke unnecessary privileges from the PUBLIC pseudo-user
• Expire and lock unnecessary users
• Do not give your users more abilities than they need

User enters data into the database thru Application/Browser.

When Users enters, username and password (user credentials),then application

authenticate the user.
If the username and password are matched, user gets connect to the server

 There are different teams: to enter data

To create objects in database
To retrieve the data.
To validate the data.
Testing the database.
To create objects, approval is needed.

Schema : is an Owner.
Schema contains a set of objects.

Users: There are 4 main accounts that are created during install sys, system, sysman

and dbmsmp. You have to adjust the parameter license_max_users to allow how many

licensed users can access the database.

SYS: Owns all internal tables

SYSTEM: Has additional tables and views

SYSMAN: Use by OEM to monitor and gather performance stats, which are stored in the sysaux

tablespace

DBSNMP: Same as sys but for the OEM owns all internal tables in the sysaux tablespace.

To create user:

CREATE USER <USERNAME>

IDENTIFILED BY<PASSWORD>
DEFAULT TABLESPACE<TABLESPACENAME>
TEMPORARY TABLEPSPACE<TEMP TABLESPACENAME>
QUOTA <SIZE> ON <DEFAULT TABLESPACENAME>
QUOTA <SIZE> ON <TEMP TABLEPSPACENAME> ;

GRANT CONNECT , RESOURCE TO <USERNAME>;

-- Allow user to connect to the database
grant create session to bob;

To know, which user is connected,

SQL> show user;

SQL> sho user;

-- List all users

select username, user_id, account_status, default_tablespace,
temporary_tablespace, profile
from dba_users;

-- List active users only

select username, user_id, account_status, default_tablespace,
temporary_tablespace, profile
from dba_users
where account_status='OPEN';

Privileges:

Privilege is a right to execute a particular type of SQL statement or a right to access other
user’s object.

2 types of privileges:

1.System Privileges:

• Over 100 types of distinct system privileges.

• Allows user to perform a particular database operation, class of database
operation.
• Set the parameter 07_DICITIONARY_ACCESSIBILITY=FALSE to secure the
data dictionary tables from non-DBA users.

2. Object Privilege:

• Each type of object has different type privilege associated with it.
• We can specify ALL(Privileges) to Grant/ Revoke all available object privileges
for an object.
 ALL is not a keyword, it’s a shortcut or a way of granting or revoking all objects
privileges with one word.

• All object privileges are granted using the ALL shortcut, individual privilege can
still be revoked.
• Likewise, all individually granted privileges can be revoked by specifying ALL.
• When REVOKE ALL used, revoking causes integrity constraints to be
deleted(because they depend on references privilege that you are revoking)So,
Cascade Constraints must be included in the REVOKE statement.

Roles:

• Role groups several privileges and roles.

• Role must be Enabled before it can be used by the users.
• Pre defined roles, DBA,CONNECT,RESOURCES
• CREATE ROLE system privilege is required to create role.
 Roles are not belong to any schema of any user.

Create role with the create role command and then grant the role to the user with
the grant command :

SQL> Create role select_data_role;

SQL> Grant select on emp, dept, bonus to select_data_role

Then grant that Oracle role to other users as in this case where we grant the
select_data_role to the ROBERT user role. Once this is done, ROBERT will be able to
query the EMP, DEPT and BONUS tables in the SCOTT schema:

SQL> GRANT select_data_role TO Robert;

Oracle roles have some limitations. In particular object privileges are granted through
Oracle roles can not be used when writing PL/SQL code. When writing PL/SQL code,
you must have direct grants to the objects in the database that your code is accessing.

If you wish to revoke an Oracle role from a user, simply use the revoke command as
demonstrated earlier in this chapter:

SQL> REVOKE select_data_role FROM Robert;

revoke delete on address_table from bob;

revoke all on address_table from bob;

-- Grant/revoke execute rights on functions/procedures for a user.

grant execute on sp_validate_address to bob;

revoke execute on sp_validate_address from bob;

In all releases prior to 10.2, the Oracle connect roles included the following system
privileges:

ALTER SESSION
CREATE CLUSTER
CREATE DATABASE LINK
CREATE SEQUENCE
CREATE SESSION
CREATE SYNONYM
CREATE TABLE
CREATE VIEW

Starting in release 10.2 the connect roles has many privileges removed and only the
CREATE SESSION privilege remains.

 Profiles:

• Profiles are a named set of resource limits.

 • By default, when you create a user, they are given the default profile. The default
profile provides unlimited use of all resources.
• You must have the CREATE PROFILE system privilege to create a profile.
• To alter a profile you must be the creator of the profile or have the ALTER
PROFILE system privilege.
• To assign a profile to a user, you must have the CREATE USER or ALTER
USER system privileg

The syntax to create a profile:

CREATE PROFILE profile LIMIT resource_parameters|password_parameters--;->

Resource_parameters (you can specify multiple paramters per command):
[SESSIONS_PER_USER n|UNLIMITED|DEFAULT]
[CPU_PER_SESSION n|UNLIMITED|DEFAULT]
[CPU_PER_CALL n|UNLIMITED|DEFAULT]
[CONNECT_TIME n|UNLIMITED|DEFAULT]
[IDLE_TIME n|UNLIMITED|DEFAULT]
[LOGICAL_READS_PER_SESSION n|UNLIMITED|DEFAULT]
[LOGICAL_READS_PER_CALL n|UNLIMITED|DEFAULT]
[COMPOSITE_LIMIT n|UNLIMITED|DEFAULT]
[PRIVATE_SGA n [K|M]|UNLIMITED|DEFAULT]
Password_parameters (Oracle8 and above):
[FAILED_LOGIN_ATTEMPTS expr|UNLIMITED|DEFAULT]
[PASSWORD_LIFE_TIME expr|UNLIMITED|DEFAULT]
[PASSWORD_REUSE_TIME expr|UNLIMITED|DEFAULT]
[PASSWORD_REUSE_MAX expr|UNLIMITED|DEFAULT]
[PASSWORD_LOCK_TIME expr|UNLIMITED|DEFAULT]
[PASSWORD_GRACE_TIME expr|UNLIMITED|DEFAULT]
[PASSWORD_VERIFY_FUNCTION function_name|NULL|DEFAULT]

Limitable resources
The following limits can be specified:

Kernel limits

• Maximum concurrent sessions for a usersessions_per_user

• CPU time limit per sessioncpu_per_session
• CPU time limit per callcpu_per_call
Call being parse, execute and fetch
• Maximum connect timeconnect_time
The session will be dropped by oracle after specified time.
• Maximum idle timeidle_time
The session will be dropped by oracle after specified time of doing nothing. Long
running processes are not idle!
• Maximum blocks read per sessionlogical_reads_per_session
• Maximum blocks read per calllogical_reads_per_call
 • Maximum amount of SGAprivate_sga
• ....
composite_limit

In order to enforce kernel limits, RESOURCE_LIMIT must be set to TRUE.

Password limits

• Maximum failed login attemptsfailed_login_attempts

• Maximum time a password is validpassword_life_time
• Minimum of different passwords before password can be
reusedpassword_reuse_max
• Minimum of days before a password can be
reusedpassword_reuse_time
• Number of days an account is locked after failing to
loginpassword_lock_time
• The number of days after the grace period begins during which a warning is
issued and login is allowed. If the password is not changed during the grace
period, the password expirespassword_grace_time
• Verify function for passwordspassword_verify_function

If a session exceeds one of these limits, Oracle will terminate the session. If there is a
logoff trigger, it won't be executed.

History of passwords
In order to track password related profile limits, Oracle stores the history of passwords
for a user in user_history$. .

Profiles and Resource Limits

The default cost assigned to a resource is unlimited. By setting resource limits, you can
prevent users from performing operations that will tie up the system and prevent other
users from performing operations.

You can use resource limits for security to ensure that users log off the system and do not
leave the session connected for long periods of time.

You can also assign a composite cost to each profile . The system resource limits can be
enforced at the session level, the call level or both.

The session level is from the time the user logs into the database until the user exits.

The call level is for each SQL command issued.

Session level limits are enforced for each connection. When a session level limit is
exceeded, only the last SQL command issued is rolled back and no further work can be
performed until a commit, rollback or exit is performed.

You can combine the CPU_PER_SESSION, LOGICAL_READS_PER_SESSION,

CONNECT_TIME, and PRIVATE_SGA to create a COMPOSITE LIMIT.

• Call-level limits are enforced during the execution of each SQL statement.
• When a call-level limit is exceeded, the last SQL command issued is rolled back.
All the previous statements issued are still valid and the user can continue to
execute other SQL statements. The following system resources can be regulated
at the call level:

CPU_PER_CALL for the CPU time for the SQL statement

LOGICAL_READS_PER_CALL for the number of data blocks read for the SQL
statement

Data dictionary views for resources.

DBA_PROFILES

Column Definition
Profile the name given to the profile
Resource_name the name of the resource assigned to the profile
Limit the limit placed on the profile

RESOURCE_COST

Column Definition
Resource_name name of the resource
Unit_cost cost assigned

USER_RESOURCE_LIMITS

Column Definition
Resource_name the name of the resource
Limit the limit placed on the user