Le mot Checkpoint signifie la synchronisation des données modifiées en mêmoire avec les fichiers de données dans la base. Par intervalle, le fait d'écrire les données modifiées dans les fichiers de données entre les checkpoints assure la disponibilité d'une quantité de mémoire, qui améliorera les performances pour trouver de la mémoire libre pour les opérations suivantes. Le mécanisme d'écritures des blocs modifiés dans le disque n'est pas synchronisé avec le commit des transactions.

Le checkpoint doit s'assurer que toutes modifications de tampons dans la cache sont réellement écrites dans les fichiers de données correspondants.

Le checkpoint se réalise sous quatre types d'évènements :

Le checkpoint doit être rompus dans deux cas spécifiques :

Quand LGWR effectue cette tâche, il ne peut pas faire son travail normalement, qui consiste à écrire les transactions dans les fichiers redo. Un process spécifique CKPT doit être utiliser pour liberer le LGWR de cette tâche. A partir de la version Oracle8 le process CKPT démarre automatiquement.

Le mécanisme de checkpoints présente un dilemme pour les dba Oracle, qui doivent trouver un point de compromis entre une performance global de l'instance et la rapidité de la restauration. La durée de restauratement est directement lié à la frequence des checkpoints.

Plus il y'a de checkpoints, plus la restauration est rapide. La restauration dépend de la quantité écrite dans le fichier redo depuis le dernier checkpoint.

Quand une restauration est nécessaire suite à un crash de l'instance, seulement les transactions écrites depuis le dernier checkpoint qui sont appliqués. Suivant le contexte, on a le choix entre la sécurité avec des checkpoints fréquents et un temps de restauration court ou une performance globale de l'instance avec des checkpoints moins fréquents. Normalement la majorité préfère la performance, car elle représente l'activité majeure dans une base de production.

Il y'a deux types de checkpoints :

Le checkpoint normal met à jours les fichiers de contrôle et les entêtes des fichiers de données

Le checkpoint incremental met à jours seulement le fichier de contrôle.

Voir l'article sivant : Avant la 10g

L'opération de checkpoint est constituée de trois phases distinctes. Dans la première phase, le process qui lance le checkpoint "capture" le RBA checkpoint. Ce RBA est plus souvent le RBA courant (le RBA de la dernière modification dans le buffer) au moment où la demande est initiée. Dans la seconde phase, le process DBWR écrit ailleurs tous les tampons demandés, c.a.d, tous les tampons qui ont été modifiés dont les RBA inférieurs ou égale au RBA checkpoint. Après que tous les tampons modifiés sont écrits, dans la troisième phase, le process CKPT enregistre l'achèvement du checkpoint dans le fichier de contrôle. Seulement quand la troisième phase est achevée qu'on peut affirmer que le checkpoint de l'instance a avancé au nouveau RBA. L'activité normale du checkpoint n'a pas touché quand la demande du checkpoint est active. Dans la figure suivante, on montre comment les tampons sont sélectionnés pour être écrites pour des opérations de checkpoints. Les tampons b1,b3 et b4 ont besoins d'êtres écrites pour achever le checkpoint. Le tampon b6 n'a besoin d'être écrit. Les tampons b2, b5 et b7 sont des tampons propres.