Kosmous beyond the clouds: Sviluppo, Formazione e Consulenza Informatica

Oracle DBA 9i - Cap. 5

I Redo Log Files (RLF) sono la controparte fisica della Redo Log Buffer Cache, l’area di memoria all’interno della SGA che registra tutti i comandi di modifica eseguiti sul database.
Man mano che gli utenti eseguono modifiche al database, Oracle registra i comandi nella Redo Log Buffer Cache, il cui contenuto viene salvato negli RLF dal processo LGWn che si attiva quando:

  • Per timeout ogni 3 secondi.
  • Un utente lancia il Commit.
  • La Redo Log Buffer Cache è piena per 1/3.
  • La Redo Log Buffer Cache contiene 1 Mb di records (escluso records inseriti o cancellati).
  • Il DBWn scrive i dirty buffer su disco
Lo scopo principale degli RLF è quello di garantire la coerenza dei dati anche in seguito ad un crash di sistema. In un determinato istante potrei infatti avere:

  • transazioni in corso, le cui modifiche sono già state applicate ai dati.
  • transazioni in corso, le cui modifiche NON sono ancora state eseguite.
  • transazioni completate, le cui modifiche sono già state applicate ai dati.
  • transazioni completate, le cui modifiche NON sono ancora state eseguite.
Se si verifica un crash, la logica impone che il database sia riportato all’ultimo stato coerente possibile. Qualche attimo prima del crash avrei potuto suddividere le varie transazioni in:
  • complete, se l’utente ha eseguito il commit;
  • incomplete, se l’utente non ha eseguito il commit;
Al riavvio del database, Oracle entra in modalità recovery, durante la quale prova a riportare il database in uno stato coerente, e cioè:
  • Tutte le transazioni committate al momento del crash devono essere ripristinate.
  • Tutte le transazioni che al momento del crash non erano committate devono essere annullate.
Quando una transazione viene committata, verrà assegnato un SCN (System Change Number, vedi capitoli successivi) ai redo records; l’SCN identifica in maniera univoca le transazioni.

L’operazione di Recovery viene svolta dal processo SMON che, avvalendosi del contenuto degli RLF (chiamato REDO RECORDS o anche REDO ENTRY), riesce ad individuare quali comandi devono essere eseguiti per riportare il database in uno stato coerente.

Ogni REDO RECORDS è costituito da un insieme di CHANGE VECTORS, ciascuno dei quali descrive la modifica ad un singolo blocco del Database.

La gestione degli RLF avviene tramite Gruppi, ognuno dei quali può avere uno o più membri.
I membri di un gruppo non sono altro che dei mirror (si parla di MULTIPLEXING), contenenti le stesse informazioni e scritti in contemporanea.
Pertanto è consigliabile tenere i membri dello stesso gruppo su dischi diversi per non creare colli di bottiglia nelle operazioni di I/O.

I gruppi vengono utilizzati ciclicamente: LGWR scrive sul primo, quando esso è pieno esegue uno switch e continua a scrivere sul secondo, e così via. Quando anche l’ultimo gruppo è pieno, LGWR ritorna sul primo, sovrascrivendone per intero il contenuto.

Oracle necessita di almeno due gruppi di RLF per funzionare.

Se si vuole conservare il contenuto degli RLF, si deve modificare lo stato del database da NOARCHIVELOG (che è il default) ad ARCHIVELOG; in questo modo viene attivato il processo ARCn che esegue una copia degli RLF prima che vengano sovrascritti: vedremo nei capitoli successivi cosa implica questa modifica e come viene fatta.

Se ho il RAC, ciascuna istanza avrà un “online redo thread”, cioè ciascun LGWR scriverà sullo stesso file, ed Oracle dovrà tenere traccia anche dell’istanza da cui proviene la modifica. Se non ho il RAC, ci sarà un solo thread avente numero 1.

Il range dei numeri assegnati ai gruppi varia da 1 a MAXLOGFILES, mentre il numero massimo di membri che un gruppo può avere è limitato dal parametro MAXLOGMEMBERS.

Per sapere quali sono i gruppi di Redo Log presenti posso eseguire la query:
SQL> select * from V$LOG; 
                                                          
GROUP# THREAD#  SEQUENCE#      BYTES MEMBERS ARC STATUS   
------ ------- ---------- ---------- ------- --- ---------
     1       1        199   10485760       1 NO  INACTIVE 
     2       1        200   10485760       1 NO  CURRENT  
     3       1        198   10485760       1 NO  INACTIVE 

FIRST_CHANGE# 
------------- 
       428437 
       451848 
       406444 
