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

Les fichiers redo archivés

L'auteur

Profil Pro

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

I. Le mode NOARCHIVELOG et ARCHIVELOG

I-A. Le mode NOARCHIVELOG

Quand la base est en mode NOARCHIVELOG, l'archivage des fichiers redo est désactivé. Le fichier de contrôle indique que les groupes des fichiers redo pleins ne sont plus nécessaires. Dès qu'ils sont inactifs après un log switch, le groupe sera disponible pour une réutilisation par LGWR.

Le mode NOARCHIVELOG protège la base contre une défaillance d'instance et non pas contre une défaillance media. Seulement les modifications récentes dans la base, stockées dans les groupes de fichiers redo en ligne seront disponibles pour la restauration de la base.

En mode NOARCHIVELOG, on ne peut pas sauvegarder en ligne une tablespace. Pour restaurer une base en mode NOARCHIVELOG, on est obligé de faire une sauvegarde complète quand la base est fermée. Dans ce mode, il faut toujours faire des sauvegardes régulièrement.

Image non disponible

I-B. Le mode ACHIVELOG

Quand la base est en mode ARCHIVELOG, l'archivage des fichiers redo est activé. Le fichier de contrôle de la base signale que les groupes contenant des fichiers redo pleins ne peuvent pas être utilisés par le process LGWR tant que les groupes n'ont pas été archivés.

Image non disponible

II. Changement du mode d'archivage

Pour modifier le mode d'archivage de la base, on utilise la commande ALTER DATABASE avec la clause ARCHIVELOG ou NOARCHIVELOG et il faut être connecté avec des privilèges d'administrateur (AS SYSDBA).

Dans cet exemple, on montre comment activer le mode ARCHIVELOG :

1. Arrêter la base.

SHUTDOWN

On ne peut pas modifier le mode ARCHIVELOG en NOARCHIVELOG si la base à besoin d'une restauration media.

2. Sauvegarder la base.

Avant de faire des modifications majeures dans la base, il faut toujours sauvegarder votre base pour se protéger d'un autre nouveau problème.

3. Éditer le fichier d'initialisation pour ajouter les paramètres qui spécifient la destination des archives. (Voir Destination des archives).

4. Démarrer la base en mode mount sans l'ouvrir.

STARTUP MOUNT

5. Modifier le mode d'archivage et ouvrir la base.

 
Sélectionnez
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;

6. Arrêter la base.

SHUTDOWN IMMEDIATE

7. Sauvegarde la base.

Le changement du mode d'archivage mettra à jour le fichier de contrôle et rendra les anciennes sauvegardes inutilisables.

III. L'archivage manuel et l'archivage automatique

Dans Oracle 10g, l'archivage automatique est activé par la commande SQL suivante :

ALTER DATABASE ARCHIVELOG;

Si la base est en mode ARCHIVELOG, Oracle archive les fichiers redo dès qu'ils sont remplis. Le fichier redo en entier doit être archivé avant d'être utilisé.

Avant la 10g, les fichiers redo sont marqués comme prêts pour être archivés ce qui ne signifie pas qu'ils devraient être archivés automatiquement. Il fallait renseigner le paramètre d'initialisation :

LOG_ARCHIVE_START = TRUE

Mettre ce paramètre à TRUE, démarrera un process qui consiste à copier un fichier redo dans le répertoire des fichiers redo archivés. La destination et le format du nom des fichiers redo archivés sont spécifiés par deux paramètres, LOG_ARCHIVE_DEST et LOG_ARCHIVE_FORMAT.

LOG_ARCHIVE_DEST = C:\ORANT\DATABASE\ARCHIVE

Spécifie le nom du répertoire où Oracle doit écrire les fichiers redo archivés.

Et

LOG_ARCHIVE_FORMAT = "ORCL%S.ARC"

