Download Materialy/32/Lectures Oracle

Slovak University of Technology
Faculty of Material Science and Technology in Trnava
Information Systems
Development
The DBMS Oracle structure
Oracle
software
deveopment tools
Oracle
applications
Oracle
database system
Oracle
network technology
Oracle
end user
tools
The DBMS Oracle
The DBMS Oracle
ORACLE ARCHITECTURE




I. database architecture
II. software architecture
III. database processes
IV. data dictionary
I. Database architecture

physical structure:
 as many as you like DB files distributed to as many as you
like disks; containing all database objects like data
structures, procedural objects, access structures, data
 at least two redo log files; protocolling and storing all
changes of data; serve for recovery of the database after
system crash
 at least two control-files; containing the basic structures and
basic information about an Oracle database (moment of
creation, names of all DB files, names of all redo log files und
the sequence number of this, moment of the last checkpoint
and corresponding redo log files, ...)
Database architecture
F6
F1
F2
F4
F3
F5
database files
online redo log files
control files
Database architecture

logical structure of the database files:
 DB files are assigned to tablespaces
 for each database at least one tablespace exists (SYSTEM),
created at the same time with database; further can be
created
 all database objects will be assigned to a tablespace
 creation possible only with DBA grant
Database architecture
physical sight to database files
F4
F5
F6
F3
F1
F2
logical sight
tablespace SYSTEM
tablespace A
F2
tablespace B
F6
F1
F4
F3
F5
Creating a database
 deletes all data in the specified DB files, preparing them for new use;
loosing of data for an existing database
 creating only possible with DBA grant
create database [database]
[controlfile reuse]
[logfile filespec [, filespec] ...]
[maxlogfiles integer]
[datafile filespec [, filespec] ...]
[maxdatafiles integer]
[maxinstances integer]
[archivelog | noarchivelog]
[exclusive]
Creating a database
database
name of the database
filespec
specification of a db-file in the form of
‘filename’ [size integer [k|m]] [reuse]
size integer [k|m]] size of the database in K- resp. MByte
reuse
controlfile reuse
maxinstances
specifies the reuse (overwriting) or not of existing files
existing control-files will be overwritten
number of instances, accessing at the same time
to the database (1-255)
only one instance can access
exclusive

 changes of any settings possible with
 alter database
Creating a tablespace
create tablespace tablespace
datafile filespec [, filespec] ...
[default storage storage]
[online | offline]
Creating a tablespace
tablespace
name of the tablespace
filespec
specification of a file containing the tablespace in
form of
‘filename’ [size integer [k|m]] [reuse]
size integer [k|m]] size of the database in K- resp. MByte
reuse
storage
specifies the reuse (overwriting) of existing files
default parameter for all objects prepared in the
tablespace, e.g. (initial 10k next 50k
minextents 1 maxextents 999 pctincrease
10)
online | offline
makes the tablespace directly accessable
changes are possible with alter tablespace, drop tablespace, ...
Structure of a tablespace



types of objects resp. kinds of segments in a tablespace:
 tables (data segments)
 indexes (index segments)
 rollback segments
 temporary segments
each table, index, rollback segment is assigned to exactly one
segment in the concerning tablespace; temporary segments will
be created by Oracle
assignment to a tablespace depends on
 tablespace of the objects owner
 owner options
 options in the create statement of the object
Structure of a tablespace
database files
create table
D
create index
create
rollback segment
created by Oracle
if necessary
(temporary)
I
R
T
Structure of segments





segment is created by extents (= memory ranges of
determinable size)
differentiation between initial extents and next extents
next extents can have an increasing factor additionally
(pctincrease)
extent contains Oracle datablocks of mostly 2 KByte
specification of storing parameters in create / alter e.g.. for
 tablespace
 table
 index
 rollback segment
Structure of segments


example:
storage (
initial
next
minextents
maxextents
pctincrease
freelist
20 MB,
10 MB,
3,
80,
15,
3)
supervision of tablespaces and tables by view on data dictionary:
select * from user_tablespaces;
select * from user_tables;
Structure of database blocks


smallest units of a database are blocks; are stored in the extents
of segments
configuration of datablocks by pctfree, pctused, initrans,
maxtrans
database blockheader
free range for
expanding records
pctfree
database block
insert area
(slip)
minimal
filling
pctused
Structure of database blocks


