IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Notes pour OCP 9i DBA1

Date de publication : 01/09/2004 , Date de mise a jour : 01/09/2004




5. Fichiers de contrôle et fichiers de reprise


5. Fichiers de contrôle et fichiers de reprise


Les fichiers de contrôle tout comme les fichiers de reprise peuvent être multiplexés. C'est Oracle qui assure la synchronisation des différents exemplaires d'un fichier ; il n'y a donc pas besoin de matériel ou de fonctionnalité OS spécifiques.

Les fichiers de contrôle
Ils servent à stocker les informations sur la structure de la base, c'est à dire principalement le nom des tablespaces et l'emplacement des fichiers constitutifs de la base.
On y trouve aussi le log sequence number, c'est à dire le numéro séquentiel de reprise, qui indique quel est le dernier fichier de reprise en cours d'utilisation.
Il stocke également des informations concernant le dernier point de synchronisation (où tous les blocs modifiés sont transférés sur disque) et sur le dernier SCN, c'est à dire le numéro de la dernière transaction effectuée.
Enfin, il renferme des informations sur les segments d'annulation.
Un fichier de contrôle a une taille fixe qui résulte des paramètres de création de la base, tels que MAXDATAFILES ou MAXLOGFILES. Si on a vu trop petit, il faut recréer un fichier de contrôle.
Les différentes informations d'un fichier de contrôle ne sont pas toutes mises à jour par le même processus. LGWR, CKPT et ARCn peuvent tous modifier le fichier de contrôle suivant l'information concernée.

