Discussion :

[Isabella]

Bonjour

Les points de synchronisation ou CHECKPOINTS servent à garantir la cohérence d'une base de données en écrivant le contenu de la DATA BUFFER CACHE dans les fichiers DATAFILES régulièrement selon un certains nombre de règles comme staturation des Redo log files ou partie des redologs, redémarrage de l'instance, écoulement d'un laps de temps ainsi que d'autres événements importants qui pourraient se produire dans la base - si j'ai bien compris la doc-

ma question porte surtout sur le moyen de consulter ces CHECKPOINTS suivre leur évolution, interpréter leur valeurs etc.

je sais que la colonne CHECKPOINTS_CHANGE# figure dans pas mal de vues, telles que :

v$database, v$datafile, v$datafile_header ....
je ne sais pas s'il s'agit bien de ces points de synchronisation ?

et doit on avoir les mêmes valeurs partout dans ces vues pour la colonne CHECKPOINTS_CHANGE# pour dire qu'il y a cohérence dans la base ?

Merci à tous ceux qui pourraient m'éclairer sur ce point

[pifor]

Voir le document:
SCN : System Change number

[Isabella]

Merci pifor
je vais lire ce document à tête reposée, il a l'air interessant
merci aussi à l'auteur

[bouyao]

Si tu n'a pas compris quelque chose dans le document je te repondrai clairement Demain.

[bouyao]

C'est le début d'un autre article en cours de préparation

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 :

* Quand le delai de LOG_CHECKPOINT_TIMEOUT est atteint.
* Quand la taille en byte de (LOG_CHECKPOINT_INTERVALL * taille d'E/S des blocs OS) est écrite dans le fichier redo en cours.
* Directement par la commande ALTER SYSTEM SWITCH LOGFILE.
* Directement par la commande ALTER SYSTEM CHECKPOINT.

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

* Le DBWR écrit les tampons modifiés de la cache dans les fichiers de données.
* Le LGWR met à jours l'entête des fichiers de données et le fichier de contrôle.

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 :

* Checkpoint normal
* Checkpoint incremental

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.