La Journalisation est au coeur de la robustesse des databases, c’est l’ensemble des processus caractéristiques de ce concept qui place Oracle en première ligne parmi tous les logiciels de bases de données relationnelles professionnelles.

La journalisation des données des bases Oracle peut globalement être approchée selon trois axes : les journaux en ligne, les journaux archivés et les journaux d’annulation. Ces trois méthodes de journalisation des données permettent d’atteindre un niveau de sécurité hors du commun dans le domaine des SGBDR.

1 – Journaux en ligne (“redolog”)

1.1 – Préambule

Les journaux en ligne ou “redologs” sont les fichiers de log de l’activité DML (Data Manipulation Language) de la base de données Oracle. Toute activité logique sur les éléments d’une base de données sont en priorité inscrits dans les redologs, on parle de Redolog Before dans le monde Oracle pour insister sur le fait que, quelle que soit une modification logique sur un élément d’une base de données (insert, update, delete), celui-ci sera en priorité inscrit dans les redologs, avant même d’être inscrit dans les fichiers proprement dits de la base de données (datafiles).

Dans le cadre d’un crash, physique ou logique, de l’instance de base de données, les procesus de recovery vont en tout premier aller consulter l’état et le contenu des redologs pour procéder à la récupération de la database.

Une bonne gestion des fichiers de journaux en ligne vous mettra en position idéale pour récupérer vos données en cas de panne.

1.2 – Principe d’alimentation mémoire des RedoLogs

Comme évoqué dans le préambule, les informations (create, drop, alter, …) DDL ne sont jamais stoquées dans les redologs mais seules les instructions de manipulation de données. N’espérez donc pas avoir uniquement recours aux redologs pour “rattraper” un malencontreux “drop tablespace … cascade” par exemple !

Une instance de base de données est entre autre composée d’un certain nombre d’espaces mémoires (buffers), le principe est fort simple : pour des raisons de rapidité, toute opération sur la database se fait en mémoire en allouant ou en réutilisant certains blocs dans les buffers Oracle appropriés. Régulièrement, les blocs des buffers sont synchronisés avec les fichiers de données selon des critères empiriques (taux de remplissage des buffers, temps d’attente maximal, ordre spécifique, etc).

Il existe un cetain nombre de processus serveurs qui sont chargés de ce principe, dans le cadre des redologs, c’est le processus LGWR (LogWriter), il se déclanche précisément dans les cas suivants :

  1. Commit
  2. Au bout de 3 secondes d’innactivité
  3. Si un tiers du buffer est plein

Nous verrons plus loin en observant ces principes que du dimensionnement des fichiers de journaux en ligne dépend énormément la capacité à éffectuer des recovery dans de bonnes conditions.

1.3 – Dimensionnement des Redologs

Il est quasiment impossible de faire un descriptif sur le meilleur dimensionnement d’un fichier redo car cette notion dépend intimement de l’activité de votre base de données et de vos exigences en matière de haute disponibilité et de capacité à restaurer plus ou moins rapidement les données en cas de crash d’instance (instance recovery) ou de base de donnée (media recovery).

La meilleure des méthodes et de choisir un dimensionnement par défaut et, d’observer la fréquence avec laquelle vos logs sont remplis, ce qui vous permettra de préciser une taille plus grande ou plus petite en fonction de l’activité.

Les informations nécessaires pour cela sont principalement contenus dans les vues

  1. v$log
  2. v$logfile
  3. v$instance_recovery

Mais le principe est simple, vous devez principalement jouer sur les critères de TAILLE et de FREQUENCE de switch.

Si vos fichiers redos sont de taille trop faible et l’activité de votre database trop intense, vous risquez d’arriver à tous les remplir avant même qu’un archivage soit terminé, ce qui est une catastrophe car l’activité de la database est stoppée durant ce temps !

Si vos fichiers redos sont trops importants, vous risquez de perdre du temps à les archiver et éventuellement de vous mettre en position de ne pas pouvoir restaurer votre base de données correctement en cas de crash car vous serez trop “loin” de la date du crash.

1.4 – Création et Multiplexage des Redologs

Introduction :

La création des journaux en ligne ets fort simple, elle consiste en la définition d”un “groupe” de redologs, entitée pour laquelle le DBA doit entendre “un fichier Redo et l’ensemble de ses miroirs multiplexés”.

En effet, par abus de langage on parle d’inscriptoin d’informations dans un fichier RedoLog alors qu’on devrait dire dans un “Groupe de RedoLogs” : c’est exactement la même chose sauf que, le DBA a la possibilité d’indiquer à l’instance que, lorsque une information doit être inscrit dans un fichier redo A, elle doit être en parallèele inscrite dans un fichier redo B, on parle alors de multiplexage.

Ce n’est alors plus le nombre de fichiers Redolog qui doit être pensé par le DBA mais le nombre de groupes de fichiers redologs. Comme nous le verrons par la suite, Oracle se chargera avec brio de la gestion online de la disponibilité de tous les éventuels fichiers redos membres d’un même groupe.

Syntaxe :

Création / suppression d’un groupe de redos :

alter database add log group <n_group> '<first_redolog_file_global_path>'

Exemple:

alter database add log group 1 '/redos/g1/1.log';
alter database add log group 2 '/redos/g2/1.log';

Ajout d’un membre à un redo log group :

alter database add log member '<redolog_file_global_path>' to group <n>

Exemple:

alter database add log member  '/redos/g1/2.log' to group 1;
alter database add log member  '/redos/g2/2.log' to group 2;

Comme pour tout autre fichier de la base de données Oracle, à tout moment, il est possible de modifier le chemin d”un redolog file du moment que l’instance est en mode “mount” avec la commande :

alter database rename file '<global_filename1>' to '<global_filename2>';

Remarque: cet ordre n’est valable que si le fichier cible existe au sens de l’OS;

1.5 – Considérations matérielles

Les temps de réponse d’une base de données sont intimemtn liés à ceux que Oracle préconise en matière de gestion des fichiers de journaux en ligne. Vous l’avez comrpsi, toute activit sera inscrit dans les Redologs avant tout, leur temps de réponse est donc … ESSENTIEL

Dans ce cadre d’étude, il est observé que les disques à monousage (sans aucunne sécurité) réponde évidement aux meilleures performances, que les disques en mirroir (RAID 1) répondent aux best practice en matière de temps d’accès etr que


2 – Journaux archivés

Les processus d’archivage des journaux en ligne sont en étroite relation avec la nécessité de sauvegarde, cette notion sera abordée ultérieurement.

3 – Journaux d’annulation

Les processus de gestion des journaux d’annulation (“Oracle Flash Back OFB”) sont en étroite relation avec la nécessité de sauvegarde, cette notion sera abordée ultérieurement.