database blockheader contains management information (row
directory, transaction directory)
data range is divided in pctfree und pctused; important for
varchar2-data (pctfree) and balanced filling of all blocks if
possible (pctused)
Structure of records



smallest logical units of the database; containing record header
and record body
record header: min. 3, max. 5 Bytes
record body: data as specified by create table statement incl.
column length, but not absolute in the defined order (LONG und
LONG ROW always at the end)
Structure of records
column length
1 orr 3 Byte
record header
number of columns
1 Byte
record header
2 Bytes
cluster key
(optional) 1 Byte
data of column
column lengt
variable (VARCHAR2) 1 or 3 Byte
fixed (CHAR)
data of the columns
linkaddress for records
> blocksize (Byte)
Database architecture
tablespace
ORACLEdatabase
file
segment
data
table
index
index
rollback
extent
temporary
db block
Database architecture
Database architecture
views to the data dictionary:
dba_data_files
shows all DB files and there state
dba_tablespaces
shows all tablespaces and there state
dba_freespaces
shows the free memory within the tablespaces
dba_quota
shows the tablespace-quotas of all users
user_extents
(all_extents
dba_extents)
shows the extents of all tables and indexes of a
user (resp. of all tables / indexes accessible by
the user resp. of the whole database
user_tables
shows all tables of a user
II. Software architecture
application processes
ORACLE DBMS
ORACLE database
DBWR
DBC
A
C
H
E
LGWR
ARCH
SMON
PMON
CHKP
shared and dedicated
ORACLE server processes
ORACLE instance with DB cache (SGA)
and background processes
Software architecture
Software architecture



database system consists of
 ORACLE instance and
 several server processes being part of them
ORACLE instance consists of
 database cache (Shared Global Area SGA) and
 several background processes
ORACLE server processes (usually several activ at the same
time) take it up to do e.g.
 parsing of SQL statements,
 executing of SQL statements,
 reading of DB blocks from DB files into the DB cache,
 ...
III. Process structure
ORACLE database server
DB-Cache
R
E
D
O
DB block
buffer
1
4
DBWR
1
4
2
Shared
SQL pool
3
LGWR
3
PMON
4
SMON
2
ARCH
4
5
5
4'
database files
redo log files
into archives putted
redo log files
Oracle processes: database write process (DBWR)



writes DB blocks changed in the DB cache back to the DB files
is started when
 all DB blocks in the cache are covered and space in the
memory is needed (blocks not used longest time are first
restored)
 number of modified blocks in cache is too large
 not activated by an external event for a too long time
(DBWR timeout ca. all 3 seconds)
 a checkpoint is reached (all changes will be restored,
fileheader of DB files, control files and redo log files will be
actualized; database is in a defined state)
when activated synchronization with LGWR process necessary
Redo log writer process (LGWR)



restoring of changes in Oracle not synchroniously with commit,
but "any time" asynchroniously
DB changes are additionally protocolled in the redo log buffer
(old + new value)
LGWR writes redo log buffer to the redo log file when
 redo log buffer is filled up to 80 percent
 an user process signalizes an end of transaction
 the DBWR process signalizes a writing process (LGWR
writes before)
Redo log writer process (LGWR)

at the end of a transaction (caused by commit) after the writing
process the user process will receive the commit end message,
ensuring that
 all finished transactions are made permanent in the redo log
file (safety)
 all modified DB blocks will be kept as long as possible in the
DB cache in the memory (performance)
 all transactions get very quickly the commit end
acknowledgement (commit) when finished, because max.
one redo log buffer has to be written to the disk
(performance)
Redo log writer process (LGWR)


at a checkpoint the LGWR has additional tasks as follow:
 marking all modified DB blocks in the DB cache und so
prepare them for restoring by the DBWR
 actualize all fileheaders relating to checkpoint
 write the actual redo log buffer to redo log file
 signalize the checkpoint to the DBWR process; DBWR then
writes all marked DB blocks to the DB files
for highly stressed DB systems checkpointing is optional a
separate process (CHKP)
Processing a transaction
process
insert into
<table>
update <table>
delete from
<table>
commit
ORACLE DB cache
LGWR
DBB
L
O
C
K
B
U
F
F
E
R
R
E
D
O
DBWR
writes asynchroniously
modified DB blocks
preceeded and
possible actual
transactions back
to the DB files
After commit
the redo log buffer
will be restored
to the redo log file
if ok then go on
redo log files
time
DB files
Process monitor (PMON)


checking in periodically
 user processes have to be stopped by the systemmanager
 programs not regularly finished due to crash and that have
locked database ressources
unlocking and rollback the changes of this transaction
System monitor (SMON)



checking for opened transactions resp. not restored changes
when database is started
reason is e.g. not regularly finished DB working if
 closing the database by the DB administrator with shutdown
immediate or abort
 crash of the DBMS or of the operating system
 hardware error, power fall out
starts the recovery automatically; all completed transactions will
written with help of the redo log files to the DB files, all
uncompleted transaction will be rollbacked
Archieving process (ARCH)



optional background process
when DB is started in ARCHIVE LOG mode with the redo log
files it can be reconstructed
ARCH copies redo log files to another medium, actualizes the
control files
Database cache

DB block buffer
 DB blocks requested by the application program will be read
into the DB cache, there processed and available for the user
process
 blocks in the DB cache can be used by several processes
(good tuning means 9 logical reads related to one physical
read from disk)
 DB blocks are subject of last recently used algorithm (LRU);
blocks not used for the longest time will be first restored if
possible
Database cache



shared pool contains
 parsed SQL statements, compiled functions, procedures,
data dictionary information and DB trigger (shared SQL
region for public use)
 private SQL region for session oriented private information
 are also subject of LRU-algorithm
instance information
 registration of locked resources, order for processing a
queue, active transactions with information about state, ...
db cache parameters are defined in init.ora
IV. Data dictionary
contents oriented view of an Oracle database
users
D
A
T
A
D
I
C
T
I
O
N
A
R
Y
user 1
user 2
user 3
user n
DB resources, tables, indexes, ...
Data dictionary

Oracle database consists of
 data dictionary, storing all data responsible for regular
function of the database = database for the management
of database objects
 as many as you like users with different privileges
 database objects like tables, views, indexes, procedures,
DB triggers, ...
Data dictionary


data dictionary
 consists of system tables, accessible by SQL
 internal level = real tables; no accesss by normal users
 external level = views to system tables
data dictionary tables
 when creating a database the users SYS, SYSTEM and
PUBLIC will be created automatically
 SYS is owner of all data dictionary tables (internal level) and
of all data dictionary views (external level) = highest
privileged user
 SYSTEM is owner of DB tables for Oracle tools
 PUBLIC is a user, representing all users of an Oracle system;
all users have privileges of PUBLIC
Data dictionary

data dictionary content
 users and their privileges
 tables and their column names and datatypes
 statistics about tables and indexes
 index information
 access privileges to tables
 profile information and allocation to the users
 free space management
 ...
Data dictionary
Using the data dictionary
for processing a SQL statement
Oracle
data dictionary
select * from
employees
where salary>4500;
1. checking
ok ?
- exists the table "employees" ?
- does user have the privileg to access ?
- exists a column "salary" ?
- what means '*' ?
- is there an index to "salary" ?
- exists statistical information ?
- ...
Oracle user data
2. execution
3. result
Data dictionary views

each view exists in 3 groups, accessible with the assigned prefix
in SQL:
 USER consists all DB objects, where the user is owner
z.B.: select * from user_tables
 ALL consists all DB objects, where the access by the user is
possible
z.B.: select * from all_tables
 DBA consists all database objects, where DBA privileges are
necessary = overall view to the database
z.B.: select * from dba_table
Database Management





Tasks of database management and administration
Database integrity
Administration of database privileges
Backup / Recovery
Database tuning
User groups and their tasks



DBMS-designers / -implementors:
Database designers:
 development of DBMS
 problem analysis
 establishing the schema
Applications programmers:
 realization of the end-user demanded applications
User groups and their tasks


Database administrators:
 maintenance of data / of the system
 user support
 minimization of expense for database management
End-users:
 predefined queries (parameterized user)
 ad hoc queries (occasional user
Tasks in the management phase

system maintenance and monitoring
 keep documentation of the DBS
 keep statistics (access behavior, memory requirements, ...)
 monitoring of security protocols
 management of authorizations / creating new users

system changes
 actualization of system documentation
 coordination and planning of the hardware development
Tasks in the management phase

system changes – cont.
 coordination of software maintenance
 extensions of the conceptual schema
 changes of the internal schema (optimizations)

database administration
 allocation of user-id's
 granting / revoking of access privileges
Oracle database administration







initialize the database
start and stop the database
structuring the database
 definition of tablespaces
 file allocation for tablespaces
 distribution of database files to disks
 definition of rollback segments (size, count, place, ...)
development and implementation of strategies for backup /
recovery of the database
development and implementation of security concepts
monitoring of the databse activities
tuning the database
Database integrity - transactions


definition:
 A transaction is a sequence of operations, leading the
database in no- interruptable way from one consistent state
to (not necessarly different) consistent state.
features of transactions (ACID):
 Atomicity (no-interruptability, indivisibility): A transaction is
an atomar unit, will be processed as a whole or not.
 Consistency (preservation of consistency): The correct
processing of a transaction leads the database from one
consistent state into a consistent state again.
 Isolation (isolated processing): The transaction must be
serializable.
 Durability (durability of results): After a transaction is
successfully finished, the changes may not get lost. That is
because this information is needed for recovery of the
consistent state in case of an error.
Database integrity



lost update problem (lost changes):
 If the transaction T2 reads the value of X, before the
transaction T1 has stored the changes, the result of T1 is
lost.
temporary update problem (temporary changes):
 If a transaction fails during the processing and the changes in
the database are already stored, another transaction can
read the changed date before the the old state was re-stored.
incorrect summary problem (dirty read):
 Incorrect values can be caused by e.g. adding up data
elements over several records while another transaction
updates one of these data elements.
Oracle processing integrity protection of integrity by lock mechanism
update employees
set salary = salary * 1.04
where name like 'A%'
locking granulates
DB table
DB block
record
locking escalation
Oracle processing integrity typical locking granulates



locking of tables
 a transaction locks the whole table for access by other
transactions
locking db blocks
 locking the DB block for other transactions, not affected
blocks of the same table are free
locking records
 only the affected records are locked, all the others are free
for access
Oracle locking mechanisms locking modes
operation
locking mode
record
table
select
-
-
insert
X
RX
update
X
RX
delete
X
RX
DDL / DML-Befehle
-
X
legend:
X RX -
remarks
reading access needs no locks
All DML-operations lock on record level;
other transaction can read the tables
record is eXklusively locked
table is in Row EXclusively mode;
RX can keep by some transactions; no locking escalation
Oracle locking mechanisms principles

Oracle locking is based on
 transactions directory within each DB block
 system change / commit number (SCN)
 Oracle transaction table within the rollback segment header
process 1
update employees
set salary = salary * 1.04
where pnr > 7000 or
depnr = 40
table 'employees'
process 2
insert into employees
values
(2341, 'Maier', 4500.00)
process 3
select *
from employees
Oracle locking mechanisms processing transactions (default, automatically)



when started transaction gets a transaction number (SCN)
managed within the transaction table
all records changed by the transaction get the SCN; record
accepts as locked if the record-SCN corresponds with the SCN
of an active transaction in the transaction table
unlocking by deleting the SCN from the transaction table after
ending the transaction (commit or rollback)
Oracle locking mechanisms processing transactions (default, automatically)
transaction 1
transaction table
update <tab>
set ...
where ...
3982
transaction 2
3999
4003
update ...
4007
db block header
2100
3999
3501
1001
3999
X
X
db block
Oracle locking mechanisms explicite locks
additionally explicite locks with SQL possible
lock table <tab> in <mode> (nowait)
possible modes:
X
exclusive mode
table is exclusively locked; other processes can have only
reading access
S
shared mode
table is in READ-ONLY-mode locked; other processes can
also in S-mode lock and read; no process can change
RX row exclusive mode
default locking of Oracle; as many as you like processes
can access in RX-mode and at the same time DMLoperations realize
RS row shared mode
allows other processes RS- und RX-locking; other
processes can read the table, but not lock in X-mode; update change RS-locks into RX-locks
SRX shared row exclusive mode
other processes can read the table and lock in RS-mode;
X- and S-locks are not allowed
Oracle locking mechanisms toleration of locking of two DB processes
process 1
process 2
X
S
RX
RS
SRX
X
-
-
-
-
-
S
-
+
-
+
-
RX
-
-
+
+
-
RS
-
+
+
+
+
SRX
-
-
-
+
+
Oracle transaction concept
t0
t1
account 63427
10,000 $
subtotal
account 63427
8,000 $
transaction
opened
t2
t3
total
account 63427
8,000 $
transaction
account 5546
2,000 $
update konto
set saldo=saldo-2000
where knr=63427
update konto
set saldo=saldo+2000
where knr=5546
commit
subtotal
account 5546
4,000 $
total
account 5546
4,000 $
Oracle transaction concept

commit statement results in a transaction

transaction is successfully ended
 all changes carried out are saved by storing the redo-logblock into the redo-log-file
 all locked ressources are cleared
rollback statement results

transaction is successfully ended
 all changed data will be re-changed again to the old value
with the help of rollback segment
 all locked resources are cleared
rollback must not be complete; transaction can set a <savepoint>


Oracle
problem: consistent read
time
t1
process 1
table
'employees'
process 2
time
select *
from employees
2000
update employees
set salary=salary*1.1
where depnr=30
result:
2000 ...
3300 (instead of 3000)
2200 (instead of 2000)
3000 (3300)
by the process 2
changed data
are also in the
result (dirty read)
2000 (2200)
problems:
locking of the whole table for changes during reading causes loss
of performance approval of "dirty read" is not acceptable
t2
Oracle
problem: consistent read
Read-Consistency-model for reading without locks
time
t1
process 1
table
'employees'
select *
from employees
process 2
time
Rollback
segment
2000
update employees
set salary=salary*1.1
where depnr=30
result:
2000 ...
3000
2000
consistent state
at the time t1;
consistent read
without locks
3000 (3300)
3000
2000 (2200)
2000
access to several tables in analogue way possible
(read-only-transaction) as a snapshot on start-time
t2
Tasks of the DB administration





allocation of user identification number
registration in DB table inclusively password
checking of access privileges at each login; makes together with
the terminal identificator possible to identify the user trying
access without privileges
registration of the person responsible of write operations in the
systems protocol (user-ID + terminal-ID)
in case of illegal access the database audit following the system
protocol determines cases of illegal access during a certain
period of time (user-ID, ...)
Access control

access control saves that all information in the database
 only by authorized user
 is read or changed resp. in the authorized format
 and is transported and processed only on authorized ways
Access control: functions



identification
 means the registration of an user in the system with the
specification of his user-ID
authentification
 means the checking process by the system to save that the
user logging in with a definite password is also in fact this
user
authorization
 is the act of allocation the grants for access to the user. Who
is allocating grants must have the grants themselve with
grant option.
Requirements on access protection




graded units of protection
 definition of several grades of protection and several
granularity of protecting objects must be possible
clear interfaces
 access to the database has to be possible only via this
defined interfaces
decentral authorization
 access grants to distinguished groups of data should be
allocated and revoked
dynamic authorization
 allocating and revoking of grants must be possible during
running the database system
Requirements on access protection




Different criteria of decision
 for precise adjustment to objective, legal and other facts the
access grants should depend on several criteria
dataflow and inference control
 storing of protected data and so making them accessable for
other users is not allowed even for authorized users;
remaining and using must be controlled
little influence on system performance
integral access control in the DMBD
 access control must be considered from the beginning of
implementation
Concepts of protection



isolation (no common use of data)
 data and programs are only available for the owner; but in
contradiction to the target of large database systems
unlimited access control
 as many as you like users use all data commonly and have
determined grants to the objects (data, programs, terminals)
principle of smallest as possible privileges
 users get access grants to smallest possible units (access
keys, values of attributes, ...); but not to storage media, files,
record types, ...
Concepts of protection



partial ordering of privileges of using
 e.g. hierarchical order of user groups and therefore of access
grants
(partial) ordering of access operations
 e.g. hierarchical order of access operations; who has
determined access grants has these also for all subordinated
operations (e.g. who is allowed to update is allowed to read
too)
order of objects needs of protection
 classification of information on needs of protection
Allocating grants in SQL
allocating grants in SQL:
grant
{
all
<list of grants>
all but <list of grants>
}
on <table>
to <list of users>
[with grant option]
}
on <table>
from <list of users>
revoking grants in SQL:
revoke
{
all
<list of grants>
all but <list of grants>
Access grants


object privileges define allowed operations on database
objects like
 tables
 views
 PL/SQL programs
 sequences
system privileges define operations being able to carry out on
the database resp. within the database server like
 creating a table (‘create table’ privilege)
 alter a tablespace (‘alter tablespace' privilege)
 creating a roll back segment (‘create rollback segment’
privilege)
Access grants
users
privileges
database
tab1
insert, select, update
proc1
execute
view1
select
update (a,b)
tab2
create tablespace
alter rollback segment
Object privileges
 can be defined by grant statement (Form III)
grant obj_priv [, obj_priv] ... | all [privileges]
on [user.]object to {user | public } [, user] ...
[with grant option]
obj_priv
for tables one of the following: ALTER, DELETE, INDEX, INSERT,
REFERENCES, SELECT, UPDATE
for views one of the following: DELETE, INSERT, SELECT, UPDATE
for sequences: ALTER, SELECT
update and references privileges can explain constraint for determined
columns:
grant col_priv [, col_priv] (col , col ...)
on [user.]table to {user | public} [, user] ...
[with grant option]
all [privileges]
specifies all referred object privileges
on [user.]object
specifies the refered object
public
specifies all users, futural too
with grant option
specifies that the receiver of the grant can pass this grant on other users
System privileges
 can be specified by grant statement (Form I); DBS privileges necessary
grant db_priv [, db_priv] ...
to user [, user] ... [identified by password [, password] ...]
db_priv
DBA: allows to avoid default privileges und to take over DBA functions like create
tablespace, create rollback segment; allows select on any tables and views, create for
DB objects of other users, drop for DB objects of other users, grant for different DB
privileges, create for public synonyms and DB links, complete DB export and import
CONNECT: allows the user to connect the DB and to process DB objects he ownes the
grants for; can create views, synonyms and DB links
RESOURCE: allows to create DB objects with unlimited resources on all tablespaces
user
specifies a new or existing DB user name; existing one gets the grants additionally, a new
one will be created with the specified grants
password
specifies the password of each specified user
Available system privileges
analyze any
audit any
audit system
create cluster
create any cluster
alter any cluster
drop any cluster
alter database
create database link
create any index
alter any index
drop any index
grant any privilege
create procedure
create any procedure
alter any procedure
execute any
procedure
create profile
alter profile
drop profile
alter resource cost
create public
database link
drop public database
link
create snapshot
create any snapshot
alter any snapshot
drop any snapshot
create role
alter any role
grant any role
create synonym
create any synonym
drop any synonym
create rollback
segment
alter rollback segment
drop rollback segment
alter system
create session
alter session
restricted session
create sequence
create any sequence
alter any sequence
drop any sequence
select any sequence
create table
create any table
alter any table
backup any table
drop any table
lock any table
comment any table
select any table
insert any table
update any table
delete any table
create tablespace
alter tablespace
manage tablespace
drop tablespace
unlimited tablespace
force transaction
force any transaction
create trigger
create any trigger
alter any trigger
drop any trigger
create user
become user
alter user
drop user
create view
create any view
drop any view
Resource privileges
 can be defined by grant statement (Form II)
 DBA grant necessary
grant resource [ (quota [k|m] ) ]
on tablespace to { public | user [, user] ...}
resource
specifies that the user is allowed to create DB objects in the specified
tablespace
quota
specifies the amount of memory in Kbyte or Mbyte allowed to be consumed
by the user; specifying 0 revokes the grant
tablespace
name of an existing tablespace
user
specifies an existing username
Concept of roles


individual allocation of privileges causes high expenditure of
management
remedy: definition of roles / task profiles ('create role' privilege
necessary) :
create role rolename;


with grant statements roles get privilegs
several and as many as you like roles can be allocated to
users
Concept of roles
create role in92;
grant in92 to in95;
grant in92 to benny;
grant select,insert
on tab1
to in92;
grant create tablespace,
create any view,
manage tablespace
to in92;
grouped privileges
individual privileges
States of roles
 categories
of roles:
available roles: all roles allocated to a user by
grant
 default roles: after Oracle logon already active
roles; defined by alter user statement, must be
allocated to a user by grant
 active roles: actually for a user activated roles; can
be activated and deactivated during a session with
set role ('set role' privileg necessary)
 deactivated roles: currently deactivated roles of the
user

States of roles
available roles
b
d
a
shows all roles of the user
e
c
default roles
select *
from user_role_privs;
select *
from user_role_privs;
alter user benny
default role b, d;
d
b
'DEF'-Column= YES (default)
NO (no default)
logon
activated roles
select *
from session_roles;
b
c
d
deactivated roles
b
c
d
a
e
select granted_role
from user_role_privs
MINUS
select role
from session_role;
Operations with roles
create a role
create role rolename;
giving privileges to a role
grant sys_privs, obj_privs to role;
allocating roles to users / roles
grant role1 to user / role2
revoking role from user / role
revoke priv / rolle from user / role
activate / deactivate roles
set role role1, ...
set role all;
set role all except role1, ...
set role role identified by pw;
define role as default role
alter user user default role role, ...
drop a role
drop role role;
Backup - principles
Backup – is a way how to save a data.
The replicas of data include part of database - control files and data
files.
Backup is possible to use for:
database, tablespace, tables, materialized views datafiles, control
files or archived redo logs.
Backup is possible to perform:
• with Export utility
• with Recovery Manager
Backup - Export utility
• EXP MSADMIN/msvp PARFILE= E:\oracle\exp\MSVP.EXP
MSVP.EXP obsahuje:
FILE=E:\oracle\exp\MSVPEXP.DMP
LOG=E:\oracle\exp\INFOEXP.TXT
OWNER=MSADMIN
BUFFER=8192
• IMP Scott/Tiger PARFILE=E:\oracle\exp\MSVP.IMP
MSVP.IMP obsahuje:
FILE=E:\oracle\exp\MSVPEXP.DMP
LOG=E:\oracle\exp\INFOIMP.TXT
FROMUSER=MSADMIN
TOUSER=Scott
BUFFER=8192
Restore
Restore – is a process that use backup for renew lost or damaged
files.
Using of restore:
 command cp – in Unix
 command restore – in RMAN (Recovery Manager).
Backup and Restore
Recovery - principles



database as a whole must be consistent in the most varied error
situations, competition control protects consistency in detail only
target: no approval of data loss
kinds of errors:
 abnormal end of a user program that carried out changes
without reaching commit
 abnormal end of the database system (crash of the DB
server)
 abnormal end of the operating system (crash of the operating
system)
 loosing database files (disk error)
Recovery - principles

recovery procedures of Oracle:



process recovery (if the user program was crashed)
instance recovery (if the DB server or the operating system
was crashed)
medium recovery (in case of loss of database files)
Recovery - run of a transaction
process
DB cache
DB buffer
update employees
set salary=2000
where salary=1000;
1000
2
2000
commit;
rollback segment
buffer
1
1000
redo log
buffer
3
1 RS 1000
4
1 DW 2000
5
1 commit
0
6
redo log
files
1000
DB files
1 RS 1000
1 DW 2000
1 commit
Recovery - run of a transaction
0. read the DB block into the DB cache (if not already
available); lock the affected DB record
1. copy the actual value into the rollback segment buffer
2. changing within the DB block (1000 ---> 2000)
3. rollback segment changes will also be protocolled into
the redo log buffer (neuer item in RS: 1000)
4. new value of data will be protocolled (DW 2000)
5. end of transaction by commit, item in redo log buffer
6. commit causes writing of the redo log buffer into the redo
log file (LGWR process)
7. end of commit message to the user program after
successful writing of the redo log file
DB file remains unchanged; but all changes are permanent
Process recovery

example:
 value ‘salary‘ changed from 1000 to 2000; afterwards crash
of the user program without commit
 result:
 record is changed in DB cache (new value 2000)
 record is exclusively locked by the crashed program
 entries in rollback segment and in redo log buffer are
done
Process recovery

solution:
 PMON process checks (ca. all 20 sec) whether DB
resources of no longer existing process are locked
 process number in DB cache available, process in
operating system not active
 PMON initializes rollback of the opened transaction (old
value from the rollback segment will be copied into the
DB block, record will be unlocked)
Process recovery
process
update employees
set salary=2000
where salary=1000;
DB cache
DB buffer
1000
comment
rollback segment
buffer
1000
2000
crash of the
user process
2000
1000
1000
PMON background process:
recognizes that
the user does not exist
rollback:
old value from RS
will be restored;
unlocking
Instance recovery
several transactions are affected
situation at the time of system crash:
process
DB cache
DB-Puffer
update employees
set salary=2000
where salary=1000;
1000
commit;
rollback segment
buffer
1000
2000
redo log
buffer
1 RS 1000
1 DW 2000
1 commit
update department
set city='Leipzig'
where city='Halle'
Halle
Halle
Leipzig
Halle
1 DW Leipzig
redo log
files
1000
DB files
1 RS Halle
1 RS Halle
1 RS
1 1000
DW Leipzig
1 DW 2000
1 commit
Instance recovery
SMON process:
 execute a roll forward for each closed transaction from the redo log file (commit
exists), a rollback for each open transaction (commit doesn’t exist)
 start the recovery from the check point
SMON background process
DB files
redo log files
1000
1000
2000
Halle
Halle
Leipzig
6
1
2
3
1 RS 1000
4
5
2 RS Halle
1 DW 2000
1
commit
2 DW Leipzig
Instance recovery


transaction 1:
1. RS item will be written from the redo log file to the DB into
the RS (1000)
2. changed value will be written into the DB (2000)
3. commit record in the redo log file affects deletion of the RS
item
transaction 1 completely recreated
transaction 2:
4. RS item will be written from the redo log file to the DB into
the RS (Halle)
5. changed value will be written into the DB (Leipzig)
6. commit record in the redo log file is absent and will be
recreated with help of the RS item
transaction 2 is cancelled
Medium recovery



requirements:
 DB have to run in archive mode
 periodically backups have to be made
 redo log files have to be archived (ARCH process)
in case of problems the DBA has to bring back the archived files
manually
in Oracle several backup / recovery methods (online/ offline) are
available
DB tuning - idea

tuning process, to provide optimal performance on a given
platform and in a determined application and datastructural
profile
DB tuning - tuning levels
datastructure
 logical structure of DB objects
 index structure
 cluster (index / hash)
 sequences
SQL operations
 SQL optimization (statistical / rule based method)
 determination of statistics of the DB objects
application
 kind of configuration
 integrity constraints in the DB server / application
(declarative / procedural method)
 stored PL/SQL programs
 discrete transactions
DB server
 DB cache optimization (DB block buffer pool / shared pool
for SQL objects / data dictionary)
 checkpointing
database
 object distribution to different disks
 rollback segments (number / distribution / number of
transactions per RS)
 redo log file (size / disk)
DB tuning - datastructure level

influences:
 logical structure of tables
 appropriate index structures
 primary key creates automatically an unique index
 for foreign key there should be non unique indexes
(referencing creates then only an index entry lock)
 indexes to columns and combinations of columns only if
necessary and selectivity is expected
DB tuning - SQL statement level

SQL optimizer:
 works with rules corresponding to evaluation of where
clauses
 based on statistics created with the help of the analyze
statement and stored in the data dictionary (Oracle default
method), e.g.:
 for a table:
 number of records
 number of DB blocks of the table
 number of not used DB blocks
 averagely free space within the DB blocks
 number of chained records
 number of unique values per column
DB tuning - SQL statement level
for an index:
 minimal / maximal value of each column
 height of the index tree
 number of index blocks on sheet level
 number of unique values within the index
 minimal / maximal value of the index
 average number of index blocks per index value
 average number of DB blocks per index value
 additional possibility: information for faster access

DB tuning - SQL statement level

possibilty to trace:
 set Oracle session by alter session statement sql_trace=true
and collect information in a trace file, e.g.
 schedule for access of each SQL statement
 CPU time for execution / parsing of a statement
 number of physical / logical I/O's
 number of executions of a statement
 number of parsing processes
 evaluation with utility tkprof
DB-Tuning - application level



server mode (multithreaded server mode: many applications
served by few server processes / dedicated server mode: big DB
loadings)
use of declarative or procedural integrity constraints
stored PL/SQL procedures (in the shared pool on the server;
little net loadings)
DB tuning - DB server level


size and configuration of the DB cache
 size of the DB block buffer (should be so that for one physical
read operation from disk there are 10 to 20 logical read
operations from DB cache)
 number of DB block buffers
size of the shared pool
 SQL statements, PL/SQL programs, DB trigger
 data dictionary information
DB tuning - database level






redo log files on the fastest disks
tablespace SYSTEM only used for data dictionary information
temporary segments in an extra tablespace
rollback segments in an extra tablespace
provides rollback segments always with storage parameters
data segments and index segments of the same DB object in
different tablespaces on different disks