Overview Architettura Oracle Database 10g
Fig. 1 : Architettura Database Oracle
Un Oracle database server è costituito da due strutture : database e istanza.
Database server
Per database si indicano tutti i file fisici in cui vengono memorizzati i dati. Ha il compito di controllare un’enorme quantità di dati in un ambiente multiutente, in modo da permettere l’accesso contemporaneo agli stessi dati da parte di più utenti provvedendo anche a fornire soluzioni efficienti per il recovery.
Il database è formato da strutture di memorizzazione, logiche e fisiche. Le prime vengono utilizzate per immagazzinare, attraverso Tablespace, Block, Extent e Segment, e gestire (tabelle, indici, etc.) i dati, le seconde invece contengono le strutture fisiche (data file, redo log file, control file).
I servizi offerti dalle strutture logiche del server sono indipendenti dalle strutture fisiche che le contengono, perché le strutture logiche possono essere progettate nello stesso modo, indipendentemente dall'hardware e dal sistema operativo impiegati.
Istanza
Per istanza si intendono l'insieme delle aree di memoria (System Global Area) e dei processi di background necessari ad accedere ai dati. Tali aree sono allocate nell'istanza Oracle ogni volta che viene fatta partire e rilasciate quando l’istanza viene terminata. Le aree di memoria di un server Oracle sono usate per contenere i dati, le informazioni del dizionario dei dati, i comandi SQL, il codice PL/SQL ecc.
Ogni database deve obbligatoriamente fare riferimento almeno ad un'istanza.
Le due maggiori strutture di memoria sono la System Global Area (SGA) e la Program Global Area (PGA).
Tablespace
Un tablespace è una suddivisione logica del database, costituito fisicamente da uno o più files chiamati DATA-FILES (DF). Tutti gli oggetti del database vengono logicamente memorizzati in tablespace. Ogni database ha almeno un tablespace, il tablespace SYSTEM, che contiene il data dictionary. Altri tablespace possono essere creati e usati per differenti applicazioni o compiti o per semplificare e migliorare l’efficienza. Ad esempio si può creare un tablespace USERS di utilizzo generale e un tablespace UNDO per i segmenti di rollback. Un tablespace può appartenere ad un solo database.
SGA e PGA
Componenti della SGA
La SGA è l'area di memoria assegnata all'avvio da Oracle, contiene le strutture della memoria per memorizzare i dati e controllare le informazioni. Gli utenti che si connetteranno al database condividaranno le informazioni nella stessa SGA. Le informazioni memorizzate nella System Global Area sono divise in diversi tipi di buffer:
• Database Buffer
• Redo Log Buffer
• Shared Pool
• Large Pool
• Java Pool
PGA (Program Global Area)
La PGA è un'area di memoria che contiene i dati di un singolo processo utente ed è allocata da Oracle quando un utente si collega al database e una sessione viene creata.
Processi
Processi di background e File
Il processo DBWn (Database Writer) è responsabile della scrittura dai blocchi del database al disco (data file) e modifica la posizione del checkpoint.
Il processo CKPT (Checkpoint) è responsabile della scrittura delle informazioni sulla posizione del checkpoint dal buffer cache aggiornando i control file e i data file, riducendo così il tempo necessario per il recovery dell’istanza (si può verificare automaticamente quando il Redo Log online e’ pieno – Log Switch).
Il processo LGWR (Log Writer) scrive i redo log buffer data nei redo log file e il processo ARCn (Archiver) copia i redo log file nell’archivio del Log File.
Processo Database Writer (DBWn)
Scrive nei Data file il contenuto del dirty buffer e avanza il checkpoint.
Il DBWn agisce quando :
• Scatta il Checkpoint
• I ‘Dirty buffer’ sono pieni
• Non ci sono più Buffer liberi
• Timeout di una transazione
• RAC effettua delle richieste
• Presenza di Tablespace OFFLINE
• Presenza di Tablespace READ ONLY
• DROP OR TRUNCATE
• Un Tablespace viene posto in BACKUP MODE
Fig 2 : Processo Database Writer
Il DBWn non dipende dal COMMIT
Il processo del server registra i cambiamenti e i data block nel buffer di cache del database.
DBWn scrive i buffer rovinati dal database buffer cache ai data file e assicura un sufficiente numero di buffer liberi che sono disponibili al database buffer cache. I processi del server effettuano cambiamenti solo nel buffer cache del database aumentando così le performance del database.
Il DBWn posticipa la scrittura ai data file fino a uno degli eventi elencati. Se ognuno di questi eventi si verifica molto frequentemente, DBWn deve scrivere tanti piccoli batch. Un buffer cache, anche molto piccolo, può provocare una scrittura extra per il DBWn.
Processo Checkpoint (CKPT)
Il checkpoint è un evento del database durante il quale viene salvato, sui file di pertinenza, tutto quello che c’è in memoria. Questa operazione è utilissima, in quanto dopo un crash, Oracle esegue il recovery automatico partendo dall’ultimo checkpoint effettuato (checkpoint position). Quindi più spesso si verifica l’evento checkpoint e minore sarà il tempo necessario per eseguire il recovery. Il checkpoint consuma risorse, pertanto se si verifica troppo spesso, il database perderà in performance. Di solito viene effettuato almeno ogni 3 secondi. L’obiettivo di un checkpoint è di identificare la posizione nel Redo log file dove l’istanza di recovery è iniziata (chiamata “checkpoint position”).
In caso di uno switch del log, il processo di CKPT scrive anche le informazioni di questo checkpoint nell’intestazione dei data file.
Le funzionalità dei Checkpoint sono:
- Controllare che i data block modificati nella memoria vengano scritti nel disco regolarmente, così che i dati non vengano persi in caso di un guasto, provocato sia da parte del sistema sia da parte del database.
- Ridurre il tempo di richiesta per il recovery di un’istanza.
- Controllare che tutti i dati salvati vengano scritti nei data file durante lo spegnimento.
Le informazioni dei checkpoint scritte dal processo di CKPT includono il checkpoint position, il cambiamento del numero del sistema e la posizione nel redo log file dove comincia il recovery.
Il CKPT process non scrive data block nel disco o nei redo block ma nell’online redo log file.
Fig 3 : Processo di Checkpoint
Archiver (ARCn)
L’ARCn è un processo opzionale che gira in background. E’ fondamentale per recuperare un db dopo la perdita di un disco. Come i redo log file vengono popolati online, cosi l’istanza di Oracle inizia a scrivere nel successivo redo log file. Si definisce “switch di un log “ il processo che permette di passare da un redo log file ad un’altro.
Il processo di ARCn inizializza la copia del file log group riempito a ogni switch del log. Esso archivia automaticamente il redo log file che è online prima che il log possa essere riusato, così che tutti i cambiamenti fatti nel db vengono mantenuti. Questo abilita il recupero del database dal punto di fallimento anche se un disco è stato danneggiato.
Una delle decisioni importanti che un DBA deve prendere è configurare il database per operare nella modalità ARCHIVELOG o NOARCHIVELOG.
• NOARCHIVELOG, i redo log file online vengono sovrascritti ogni volta che avviene un cambiamento del log
• ARCHIVELOG, i gruppi inattivi dei redo log file online pieni devono essere archiviati prima che essi possano essere riusati.
Anche se c’è un piccola penalità nelle performance per la modalità ARCHIVELOG, la decisione di archiviare è di solito motivata dalle scelte di business. ARCHIVELOG è molto facile da configurare.
Fig 3 : Processo Archiver
Checkpoint e Redo
Checkpoint e Redo sono operazioni legate strettamente tra loro e i processi che eseguono sono a loro volta coordinati tra di loro.
Gli obiettivi sono:
per il Checkpoint:
• Trasferire i dati modificati dalla System Global Area (SGA) al disco, memorizzare i Data Block che sono stati trasferiti nei dischi e richiedere il redo per il recovery.
• Creare buffer disponibili per i data block. In questo caso i buffer vengono segnati come liberi.
• Controllare il tempo medio di recupero (MTTR – Mean Time To Recovery). Il numero dei buffer cambiati ma non ancora copiati nel disco determina il tempo di recupero dell’istanza.
per il Redo:
• Fornire i dati non committati sul disco per le operazioni di rollback
• Fornire i sorgenti per completare il recovery. Se si sta usando la modalità ARCHIVELOG, si terrà traccia del contenuto dei redo log file (RLF), così che si attiva il processo ARCn che esegue una copia degli RLF prima che vengano sovrascritti.
Lo stato di default del database è NOARCHIVELOG.
Checkpoint Architecture
L’architettura checkpoint fornisce:
- Checkpoint position: è la posizione iniziale nei redo log file prima del recovery
- Checkpoint target: è la posizione calcolata nei redo log file, dove potrebbe esserci un checkpoint position
- Una stima media dei tempi di recupero (MTTR)
- Un incremento delle prestazioni dei checkpoint attraverso un metodo di alte performance, per controllare se i dati sono stati scritti correttamente nel disco, ed è recuperabile in caso di un guasto di un’istanza.
- Un Checkpoint Full quando è richiesto
Esistono due tipi di checkpoint: Full e Incrementale.
I checkpoint full sono effettuati solo attraverso comandi specifici, per esempio durante lo shutdown, eccetto per lo SHUTDOWN ABORT o lo STARTUP FORCE. Quando un checkpoint full viene effettuato, tutti blocchi rovinati (dirty block) nella buffer cache vengono scritti nei data file.
Un checkpoint normale, o checkpoint incrementale, si verifica quando i blocchi, che erano sporchi da tantissimo tempo, vengono scritti nei data file. Dopo che un blocco sporco è stato scritto nel data file, i redo record delle operazioni che hanno cambiato il blocco non sono più richiesti per l’istanza di recovery.
Il checkpoint Position o Redo Block Address (RBA) è presente nel redo log file per indicare che nessuno dei record di redo venga scritto prima che l’RBA vengano utilizzati ancora dall’istanza di recovery. Gli algoritmi interni determinano come aumentare rapidamente il checkpoint position per associare o avanzare il checkpoint target.
Checkpoint Incrementale
A causa del DB server, che usa uno schema di scrittura di logging anticipata, la modifica del redo progettata deve essere generata prima che un buffer possa essere modificato. Questo redo viene memorizzato in un buffer log, il quale viene periodicamente svuotato dal processo LGWR nel redo log file.
L’insieme dei redo log file online per una particolare istanza viene chiamata redo thread e funziona con un buffer ciclico.
Il redo è indicizzato dal Redo Block Address (RBA). L’RBA checkpoint è l’indirizzo dal quale l’applicazione inizia a riprendere il redo nell’evento di un crash dell’istanza. Questo indirizzo è chiamato anche checkpoint position.
Se c’è una coda di checkpoint per un’intera istanza, ogni successiva scrive dall’inizio della coda del checkpoint che potrebbe teoricamente avanzare la posizione del checkpoint.
Questa struttura di code di checkpoint abilita un meccanismo di checkpointing efficiente chiamata checkpoint incrementale. Si possono avere molti parametri che possono gestire il checkpoint incrementale, il parametro principale per la configurazione è il FAST_START_MTTR_TARGET.
Questo parametro è una valutazione media del periodo di recupero della istanza durante un crash. Questo periodo rappresenta la fase di roll-forward (scorrimento) e dipende principalmente dal tempo che si impiega a leggere e processare il redo log, così come il tempo che si impiega a leggere e a scrivere nei blocchi di dati che devono essere recuperati.
Fig 4 : Checkpoint incrementale
Redo Architecture
Redo è stato creato per avere impatti minimi sulle performance.
Redo logging è una caratteristica del DB Oracle. Redo è progettato in relazione ai checkpoint per fornire un meccanismo performante per proteggere il database dalla corruzione o dalla perdita dei dati da un fallimento di un’istanza. I checkpoint memorizzano lo starting point nei log di redo per il recovery dell’istanza, i record di redo contengono le modifiche necessarie per essere applicate ai data file e per ricostruire le informazioni dall’ultima transazione committata prima del failure dell’istanza.
I Redo Record sono piccoli vettori che contengo le righe che sono cambiate e non l’intero blocco di dati. I processi del server effettuano la scrittura “memory to memory” di questi record. LGWR scrive blocchi pieni se è possibile dal buffer di log (memory) al file di log (disk) per fare spazio a più record di redo nel buffer log. Quando la modalità ARCHIVELOG è attivata, ad ogni variazione del log, l’Archiver Process (ARCn) copierà i redo log file in un unico archivio di file di log.
Gli Archiver Process effettuano copie disco a disco e scrivono una serie di tre tipi di processi. Se gli Archiver Process non possono pulire un file di log abbastanza velocemente, LGWR attende fino a quando l’archiver non avrà completato. LGWR non può sovrascrivere un log file fino a quando non è stato archiviato. Quando il LGWR non può pulire lo spazio per il log buffer necessario ai processi del server, che scrivono i record di redo, l’utente in sessione è costretto a rimanere in attesa.
Questa situazione si può verificare quando il LGWR è in attesa che o processo archiver, o un log switch o un checkpoint finisca.
Redo Log Buffer Content
I processi del Server Oracle copiano le informazioni di redo dallo spazio in memoria dell’utente al buffer di redo per ogni statement DML o DDL. Queste informazioni contengono il necessario per ricostruire o modificare i cambiamenti nel DB da operazioni DML o DDL, inoltre includono i cambiamenti a oggetti, righe, tabelle, indici e undo segments. I record di redo vengono usati dal DB recovery e occupano spazi continui nel buffer di log.
Il redo log buffer è un buffer ciclico. I processi del server possono copiare nuovi dati sopra gli altri nel redo log buffer che sono stati già scritti nel disco.
Il processo LGWR di norma copia nel disco tutte le redo entry che sono state inserite all’interno del buffer scrivendole abbastanza velocemente per assicurarsi che lo spazio sia sempre disponibile nel buffer per una nuova entry. Il processo LGWR scrive il redo log buffer sull’attuale redo log file nel disco.
Redo Log Files e LogWriter
I File di redo memorizzano i cambiamenti nel DB come conseguenza di una transazione o azione interna del Server Oracle. I redo log file proteggono il db dalla perdita d’integrità a causa di fallimento del sistema, causato da guasti all’alimentazione, disk failure ecc. I redo log file dovrebbero accertarsi che le informazioni memorizzate non vengano perdute durante un disk failure.
Il redo log consiste in gruppi di redo log file. Un gruppo consiste in un redo log file e le sue copie. Ogni copia identica viene chiamata per essere membro del gruppo e ogni gruppo viene identificato da un membro.
Il processo di LogWriter (LGWR) scrive i redo record dal redo log buffer a tutti i membri di un redo log group fino a che il file è pieno o un’operazione di cambio del log viene richiesta. Così LogWriter cambia e scrive nel file del prossimo gruppo. I redo log group vengono utilizzati ciclicamente.
I redo log file dovrebbero risiedere in dischi differenti. L’Archiver Process legge i log file members nella modalità round robin (un blocco alla volta) mentre sta copiando, spargendosi così anche attraverso l’I/O dei dischi.
Fig 4 : Redo log file e LogWriter
Riferimenti
Oracle® Database Performance Tuning Guide
Oracle Backup and Recovery
Redo Byte Address (RBA)
Tuning the Log Buffer Size
|