Spécifie le format du nom des fichiers archivés. Ici, le fichier commence par le mot "ORCL" plus le numéro de séquence du journal et finit par le mot ".ARC".

Les autres options sont :

%s : le numéro de séquence du fichier redo sans zero-padding à gauche ;

%T : le numéro du thread redo avec zero-padding ;

%t : le numéro du thread redo sans zero-padding.

Par exemple, si on veut que les noms des fichiers archivés contiennent les numéros du thread et les numéros de séquences avec zero-padding :

LOG_ARCHIVE_FORMAT = "ORCL%T%S.ARC"

IV. Destination des Archives

On a le choix d'archiver les fichiers redo dans une seule destination ou dans plusieurs. Si on choisit une seule destination, alors on utilise le paramètre LOG_ARCHIVE_DEST. Et si on choisit plusieurs destinations, on aura le choix entre 10 destinations (paramètre LOG_ARCHIVE_DEST_n) ou archiver seulement dans les destinations primaire et secondaire en utilisant LOG_ARCHIVE_DEST et LOG_ARCHIVE_DUPLEX_DEST.

Voici un tableau qui récapitule le choix du multiplexage :

Image non disponible

IV-A. Méthode 1 : Utilisation du paramètre LOG_ARCHIVE_DEST_n

On utilise le paramètre LOG_ARCHIVE_DEST_n (avec n un entier entre 1 et 10) pour désigner l'une des dix destinations d'archives.

Si on utilise la clé LOCATION, il faut spécifier un répertoire valide de l'OS. Si on spécifie SERVICE, Oracle traduit le nom du service réseau à travers le fichier tnsnames.ora en descripteur de connexion. Le descripteur contient les informations nécessaires pour se connecter à la base distante. Le nom du service doit être associé au SID de la base, de cette façon, la base met à jour correctement la section log history du fichier de contrôle pour une base standby.

Pour fixer la destination des fichiers redo archivés en utilisant le paramètre d'initialisation LOG_ARCHIVE_DEST_n :

1. Arrêter la base.

SHUTDOWN

2. On fixe le paramètre d'initialisation LOG_ARCHIVE_DEST_n. Par exemple :

 
Sélectionnez
LOG_ARCHIVE_DEST_1 = 'LOCATION = /disk1/archive'
LOG_ARCHIVE_DEST_2 = 'LOCATION = /disk2/archive'
LOG_ARCHIVE_DEST_3 = 'LOCATION = /disk3/archive'

Si on archive dans une base standby, on utilisera le mot clé SERVICE. Par exemple :

LOG_ARCHIVE_DEST_4 = 'SERVICE = standby1'

3. En option, on fixe le paramètre d'initialisation LOG_ARCHIVE_FORMAT.

Si le paramètre d'initialisation COMPATIBLE est fixé à 10.1.0 ou plus, la base réclame l'ID du resetlogs (%r) quand le paramètre LOG_ARCHIVE_FORMAT est utilisé. Par défaut sous UNIX ce paramètre est :

LOG_ARCHIVE_FORMAT=%t_%s_%r.dbf

L'incarnation de la base change quand elle est ouverte avec l'option RESETLOGS. Le fait de spécifier %r, provoquera la capture de l'ID resetlogs dans le nom du fichier redo archivé, ce qui facilite la restauration depuis la sauvegarde de la dernière incarnation de la base.

IV-B. Méthode 2 : LOG_ARCHIVE_DEST et LOG_ARCHIVE_DUPLEX_DEST

Si on spécifie au maximum deux locations, alors c'est mieux d'utiliser le paramètre LOG_ARCHIVE_DEST pour la destination d'archive primaire et LOG_ARCHIVE_DUPLEX_DEST pour la destination d'archive secondaire. Toutes les locations doivent être en local.

Pour cela, il faut :

1. Arrêter la base.

SHUTDOWN

2. Spécifier les paramètres LOG_ARCHIVE_DEST et LOG_ARCHIVE_DUPLEX_DEST (on peut utiliser la commande ALTER SYSTEM pour les modifier dynamiquement).

