Schema Management

In oracle a schema is a collection of logical structures of data, or schema objects, it is

mostly associated with a user that owns the schema pertaining to a specific
application. A schema can contain tables, PL/SQL procedures, functions, packages,
views, sequences, synonyms and clusters. This logical separation of objects allows
considerable flexibility in managing and securing your oracle database. The user who
owns the objects within the schema has to assign access rights to other users in order
for other users to run commands against those objects such as select, insert, etc.
Basically when an owner of a schema creates a object only that user has access to that
object.
Tablespaces
Before a schema can be created a tablespace must exists, the tablespace is a logical
entity that contains schemas. Normally a dedicated tablespace is created specifically
for application schema making sure that it is separate from the system tablespace.
Tablespaces themselves will contain one of more data files depending on the size.
See tablespaces for more information about how to create, drop, etc.
Users
A schema is normally associated with a user which is then normally associated with
an application. Oracle uses the least privilege rule, thus when a user gets created he
has no privileges at all, the user will not even be allowed to connect to the database.
See users for information about how to create, drop and to give privileges to users.
Data Access
Oracle uses several means to control data access and the best way is to assign
privileges and roles to users.
See data access for information about how to grant and revoke access and creating
roles.

User Management

Everything in oracle requires privileges which can be granted, oracle is based on

giving the least amount of privilege. The main aspects of Oracle security management
are
Controlling access to data (authorization)
Restricting access to legitimate users (authentication)
Ensuring accountability on part of the users (auditing)
Safeguarding key data in the database (encryption)
Managing the security of the entire organizational information structure
(enterprise security)
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.

There are two privileges which many junior DBA get confused (including myself)
with sysoper and sysdba, these are system privileges not users or roles, see here for
more details on these two privileges.
All users need a default tablespace, this is where all objects created by the user will be
stored and a temporary tablespace which is where they perform work such as sorting
data during SQL execution. Make sure that you assign the tablespaces as on some
systems they could end up using the system tablespace which is not a good idea.

Creating

create user vallep identified by password;

create user vallep identified by password default tablespace users temporary tablesp

Remove
drop user vallep;
drop user vallep cascade;

Note: the cascade option will remove all the users objects as well.

Alter

alter user vallep idenitfied by newpassword;

alter user vallep quota 200m on users;
alter user vallep identified by password;
alter user vallep identified externally;
alter user vallep identified globally as extname;

Password options

Note:
identified by - the password will be kept in the data dicitonary
identified externally - authenication will be performed by the O/S
idenitified globally as extname - authenication will be performed by external app i.
a user is only allowed to change is his/her password

Expire password

alter user vallep password expire;

Lock/unlock

alter user vallep account lock;

alter user vallep account unlock;
grant create session to vallep;

Connecting
Note: this allows the user to connect to the database

Revoke access

revoke create session from vallep;

Quota

alter user vallep quota 100m on users;

alter user vallep quota unlimited on users;
grant unlimited tablespace to vallep;

Kill a users session

select username, sid, serial# from v$session;

alter system kill session '<session_id>,<session-serial>';

User connection type

(decicated/shared)

select username, program, server from v$session;

Useful Views
DBA_USERS

describes all users of the database

DBA_TS_QUOTAS

describes tablespace quotas for all users

V$SESSION

lists session information for each current session

By default oracle passwords are sent in clear text across the network, set the following
environment variables to encrypt the password between the client and server.
Server

dblink_encrypt_login = true

Client

ora_encrypt_login = true

Profiles
Profiles are used to limit a users resource, it can also enforce password management
rules, only the DBA can change profiles. There is a global default profile which every

users is assigned to if they are already not assigned to one. If a user reaches one of the
limits in the profile the transaction is rolled back and a error message is displayed
stating that a resource limit has been reached. There are a number of resources that
can be limited
connect_time - limits session to number of minutes
cpu_per_call - limits cpu time by any single database call
cpu_per_session - limit cpu by session
idle_time - limit session to idle time, allows user to rollback or commit before
logging off
logical_reads_per_call - caps the amount of work by any single database call
logical_reads_per_session - caps the amount of work by any session
private_sga - limits memory when using shared servers
sessions_per_user - limits the number of sessions a user can have
composite_limit - calculated by cpu_per_session, logical_reads_per_session,
connection_time and private_sga
The security features that the profile can also manage are
failed_login_attemps - number of times a user can enter the wrong password
before the account is locked
password_lock_time - if the above is breached lock password for this number
of days
password_life_time - number of days a password can remain in force
password_grace_time - number of days user is notified but is used in above
value
password_reuse_time - maximum # of days before a password can be reused

 password_reuse_max - minimum # of different passwords before password can

