DATABASE Create and Manage Database

User

ADMINISTRATION Accounts Chapter 8 (OCA

Oracle Exam book)
ADMINISTERING USER
SECURITY
To establish a session against an instance and a database, a user must connect to a
user account.
The account must be specified by name and authenticated by some means. The way
the account was created will set up a range of attributes for the session, some of
which can be changed later while the session is in progress. T
here are a number of accounts created at database creation time, and the DBA will
usually create many more subsequently.
USER ACCOUNT ATTRIBUTES
user account has a number of attributes defined at account creation time. These
will be applied to sessions that connect to the account, though some can be modified
by the session or the DBA while the session is running. These attributes are
Username
Authentication method hr
 Default tablespace
Tablespace quotas
Temporary tablespace
User profile
Account status (lock)
All of these should be specified when creating the user, though only username
and authentication methods are mandatory; the others have defaults
USERNAME
The username must be unique in the database and must conform to certain rules.
A username must begin with a letter, must be no more than 30 characters, and can
consist of only letters, digits, and the characters dollar ($) and underscore (_). A
user name may not be a reserved word. The letters are case sensitive but will be
automatically converted to uppercase. All these rules (with the exception of the
length) can be broken if the username is specified within double quotes,
 CREATE USER COMMAND

Before creating user run this command

Alter session set “_ORACLE_SCRIPT”=TRUE
SQl * plus
Create user john identified by Password

A username can never be changed after creation. If it is necessary to change it,

the account must be dropped and another account created. This is a drastic action,
because all the objects in the user’s schema will be dropped along with the user.
DEFAULT TABLESPACE AND
QUOTAS
Every user account has a default tablespace. This is the tablespace where any
schema
objects (such as tables or indexes) created by the user will reside.
DEFAULT TABLESPACE AND
QUOTAS
There is a database-wide default tablespace that will be applied to all user
accounts if a default tablespace is not specified when creating the user. The default
can be set when creating the database and changed later with
ALTER DATABASE DEFAULT TABLESPACE tablespace_name ;
DEFAULT TABLESPACE AND
QUOTAS
TEMPORARY TABLE SPACE
Permanent objects (such as tables) are stored in permanent tablespaces; temporary
objects are stored in temporary tablespaces. A session will need space in a temporary
tablespace if it needs space for certain operations that exceed the space available in
the session’s PGA.
SQl * PLus
ALTER USER username TEMPORARY TABLESPACE tablespace_name;
ACCOUNT STATUS
Account Status
Every user account has a certain status, as listed in the ACCOUNT_STATUS
column of DBA_USERS. There are nine possibilities:
■ OPEN The account is available for use.
■ LOCKED This indicates that the DBA deliberately locked the account.
No user can connect to a locked account.
■ EXPIRED This indicates that the password lifetime has expired. Passwords can have
a limited lifetime. No user can connect to an EXPIRED account until the
password is reset.
ACCOUNT STATUS
■ EXPIRED & LOCKED Not only has the account been locked, but its
password has also expired.
■ EXPIRED (GRACE) This indicates that the grace period is in effect.
A password need not expire immediately when its lifetime ends; it may be
configured with a grace period during which users connecting to the account
have the opportunity to change the password.
ACCOUNT STATUS
LOCKED (TIMED) This indicates that the account is locked because of
failed login attempts. An account can be configured to lock automatically for
a period after an incorrect password is presented a certain number of times.
■ EXPIRED & LOCKED (TIMED)
ACCOUNT STATUS
Command SQL * PLus
ALTER USER username ACCOUNT LOCK ;
ALTER USER username ACCOUNT UNLOCK ;
To force a user to change his password, use this command:
ALTER USER username PASSWORD EXPIRE;
CREATING ACCOUNTS
The CREATE USER command has only two required arguments: a user name and
a method of authentication. Optionally, it can accept a clause to specify a default
tablespace and a temporary tablespace, one or more quota clauses, a named profile,
and commands to lock the account and expire the password. A typical example
(with line numbers added) would be
SQl * plus command

create user sara identified by 123

default tablespace users temporary tablespace temp
quota unlimited on users quota unlimited on temp
Hr_groip
password expire
account unlock;
CREATING ACCOUNTS
Every attribute of an account can be adjusted later with ALTER USER
commands, with the exception of the name. To change the password,
alter user sara2 identified by 1234;
To change the default and temporary tablespaces,
alter user sara2 default tablespace hr_data temporary tablespace hr_temp;
To change quotas,
alter user sara2 quota unlimited on hr_data, quota 100m on hr_temp;
To change the profile,
 alter user scott profile prod_profile;

To force a password change,

• alter user scott password expire;
To lock the account,
alter user scott account lock;
Having created a user account, it may be necessary to drop it:
drop user scott;
This command will only succeed if the user does not own any objects: if the
schema is empty. If you do not want to identify all the objects owned and drop them
first, they can be dropped with the user by specifying CASCADE:
drop user scott cascade;
Assigning Privilege to User.

Two types
1. System privilege
2. Object Privilege
SYSTEM PRIVILEGES

There are about two hundred system privileges. Most apply to actions that affect
the data dictionary, such as creating tables or users. Others affect the database or
the instance, such as creating tablespaces, adjusting instance parameter values, or
establishing a session. Some of the more commonly used privileges are
■ CREATE SESSION This lets the user connect. Without this, he/she
cannot even log on to the database.
■ RESTRICTED SESSION If the database is started with STARTUP
RESTRICT, or adjusted with ALTER SYSTEM ENABLE RESTRICTED
SESSION, only users with this privilege will be able to connect.
SYSTEM PRIVILEGES

