Oracle SCN en recovery

SCN
SCN is een intern nummer dat gebruikt wordt door de database om changes te loggen.

Commit
Bij een commit schrijft de LGWR
- records van de log buffer naar redo log files
- transactie SCN naar online redo log

Atomic event: als schrijven naar schijf lukt dan pas is transactie compleet. Dit kan een bottleneck voor applicatie worden

 Checkpoint.
The checkpoint process (CKPT) 
- updates all datafiles and control files with the SCN at the time of the checkpoint
- signals DBWn to write out the blocks (flush modified db buffers to datafiles)

A successful checkpoint guarantees that all database changes up to the checkpoint SCN have been recorded in the datafiles. As a result, only those changes made after the checkpoint need to be applied during recovery.

Checkpoints occur automatically as follows:

• Whenever a redo log switch takes place
• Whenever the time set by the LOG_CHECKPOINT_TIMEOUT initialization parameter is reached
• Whenever the amount of redo written reaches the number of bytes associated with the LOG_CHECKPOINT_INTERVAL

Typically, LOG_CHECKPOINT_INTERVAL is chosen so that checkpoints only occur on log switches. 

Oracle stores the SCN associated with the checkpoint in four places
- three of them in the control file (system checkpoint scn, datafile checkpoint, stop scn)
- one in the datafile header for each datafile. (start SCN)

























System Checkpoint SCN (ctrlfile):  
select checkpoint_change# from v$database;

Datafile Checkpoint SCN (ctrlfile):
Na een Checkpoint wordt de SCN van elke datafile apart in de ctrlfile bijgehouden


select name,checkpoint_change# from v$datafile where name like '%users01%';

Stop SCN (ctrlfile)
Stop SCN wordt voor iedere datafile bijgehouden in de ctrfile


select name,checkpoint_change# from v$datafile_header where name like '%users01%';

Start SCN(header datafile)

Checkpoint SCN wordt in de header van elke datafile bijgehouden


select name,last_change# from v$datafile where name like '%users01%';

Tijdens normale db operatie Stop SCN is NULL for all datafiles that are online in RW mode

Na een succesvol checkpoint  system, datafile en start SCN zijn gelijk

Clean Shutdown
checkpoint is performed and the STOP SCN wordt gelijk aan de START SCN(header) gemaakt.
Bij opstarten checkt Oracle de START SCN(header) met de Datafile CHK SCN.
Gelijk dan START SCN vergelijken met STOP SCN (ctrl).
Gelijk dan database openen, geen recovery nodig, Stop SCN kan weer op NULL, normale operatie


Instance Crash (STOP SCN <> START SCN)
Bij een crash (shutdown abort) is de STOP SCN (ctrlfile) niet gezet dus nog NULL.
Bij opstarten detecteert Oracle dat STOP SCN niet is gezet Crash recovery, roll forward mbv redo log records van de online redo log toe en roll back adhv undo

Media Failure (DATAFILE CHKP SCN > START SCN)
Bij media failure, moet een datafile gerecoverd worden door een backup copy. Dit betekent dat de Datafile Checkpoint SCN (ctr) groter is dan START SCN (header), want oude backup datafile. Voor recovery zijn de archive logs nodig.

Waarom SYSTEM CHKP SCN en DATAFILE CHKP SCN?
1. Read only tabelspaces worden niet bijgewerkt bij een checkpoint. De SCN is dus minder dan de SYSTEM CHKP SCN
2. The second reason for the maintenance of multiple checkpoint SCNs in the control file is that you might not have a current control file available at recovery time. In this case, you need to restore an earlier control file before you can perform a recovery. The system checkpoint in the control file may indicate an earlier change than the start SCN in the datafile headers.




If try you to recover a database in the usual way in this situation, Oracle detects that the control file is older than some of the datafiles, as indicated by the checkpoint SCN values in the datafile headers, and reports the following message:

SQL> recover database
ORA-00283: recovery session canceled due to errors
ORA-01610: recovery using the BACKUP CONTROLFILE option must be done

If you want to proceed with recovery in this situation, you need to indicate to Oracle that a noncurrent control file—possibly containing mismatches in the SCN values identified by the previous error messages—is about to be specified for recovery by using the following command:
recover database using BACKUP CONTROLFILE;