c



 
    


 
  
      

Un database Oracle è composto da:

‡ Aree di memoria
‡ Processi
‡ File fisici


  

   

i
 
 ë   
  

Un¶istanza Oracle viene identificata tramite un gruppo di

strutture di memoria e processi background che accedono
ad un set di file di database.

Y



  

   

 Y 
  

Ogni qualvolta si avvia un database Oracle, viene allocata

la System Global Area (SGA) e vengono avviati i processi
background. Una istanza Oracle apre un SOLO database.

Ñ
 





  

  

  

 
  


Ñ
 =      

Un¶istanza Oracle ha due tipi di processi: processi utente e processi

Oracle:

‡ Un processo utente esegue il codice di una applicazione come

una pacchetto di maschere o un tool di interfaccia al database.

‡ I processi Oracle sono processi server che effettuano operazioni

per i processi utente e i processi background che fanno lavoro di
manutenzione per il server Oracle.
 =  

rGira su una macchina client

r Viene aperto quando un tool o un¶applicazione viene
invocata
r Permette di far girare un tool o una applicazione
(SQL*Plus, Developer 2000)
r Include la User Program Interface (UPI)
rGenera chiamate al server Oracle
 =  


r Gira su una macchina server (host)

rServe un singolo processo user in una configurazione
server dedicated
rUtilizza una PGA esclusiva
rInclude la Oracle Program Interface (OPI)
r Le chiamate al processo vengono generate dal client
r Restituisce i risultati al client
     
   
RECO PMON SMON
LCK0

i
   System Global Area






User Shared Dedicated

Process Server Server
Process Process
CKPT
ARC0
D000 DBW0
‡ LCK0 Lock Process 
‡ RECO Recoverer Process User
LGWR
 
‡ PMON Process Monitor i 
‡ SMON System Monitor Process
‡ CKPT Checkpoint
‡ ARC0 Archiver 

‡ DBW0 Database Writer  

i


‡ LGWR Log writer
 =    
I processi background eseguono le funzioni più comuni per servire gli utenti che
accedono al database, senza compromettere l¶integrità e le performance
dell¶intero sistema. Ogni istanza ha almeno questi cinque processi background:

r 

  la sua funzione primaria è quella di fare un check

sulla consistenza del database ed avviare una fase di recovery se aprendo il db se
ne riscontra la necessità;
r=
 =pulisce le risorse in caso di fallimento di un
processo utente;
ri
 
 i
r  
 
r
 =
responsabile dell¶aggiornamento dello stato del
database quando i cambiamenti all¶interno della buffer cache vengono registrati
nel database in maniera permanente
     

Database DBWR scrive i µbuffer dirty¶ della

Shared Pool Redo log
buffer cache
buffer database buffer cache sui datafile, questa
scrittura sui datafile non avviene
contestualmente alla modifica ma viene
rimandata al verificarsi di uno dei seguenti
S GA eventi:
r il numero di µbuffer dirty¶ raggiunge un
DBW0
valore di soglia
r un processo cerca un buffer libero e non
ne trova nessuno




r avviene un timeout
i
  

 r avviene un checkpoint che invoca
DBWR, ciò può accadere per vari eventi,
Database come ad esempio alla chiusura del
database.
 Ñ  

Database LGWR scrive le registrazioni dei

buffer cache Shared Pool Redo log
buffer cambiamenti dalla red log buffer ai file
di redo log. Queste scritture avvengono
nei seguenti casi:
S GA r quando la redo log buffer è piena per
un terzo
LGWR r avviene un timeout
r quando viene eseguita la commit su
una transazione



 r prima che DBWR scriva i blocchi
modificati nella database buffer cache
 
i


 sui datafile
Database
        
ri

Contengono i dati presenti nel database. Le strutture logiche
come tavole ed indici sono immagazzinati fisicamente nei
datafile;
r 
Contengono le registrazioni di tutti i cambiamenti fatti al
database dalle transazioni correnti al fine di assicurare un
corretto recovery se necessario;
r


Contegono le informazioni necessarie per mantenere e
verificare l¶integrità della struttura fisica del database;
       
  
r 
 
 
Utilizzato per definire le singole caratteristiche di una istanza
Oracle;
r    
Utilizzato per autenticare gli utenti che si occuperanno
dell¶amministrazione remota del database;
r  

Copie fuori linea dei redo log archiviati che possono essere
necessari in caso di rottura di uno o più dischi per eseguire un
recovery;
 Ñ  







  

    

 i

 


Database


 
 Ñ   



La memoria condivisa di Oracle è meglio conosciuta come SGA

(System Global Area) contiene informazioni accessibili da tutti
gli utenti ed ha tre componenti principali:

r Shared Pool;
r Database buffer Cache;
rRedo log Buffer;
 c !c    "

Potete sentire nominare la SGA Shared Global Area, ma il significato è lo

