Kosmous beyond the clouds: Sviluppo, Formazione e Consulenza Informatica

Oracle DBA 9i - Cap. 1

Un Server Oracle è costituito da tre componenti:

  1. Le strutture di memoria
  2. I processi
  3. I file fisici

In genere con il termine “database” si fa riferimento esclusivamente ai file fisici, mentre gli altri due componenti, processi e strutture di memoria, costituiscono l’istanza.
Prima di andare avanti con una descrizione dettagliata dei tre componenti, analizziamo brevemente il funzionamento del sistema.
Supponiamo di aver installato il software in una directory chiamata c:\oracle e di aver creato un database chiamato ORCL.
La directory c:\oracle viene chiamata ORACLE_HOME.
Al suo interno troveremo una serie di altre directory, tra le quali:

c:\oracle\admin\ORCL\pfile
c:\oracle\database
c:\oracle\oradata\ORCL

Le prime due contengono il file di inizializzazione, ad esempio init.ora o spfileORCL.ora, cioè il file necessario per informare il sistema della quantità di RAM da allocare (conterrà le strutture di memoria descritte nei paragrafi successivi), e quali processi lanciare. Tutte queste informazioni sono memorizzate nel file sotto forma di parametri cui viene assegnato un valore. Ad esempio troverò il parametro db_name=orcl che indica il nome del database.

La directory c:\oracle\oradata\ORCL conterrà invece i files che costituiscono il database ORCL.

Affinché si possano utilizzare il database, inteso come insieme di files fisici, occorre allocare una struttura che possa interagire con essi. Tale struttura, come accennato prima, prende il nome di Istanza (Instance) o Server, ed è costituita da strutture di memoria e processi che lavorano con essa.

Analizziamo nel dettaglio i singoli componenti, cominciando dalle strutture di memoria.


1. STRUTTURE DI MEMORIA

Il sistema leggerà il file di inizializzazione (parameter file) e richiederà al sistema operativo una certa quantità di RAM. All’interno di essa verranno create due tipi di strutture di memoria: la SGA e la PGA.

1.1. SGA

La SGA (System Global Area) possiamo immaginarla come un grosso contenitore all’interno del quale possiamo identificare alcune componenti:

  1. Redo Log Buffer Cache
  2. Database Buffer Cache
  3. Shared Pool
  4. Large Pool
  5. Java Pool
I componenti della System Global Area (SGA)

I componenti della System Global Area (SGA)

Tutti i singoli componenti possono essere dimensionati in maniera opportuna usando i parametri presenti nel file di inizializzazione, ad esempio nell'init.ora. La dimensione totale della SGA è data quindi dalla somma delle dimensioni dei singoli componenti.
A partire dalla versione 9 del database è possibile modificare le dimensioni dei singoli componenti (non tutti) in maniera dinamica, cioè senza dover chiudere il database, modificare il file di inizializzazione e riavviare il Db. Inoltre il Database ha una certa autonomia, nel senso che può automaticamente ridimensionare le singole aree senza interventi espliciti dall'esterno. Esiste tuttavia un parametro, chiamato SGA_MAX_SIZE che limita la dimensione massima dell’intera SGA, in modo che Oracle non chiederà mai al Sistema operativo una quantità di RAM superiore al valore impostato.



1.1.1. RL BC (Redo Log Buffer Cache)
La Redo Log Buffer Cache e’ quella parte della memoria in cui vengono registrati tutti i comandi di modifica che vengono lanciati sul database. Lo scopo principale è quello di garantire la consistenza del database, permettendo al sistema di ripristinare i dati in seguito a crash improvvisi.
Inoltre, se in qualche modo riesco a salvare su file tutti i comandi che sono transitati in quest’area, ad esempio a partire dalla data di creazione del database, potrei, utilizzando solo detti file, ricreare l’intero Db anche su un’ altro PC. Mi basterebbe infatti creare un DB vuoto, applicare il contenuto del file, ottenendo così una copia del DB.

1.1.2. DB BC (Data Base Buffer Cache)
Quest’area viene utilizzata per memorizzare tutti i dati elaborati dal sistema. Quindi, se viene lanciata una query, il sistema ad esempio accede ai file di pertinenza, prende i dati, li porta nella DB BC, quindi li elabora ed infine li restituisce all’utente che ne ha fatto richiesta.

