Checkpoint not complete: Comment limiter les alertes liées à la journalisation

vendredi, juillet 8, 2011
By Louis PROU in Oracle (lprou@capdata.fr) [1 article(s)]

Mécanisme :

Le moteur oracle met en œuvre un mécanisme de journalisation via les fichiers redo logs afin d’enregistrer toutes les modifications apportées à la base de données. Ceux-ci sont organisés en groupes qui vont être écrits de manière circulaire, c’est-à-dire écrasés à intervalle plus ou moins régulier.

Ils sont primordiaux pour la restauration de l’instance dans le cas d’un arrêt anormal ou pour la restauration de média si un fichier de données est corrompu ou tout simplement perdu. Couplés à une sauvegarde de fichiers de données, ils permettent donc de rejouer l’intégralité des changements survenus entre la sauvegarde et l’incident.

Les fichiers de journalisation se composent d’au minimum deux groupes constitués chacun d’un ou  plusieurs membres. Ainsi les membres d’un même groupe vont être écrits de manière simultanée par l’instance via le processus LGWR (logwriter) et contenir exactement les mêmes données. Cette mise en miroir appelée également multiplexage permet de diminuer les risques en cas de perte de fichiers. C’est pourquoi il est conseillé de positionner les redo logs sur des espaces physiques différents. Tous les membres d’un groupe ont la même taille définie lors de leur création et celle-ci reste fixe. Il faut également savoir que le nombre de groupes n’augmente pas dynamiquement. Ainsi lorsqu’il n’est plus possible d’écrire dans un groupe qui est plein Oracle passe au groupe suivant et ainsi de suite jusqu’au dernier. L’écriture d’un fichier à un autre se nomme basculement (switch). Puis il va repasser au premier, d’où la notion de circularité, en écrasant toutes les informations qui y sont stockées. Elles ne seront donc plus disponibles lors par exemple, d’une restauration de média. Pour garantir cela il faut donc activer le mécanisme d’archivage, qui comme son nom l’indique, permet d’archiver les fichiers de journalisation dès lors qu’ils sont pleins avant qu’ils ne soient réutilisés.

Problématique :

Toute la problématique se situe donc dans le simple fait de parvenir à dimensionner correctement la taille des fichiers de journalisation et avoir le bon nombre de groupes.

Cependant l’objectif reste simple :

Avoir une taille de fichiers de journalisation suffisamment grande dans le but d’éviter des basculements trop fréquents qui seraient pénalisants pour les performances. Sans perdre de vue qu’avoir des basculements peu fréquents et donc des points de reprise peu fréquents pourraient dans certain cas allonger la durée de récupération de l’instance et donc la durée de redémarrage lors d’un arrêt anormal. Il faut donc trouver le juste milieu entre bonne performance en fonctionnement normal mais également en cas de dysfonctionnement.

Utiliser un nombre de groupes suffisamment important afin de permettre aux points de reprise et à l’archivage de se terminer avant que l’instance ne revienne sur un fichier de journalisation et écrase les informations. Si ce n’est pas le cas le processus LGWR est en attente dégradant ainsi les performances.

Analyse:

La première chose à faire est d’analyser le fichier d’alerte de l’instance afin d’auditer de manière simple l’activité des fichiers de journalisation.

Voici donc les trois types d’informations à surveiller :

– Basculement d’un fichier de journalisation à un autre

Mon Jul 04 10:08:05 2011
Thread 1 advanced to log sequence 50
Current log# 2 seq# 50 mem# 0: E:\ORADATA\DBVC\REDO02A.RDO 
Current log# 2 seq# 50 mem# 1: D:\ORADATA\DBVC\REDO02B.RDO

– Attente lors d’un basculement : Point de reprise non terminé

Thu Jul 07 10:42:25 2011
Thread 1 cannot allocate new log, sequence 56
Checkpoint not complete

– Attente lors d’un basculement : Archivage non terminé

Thu Jul 07 10:42:25 2011
Thread 1 cannot allocate new log, sequence 57
All online logs needed archiving

Ensuite il est bon de vérifier la manière dont sont organisés les redo logs en se connectant à l’instance, via par exemple  sqlplus:

SQL> select *from v$log;
 GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
1          1      12364  419430400           2 NO  CURRENT           530717709 18-MAY-11
2          1      12363  419430400           2 NO  ACTIVE               530642826 18-MAY-11
3          1      12362  419430400           2 NO  INACTIVE            530562254 18-MAY-11