Dove:
    GROUP# indica il gruppo;
    THREAD# indica il Thread, e vale sempre 1 se non ho il RAC.
    SEQUENCE# indica il numero di sequence del gruppo. Ogni volta che il sistema completa un gruppo e passa al successivo, il numero di sequence viene aumentato di una unità. Il valore 200, che è il più alto del nostro esempio, indica che dalla creazione del database il sistema ha cambiato gruppo di Log per ben 200 volte, ed adesso sta scrivendo sul gruppo numero 2.
    MEMBERS indica quanti sono i membri di quel gruppo.
    ARCHIVED indica se quel gruppo è stato già archiviato (da ARCn)
    STATUS indica lo stato del contenuto del gruppo che può essere:
      CURRENT: è file su cui LGWR sta scrivendo.
      ACTIVE: Il gruppo è necessario per eseguire il recovery dell’istanza (all’interno vi sono transazioni attive)
      INACTIVE: il contenuto del gruppo non è necessario per il recovery
    FIRST_CHANGE# indica l’SCN più basso presente nel gruppo.

Se volessi sapere nel dettaglio quali sono i files che costituiscono i vari gruppi, eseguo la query:

SQL> select * from V$LOGFILE;                                  
                                                               
    GROUP# STATUS  TYPE    MEMBER                              
---------- ------- ------- ----------------------------------- 
         1 STALE   ONLINE  C:ORACLEORADATAORCLREDO01.LOG   
         2         ONLINE  C:ORACLEORADATAORCLREDO02.LOG   
         3 STALE   ONLINE  C:ORACLEORADATAORCLREDO03.LOG   
Infine, per avere un’idea dello storico delle sequence, posso usare la V$LOG_HISTORY:

SQL> select * from V$LOG_HISTORY;
RECID STAMP THREAD# SEQUENCE# FIRST_CH FIRST_TIM NEXT_CH ----- --------- ------- --------- ------- --------- -------- 188 548082862 1 188 359269 20-GEN-04 360124 189 548082872 1 189 360124 20-GEN-04 360740 190 548082885 1 190 360740 20-GEN-04 361943 191 548082901 1 191 361943 20-GEN-04 364601
Dalla quale estraggo:
    La data in cui LGWR ha cambiato gruppo di log. Gli SCN presenti in ciascun gruppo (il più basso ed il più alto valore).
Queste informazioni sono molto utili, soprattutto in modalità ARCHIVELOG, perché permettono di avere un quadro molto preciso dei file necessari in caso di recovery del database.
Inoltre mi danno un’idea di massima sul corretto dimensionamento dei gruppi di Log, sia come numero di gruppi presenti che come dimensionamento dei singoli membri.

5.1 Log Switch

Il Log Switch è l’evento del database in cui LGWR passa da un gruppo di RLF ad un’altro.
Tale evento avviene generalmente in automatico quando un gruppo è pieno, ma può anche essere forzato. Il comando per forzarlo è:
SQL> ALTER SYSTEM SWITCH LOGFILE;
Dopo aver forzato il Log Switch posso dare un’occhiata alle viste V$LOG e V$LOG_HISTORY per vedere i cambiamenti.
Tra i casi in cui è necessario forzare lo switch, annoveriamo quando è necessario eliminare un gruppo od uno dei suoi membri, ed il sistema lo impedisce perché il gruppo è in uso, oppure quando il sistema si blocca perché non riesce a scrivere su un gruppo di RLF perché i suoi membri sono danneggiati.

Quando si verifica un Log Switch, si verifica anche il CHECKPOINT che posso forzare con:
SQL> ALTER SYSTEM CHECKPOINT;
Il checkpoint è un evento del database durante il quale viene salvato, sui files 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.
Quindi più spesso si verifica l’evento Checkpoint e minore sarà il tempo necessario per eseguire il recovery. Il rovescio della medaglia è che il checkpoint consuma risorse, pertanto se si verifica troppo spesso il database perderà in performance.

Nelle versioni precedenti il Checkpoint poteva essere controllato con i parametri:

FAST_START_IO_TARGET (non più supportato)

LOG_CHECKPOINT_TIMEOUT (non più supportato)

Mentre adesso si usa il FAST_START_MTTR_TARGET il cui valore, espresso in secondi, indica il tempo massimo (desiderato) di ripristino del sistema in caso di recovery: sarà Oracle a decidere qual è il momento migliore per effettuare il checkpoint, in funzione del carico di lavoro, per garantire che una eventuale operazione di recovery venga eseguita enro il tempo specificato.

Quando si verifica un Log Switch (e quindi anche il relativo Checkpoint), viene inserito un messaggio nel file ALERT.Log (in genere contenuto in C:oracleadminORCLbdump).
Se volessi memorizzare nell’ALERT.Log anche i checkpoints che avvengono separatamente dai Log Switch, devo impostare a TRUE il parametro LOG_CHECKPOINTS_TO_ALERT.




5.2 Gestione dei Gruppi e dei Membri