Par exemple :

 
Sélectionnez
LOG_ARCHIVE_DEST = '/disk1/archive'
LOG_ARCHIVE_DUPLEX_DEST = '/disk2/archive'

3. Fixer le paramètre d'initialisation LOG_ARCHIVE_FORMAT

V. Statut des destinations d'archives

Toutes les destinations d'archives ont des caractéristiques variables pour déterminer leur statut :

Valid/Invalid : indique si la location du disque et l'information sur le nom du service est spécifiée et valide ;

Enabled/Disabled : indique l'état de la disponibilité de la location et si la base peut utiliser cette destination ;

Active/Inactive : indique s'il y a un problème pour accéder à la destination.

Plusieurs combinaisons sont possibles. Pour obtenir le statut en cours et d'autres informations sur chacune des destinations, on utilise alors la vue V$ARCHIVE_DEST.

 
Sélectionnez
SQL> desc V$ARCHIVE_DEST
 Name                                      Null?    Type
 ----------------------------------------- -------- -----------------------
 DEST_ID                                            NUMBER
 DEST_NAME                                          VARCHAR2(256)
 STATUS                                             VARCHAR2(9)
 BINDING                                            VARCHAR2(9)
 NAME_SPACE                                         VARCHAR2(7)
 TARGET                                             VARCHAR2(7)
 ARCHIVER                                           VARCHAR2(10)
 SCHEDULE                                           VARCHAR2(8)
 DESTINATION                                        VARCHAR2(256)
 LOG_SEQUENCE                                       NUMBER
 REOPEN_SECS                                        NUMBER
 DELAY_MINS                                         NUMBER
 NET_TIMEOUT                                        NUMBER
 PROCESS                                            VARCHAR2(10)
 REGISTER                                           VARCHAR2(3)
 FAIL_DATE                                          DATE
 FAIL_SEQUENCE                                      NUMBER
 FAIL_BLOCK                                         NUMBER
 FAILURE_COUNT                                      NUMBER
 MAX_FAILURE                                        NUMBER
 ERROR                                              VARCHAR2(256)
 ALTERNATE                                          VARCHAR2(256)
 DEPENDENCY                                         VARCHAR2(256)
 REMOTE_TEMPLATE                                    VARCHAR2(256)
 QUOTA_SIZE                                         NUMBER
 QUOTA_USED                                         NUMBER
 MOUNTID                                            NUMBER
 TRANSMIT_MODE                                      VARCHAR2(12)
 ASYNC_BLOCKS                                       NUMBER
 AFFIRM                                             VARCHAR2(3)
 TYPE                                               VARCHAR2(7)

En 10.2 la vue V$ARCHIVE_DEST a d'autres nouveaux champs : MAX_CONNECTIONS, VALID_NOW , VALID_TYPE, VALID_ROLE, DB_UNIQUE_NAME et VERIFY

Image non disponible

Le paramètre d'initialisation LOG_ARCHIVE_DEST_STATE_n (n un entier entre 1 et 10) consiste à contrôler l'état de la disponibilité d'une destination (n) spécifique.

ENABLED : indique que la base peut utiliser la destination.

DEFER : indique que cette location est temporairement désactivée.

ALTERNATE : indique que cette destination est alternée.

VI. Mode de transmission d'un fichier redo

Les deux modes pour transmettre les fichiers redo archivés dans leur destination sont : normal archiving transmission et standby transmission. La transmission normale concerne la transmission des fichiers dans des disques locaux. Standby transmission concerne la transmission des fichiers à travers le réseau soit en local ou à distante dans une base standby

VI-A. Mode de transmission normale

En mode de transmission normal, la destination de l'archive est un autre disque du serveur de la base. Dans cette configuration, l'archive n'est plus concurrente avec les autres fichiers réclamés par l'instance et peut finir rapidement. Il faut spécifier la destination soit avec LOG_ARCHIVE_DEST_n ou LOG_ARCHIVE_DEST.