Ici l’on interroge la vue v$log, où l’on constate que l’on dispose de trois groupes de fichiers de 400 Mo chacun. Le groupe N°1 étant celui en cours d’utilisation par l’instance.

SQL> select * from v$logfile order by group#;
 GROUP# STATUS  TYPE    MEMBER                                   IS_
---------- ------- ------- ---------------------------------------- ---
1         ONLINE  D:\ORADATA\DBVC\REDO01A.RDO              NO
1         ONLINE  F:\ORADATA\DBVC\REDO01B.RDO              NO
2         ONLINE  E:\ORADATA\DBVC\REDO02A.RDO              NO
2         ONLINE  D:\ORADATA\DBVC\REDO02B.RDO              NO
3         ONLINE  F:\ORADATA\DBVC\REDO03A.RDO              NO
3         ONLINE  E:\ORADATA\DBVC\REDO03B.RDO              NO

Ici l’on interroge la vue v$logfile où l’on voit que chaque groupe est composé de deux membres. Chaque membre étant positionné sur un disque physique distinct.

SQL> select * from v$loghist;
THREAD#  SEQUENCE# FIRST_CHANGE# FIRST_TIME SWITCH_CHANGE#
---------- ---------- ------------- ------------------- --------------
1    12247    523471807    17/05/2011    0:11:07        523552937
1    12248    523552937    17/05/2011    0:26:08        523634497
1    12249    523634497    17/05/2011    0:46:07        523650275
1    12250    523650275    17/05/2011    1:11:08        523746442
1    12251    523746442    17/05/2011    1:26:08        523817931
1    12252    523817931    17/05/2011    1:43:10        523844135
1    12253    523844135    17/05/2011    2:07:33        523925461
1    12254    523925461    17/05/2011    2:26:08        523985782
1    12255    523985782    17/05/2011    2:42:57        524023131
1    12256    524023131    17/05/2011    3:06:09        524118467
1    12257    524118467    17/05/2011    3:23:03        524159631
1    12258    524159631    17/05/2011    3:42:51        524216095
1    12259    524216095    17/05/2011    4:04:04        524297285
1    12260    524297285    17/05/2011    4:21:50        524330560
1    12261    524330560    17/05/2011    4:42:45        524393688
1    12262    524393688    17/05/2011    5:01:10        524491001
1    12263    524491001    17/05/2011    5:21:08        524506409
1    12264    524506409    17/05/2011    5:42:36        524587362
1    12265    524587362    17/05/2011    6:01:08        524668639
1    12266    524668639    17/05/2011    6:16:25        524684295
1    12267    524684295    17/05/2011    6:41:46        524764738
1    12268    524764738    17/05/2011    6:59:28        524861296
1    12269    524861296    17/05/2011    7:16:10        524877473
1    12270    524877473    17/05/2011    7:41:13        524958651
1    12271    524958651    17/05/2011    7:56:14        525040362
1    12272    525040362    17/05/2011    8:16:10        525056411
1    12273    525056411    17/05/2011    8:41:11        525137127
1    12274    525137127    17/05/2011    8:56:15        525233811

On peut également interroger la vue v$loghist où l’on peut ici constater qu’il y a un switch log toutes les 15/25 min environ, ce qui reste correct.

Il faut donc comprendre que si la durée qui sépare les messages d’alerte de type « Basculement d’un fichier de journalisation à un autre » est courte, les fichiers sont mal dimensionnés. Il faudra donc veiller à les agrandir. C’est-à-dire supprimer les membres non actifs pour les recréer de taille plus importante. Si ce message d’alerte n’apparait que de manière occasionnelle (par exemple une fois par jour) c’est que les fichiers sont correctement taillés.

Si il y a beaucoup de messages d’alertes au niveau des attentes (Checkpoint not complete / All online logs needed archiving) il faudra veiller à ajouter un groupe de fichier. En effet de cette manière le processus LGWR mettra plus de temps à effectuer le tour complet des fichiers de journalisation et permettra donc au point de reprise ou à l’archivage de se terminer correctement sans attente.

Continuez votre lecture sur le blog :




Cliquer pour partager cet article sur Viadeo
Cliquer sur "CAPTURER" pour sauvegarder cet article dans Evernote Clip to Evernote

Leave a Reply