Developpez.com - Oracle
X

Choisissez d'abord la catégorieensuite la rubrique :


Les Fichiers redo archivés

Date de publication : le 20 Octobre 2005

Par Mohammed Bouayoun
 


I. Le mode NOARCHIVELOG et ARCHIVELOG
I.1. Le mode NOARCHIVELOG
I.2. Le mode ACHIVELOG
II. Changement du mode d'archivage
III. L'archivage manuel et l'archivage automatique
IV. Déstination des Archives
IV.1. Methode 1 : Utilisation du paramètre LOG_ARCHIVE_DEST_n
IV.2. Methode 2 : LOG_ARCHIVE_DEST et LOG_ARCHIVE_DUPLEX_DEST
V. Statut des destinations d'archives
VI. Mode de transmission d'un fichier redo
VI.1. Mode de transmission normal
VI.2. Mode transmission standby
VII. Gestion des pannes des destinations archives
VIII. Trace du processus d'archivage
IX. Informations sur les vues des fichiers redo archivés
IX.1. Les vues dynamique
IX.2. La commande ARCHIVE LOG LIST


I. Le mode NOARCHIVELOG et ARCHIVELOG


I.1. 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és 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.

   LGWR écrit dans le premier fichier redo
   Le premier fichier redo est plein. LGWR écrit dans le second fichier redo2
   Le second fichier redo est plein. LGWR écrit dans le troisième fichier redo3
   Après que le dernier fichier redo est plein, LGWR écrit sur le premier fichier redo

I.2. 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.

   LGWR écrit dans le premier fichier redo
   Lé premier fichier redo est plein. LGWR écrit dans le second fichier redo2 e ARCn crée une copie de redo1
   Lé second fichier redo est plein. LGWR écrit dans le troisième fichier redo3, ARCn crée une copie du fichier redo2 et le cycle continue

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 cette 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 ce protéger d'un autre nouveau problème.

3. Editer le fichier d'initialisation pour ajouter les paramètres qui spécifies la déstination 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.
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;
6. Arrêter la base..
SHUTDOWN IMMEDIATE
7. Sauvegarde la base.

Le changement du mode d'archivage mettra à jours 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 fini 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. Déstination 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 :

Méthode Paramètre d'initialisation Host Exemple
1 LOG_ARCHIVE_DEST_n avec n entre 1 et 10 remote et local LOG_ARCHIVE_DEST_1 ='LOCATION=/disk1/arc' LOG_ARCHIVE_DEST_2 = 'SERVICE=standby1'
2 LOG_ARCHIVE_DEST et LOG_ARCHIVE_DUPLEX_DEST seulement local LOG_ARCHIVE_DEST = '/disk1/arc' LOG_ARCHIVE_DUPLEX_DEST = '/disk2/arc'

IV.1. Methode 1 : Utilisation du paramètre LOG_ARCHIVE_DEST_n

On utilise le paramètre LOG_ARCHIVE_DEST_n (avec n un entier antre 1 et 10) pour désigner l'un 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 à jours 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
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.

idea 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.2. Methode 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 modifiés dynamiquement).

Par exemple
LOG_ARCHIVE_DEST = '/disk1/archive'
LOG_ARCHIVE_DUPLEX_DEST = '/disk2/archive'
3. Fixer le paramète 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 specifié et valide.

Enabled/Disabled : indique l'état de la disponibilité de la location et si la base peut utiliser cette déstination.

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

Plusieurs combinaisons sont possibles. Pour obtenir la 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
 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 à d'autres nouveaux champs : MAX_CONNECTIONS, VALID_NOW , VALID_TYPE, VALID_ROLE, DB_UNIQUE_NAME et VERIFY

STATUS Valid Enabled Active Signification
VALID True True True L'utilisateur à proprement initialiser la destination, qui est disponible pour l'archivage.
INACTIVE False n/a n/a L'utilisateur n'a pas fournis ou il a supprimer l'information sur la destination.
ERROR True True True Une erreur s'est produite en créant ou en écrivant dans le fichier de destination. voir l'erreur.
FULL True True False La destination est plein.
DEFERRED True False True L'utilisateur à manuellement et temporairement désactiver la destination.
DISABLED True False False L'utilisateur à manuellement et temporairement désactiver la destination suite à une erreur. Voir l'erreur.
BAD PARAM n/a n/a n/a Une erreur de paramètre à eu lieu, voir l'erreur.

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 leurs déstinations sont : normal archiving transmission et standby transmission. La transmission normal concerne la transmission des fichiers dans des disques locaux. Standby transmission concerne la transmission des fichiers à travers le reseau soit en local ou à distante dans une base standby


