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 :
- Création d’un Dataguard physique (Benjamin VESAN) [Oracle]
- Une solution de “Disaster Recovery” sous Oracle Standard Edition avec DBVisit standby (Emmanuel RAMI) [GénéralOracle]
- Utiliser ASMCMD (Capdata team) [OracleVintage]
- Principes d’une sauvegarde à chaud (David Baffaleuf) [SQL ServerVintage]
- Limiter la PGA totale en 12c (Benjamin VESAN) [Oracle]