1.1.3. Shared Pool Area
e’ un’area condivisa, all’interno della quale possiamo distinguere tre sotto aree:
    Data Dictionary (DD)
    Library Cache
    Strutture di controllo

Il Data Dictionary e’ il contenitore delle informazioni di sistema come gli utenti, le tabelle, le viste, i file, i permessi. Ad esempio, quando viene lanciata una query il sistema controlla se gli oggetti indicati nella query esistono, se l’utente ha i permessi per eseguire quell’operazione, etc. Per eseguire tutti questi controlli il sistema utilizza il Data Dictionary.

La Library Cache invece è costituita dalla:
    Shared Sql Area
    Pl/Sql procedure e package
    Locks ed altre strutture

La Shared Sql Area e’ un’area particolare che contiene le query lanciate sul db, ed il loro codice risultante (non il risultato). Facciamo un esempio per capire meglio. Supponiamo che l’utente Scott scriva una query. Il sistema prima di eseguirla deve fare una serie di operazioni: innanzi tutto deve controllare che la sintassi dell’istruzione sia corretta (Select e non Selct ad esempio). Quindi deve verificare che gli oggetti indicati nella query esistano. Indi deve controllare che l’utente che ha scritto la query abbia effettivamente i privilegi per accedere agli oggetti indicati. Ma non basta: per eseguire la query il sistema deve anche individuare le operazioni necessarie per ottenere il risultato nel minor tempo possibile. Deve quindi controllare se nella tabella indicata esiste ad esempio un indice e se conviene usarlo per accedere ai dati. Quindi il sistema esegue tutta una serie di passaggi per arrivare per ogni Q1 (query) ad elaborare il corrispondente R1 (istruzione Risultante). Sara’ l’esecuzione di R1 che fisicamente accedera’ ai dati restituendoli all’utente che ha lanciato la Q1.

Se dopo 5 minuti l’utente Scott rilancia la stessa identica query, il sistema potrebbe utilizzare l’R1 che ha gia’ calcolato, risparmiando un po’ di tempo che sì, e’ eseguo, ma moltiplicato per le centinaia di migliaia di utenti e/o query, riesce a consentire significativi incrementi di prestazioni.


Le altre aree, PL/SQL, Locks e le strutture di controllo, contengono i dati necessari al corretto funzionamento del sistema, memorizzando il codice delle procedure e funzioni registrate nel database, attivando i lock per impedire che due utenti modifichino in contemporanea lo stesso record etc.

1.1.4. Large Pool
E’ un’area di memoria opzionale. Puo’ essere configurata per fornire memoria aggiuntiva per alcune particolari operazioni sul database, come il backup od il restore. Se quest’area non è configurata, viene utilizzata la database buffer cache, cosa che potrebbe provocare contese con i dati degli utenti.

1.1.5. Java Pool
Anche questa e’ un’area opzionale, usata per eseguire al suo interno codice java



1.2. PGA Program Global Area
Questa e’ un’area di memoria che contiene informazioni su ogni singolo processo, e non è condivisa come la SGA, nel senso che ogni singolo processo di Oracle ha la sua area privata nella quale vengono memorizzate i valori delle variabili, informazioni sulle connessioni etc.

La Pga è a sua volta costituita da tre aree, su cui torneremo più avanti:
    lo stack space
    informazioni sulla sessione
    un’area di ordinamento






2. PROCESSI

I processi sono quei componenti che mettono in relazione tra di loro i vari elementi del server.
Ad esempio si occupano di caricare in memoria i dati presenti sui files, elaborano le istruzioni inviate dagli utenti, salvano su file le modifiche ai dati e così via. Ogni database ha un certo numero di processi sempre attivi, mentre altri possono essere attivati solo in particolari configurazioni. Per completezza elencheremo i principali, riservandoci di analizzare più nel dettaglio il loro comportamento nei capitoli successivi.
Alcuni processi, quelli che hanno una “n” nella loro sigla, possono essere lanciati più volte. Ad esempio il DBWn.