VI.1. Mode de transmission normal

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 concurrent 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.2. 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é 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 doit 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 à son correspondant RFS pour chaque destination standby. Par exemple, si trois processus ARCn sont archivés dans deux bases standby, alors Oracle établi six connections RFS.

On transmis 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 distant 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 à ce que la base met à jours correctement la section log history dans le fichier de contrôle pour la base standby.

Le processus RFS, qui s'exécute dans le noeud de destination, agi comme un serveur réseau au client ARCn. Essentiellement, ARCn envoi l'information au RFS, qui la transmis à la base standby.

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

  • Consommer les E/S réseau depuis les processus ARCn.
  • Créer des noms de fichiers dans la base standby en utilisant le paramètre STANDBY_ARCHIVE_DEST.
  • Peupler les fichiers journaux dans le site distant.
  • Mettre à jours 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 fonctionner notre base mode archive standby, qui mis à jours automatiquement la base standby avec les fichiers redo archivés depuis la base d'origine.

warning 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 laquelle 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 à jours le fichier redo en ligne. Les règles suivantes s'appliquent :

  • Omettre l'attribut MANDATORY pour une destination est la même que de spécifier OPTIONAL
  • On doit avoir au minimum une destination en locale, 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 locale comme MANDATORY, car la valeur minimal 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 destination MANDATORY plus le nombre de destinations local OPTIONAL.

Si on différe une destination MANDATORY, et la base met à jours 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) :

Valeur Signification
1 La base peut réutiliser les fichiers redo seulement si au moins un des destinations OPTIONAL à reussi.
2 La base peut réutiliser les fichiers redo seulement si au moins deux des destinations OPTIONAL ont reussis.
3 La base peut réutiliser les fichiers redo seulement si toutes les destinations OPTIONAL ont reussis.
4 et plus ERROR: La valeur est plus grande qu'au nombres des destinations.

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

Valeur Signification
1 La base ignore la valeur et utilise le nombre de destination MANDATORY (dans cet exemple,2).
2 La base peut réutiliser les fichiers redo même si aucune destination OPTIONAL n'a réussi.
3 La base peut réutiliser les fichiers redo seulement si au moins un des destinations OPTIONAL à réussi.
4 La base peut réutiliser les fichiers redo seulement si les deux destinations OPTIONAL ont réussis.
5 ou plus ERROR: La valeur est plus grande qu'au nombres des destinations.

Ce cas montre que la base doit être archivée dans les destinations spécifiées par MANDATORY, sans 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 à réarchiver dans une destination défailli suivant l'erreur. REOPEN s'applique à tous les erreurs, non seulement au erreurs OPEN.

REOPEN=n, fixe le nombre minimum de secondes avant que le process ARCn devrait essayer à rouvrir une destination défaillie. La valeur par défaut de n est de 300 secondes. Une valeur à 0 est pareil que d'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 tentative que le process ARCn devrait faire pour rejoindre et transférer les fichiers redo archivés. La tentative REOPEN soit elle réussi ou elle échoue.

Quand on spécifie REOPEN pour une destination OPTIONAL, Oracle peut mettre à jours 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 facultatif 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é comme suit :

Niveau de Trace Signification
0 Désactive la trace des fichiers redo archivés. Par défaut.
1 Piste l'archivage du fichier redo.
2 Piste la statu de l'archivage pour chaque destination du fichier redo archivés.
4 Piste la phase opérationnelle de l'archivage.
8 Piste l'activité de la destination des fichiers redo archivés.
16 Piste l'activité détaillée de la destination des fichiers redo archivés.
32 Piste les modifications du paramètre de destinations des fichiers archivés.
64 Piste l'activité de l'état du process ARCn.
128 Piste les activités du serveur FAL (fetch archived log).
256 Pour une version future.
512 Piste l'activité asynchrone du LGWR.
1024 Piste le client physique RFS.
2048 Piste le heartbeat du ARCn/RFS .
4096 Piste en temps réel.

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érents valeurs pour une base primaire et une base standby.

La valeur par défaut du paramètre LOG_ARCHIVE_TRACE est 0. A 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;
A 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 dynamique
  • La commande ARCHIVE LOG LIST

IX.1. Les vues dynamique

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 :
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.2. La commande ARCHIVE LOG LIST

La commande ARCHIVE LOG LIST affiche des informations sur las archives de l'instance connecté. 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


Valid XHTML 1.1!Valid CSS!

Ce document est issu de http://www.developpez.com et reste la propriété exclusive de son auteur. La copie, modification et/ou distribution par quelque moyen que ce soit est soumise à l'obtention préalable de l'autorisation de l'auteur.
Contacter le responsable de la rubrique Oracle