Se un intero gruppo di RLF non è disponibile, l’Instanza viene chiusa ed è necessario recovery. Invece se almeno un membro è disponibile, l’attività del database continua (e viene inserita l’informazione nell’Alert.log). Per questo è buona norma avere almeno due membri per ogni gruppo, ovviamente su dischi diversi per non peggiorare le performance.

Per aggiungere nuovo gruppo posso usare indifferentemente una delle tre sintassi di seguito riportate:

SQL> ALTER DATABASE ADD LOGFILE
     GROUP 3 ('C:ORACLEORADATAORCLREDO03.LOG',
              'C:ORACLEORADATAORCLREDO03b.LOG') SIZE 10M;
SQL> ALTER DATABASE ADD LOGFILE
     ('C:ORACLEORADATAORCLREDO03.LOG'
      'C:ORACLEORADATAORCLREDO03b.LOG') SIZE 10M;
SQL> ALTER DATABASE ADD LOGFILE
     'C:ORACLEORADATAORCLREDO03.LOG' REUSE;
Il primo esempio aggiunge esplicitamente il gruppo 3 (non deve già esistere) costituito dai due membri indicati.

Nel secondo esempio non viene specificato il numero del gruppo, numero che verrà scelto da Oracle (il primo disponibile). Questa metodologia non è consigliata, in quanto per chiarezza è sempre bene che il nome del file contenga un riferimento al gruppo cui appartiene.

Nel terzo caso, si sta indicando ad oracle di creare un gruppo costituito da un solo membro. La clausola REUSE indica che il file già esiste, e pertanto non devo specificarne la dimensione.

Posso anche aggiungere con unico comando più di un gruppo, separando l’elenco dei gruppi con la virgola.


Per aggiungere un membro ad un gruppo che già esiste, posso usare:
SQL> ALTER DATABASE ADD LOGFILE MEMBER
     'C:ORACLEORADATAORCLREDO04b.LOG' TO GROUP 4;
oppure:
SQL> ALTER DATABASE ADD LOGFILE MEMBER
     'C:ORACLEORADATAORCLREDO05c.LOG'TO
        ('C:ORACLEORADATAORCLREDO05.LOG',
         'C:ORACLEORADATAORCLREDO05b.LOG');

5.3 Spostamento degli RLF

Se si vuole fisicamente spostare un RLF, ad esempio da un disco ad un’altro, occorre eseguire una serie di passaggi:

  1. SHUTDOWN del database.
  2. Spostamento del file da SO
  3. STARTUP NOMOUNT
  4. ALTER DATABASE RENAME FILE ‘vecchio_file’ TO ‘nuovo_file’;
  5. ALTER DATABASE OPEN

5.4 Cancellazione degli RLF

La cancellazione di un RLF è possibile solo se il gruppo è nello stato di INACTIVE; se così non fosse devo forzare un LOG SWITCH.

Per cancellare un intero gruppo uso:
SQL> ALTER DATABASE DROP LOGFILE GROUP 4;
Quindi completo l’operazione cancellando i files relativi da SO.
Per cancellare un solo membro uso invece:
SQL> ALTER DATABASE DROP LOGFILE MEMBER
     'C:ORACLEORADATAORCLREDO05c.LOG’;
Quindi procedo con la cancellazione del file da SO.

Attenzione: se sono in modalità ARCHIVELOG Oracle mi impedisce la cancellazione anche dei singoli membri se il gruppo di RLF non è stato ancora archiviato.

5.5 Clear degli RLF

Se si rovina il contenuto di un membro o di un intero gruppo, posso cancellarlo e ricrearlo oppure, più semplicemente, posso usare:
SQL> ALTER DATABASE CLEAR [UNARCHIVED] LOGFILE GROUP 3;
La clausola UNARCHIVED serve per poter eseguire il comando anche se il gruppo non è stato ancora archiviato. Attenzione perché, in questo caso avrò un buco negli ARLF che mi potrebbe pregiudicare un eventuale recovery.
Il vantaggio di questo comando è di poterlo usare anche su database aventi solo due gruppi; ricordo infatti che un database Oracle deve sempre avere almeno due gruppi di RLF, e si consiglia caldamente di averne almeno tre.




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.
<< Capitolo 4 Capitolo 6 >>
Commenti (4)2005-04-04

15/11/2017 - cialis_canada scrive:
Hello! cialis canada , generic cialis online , buy cheap viagra , buy cheap viagra , generic viagra ,
03/11/2017 - cheap scrive:
Hello! buy cheap viagra , cialis for sale , order cialis online , buy cialis , generic viagra ,
20/10/2017 - cialis_online scrive:
Hello! loans for bad credit , cialis cheap , cialis online , cheap viagra , viagra cheap ,
14/10/2017 - viagra_online scrive:
Hello! generic cialis , cialis canada , viagra online , viagra online , cialis coupon ,