2.1. DBWn (Database Writer)
Questo processo viene spesso indicato come lo “scrittore del database”, nel senso che si occupa di memorizzare sui file di pertinenza le modifiche che vengono eseguite nel database. Ogni volta che viene modificato un dato, esso viene dapprima modificato in memoria, e poi la modifica viene salvata su file dal DBWn.
Il primo DBWn attivato è il DBW0, e posso attivarne altri 9 (da DBW1 a DBW9) utilizzando il parametro DB_WRITER_PROCESSES presente nel file di inizializzazione. Ovviamente, affinché si abbia un effettivo miglioramento prestazionale del database attivando altri DBWn, devo avere un hardware adeguato: nel caso specifico del DBWn conta sia il numero di CPU che il numero di dischi fissi, ma anche la distribuzione dei files sui vari dischi, altrimenti rischio di peggiorare le performance globali in quanto i vari DBWn possono intralciarsi a vicenda.

Quando viene eseguita una modifica ad un dato, la modifica viene inizialmente fatta in memoria, in un buffer adeguato. I buffers che sono stati modificati e non ancora salvati su file vengono chiamati Dirty Buffers.

Il DBWn scrive i Dirty Buffers sui DF (Data Files, trattati più avanti).
La scrittura avviene in blocco, per ridurre le contese di accesso a disco, e la quantità di blocchi scritti in unica operazione di I/O dipende dal SO.


Il DBWn si attiva quando:
    - Il processo server ha superato la soglia di ricerca senza aver trovato buffers liberi.
    - Si verifica un Checkpoint
    - Per timeout
    - Un tablespace viene modificato in Ready-only oppure Offline o in modalita' Backup
    - Dopo il drop o Truncate di una tabella

NB: L'attivazione del DBWn è indipendente dal Commit.

2.2. LGWR (Log Writer)
Questo processo si occupa di scrivere sugli RLF (Redo Log Files), in maniera circolare, i buffers della Redo Log Buffer Cache. In pratica si occupa essenzialmente di registrare su file tutti i comandi di modifica che sono transitati nella rispettiva area di memoria.

Si attiva quando:
    - Utente lancia il Commit
    - La redo log buffer cache è piena per 1/3
    - Il DBWn scrive i dirty buffer su disco
    - Per timeout ogni 3 secondi
    - La RL Buffer contiene 1 Mb di records.

2.3. CKPT (Checkpoint)
E' un evento che scarica tutti i dati modificati nella buffer cache sui dischi, ed esegue l'update dei CF e dei DF aggiornandone gli headers. Più spesso si verifica il Checkpoint, minore sarà il tempo necessario a fare il recovery.
Si attiva automaticamente dopo un Log Switch.

2.4. SMON (System Monitor)
Si occupa di fare il recovery dell'instanza dopo crash, e comunque controlla il Db all'avvio, appogiandosi al contenuto dei RLF.
Inoltre esegue la pulizia dei segmenti temporanei non piu' usati ed esegue il coalesce dei segmenti liberi nei tablespaces (a patto che il tablespace abbia un valore di default per PCTINCREASE diverso da zero).
Se in fase di recovery alcune transazioni vengono saltate, perchè i file corrispondenti sono off-line o perchè il Db non riesce comunque a leggerli, SMON esegue il recovery di tali transazioni quando i file tornano on-line.
SMON saltuariamente si attiva per eseguire controlli, ma può anche essere attivato da altri processi.

2.5. PMON (Process Monitor)
Esegue la pulizia di tutte le risorse usate dai processi nel caso essi terminino in maniera anomala.
Esegue quindi il Reset sulla tabella delle transazioni attive, e rimuove il Process Id dalla lista dei processi attivi.
Rilascia quindi tutte le risorse bloccate dall'utente, e tutti i suoi locks.
Si attiva periodicamente.

2.6. ARCn (Archiver)
Si occupa di eseguire copia dei RLF prima che vengano sovrascritti.
Ne posso avere fino a 10, da ARC0 fino ad ARC9.
E' il LGWR che lancia nuovi ARCn se il loro numero e' insufficiente a gestire il carico di lavoro.
ARCn viene attivato solo se Db e' in modalita' ARCHIVELOG, e se l'archiviazione automatica e' attiva, cioè LOG_ARCHIVE_START=TRUE.

2.7 RECO (Recoverer)
Viene usato per gestire le transazioni distribuite, e quindi se parametro DISTRIBUTED_TRANSACTIONS e' diverso da zero.
Se il parametro vale zero, RECO non viene avviato all'avvio dell'instanza.
Il suo scopo e' quindi gestire le transazioni "in-doubt", cioè quelle che coinvolgono più Db in contemporanea e che falliscono (problemi di rete o crash di server) prima di salvare le modifiche.