■ ALTER DATABASE Gives access to many commands necessary for

modifying physical structures.
■ ALTER SYSTEM Gives control over instance parameters and memory
structures.
■ CREATE TABLESPACE With the ALTER TABLESPACE and DROP
TABLESPACE privileges, these will let a user manage tablespaces.
■ CREATE TABLE Lets the grantee create tables in his/her own schema;
includes the ability to alter and drop them, to run SELECT and DML
commands on them, and to create, alter, or drop indexes on them.
SYSTEM PRIVILEGES
GRANT ANY OBJECT PRIVILEGE Lets the grantee grant object
permissions on objects he/she does not own to others—but not to himself/
herself.
■ CREATE ANY TABLE The grantee can create tables that belong to
other users.
■ DROP ANY TABLE The grantee can drop tables belonging to any other
users.
■ INSERT ANY TABLE, UPDATE ANY TABLE, DELETE ANY
TABLE The grantee can execute these DML commands against tables
owned by all other users.
■ SELECT ANY TABLE The grantee can SELECT from any table in the
database.
SYSTEM PRIVILEGES
The syntax for granting system privileges is
1. GRANT create session , create table TO sara2 ;
After creating a user account, a command such as this will grant the system
privileges commonly assigned to users who will be involved in developing
applications:
grant create session, alter session,
create table, create view, create synonym, create cluster,
create database link, create sequence,
create trigger, create type, create procedure, create operator
to username ;
SYSTEM PRIVILEGES(ADMIN
OPTION)
It let SCOTT query every table in
every schema in the database. It is
often
considered bad practice to grant
the ANY privileges to any user
other than the
system administration staff.
OBJECT PRIVILEGES
Object privileges give the ability to perform SELECT, INSERT, UPDATE,
and
DELETE commands against tables and related objects, and to execute
PL/SQL
objects. These privileges do not exist for objects in the users’ own schemas; if
a user has the system privilege CREATETABLE, he/she can perform
SELECT and DML operations against the tables he/she creates with no
further need for permissions.
OBJECT PRIVILEGES
The object privileges apply to different types of object:
Privilege Granted
OBJECT PRIVILEGES
The syntax is
GRANT privilege ON schema.object TO username [WITH GRANT OPTION] ;
For example,
grant select on hr.regions to scott;
grant select on hr.employees to scott;
grant update (salary) on hr.employees to scott;
grant all on hr.regions to scott;
OBJECT PRIVILEGE WITH
GRANT OPTION
WITH GRANT OPTION
Just like we use ADMIN OPTION flag with system privileges similarly we use Grant option flag with object
privileges. GRANT OPTIONflag allows the user to grant an object privilege to another user. Let’s see how. 
Let’s grant update privilege on employees table of user HR to user Hulk.
1.Conn sys as sysdba
2.GRANT  update  ON  hr.employees  TO  hulk  WITH GRANT OPTION;
Grant select on hr.emplouee to hulk with grant option;
After executing this query user Hulk not only gets update object privilege but can also grant and revoke the same
privilege to and from any user or roles.
Conn hulk
2.. Grant select on hr.employees to jon, scott ;
3:
CREATING AND GRANTING
ROLES
Roles are not schema objects: they aren’t owned by anyone and so cannot be
prefixed with a username. However, they do share the same namespace as users: it is
not possible to create a role with the same name as an already-existing user, or a user
with the same name as an already-existing role.
Create a role with the CREATE ROLE command:
CREATE ROLE rolename ;
Then grant privileges to the role with the usual syntax, including WITH ADMIN or
WITH GRANT OPTION of desired
CREATING AND GRANTING
ROLES
For example, assume that the HR schema is being used as a repository for data to
be used by three groups of staff: managerial staff have full access, senior clerical staff
have limited access, junior clerical staff have very restricted access.
First create a role that might be suitable for the junior clerk; all they can do is answer questions
by
running queries:
create role hr_junior;
grant create session to hr_junior;
grant select on hr.regions to hr_junior;
grant select on hr.locations to hr_junior;
CREATING AND GRANTING
ROLES
grant select on hr.countries to hr_junior;
grant select on hr.departments to hr_junior;
grant select on hr.job_history to hr_junior;
grant select on hr.jobs to hr_junior;
grant select on hr.employees to hr_junior
CREATING AND GRANTING
ROLES
Then create a role for the senior clerks, who canalso write data to the EMPLOYEES
and JOB_HISTORY tables:
create role hr_senior;
grant hr_junior to hr_senior with admin option;
grant insert, update, delete on hr.employees to hr_senior;
grant insert, update, delete on hr.job_history to hr_senior;
CREATING AND GRANTING
ROLES
Then create the
manager’s role, which can update all the other tables:
create role hr_manager;
grant hr_senior to hr_manager with admin option;
grant all on hr.regions to hr_manager;
grant all on hr.locations to hr_manager;
grant all on hr.countries to hr_manager;
grant all on hr.departments to hr_manager;
grant all on hr.job_history to hr_manager;
grant all on hr.jobs to hr_manager;
grant all on hr.employees to hr_manager;
ASSIGNING ROLE TO USER