Redo Log Files

I file Redo Log sono file che contengono una copia delle transazioni eseguita sul database e quindi registra tutte le modifiche apportate ai dati.

Dopo aver avviato l'Istanza Oracle entriamo in sqlplus come SYS.
Per vedere le colonne di una tabella usare il comando desc <nome tabella>.
SQL> desc v$datafile;

Per visualizzare lo stato dei redlog file:
SQL> select GROUP#, STATUS , MEMBERS,ARCHIVED from V$LOG;
GROUP#         STATUS              MEMBERS      ARC
---------- --------------------------------------------------------------
         1             INACTIVE                 2                 YES
         2            CURRENT                 2                 NO
         3            INACTIVE                  2                YES

Per visualizzare a quale gruppo appartiene il file redo:
SQL> select GROUP# , STATUS, MEMBER from  V$LOGFILE;

Vediamo il numero della ultima transazione, che è letto dinamicamente nella RAM:
SQL> select  CURRENT_SCN from V$DATABASE;
CURRENT_SCN
------------------------
    1040489

Creo una tabella e la popolo:
SQL> conn hr/oracle
Connected.
SQL> create table X (call number);
Table created.
SQL> insert into X values (22);
SQL> select count(*) from X;
  COUNT(*)
--------------------
        38

SQL>select RECOVERY_ESTIMATED_IOS  from V$INSTANCE_RECOVERY;
RECOVERY_ESTIMATED_IOS
---------------------------------------
                    90

SQL> conn hr/oracle
Connected.
SQL> commit;
Commit complete.

Con il comando commit il processo LGWR scrive le modifiche presenti nel Redo Log Buffer Cache nei Redo Log online e risponde all'user "commit eseguita".

Vediamo cosa è successo ai redo log:
SQL> select GROUP#, STATUS , MEMBERS,ARCHIVED from V$LOG;
    GROUP#           STATUS          MEMBERS ARC
--------------------------------------------------------- ----------
         1             INACTIVE              2            YES
         2             ACTIVE                  2            YES
         3             CURRENT              2            NO

Il 1° blocco non è usato perché contiene blocchi sporchi che fanno riferimento a transazioni già scritte dal Dbwr sui data files.
Il 2° è diventato pieno ma è ancora ATTIVO perché contiene i riferimenti a modifiche di blocchi oracle ancora presenti nella cache.
Il 3° è CURRENT cioè quello in cui scriverà il LGWR.

Il file Alert log traccia lo switch da un redo log ad un altro:
[oracle@dbserver1 trace]$ tail -f alert_sales.log
Current log# 2 seq# 5 mem# 1: /home/oracle/u01/app/oracle/flash_recovery_area/SALES/onlinelog/o1_mf_2_8gzw8t9q_.logThread 1 advanced to log sequence 6 (LGWR switch)  Current log# 3 ...........

Per spiegare perchè il blocco 2° è ancora in stato ACTIVE, eseguire la seguente query:
SQL> select RECOVERY_ESTIMATED_IOS  from V$INSTANCE_RECOVERY;
RECOVERY_ESTIMATED_IOS
----------------------------------------
                   192
otteniamo un valore maggiore di prima, 90, perchè i dati non sono stati spostati dal Database Buffer Cache nel Data File.
Spostiamo tutto dal Database Buffer Cache al Data File lanciando un chek point globale che avvia il processo DBWR:
SQL> ALTER SYSTEM CHECKPOINT;
System altered.

SQL> select RECOVERY_ESTIMATED_IOS  from V$INSTANCE_RECOVERY;
RECOVERY_ESTIMATED_IOS
---------------------------------------------
                    51
SQL> select GROUP#, STATUS , MEMBERS,ARCHIVED from V$LOG;
    GROUP#       STATUS              MEMBERS ARC
---------- ------------------------------------------------- ---------- ---
         1               INACTIVE                  2              YES
         2               INACTIVE                  2              YES
         3              CURRENT                   2             NO

Il 2° blocco è diventato INATTIVO perché i dati referenziati nel database buffer cache sono stati copiati nel Datafile.

Lo switch da un redolog ad un altro avvia un chekpoint incrementale che fa partire il processo DBWR che legge la parte di Database Buffer Cache la cui storia è indicata nel redologfile attivo. A questo punto parte anche il processo Checkpoint - CKPT che scrive nel control file e in ogni datafile header gli SCN e sale il livello di SCN da cui far partire un eventuale recovery.
Il valore SCN scritto nei data file headers garantisce che tutti i cambiamenti fatti sui blocchi del database fino a quel valore sono stati scritti sul disco.

Vedi anche il post Multiplexing Redo Log

Calcolare la dimensione dei redolog

 

SQL >  select group#, sum(bytes)/1024/1024

       from v$log

       group by group#;

Esempio dimensione 100 MB.

Calcolare la dimensione degli archivelog

Quanti switch fa al giorno un redolog file (verificare anche su alert file)?

SQL > select count(*),to_char(FIRST_TIME,'DD-MM-YYYY'),thread#

      from v$log_history

      where FIRST_TIME > to_date('21-01-2021','DD-MM-YYYY')

      group by to_char(FIRST_TIME,'DD-MM-YYYY'),THREAD# 

      ORDER BY THREAD#,to_char(FIRST_TIME,'DD-MM-YYYY');

Esempio count(*) = 3 cioè tre switch in un giorno.

Quindi 3 x  100 (dimensione dei redolog file) = 300 MB 

300 sarebbe la dimenzione massima al giorno di archive log.

Query per controallre la dimensione giornaliera degli Archive Log.
Attenzione che non tutti gli archive log sono presenti, alcuni potrebbero essere stati cancellati dalle politiche di backup.

SQL> select trunc(COMPLETION_TIME) TIME, 

     SUM(BLOCKS * BLOCK_SIZE)/1024/1024 SIZE_MB 

     from V$ARCHIVED_LOG 

     group by trunc (COMPLETION_TIME)

     order by 1;