Giorno IVGiorno IV
Istanza Oracle, Strutture Istanza Oracle, Strutture Fisiche,Fisiche,
Dizionario Dati Dizionario Dati
Database Oracle
Un database Oracle è composto da:
• Aree di memoria
• Processi
• File fisici
Database Files
System Global Area
Background Processes
Cos’è un’istanza Oracle
Un’istanza Oracle viene identificata tramite un gruppo di strutture di memoria e processi background che accedono ad un set di file di database.
ISTANZA ORACLE
System Global Area
Background Processes
Istanza Oracle
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.
La combinazione di buffer di memoria e processi La combinazione di buffer di memoria e processi background viene chiamata background viene chiamata
ISTANZA ORACLEISTANZA ORACLE
Processi Oracle e processi utenteProcessi Oracle e processi utente
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.
Processi utenteProcessi utente
Gira su una macchina client
Viene aperto quando un tool o un’applicazione viene invocata
Permette di far girare un tool o una applicazione (SQL*Plus, Developer 2000) Include la User Program Interface (UPI)
Genera chiamate al server Oracle
Processi serverProcessi server
Gira su una macchina server (host)
Serve un singolo processo user in una configurazione server dedicated
Utilizza una PGA esclusiva
Include la Oracle Program Interface (OPI)
Le chiamate al processo vengono generate dal client
Restituisce i risultati al client
Architettura di un server OracleArchitettura di un server Oracle
System Global AreaDatabase Buffer Cache
Redo Log Buffer
SharedServerProcess
DedicatedServerProcess
DatafilesRedo Log
Files
ControlFiles
OfflineStorageDevice
SMONPMONRECOLCK0
CKPT
LGWR
ARC0DBW0
UserProcess
D000
UserProcess
• LCK0 Lock Process• RECO Recoverer Process• PMON Process Monitor• SMON System Monitor• CKPT Checkpoint• ARC0 Archiver• DBW0 Database Writer• LGWR Log writer
Processi BackgroundProcessi Background
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:
System Monitor (SMON): 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à;
Process Monitor (PMON): pulisce le risorse in caso di fallimento di un processo utente;
Database Writer (DBW0)
Log Writer (LGWR):
Checkpoint (CKPT): è responsabile dell’aggiornamento dello stato del database quando i cambiamenti all’interno della buffer cache vengono registrati nel database in maniera permanente
Database WriterDatabase Writer
Database
Datafiles
ControlFiles
Redo LogFiles
S G A
Shared Pool Redo log buffer
Database buffer cache
DBW0
DBWR scrive i ‘buffer dirty’ della database buffer cache sui datafile, questa scrittura sui datafile non avviene contestualmente alla modifica ma viene rimandata al verificarsi di uno dei seguenti eventi:
il numero di ‘buffer dirty’ raggiunge un valore di soglia
un processo cerca un buffer libero e non ne trova nessuno
avviene un timeout
avviene un checkpoint che invoca DBWR, ciò può accadere per vari eventi, come ad esempio alla chiusura del database.
Log WriterLog Writer
Database
Datafiles
ControlFiles
Redo LogFiles
S G A
Shared Pool Redo log buffer
Database buffer cache
LGWR
LGWR scrive le registrazioni dei cambiamenti dalla red log buffer ai file di redo log. Queste scritture avvengono nei seguenti casi:
quando la redo log buffer è piena per un terzo
avviene un timeout
quando viene eseguita la commit su una transazione
prima che DBWR scriva i blocchi modificati nella database buffer cache sui datafile
Strutture fisiche di un database Oracle
Datafiles
Contengono i dati presenti nel database. Le strutture logiche come tavole ed indici sono immagazzinati fisicamente nei datafile;
Redo Log
Contengono le registrazioni di tutti i cambiamenti fatti al database dalle transazioni correnti al fine di assicurare un corretto recovery se necessario;
Control Files
Contegono le informazioni necessarie per mantenere e verificare l’integrità della struttura fisica del database;
Altre strutture fisiche di un database Oracle
File dei parametri (parameter file)
Utilizzato per definire le singole caratteristiche di una istanza Oracle;
File di password (password file)
Utilizzato per autenticare gli utenti che si occuperanno dell’amministrazione remota del database;
Redo Log Archiviati
Copie fuori linea dei redo log archiviati che possono essere necessari in caso di rottura di uno o più dischi per eseguire un recovery;
Le Strutture fisiche
Database
Datafiles
ControlFiles
Redo LogFiles
Redo Log Archiviati
File parametri
File di password
La memoria condivisa
La memoria condivisa di Oracle è meglio conosciuta come SGA (System Global Area) contiene informazioni accessibili da tutti gli utenti ed ha tre componenti principali:
Shared Pool;
Database buffer Cache;
Redo log Buffer;
SGA (System Global Area)
Potete sentire nominare la SGA Shared Global Area, ma il significato è lo stesso.
S G A
Shared Pool Redo log buffer
Database buffer cache
La shared pool
La dimensione della shared pool è definita tramite il parametro
SHARED_POOL_SIZE
Shared Pool
Library Cache
Data dictionary CacheLa dictionary cache contiene contiene le definizioni delle tavole, delle colonne ed i privilegi relativi.
La library cache contiene il testo, il codice elaborabile ed il piano di esecuzione degli statement SQL.
Database buffer cache
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.
Redo log buffer
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.
Passi per processare uno statement DML
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
Passi per processare uno statement DML
Processare uno statement DML
Processo server
Shared Pool Redo
log buffer
Database buffer cache
Datafiles
ControlFiles
Redo LogFiles
1
2
3
4
5Database
SGA
Segmenti di rollback
Segmenti di rollback
Tavola
Immagine precedente del dato
Statement DML
Nuova immagine del dato
L’immagine precedente del dato viene usata per:
Tornare indietro nel caso si esegua un rollback;
Assicurare alle altre transazioni un accesso a dati consistenti;
Eseguire un recovery ad una situazione consistente in caso di problemi;
Passi per processare una COMMIT
Il processo server mette una riga contenente la COMMIT con un SCN (System Change Number) nella redo log buffer;
LGWR 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;
A questo punto l’utente viene informato che la COMMIT è stata eseguita correttamente;
Il processo server registra che la transazione è completa e rilascia i lock;
La scrittura dei ‘dirty blocks’ sui datafile avviene in maniera indipendente e può avvenire anche prima o dopo la COMMIT;
Autenticazione al database
Nella creazione del database vengono creati automaticamente due utenti:
SYS con password change_on_install
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.
Autenticazione al database
I seguenti metodi per l’autenticazione al database sostituiscono la sintassi CONNECT INTERNAL fornita con le precedenti versioni di Oracle:
Autenticazione da sistema operativo
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.
Autenticazione al database
Amministrazione locale del database
Utilizzare l’autenticazione da
OS
Si
Utilizzare un file di password
Si Volete utilizzare la
autenticazione da OS?
Amministrazione Remota di un
database
NoNo
Volete utilizzare la
autenticazione da OS?
Avete una connessione
sicura?
I ruoli OSDBA e OSOPER
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.
Utilizzo del file di password
Affinchè questo tipo di autenticazione funzioni bisogna:
Creare il file di password utilizzando l’utility ORAPWD:ORAPWD FILE=filename PASSWORD=password ENTRIES=max_users
Impostare il parametro di inizializzazione: REMOTE_LOGIN_PASSWORDFILE a EXCLUSIVE
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:
GRANT SYSDBA TO utente01; oppure GRANT SYSOPER TO utente02;
Ora l’utente utente01 si dovrebbe poter connettere con il comando:CONNECT utente01/[email protected] AS SYSDBA
Creare un database
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;
Come creare un database
Per creare un database ci sono varie opzioni:
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;
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;
DBCA
Questa è la schermata iniziale del DataBase Configuration Assistant, dove posso scegliere quale operazione effettuare con questo tool.
Il comando CREATE DATABASE
CREATE DATABASE DB_PROVA CONTROLFILE REUSE LOGFILE 'c:\oracle\db_prova\redo01.log' SIZE 2M REUSE, 'c:\oracle\db_prova\redo02.log' SIZE 2M REUSE, 'c:\oracle\db_prova\redo03.log' SIZE 2M REUSE
DATAFILE 'c:\oracle\db_prova\system.dbf' SIZE 20M REUSE
AUTOEXTEND ON NEXT 10M MAXSIZE 100M
CHARACTER SET WE8ISO8859P1;
Il comando CREATE TABLESPACE
CREATE TABLESPACE RBS
DATAFILE 'c:\oracle\db_prova\rbs.dbf' SIZE 10M REUSE
AUTOEXTEND ON NEXT 10M MAXSIZE 150M;
CREATE TABLESPACE UTENTI
DATAFILE 'c:\oracle\db_prova\utenti.dbf' SIZE 50M REUSE AUTOEXTEND ON NEXT 10M MAXSIZE 350M;
CREATE TABLESPACE TEMP
DATAFILE 'c:\oracle\db_prova\temp.dbf' SIZE 10M REUSE AUTOEXTEND ON NEXT 10M MAXSIZE 150M;
Parametri di inizializzazione
SQLPLUS> connect / as sysdba
SQLPLUS> startup pfile=/$ORACLE_HOME/dbs/init_sid.ora
Init_sid.ora
Shared Pool
Redo log bufferDatabase buffer
cache
SGAIstanza
SMON DBWR PMON CKPT LGWR ARCH
Esempio file di inizializzazione
# Initalization Parameter File: init_sid.oradb_name = nome_sidcontrol_files = (/mount_point01/control01.ctl, mount_point02/control02.ctl)db_block_size = 8192db_block_buffers = 2000shared_pool_size = 30000000log_buffer = 64Kprocesses = 50db_files = 100log_files = 10max_dump_file_size = 10240background_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 e Shutdown
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
Startup
Quando avviamo un’istanza: Leggiamo il file dei parametri init_sid.ora; Allochiamo la memoria necessaria per la SGA; Facciamo partire i processi in background; Tracciamo il nostro operato sull’Alert;
Quando montiamo il Database: Associamo un database con l’istanza precedentemente
avviata; Localizziamo ed apriamo i control files specificati sul file di
Parametri; Leggiamo i control file ed otteniamo nome e stato dei data
files e dei redo log files;
Startup
Quando apriamo il Database: Apriamo i data files in linea Apriamo i redo log files in linea Controlliamo la consistenza del database
Shutdown
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
Shutdown
Quando chiudiamo l’istanza:
• Chiudiamo i file di trace e l’ALERT • Liberiamo la memoria occupata dalla SGA
• Terminiamo i processi in background
Tipo di Shutdown
Esistono quattro modi differenti per fare lo shutdown di un’istanza:
1. Normal
2. Transactional
3. Immediate
4. Abort
Recommended