2.8. LCKn (Lock)
Sono usati in configurazione RAC, cioè quando più instanze montano lo stesso Db.
Posso averne 10 ( da LCK0 fino ad LCK9).

2.9. QMNn (Queue Monitor)
Usato da OAQ, Oracle Advanced Queuing, che esegue monitoraggio delle code messaggi.
Posso averne fino a 10 (da QMN0 a QMN9), in funzione del valore di AQ_TM_PROCESSES
OAQ fornisce in pratica un'infrastruttura per le applicazioni distribuite che comunicano in maniera asincrona usando messaggi.
I messaggi vengono salvati in code, e permettono ai server di processarli in "differita".

2.10. Dnnn (Dispatcher)
Si hanno in configurazione Shared Server, per gestire più utenti usando un numero limitato di processi server.
Posso crearne quanti ne voglio, ma almeno uno per protocollo.

2.11. Snnn (Shared Server)
Hanno stesse identiche funzionalita' dei processi server dedicati.
Per impostarne numero devo specificare due paramteri che ne limitano il range:
SHARED_SERVERS
MAX_SHARED_SERVERS

NB: Se un processo va in crash, l'intera instanza Oracle va in Crash, con eccezione dei processi SNP e QMN che non causano crash, ma vengono semplicemente rilanciati


2.12. Processi Server e processi utente
Un processo utente non è altro che un programma applicativo o un Tool Oracle (come sql*plus), che genera, quando viene lanciato, un processo utente.
Tale processo può quindi girare sul Server o su un qualunque Client.
Il processo server è invece il processo che prende le richieste dal processo Client, ed interagisce con l'instanza per soddisfare la richiesta. Esso pertanto si occupa di:
-eseguire il parsing e l'esecuzione dei comandi SQL.
-Accedere ai DF e portare i blocchi dati richiesti nella Buffer Cache
-restituire i dati al processo utente che ne ha fatto richiesta

In ambiente Client/Server è OracleNet che permette la comunicazione. Il processo utente cerca infatti di stabilire la connessione al Db usando il Driver di OracleNet appropriato, quindi OracleNet comunica col Server ed assegna un processo server per esaudire la richiesta del Client. OracleNet gestisce infatti un Listner sul server che sta in ascolto in attesa di richieste di connessione.

Gli utenti possono connettersi al Db usando sia una connessione dedicated che shared.
NB: per eseguire certe operazioni amministrative, è necessaria una connessione Dedicated.



3. FILE FISICI

I file fisici possono essere divisi in tre categorie principali:

DF: DATA FILES
RLF: REDO LOG FILES
CF: CONTROL FILES

I DF sono quelli che fisicamente contengono i dati del DB. Essi sono organizzati, logicamente in Tablespaces.

Gli RLF sono invece “la parte fisica” della Redo Log Buffer Cache, e memorizzano quindi tutti i comandi di modifica lanciati sul Db. Lo scopo è quello di limitare od eliminare del tutto la perdita di dati in caso di crash o failure del sistema.
Infatti, se io conservassi tutti gli RLF prodotti dal DB dal momento della sua creazione fino al momento della rottura del sistema, potrei usare un’altra macchina, ricreare un nuovo Db ed applicare su di esso tutti i comandi presenti sugli RLF generati durante la vita utile del primo DB.
In pratica è come se avessi fatto una sorta di backup del Db.
Ogni Db Oracle ha almeno due RLF usati in maniera ciclica.

Il CF è invece un file di controllo che contiene informazioni sul Db come il nome, su tutti i file che lo costituiscono, sulla loro dimensione e posizione, e su alcuni eventi particolari del Db stesso.
Ogni Db Oracle ha un CF che può essere “mirrorato”, operazione caldamente consigliata.

Un database Oracle è pertanto formato dall’insieme dei files fisici appena visti.

I vari oggetti del database, come le tabelle, le viste, gli utenti etc., sono memorizzati all’interno dei DF. La gestione dello spazio viene organizzato mediante delle strutture particolari, che adesso analizzeremo nel dettaglio.

La figura mostra la relazione tra blocchi, extent, segment (cioè insieme di extent appartenenti allo stesso oggetto), datafile, tablespace e database.

La figura mostra la relazione tra blocchi, extent, segment (cioè insieme di extent appartenenti allo stesso oggetto), datafile, tablespace e database.