be reused
password_verify_function - allows the use of a function to be used to verify a
password
Creating

create profile user_profile limit sessions_per_user 5;

drop profile user_profile cascade;

Remove

Setting a limit

Note: any users using the dropped profile will be automatically assigned the de
profile
alter profile user_profile limit idle_time 30;

Displaying current resource limits select * from user_resource_limits;

Displaying current password limits select * from user_password_limits;
Displaying profile

select * from dba_profiles where profile = 'USER_PROFILE';

Assign a profile

alter user vallep profile user_profile;

Useful Views
USER_RESOURCE_LIMITS

displays the resource limits for the current user.

USER_PASSWORD_LIMITS

describes the password profile parameters that are assigned to the user.

DBA_PROFILES

displays all profiles and their limits

Before profiles are used you must set the following systems parameter, you have
to restart the database in order for the changes to take affect.
Enable resource limits

alter system set resource_limit = true scope = both;

Disable resource limits

alter system set resource_limit = false scope = both;

Roles
See data access for more information on roles.

Data Access
Oracle uses several means to control data access and the best way is to assign
privileges and roles to users. You can assign individual privileges to users but this can
become overwhelming when you have many users, this is were roles comes in to play
as privileges can be assigned to the role then the role assigned to the user.
There are two basic privileges system and object, using the
commands grant and revoke privileges can be given and taken away from a user.

System Privileges
Here are some common system privileges, be careful to whom you grant system
privileges too as these can have devastating impact on your database.
advisor
alter database
alter system
audit system
create database link
create table
create any index
create session
create tablespace
create, alter and drop user
insert any table
It is possible to allow a user to also grant the same system privilege he/she has to
other users, when granting the system privilege, use the option "with admin option".

Granting

grant create session to vallep;

grant create tablespace to vallep;
grant create user, alter user, drop user to vallep;

Revoking

revoke create session from vallep;

revoke create tablespace from vallep;

Allow user to also grant this

privilege

grant create session to vallep with admin option;

Note: now vallep can also grant this privilege

Useful Views

SYSTEM_PRIVILEGE_MAP

table to list all system privileges

DBA_USERS

provides information about users

DBA_SYS_PRIVS

see who has system privileges

There are two very powerful system privileges sysdba and sysoper, you cannot grant
this privilege to a role and you cannot use with admin option.

SYSOPER

perform startup and shutdown operations

mount/dismount and open/close the database
use alter database commands (BACKUP, ARCHIVE, LOG AND RECOVER)
perform archiving and recovery operations
create a spfile

All the SYSOPER privileges

SYSDBA

use the create database command

all system privileges with admin option

Object Privileges
Object privileges are privileges on database objects which allows a user to perform
some action on a specific table, view, sequence, etc. You can use the following SQL
statements when you grant object privileges
alter
select
delete
execute
insert
ex type, operator, procedure, sequence, table, trigger and type
exp_full_database - used for data pump export
imp_full_database - used for data pump import
if you grant a role using with admin option the grantee can do the following:

 grant the role to or revoke it from any user or other role in the database
grant the role with admin option
alter or drop the role
create role test_role identified by <password>;

creating

Note: the password is optional, you can also use externally or globally authentica

removing

drop role test_role;

adding privileges to role

grant select on HR.employees to test_role;

grant exp_full_database to test_role;
revoke select on HR.employees from test_role;

removing privileges from role revoke exp_full_database from test_role;

grant dba to test_role;

adding a role to a role

Note: the dba is a very powerful role be careful giving this out to anyone

granting a role to a user

grant test_role to valle;

grant test_role to vallep with admin option;

revoking a role from a user

revoke test_role from vallep;

list roles/privileges

select * from session_roles;

select * from session_privs;

setting session role

set role test_role identified by <password>;

set default

alter user vallep default role test_role

Useful Views
DBA_ROLES

list all the roles

lists the users granted roles

DBA_ROLE_PRIVS
Note: useful columns are with admin option, default role
ROLE_SYS_PRIVS

lists the roles system privileges and what roles have other roles within them

ROLE_TAB_PRIVS

lists the roles table privileges

ROLE_ROLE_PRIVS

lists what other roles the role has (roles within roles)

SESSION_ROLES

lists current role in use.

SESSION_PRIVS

show privileges currently enabled for the user

You can disable a users role by inserting a row within the

table product_user_profile in the sys schema.
disable specific role for user
insert into product_user_profile (

product, userid, attribute, char_value)

values ('SQL*Plus', 'VALLEP', 'ROLES', 'TEST_ROLE')
;

delete from product_user_profile

where userid = 'VALLEP',
enable specific role for user
and char_value = 'TEST_ROLE'
;