stesso.

Database
buffer cache Shared Pool Redo log
buffer

SGA
 Ñ  
La dimensione della shared pool è definita tramite il parametro
SHARED_POOL_SIZE

Shared Pool
La dictionary cache contiene
Data dictionary Cache contiene le definizioni delle
tavole, delle colonne ed i
privilegi relativi.
Library Cache

La library cache contiene il testo, il codice elaborabile ed il piano di

esecuzione degli statement SQL.
      
La dimensione della database buffer cache è definita tramite il
prodotto tra il parametro DB_BLOCK_SIZE ed il parametro
DB_BLOCK_BUFFERS.

Database Buffer Cache

Contiene al suo interno i dati usati più di recente, Oracle utilizza

l¶algoritmo LRU per decidere quando far uscire i dati dalla
database buffer cache.
 º  
La dimensione della redo log buffer cache è definita tramite il
parametro LOG_BUFFER.

Redo Log Buffer

La redo log buffer contiene la registrazione dei cambiamenti

fatti internamente all¶istanza, questa area di memoria viene
acceduta sequenzialmente e sovrascritta in maniera ciclica.
=    
 
#Ñ

Uno statement DML viene processato tramite due passi procedurali:

[ PARSE: il processo server riceve lo statement ne verifica la validità e lo
compila, alla fine di questa fase il processo server ritorna lo stato del parsing
cioè fallimento o successo
[ EXECUTE:
1 Il processo server legge i dati e i blocchi di rollback dai datafile se
non sono nella database buffer cache
2 Copia i blocchi letti nella database buffer cache
3 Il processo server mette il lock ai dati
4 Il processo server registra i cambiamenti da fare nei segmenti di
rollback (before-image) e i dati (nuovi valori) nella redo log buffer
5 Il processo server registra la before-image sui blocchi di rollback e
aggiorna i blocchi dati, entrambi nella database buffer cache, questi
blocchi vengono marcati come µdirty¶, cioè differenti da quelli sul
datafile
=    
 
#Ñ

Processare uno statement DML

SGA
Databas Shared
Pool Redo
e buffer log
cache
buffer


 = Database
  





  
i


 
  

Segmenti di rollback
Nuova immagine del dato
Immagine precedente del dato

Tavola

Statement DML

L¶immagine precedente del dato viene usata per:

r Tornare indietro nel caso si esegua un rollback;
r Assicurare alle altre transazioni un accesso a dati consistenti;
r Eseguire un recovery ad una situazione consistente in caso di problemi;
 =    
ë##Y
rIl processo server mette una riga contenente la COMMIT con un
SCN (System Change Number) nella redo log buffer;
rLGWR si occupa di scrivere tutte le entries nei redo log compresa
la COMMIT, solo a questo punto Oracle può garantire una scrittura
consistente dei dati e che le modfifiche fatte non andranno perse;
rA questo punto l¶utente viene informato che la COMMIT è stata
eseguita correttamente;
rIl processo server registra che la transazione è completa e rilascia
i lock;
rLa scrittura dei µdirty blocks¶ sui datafile avviene in maniera
indipendente e può avvenire anche prima o dopo la COMMIT;
 


    

Nella creazione del database vengono creati automaticamente due

utenti:
r SYS con password change_on_install
r SYSTEM con password manager
Per evitare accessi non desiderati al database che amministrate è
opportuno cambiare queste password dopo la creazione del
database.
Alla creazione del database viene creato anche un ruolo di nome
DBA questo ruolo ha privilegi molto potenti e va assegnato con
cautela.
 


    

I seguenti metodi per l¶autenticazione al database sostituiscono la

sintassi CONNECT INTERNAL fornita con le precedenti versioni di
Oracle:

r Autenticazione da sistema operativo

r File di password

Se si desidera amministrare il database localmente sulla macchina

dove il database risiede o da un client remote si può scegliere tra un
metodo e l¶altro.
 


    

Amministrazione Amministrazione
Remota di un locale del database
database

Avete una Si Volete

Volete Si Utilizzare
connessione utilizzare
utilizzare la
la l¶autenticazione da
sicura? autenticazione
autenticazione OS
da
da OS
OS??

No No
Utilizzare un file di
password
 Y  =º

Il ruolo OSOPER permette di eseguire i comandi: STARTUP,

SHUTDOWN, ALTER DATABASE OPEN/MOUNT, ALTER
DATABASE BACKUP, ARCHIVE LOG, RECOVER, e include
il privilegio RESTRICTED SESSION.

Il ruolo OSDBA contiene tutti i privilegi con l¶ADMIN

OPTION, il ruolo OSOPER, permette di eseguire un comando
CREATE DATABASE e di effettuare un time-based recovery.

Questi ruoli possono avere nomi diversi e funzionalità diverse a

seconda del vostro OS, anche come la modalità di assegnazione
di questi ruoli dipende dal sistema operativo.
 ! 

   $ 

Affinchè questo tipo di autenticazione funzioni bisogna:
r Creare il file di password utilizzando l¶utility ORAPWD:
›

 
› 
   

r Impostare il parametro di inizializzazione:
REMOTE_LOGIN_PASSWORDFILE a EXCLUSIVE
r Aggiungere gli utenti al file di password utilizzando l¶SQL per
assegnare i privilegi appropiati agli utenti che dovranno occuparsi
dell¶amministrazione del database, come mostrato nell¶esempio
seguente:
c

›  !"#oppure c
› ›  !$#

r Ora l¶utente utente01 si dovrebbe poter connettere con il comando:

ë› ë  !"%& '(' 


 ë  
   
Ci sono una serie di passi da portare avanti per creare un
database:
1) Creare le strutture informative del database, incluso il data
dictionary (dizionario dei dati), Oracle ne ha bisogno per
accedere ed utilizzare il database;
2) Creare e inizializzare i control files ed i files di redo log
per il database;
3) Creare i nuovi datafile o cancellare i dati che esistevano in
datafile precedenti;
 ë   
   