Al livello più alto ho i TABLESPACEs.
Essi non sono altro che dei contenitori logici, riconosciuti solo da Oracle e non dal sistema operativo, fisicamente formati da uno o più DF.
Ogni Db Oracle ha almeno un tablespace: SYSTEM, il quale fisicamente è costituito da uno o più DF. Nel nostro database di esempio ho un file chiamato SYSTEM01.dbf all’interno della directory c:oracleoradataORCL.

Quando permetto ad un utente di creare degli oggetti, come una tabella, devo specificare su quale tablespace deve essere memorizzata. L’oggetto sarà quindi fisicamente memorizzato in uno dei file che costituiscono quel tablespace. In questo modo, se ad un certo punto lo spazio all’interno del tablespace finisce, posso intervenire aggiungendo un altro file al tablespace, file che posso creare in qualunque parte del file system, anche su un altro disco, oppure posso aumentare la dimensione di uno dei file esistenti, sempre che sul disco ci sia lo spazio necessario. Il vantaggio è che per l’utente queste modifiche sono trasparenti: l’utente sa solamente che i suoi dati sono memorizzati in un dato tablespace, e non su quale file specifico risiedono.

Ogni singolo DF del database viene, all’atto della creazione, suddiviso in blocchi (BLOCKs).
Il blocco è pertanto l’unità minima di allocazione, e viene definito come un multiplo intero della dimensione del blocco del SO.
La dimensione del blocco del SO viene definita all’atto della creazione di un file system. Se ad esempio la dimensione del blocco del file system è 4k, posso definire la dimensione del blocco Oracle pari a 4k o 8k o 12k o 16k etc.
Il parametro che ne indica la dimensione, e che devo specificare all’atto della creazione del database è: DB_BLOCK_SIZE.

Il dimensionamento di questo parametro è molto importante, ed legato al tipo di dati che devo memorizzare nel database. Tale dimensione, una volta fissata, non può più essere modificata. Posso al più creare un nuovo tablespace aventi blocchi di dimensione diversa, ma non è un operazione banalissima in quanto devo prevedere delle modifiche all’istanza per permettere l’utilizzo di tablespaces con blocchi di dimensioni diverse.


Un insieme di blocchi contigui costituiscono l’EXTENT, mentre un insieme di Extent (anche non contigui) costituiscono invece un SEGMENT che coincide, in pratica, con un oggetto.
Ad esempio, quando viene creata una tabella, viene allocato in un opportuno tablespace un SEGMENT di una certa dimensione, costituito quindi da una serie di Extent distribuiti, in funzione di certe regole, sui file fisici che costituiscono quel tablespace. Ogni extent sarà costituito da una serie di blocchi contigui.

I vari SEGMENT, che quindi coincidono con gli oggetti memorizzati nel database, possono avere caratteristiche diverse: possono essere costituiti da un certo numero di EXTENT, ognuno dei quali può avere una dimensione differente. Esistono delle regole interne che stabiliscono il numero minimo di extent e la loro dimensione, in funzione del tipo di oggetto.
I segment, e quindi gli oggetti, possono essere dei seguenti tipi:

    TABLE
    TABLE PARTITION
    CLUSTER
    NESTED TABLE
    INDEX
    IOT
    INDEX PARTITION
    TEMPORARY
    LOB
    UNDO
    BOOTSTRAP

Nei successivi capitoli analizzeremo nel dettaglio le varie tipologie.

Vi invitiamo ad inviarci commenti, eventuali segnalazioni di errore e quant'altro.



Questo documento non è un documento ufficiale della Oracle Corporation. Oracle detiene tutti i diritti sulla propria documentazione. Alcuni termini usati sono trademarks registrati. In caso di dubbi o incertezze consultate la documentazione ufficiale di Oracle o contattate il Customer Support di Oracle.
<< Indice Capitolo 2 >>
Commenti (2)2005-02-09

08/11/2009 - andrea scrive:
Ottimo veramente spiegato in modo semplice.
12/09/2009 - diego scrive:
molto interessante è buono sapere queste cose quando si progetta con oracle. Un dubbio : Nel paragrafo 3 . File Fisici viene detto che i DF sono oraganizzati in Tablespaces mentre piu avanti viene detto che i tablespaces sono fisicamente formati da 1 o piu DF.