Pour la bonne pratique, il faut toujours sauvegarder les fichiers redo archivés dans un support de stockage comme les bandes. Le rôle primordial des fichiers redo archivés est la restauration.

VI-B. Mode transmission standby

En mode de transmission standby, la destination de l'archive est soit en local ou en base standby distante.

Si nous manipulons notre base standby en mode managed recovery, nous pourrons conserver notre base standby synchronisée avec notre base source en appliquant automatiquement les redo archivés transmis.

Pour transmettre les fichiers avec succès à la base standby, soit ARCn ou le processus serveur doivent faire ce qui suit :

  • identifier l'emplacement distant ;
  • transmettre les journaux archivés ensemble avec le processus RFS (remote file server) qui réside dans le serveur distant.

Chaque processus ARCn a son correspondant RFS pour chaque destination standby. Par exemple, si trois processus ARCn sont archivés dans deux bases standby, alors Oracle établit six connexions RFS.

On transmet les fichiers redo archivés à travers le réseau vers un emplacement distant en utilisant les Services Oracle Réseaux. On spécifie au nom du service réseau, l'archive distante comme attribut de destination. La base Oracle traduit le nom du service, par le fichier tnsnames.ora, pour connecter le descripteur. Le descripteur contient l'information nécessaire pour se connecter à la base distante. Le nom du service doit avoir le SID de la base, de telle façon que la base mette à jour correctement la section log history dans le fichier de contrôle pour la base standby.

Le processus RFS, qui s'exécute dans le nœud de destination, agit comme un serveur réseau au client ARCn. Essentiellement, ARCn envoie l'information au RFS, qui la transmet à la base standby.