Per creare un database ci sono varie opzioni:
r Creare il database con il comando CREATE DATABASE, ma
affinchè il proprio db sia operativo bisogna fare una serie di
procedure dopo la creazione, creare i tablespace temporanei ed
assegnarli agli utenti, creare le viste del dizionario dati,
installare i package predefiniti di Oracle;
r Utilizzare Oracle Database Configuration Assistant (DBCA),
questo tool permette di creare il database tramite una serie di
schermate che permettono l¶immissione dei requisiti del vostro
database, DBCA ha anche l¶opzione di non creare il database
materialmente ma di preparare degli script;
 ë
Questa è la schermata iniziale del DataBase Configuration
Assistant, dove posso scegliere quale operazione effettuare
con questo tool.
 Y  
 ëº

ë



ë







 !"#
$%

&
$!"#
$%

&
'!"#
$%



()(*+!,#
$%





-


- %%-#
 %
ë. ë

/
0
0012 3
 Y  
 ëºÑ=ë

ë


 ë
 


(!,#
 %




-


- %%-#
 1%3

ë


 ë



4*5*6!,#
1%




-


- %%-#
'1%3

ë


 ë

%

*+!,#
 %




-


- %%-#
 1%3
 =  

 




Istanza
 Shared Pool

Database buffer
cache Redo log buffer

 i = =
 

Init_sid.ora

 =  
 

 =  





   

 



ë Initalization Parameter File: init_sid.ora
db_name = nome_sid
control_files = (/mount_point01/control01.ctl, mount_point02/control02.ctl)
db_block_size = 8192
db_block_buffers = 2000
shared_pool_size = 30000000
log_buffer = 64K
processes = 50
db_files = 100
log_files = 10
max_dump_file_size = 10240
background_dump_dest = (/$ORACLE_BASE/admin/nome_sid/BDUMP)
user_dump_dest = (/$ORACLE_BASE/admin/nome_sid/UDUMP)
core_dump_dest = (/$ORACLE_BASE/admin/nome_sid/CDUMP)
rollback_segments = (R0101, R0102, R0103, R0104, R0105, R0106, «, ...)
«..
   $

Startup in tre step differenti:

1. Avviare l¶istanza
2. Montare il Database
3. Aprire il Database

Shutdown in tre step differenti:

1. Chiudere il Database
2. Smontare il Database
3. Chiudere l¶istanza
  
Quando avviamo un¶istanza:
r Leggiamo il file dei parametri init_sid.ora;
r Allochiamo la memoria necessaria per la SGA;
r Facciamo partire i processi in background;
r Tracciamo il nostro operato sull¶Alert;
Quando montiamo il Database:
r Associamo un database con l¶istanza precedentemente
avviata;
r Localizziamo ed apriamo i control files specificati sul file di
Parametri;
r Leggiamo i control file ed otteniamo nome e stato dei data
files e dei redo log files;
  

Quando apriamo il Database:

r Apriamo i data files in linea
r Apriamo i redo log files in linea
r Controlliamo la consistenza del database
  $

Quando chiudiamo il Database:
‡ Scriviamo i dati cambiati sui rego log files
‡ Chiudiamo tutti i data files ed i redo log files in linea
‡ I control files rimangono aperti finche è montato il database
Quando smontiamo il Database:
‡ Chiudiamo tutti i control files
‡ Lasciamo solamente l¶istanza aperta
  $

Quando chiudiamo l¶istanza:
‡ Chiudiamo i file di trace e l¶ALERT
‡ Liberiamo la memoria occupata dalla SGA
‡ Terminiamo i processi in background
   $

Esistono quattro modi differenti per fare lo shutdown di
un¶istanza:
1. Normal
2. Transactional
3. Immediate
4. Abort