Il faut sauvegarder le fichier de contrôle après toute modification de structure de la base (concernant le nom, l'emplacement, la taille des tablespaces et des fichiers).

Oracle recommande d'avoir au moins 2 fichiers de contrôle. 1 seul est obligatoire, et on peut en avoir jusqu'à 8 en mode non OMF.
Ce multiplexage est très simple, il suffit de copier le fichier à l'endroit voulu, de lui donner un nom unique, et de modifier le paramètre d'initialisation CONTROL_FILES pour l'intégrer dans la liste :

CONTROLE_FILES= ( 'H:\oracle\oradata\ora9\CONTROL01.CTL' ,'H:\oracle\oradata\ora9\CONTROL02.CTL' ,'H:\oracle\oradata\ora9\CONTROL03.CTL' )
Si un des fichiers de contrôle est supprimé, il suffit de recopier à l'emplacement et sous le nom attendus l'un des fichiers encore présents, après quoi la base peut redémarrer.

Multiplexage avec OMF
OMF permet de supporte jusqu'à 5 fichiers de contrôle multiplexés.
Pour cela, on n'utilise plus le paramètre CONTROL_FILES, mais DB_CREATE_ONLINE_LOG_DEST_1, DB_CREATE_ONLINE_LOG_DEST_2, etc, en spécifiant pour chacun le répertoire cible. Le nom des fichiers est généré automatiquement.

Création d'un fichier de contrôle
Il peut être nécessaire de recréer un fichier de contrôle :

  • s'ils ont tous été supprimés
  • si on veut renommer la base
  • si des paramètres comme MAXDATAFILES doivent être augmentés
Cette opération est dangereuse, un mauvais choix peut provoquer une perte de données non rattrapable, due aux fichiers de reprises non pris en compte.

Il faut avoir mémorisé la liste de tous les fichiers de données et de reprise (emplacement et nom).
La commande ALTER DATABASE BACKUP CONTROLFILE TO TRACE permet d'obtenir un script qui contient toutes les informations utiles. Il est placé automatiquement dans le répertoire spécifié par USER_DUMP_DEST.

La création d'un fichier de contrôle exige que l'instance soit lancée en mode NOMOUNT.
On peut alors exécuter la commande CREATE CONTROLFILE.

Certaines vues fournissent des informations sur les fichiers de contrôle :
V$CONTROLFILE fournit le nom et l'emplacement des fichiers de contrôle (correspond au paramètre CONTROL_FILES du PFILE)
V$CONTROLFILE_RECORD_SECTION indique le nombre d'entrées total et occupé pour chaque rubrique du fichier de contrôle

Les fichiers de reprise (redo log)
Il faut obligatoirement au moins 2 fichiers de reprise. Ceux-ci sont utilisés circulairement : quand le dernier est plein, le premier est réutilisé et sont contenu précédent est perdu. C'est pour cette raison que l'archivage des fichiers de reprise est utile.

Un fichier de reprise mémorise différents types d'informations :

  • les modifications effectuées sur les données
  • les blocs d'annulation, utiles tant que la transaction en cours n'a pas été validée
  • la table des transactions du segment d'annulation
L'ensemble des fichiers de reprise (multiplexés ou non) d'une instance est appelé un thread de reprise.
Un fichier de reprise comporte un grand nombre d'entrées, qui se subdivisent en vecteurs de modification. Ce dernier niveau correspond tout simplement à l'ensemble des modifications qui concernent un bloc donné.
Quand une transaction est validée, elle reçoit un SCN (numéro système de changement) qui est associé aux entrées de reprises correspondantes.

Les données de reprises sont copiées par LGWR depuis le tampon de reprise vers les fichiers si l'une des situations suivantes se produit :

  • l'utilisateur valide sa transaction
  • le tampon de reprise est plein au tiers
  • le tampon de reprise contient 1 Mo de données
Le fichier de reprise utilisé à un moment donné (il n'y en a qu'un seul à la fois) est appelé fichier actif.
Quand il est plein, il se produit un basculement vers le fichier de reprise suivant. Un fichier de reprise est identifié par un numéro attribué lors du basculement. Ce numéro est primordial pour une récupération quand les fichiers de reprise sont archivés.
Le basculement peut être provoqué manuellement, par ALTER SYSTEM SWITCH LOGFILE.
Les basculements sont enregistrés dans le fichier d'alerte.
Le basculement provoque également un point de synchronisation (checkpoint) : tous les blocs modifiés du tampon de données de la SGA sont écrits sur disque par DBWR.
Comme un point de synchronisation est une opération lourde, il faut éviter qu'elle soit trop fréquente, et pour cela il faut donner une taille suffisante aux fichiers de reprise, ce qui réduit les basculements et les synchronisations associées.
En contrepartie, la récupération au démarrage de la base (si elle est nécessaire), sera plus longue. Elle peut être contrôlée grâce au paramètre FAST_START_MTTR_TARGET, qui fixe le temps maximal, en secondes, acceptable pour la récupération.
En fixant le paramètre LOG_CHECKPOINT_TO_TRACE à TRUE, les synchronisations seront enregistrées dans le fichier d'alerte.

Les fichiers de reprise peuvent, et devraient toujours, être multiplexés.
Les copies d'une même fichier constituent un groupe. Tous les membres du groupe, chacun sur son disque, sont actifs en même temps.
Avec des fichiers de reprise multiplexés, la base continue à fonctionner normalement tant qu'au moins un des membres du groupe de reprise est intact.
La clause MAXLOGFILES du CREATE DATABASE détermine le nombre maximum de fichiers de reprise hors multiplexage. Il équivaut au nombre de groupes en cas de multiplexage.

Création des fichiers de reprise
Initialement, les fichiers de reprise sont créés en même temps que la base, par la clause LOGFILE du CREATE DATABASE.
La clause "GROUP n" est facultative. Si elle est omise, Oracle attribue automatiquement un numéro de groupe.

CREATE DATABASE test ... LOGFILE GROUP 1 ('H:\oracle\oradata\test\redo01.log', 'I:\oracle\oradata\test\redo11.log') SIZE 102400K, GROUP 2 ('H:\oracle\oradata\test\redo02.log', 'I:\oracle\oradata\test\redo12.log') SIZE 102400K, GROUP 3 ('H:\oracle\oradata\test\redo03.log', 'I:\oracle\oradata\test\redo13.log') SIZE 102400K;
Cette commande crée une base avec 3 groupes de fichiers de reprise multiplexés, comportant chacun 2 membres.

Postérieurement à la création de la base, des fichiers de reprise peuvent être ajoutés par ALTER DATABASE ADD LOGFILE

ALTER DATABASE ADD LOGFILE GROUP 4'H:\oracle\oradata\test\redo04.log' 5M; ALTER DATABASE ADD LOGFILE ('H:\oracle\oradata\test\redo05.log', I:\oracle\oradata\test\redo15.log') 10 M;
La première commande ajoute un fichier de reprise non multiplexé (un groupe d'un seul membre); la seconde créé un groupe supplémentaire de 2 fichiers multiplexés, mais ne spécifie pas de numéro de groupe explicite.

Pour ajouter un membre à un groupe existant, on doit préciser le numéro du groupe. La taille, en revanche, ne doit pas être spécifiée ; elle est déduite de celle des autres membres.

ALTER DATABASE ADD LOGFILE MEMBER 'J:\oracle\oradata\test\redo25.log' TO GROUP 5;
Pour renommer un fichier de reprise, il faut

  • arrêter la base
  • copier le fichier à l'endroit et sous le nom désirés
  • démarrer la base en mode NOMOUNT
  • exécuter ALTER DATABASE RENAME FILE ancien_nom TO nouveau_nom;
  • ouvrir la base en mode OPEN
  • sauvegarder le fichier de contrôle
Noter que RENAME FILE n'a aucun effet sur les fichiers physiques, il se contente d'enregistrer le nouveau nom dans le fichier de contrôle. Pour supprimer un groupe et tous ses membres, on utilise

ALTER DATABASE DROP LOGFILE GROUP n;
La suppression n'est possible que si le groupe est inactif. Utiliser si besoin ALTER SYSTEM SWITCH LOGFILE.
La suppression n'est que logique, et il faut ensuite supprimer les fichiers physiques au niveau OS.

Et pour supprimer un membre dans un groupe

ALTER DATABASE DROP LOGFILE MEMBER 'J:\oracle\oradata\test\redo25.log'
Là aussi, il faut ensuite supprimer le fichier physique manuellement.

Si un fichier de reprise est endommagé pour une raison quelconque, il faut le supprimer et le recréer.
Le même effet peut être obtenu en une seule commande :

ALTER DATABASE CLEAR LOGFILE GROUP n ; -- tout le groupe est régénéré
ou

ALTER DATABASE CLEAR LOGFILE 'J:\oracle\oradata\test\redo25.log'; -- juste le fichier spécifié
ARCHIVAGE DES FICHIERS DE REPRISE En raison du caractère circulaire de l'écriture dans les fichiers de reprise, il est souhaitable de sauvegarder les fichiers de reprise avant qu'ils ne soit réutilisés.
C'est ce que permet l'archivage, qui réalise une copie des fichiers de reprise pleins vers un emplacement défini par le DBA, qui peut être un disque ou une bande.
L'archivage est réalisé par un processus ARCn.

Les fichiers de reprise archivés sont utiles dans 3 circonstances :

  • pour faire une récupération de base après panne de disque. C'est la raison d'être principale de l'archivage.
  • pour mettre à jour une base de secours
  • pour analyser l'activité grâce au LogMiner
De plus, seule une base en mode archive peut être sauvegardée à chaud.

Le mode ARCHIVELOG n'est pas synonyme d'archivage automatique.
ARCHIVELOG signifie juste qu'un fichier de reprise ne sera pas réutilisé tant qu'il n'a pas été sauvegardé.
La sauvegarde en question peut être manuelle ou automatique.

Attention : une sauvegarde faite en mode NOARCHIVELOG n'est plus utilisable sur une base passée entre temps en mode ARCHIVELOG !

Le mode d'archivage peut être spécifié lors de la création de la base, par le mot-clé ARCHIVELOG ou NOARCHIVELOG du CREATE DATABASE.
Il est ensuite modifiable, généralement pour activer l'archivage.

Pour passer une base en mode ARCHIVELOG :

  • arrêter la base
  • faire une sauvegarde complète : c'est elle qui sera utilisable si le passage à l'archivage rencontrait un problème
  • modifier le fichier d'initialisation pour paramétrer l'archivage (voir détails plus loin)
  • démarrer l'instance en mode MOUNT
  • faire ALTER DATABASE ARCHIVELOG
  • ouvrir la base par ALTER DATABASE OPEN
  • arrêter la base
  • faire une sauvegarde complète : ce sera la première sauvegarde de référence correspondant au mode ARCHIVELOG
Les paramètres d'initialisation relatifs aux cibles d'archivage
LOG_ARCHIVE_DEST_n permet de définir jusqu'à 10 emplacements d'archivage simultanés. Ce paramètre supporte diverses options, parmi lesquelles LOCATION permet de spécifier comme cible un répertoire local ou distant. SERVICE permet de spécifier un nom d'instance (dans le cas où on maintient une base de secours)
Lors de l'archivage des fichiers de reprise (qu'il soit manuel ou automatique), ils seront copiés à la fois dans toutes les destinations définies.
LOG_ARCHIVE_MIN_SUCCEED_DEST précise combien d'écritures simultanées doivent absolument réussir. Sa valeur peut aller de 1 à 10.
LOG_ARCHIVE_FORMAT spécifie le nom des fichiers archivés. Il permet d'intégrer 4 variables :
%s : numéro séquentiel (attribué lors du basculement des fichiers de reprise)
%S : numéro séquentiel complété par des zéros à gauche
%t : numéro de "thread" de reprise (utile seulement en environnement RAC)
%T : numéro de "thread" de reprise complété par des zéros à gauche
Un format a donc la forme 'arch_%s.log' ; il est concaténé avec le répertoire indiqué par la clause LOCATION de LOG_ARCHIVE_DEST_n.

Archivage automatique
Les différents paramètres vus précédemment ne suffisent pas à activer l'archivage automatique des fichiers de reprise.
C'est le paramètre d'initialisation LOG_ARCHIVE_START (TRUE/FALSE) qui déclenche l'archivage automatique, pour peu que la base soit en mode ARCHIVELOG.
On peut activer ou arrêter dynamiquement l'archivage automatique par ALTER SYSTEM ARCHIVE LOG START/STOP.

Archivage manuel
Si LOG_ARCHIVE_START est à FALSE, on est en mode d'archivage manuel.
Il faut alors exécuter ALTER SYSTEM ARCHIVE LOG CURRENT /GROUP n /LOGFILE nom /NEXT /ALL
CURRENT force un basculement avant l'archivage, NEXT archive le prochain fichier non archivé (il y en a peut-être d'autres), et ALL archive tous les fichiers pleins et non déjà archivés.

Comment connaître le statut d'archivage d'une base ?

La commande SQL*Plus ARCHIVE LOG LIST indique si la base est en mode ARCHIVELOG, si elle est en archivage automatique et la destination des archives.
Elle ne peut être exécutée qu'avec le privilège SYSDBA.

La colonne LOG_MODE de V$DATABASE indique uniquement le statut d'archivage (ARCHIVELOG ou NOARCHIVELOG).

La vue V$LOG donne diverses informations sur les fichiers de reprise, mais pas leur emplacement.
La colonne STATUS est spécialement utile. En particulier, la valeur CURRENT indique que le groupe considéré est celui qui reçoit actuellement les écritures, alors que ACTIVE signifie que le fichier de reprise peut être nécessaire pour une récupération.

La vue V$LOGFILE fournit principalement l'emplacement des différents fichiers de reprise.

La vue V$THREAD fournit quelques informations globales, telles que le numéro du groupe de fichiers de reprise courant. On trouve aussi le nom d'instance.

La vue V$LOG_HISTORY mémorise tous les basculements de fichiers de reprise, avec leur horodate et les numéros de premier et dernier SCN.

La vue V$ARCHIVED_LOG fournit bon nombre d'informations sur les fichiers archivés (elle est vide sinon).

La vue V$ARCHIVE_DEST indique l'emplacement des 10 cibles possibles d'archivage, leur statut, et précise dans la colonne BINDING si ces cibles sont obligatoires ou non.