Le processus RFS, qui est réclamé quand on archive dans une destination distante est responsable des tâches suivantes :

  • consommer les E/S réseau depuis les processus ARCn ;
  • créer des noms de fichier dans la base standby en utilisant le paramètre STANDBY_ARCHIVE_DEST ;
  • peupler les fichiers journaux dans le site distant ;
  • mettre à jour le fichier de contrôle de la base standby (pour que le Recovery Manager l'utilise pour la restauration).

Les fichiers redo archivés sont essentiels pour maintenir une base standby, qui est une réplique exacte de la base. Nous pourrons faire fonctionner notre base mode archive standby, qui met à jour automatiquement la base standby avec les fichiers redo archivés depuis la base d'origine.

On peut maintenir une base standby dans un disque local, mais Oracle encourage fortement de maximiser la protection contre un désastre en conservant la base standby dans un site distant.

VII. Gestion des pannes des destinations archives

Le paramètre facultatif LOG_ARCHIVE_MIN_SCCEED_DEST détermine le nombre minimum de destinations dans lesquelles la base doit archiver les groupes redo avec succès avant qu'elle réutilise les fichiers redo en ligne. La valeur par défaut est à 1. Les valeurs valides pour n sont 1 et 2 si on utilise le duplexage ou 1 à 10 si on utilise le multiplexage.

Le paramètre LOG_ARCHIVE_DEST_n spécifie si la destination est OPTIONAL (par défaut) ou MANDATORY. Le paramètre LOG_ARCHIVE_MIN_SUCCEED_DEST utilise toutes les destinations MANDATORY plus quelques destinations OPTIONAL non standby pour déterminer si le process LGWR peut mettre à jour le fichier redo en ligne. Les règles suivantes s'appliquent :

  • omettre l'attribut MANDATORY pour une destination est le même que de spécifier OPTIONAL ;
  • on doit avoir au minimum une destination en local, pour qu'on déclare OPTIONAL ou MANDATORY ;
  • quand on spécifie une valeur à LOG_ARCHIVE_MIN_SUCCEED_DEST, Oracle devrait traiter au minimum une destination en local comme MANDATORY, car la valeur minimale pour LOG_ARCHIVE_MIN_SUCCEED_DEST est 1.

Si une destination MANDATORY échoue, contenant une destination standby MANDATORY, Oracle ignorera le paramètre LOG_ARCHIVE_MIN_SUCCEED_DEST.

La valeur du paramètre LOG_ARCHIVE_MIN_SUCCEED_DEST ne peut pas être plus grand que le nombre de destinations, non plus que le nombre de destinations MANDATORY plus le nombre de destinations locales OPTIONAL.

Si on diffère une destination MANDATORY, et que la base met à jour un journal redo en ligne sans transférer le fichier redo archivé dans le site standby, alors on doit transférer le journal à la base standby manuellement.

Si on duplexe les fichiers redo archivés, on peut établir les destinations qui sont obligatoires ou facultatives en utilisant les paramètres LOG_ARCHIVE_DEST et LOG_ARCHIVE_DUPLEX_DEST. Les règles suivantes s'appliquent :

  • toute destination déclarée par LOG_ARCHIVE_DEST est obligatoire ;
  • toute destination déclarée par LOG_ARCHIVE_DUPLEX_DEST est facultative si LOG_ARCHIVE_MIN_SUCCEED_DEST = 1 et obligatoire si LOG_ARCHIVE_MIN_SUCCEED_DEST = 2.

On peut voir la relation entre les paramètres LOG_ARCHIVE_DEST_n et LOG_ARCHIVE_MIN_SUCCEED_DEST plus facilement dans le scénario suivant.

Dans ce scénario, on archive dans trois destinations en local, et dans chacun d'eux on déclare OPTIONAL. Le tableau suivant illustre les valeurs possibles du LOG_ARCHIVE_MIN_SUCCEED_DEST.

Les valeurs de LOG_ARCHIVE_MIN_SUCCEED_DEST (scénario 1) :

Image non disponible

Ce scénario nous montre quand même de ne pas fixer explicitement aucune destination à MANDATORY utilisant le paramètre LOG_ARCHIVE_DEST_n, la base doit être archivée avec succès dans un ou plusieurs emplacements quand LOG_ARCHIVE_MIN_SUCCED_DEST est fixé à 1,2 ou 3.

Considérons les cas suivants :

on spécifie deux destinations MANDATORY ;

on spécifie deux destinations OPTIONAL ;

aucune destination dans la base standby.

Les valeurs de LOG_ARCHIVE_MIN_SUCCEED_DEST (scénario 2) :

Image non disponible

Ce cas montre que la base doit être archivée dans les destinations spécifiées par MANDATORY, sans se soucier si on fixe LOG_ARCHIVE_MIN_SUCCEED_DEST pour archiver dans un petit nombre de destinations.

Il faut utiliser l'attribut REOPEN du paramètre LOG_ARCHIVE_DEST_n pour spécifier quand ARCn devrait tenter de réarchiver dans une destination défaillie suivant l'erreur. REOPEN s'applique à toutes les erreurs, non seulement aux erreurs OPEN.

REOPEN=n, fixe le nombre minimum de secondes avant que le process ARCn doive essayer à rouvrir une destination défaillie. La valeur par défaut de n est de 300 secondes. Une valeur à 0 est pareille qu'enlever l'attribut REOPEN ; ARCn ne tentera pas d'archiver après une défaillance. Si on ne spécifie pas la clé REOPEN, le process ARCn ne recommencera plus à ouvrir une destination si erreur.

On ne peut pas utiliser REOPEN pour spécifier le nombre de tentatives que le process ARCn devrait faire pour rejoindre et transférer les fichiers redo archivés. La tentative REOPEN, soit elle réussit ou elle échoue.

Quand on spécifie REOPEN pour une destination OPTIONAL, Oracle peut mettre à jour les fichiers redo s'il y a erreur. Si on spécifie REOPEN pour une destination MANDATORY, Oracle décline une base de production quand il n'arrive pas à l'archiver. Dans cette situation, on considère les options suivantes :

  • archiver manuellement dans la destination défaillie ;
  • modifier la destination en la différant, on spécifie la destination comme facultative ou on modifie le service ;
  • supprimer la destination.

Quand on utilise le mot clé REOPEN on a :

  • ARCn rouvre la destination seulement quand on démarre une opération d'archivage depuis le début du fichier redo, jamais durant une opération en cours. ARCn essaye toujours de copier les fichiers redo depuis le début ;
  • si on spécifie REOPEN, soit avec un temps spécifique par défaut, ARCn vérifie pour voir si l'heure des erreurs enregistrées plus l'intervalle REOPEN est plus petit que l'heure actuelle. Si c'est le cas, ARCn essaye de copier les fichiers redo ;
  • la clause REOPEN affecte avec succès l'état de la destination ACTIVE=TRUE. Les états VALID et ENABLED ne sont pas modifiés.

VIII. Trace du processus d'archivage

Les processus Background écrivent toujours dans les fichiers traces quand c'est nécessaire. Dans le cas du processus d'archivage, nous pouvons contrôler la sortie produite dans le fichier trace, en fixant le paramètre d'initialisation LOG_ARCHIVE_TRACE par un niveau de trace. Cette valeur peut être spécifiée comme suit :

Image non disponible

Nous pouvons combiner les niveaux des traces en spécifiant une valeur égale à la somme des niveaux. Par exemple : LOG_ARCHIVE_TRACE=12 produit un fichier trace de niveau 8 et 4. Nous pourrons fixer différentes valeurs pour une base primaire et une base standby.

La valeur par défaut du paramètre LOG_ARCHIVE_TRACE est 0. À ce niveau, Le processus d'archivage génère les alertes appropriées.

On peut modifier la valeur de ce paramètre dynamiquement en utilisant la commande ALTER SYSTEM. La base doit être montée, mais non ouverte. Par exemple :

ALTER SYSTEM SET LOG_ARCHIVE_TRACE=12;

De cette manière, la modification prend effet au démarrage de la base à la prochaine opération d'archivage.

IX. Informations sur les vues des fichiers redo archivés

On peut afficher des informations concernant les fichiers redo archivés en utilisant :

  • les vues dynamiques ;
  • la commande ARCHIVE LOG LIST.

IX-A. Les vues dynamiques

Il existe plusieurs vues qui nous donnent des informations sur les fichiers redo archivés comme :

•V$LOG

•V$DATABASE

•V$ARCHIVED_LOG

•V$ARCHIVE

•V$ARCHIVE_GAP

•V$ARCHIVE_PROCESSES

•V$ARCHIVE_DEST

•V$ARCHIVE_DEST_STATUS

Par exemple pour savoir le fichier redo qui doit être archivé, on lance la commande suivante :

 
Sélectionnez
SQL> SELECT GROUP#, ARCHIVED FROM SYS.V$LOG;

    GROUP#     ARC
     -----------    ------
         1         YES
         2         YES
         3         NO

Pour savoir si la base est en mode ARCHIVELOG :

 
Sélectionnez
SELECT LOG_MODE FROM SYS.V$DATABASE;
LOG_MODE
------------
NOARCHIVELOG

IX-B. La commande ARCHIVE LOG LIST

La commande ARCHIVE LOG LIST affiche des informations sur les archives de l'instance connectée. Par exemple :

 
Sélectionnez
SQL> ARCHIVE LOG LIST
mode Database log                              mode No Archive
Archivage automatique                          Désactivé
Destination de l'archive                       USE_DB_RECOVERY_FILE_DEST
Séquence de journal en ligne la plus ancienne     82
Séquence de journal courante                      84

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2005 Mohammed Bouayoun. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.