Arch Redo

Les fichiers redo archivés
Par Mohammed Bouayoun
Date de publication : 20 octobre 2005

Les fichiers redo archivés par Mohammed Bouayoun
I - Le mode NOARCHIVELOG et ARCHIVELOG....................................................................................................... 3

I-A - Le mode NOARCHIVELOG........................................................................................................................... 3
I-B - Le mode ACHIVELOG................................................................................................................................... 3
II - Changement du mode d'archivage........................................................................................................................4
III - L'archivage manuel et l'archivage automatique....................................................................................................5
IV - Destination des Archives...................................................................................................................................... 6
IV-A - Méthode 1 : Utilisation du paramètre LOG_ARCHIVE_DEST_n................................................................ 6
IV-B - Méthode 2 : LOG_ARCHIVE_DEST et LOG_ARCHIVE_DUPLEX_DEST................................................. 7
V - Statut des destinations d'archives.........................................................................................................................7
VI - Mode de transmission d'un fichier redo............................................................................................................... 8
VI-A - Mode de transmission normale................................................................................................................... 8
VI-B - Mode transmission standby.........................................................................................................................9
VII - Gestion des pannes des destinations archives...................................................................................................9
VIII - Trace du processus d'archivage.......................................................................................................................11
IX - Informations sur les vues des fichiers redo archivés......................................................................................... 12
IX-A - Les vues dynamiques................................................................................................................................12
IX-B - La commande ARCHIVE LOG LIST......................................................................................................... 13
-2-
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 et 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.
https://mbouayoun.developpez.com/archredo/
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.
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.
-3-
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.
-4-
STARTUP MOUNT
5. Modifier le mode d'archivage et ouvrir la base.
ALTER DATABASE ARCHIVELOG;

ALTER DATABASE OPEN;
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.
-5-
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 :
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 :
SHUTDOWN
2. On fixe le paramètre d'initialisation LOG_ARCHIVE_DEST_n. Par exemple :
LOG_ARCHIVE_DEST_1 = 'LOCATION = /disk1/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 :
-6-
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 :
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 :
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.
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
-7-
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
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.
-8-
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.
-9-
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) :
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.
- 10 -
Les valeurs de LOG_ARCHIVE_MIN_SUCCEED_DEST (scénario 2) :
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 :
- 11 -
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
- 12 -
•V$ARCHIVE_DEST
•V$ARCHIVE_DEST_STATUS
Par exemple pour savoir le fichier redo qui doit être archivé, on lance la commande suivante :
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 :
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 :
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
- 13 -

Arch Redo

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Arch Redo

Transféré par

Droits d'auteur :

Formats disponibles

Les fichiers redo archivés

Par Mohammed Bouayoun

Date de publication : 20 octobre 2005

I - Le mode NOARCHIVELOG et ARCHIVELOG....................................................................................................... 3

I - Le mode NOARCHIVELOG et ARCHIVELOG

I-A - Le mode NOARCHIVELOG

I-B - Le mode ACHIVELOG

II - Changement du mode d'archivage

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

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

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

ALTER DATABASE ARCHIVELOG;

III - L'archivage manuel et l'archivage automatique

ALTER DATABASE ARCHIVELOG;

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.

IV - Destination des Archives

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

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

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

LOG_ARCHIVE_DEST_1 = 'LOCATION = /disk1/archive'

LOG_ARCHIVE_DEST_4 = 'SERVICE = standby1'

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

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

Pour cela, il faut :

2. Spécifier les paramètres LOG_ARCHIVE_DEST et LOG_ARCHIVE_DUPLEX_DEST (on peut utiliser la

3. Fixer le paramètre d'initialisation LOG_ARCHIVE_FORMAT

V - Statut des destinations d'archives

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

SQL> desc V$ARCHIVE_DEST

En 10.2 la vue V$ARCHIVE_DEST a d'autres nouveaux champs : MAX_CONNECTIONS, VALID_NOW ,

Le paramètre d'initialisation LOG_ARCHIVE_DEST_STATE_n (n un entier entre 1 et 10) consiste à contrôler l'état

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

VI-A - Mode de transmission normale

VI-B - Mode transmission standby

• identifier l'emplacement distant ;

• consommer les E/S réseau depuis les processus ARCn ;

VII - Gestion des pannes des destinations archives

Le paramètre facultatif LOG_ARCHIVE_MIN_SCCEED_DEST détermine le nombre minimum de destinations dans

Le paramètre LOG_ARCHIVE_DEST_n spécifie si la destination est OPTIONAL (par défaut) ou MANDATORY.

• toute destination déclarée par LOG_ARCHIVE_DEST est obligatoire ;

On peut voir la relation entre les paramètres LOG_ARCHIVE_DEST_n et LOG_ARCHIVE_MIN_SUCCEED_DEST

Les valeurs de LOG_ARCHIVE_MIN_SUCCEED_DEST (scénario 1) :

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) :

• archiver manuellement dans la destination défaillie ;

Quand on utilise le mot clé REOPEN on a :

VIII - Trace du processus d'archivage

ALTER SYSTEM SET LOG_ARCHIVE_TRACE=12;

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

• les vues dynamiques ;

IX-A - Les vues dynamiques

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

Pour savoir si la base est en mode ARCHIVELOG :

SELECT LOG_MODE FROM SYS.V$DATABASE;

IX-B - La commande ARCHIVE LOG LIST