Les Fichiers redo

Ce tutoriel présente la notion des fichiers redo (Oracle 8i à 10g).

Article lu   fois.

L'auteur

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

I.1. Introduction

Oracle utilise les fichiers redo pour être sûr que toute modification effectuée par un utilisateur ne sera pas perdue s'il y a défaillance du système. Les fichiers redo sont essentiels pour les processus de restauration. Quand une instance s'arrête anormalement, il se peut que certaines informations dans les fichiers redo ne soient pas encore écrites dans les fichiers de données. Oracle dispose les journaux redo en groupes.

Les fichiers redo doivent être placés sur des axes différents et des disques très rapides.

Chaque groupe a au moins un fichier redo. On doit avoir au minimum deux groupes distincts de fichiers redo (aussi appelés redo threads), chacun contient au minimum un seul membre. Car, si l'on n'a qu'un seul fichier redo, Oracle ecrasera ce fichier redo et on perdra toutes les transactions.

Chaque base de données à ses groupes de fichiers redo. Ces groupes, multiplexés ou non, sont appelés instance du thread de redo. Dans des configurations typiques, une seule instance de la base accède à la base Oracle. Ainsi, seulement un thread est présent. Dans un environnement RAC, deux ou plusieurs instances accèdent simultanément une seule base de données et chaque instance à son propre thread de redo.

Image non disponible
Groupe de fichiers de journalisations et les membres

I.1.1. Contenu du fichier redo

Les fichiers redo sont remplis par des enregistrements redo. Un enregistrement redo, aussi appelé une entrée redo, est composé d'un groupe de vecteurs de changements, qui est une description d'un changement effectué à un bloc de la base. Par exemple, si l'on modifie la valeur d'un salaire dans la table employé, on génère un enregistrement redo qui contient des vecteurs de changements décrivant les modifications sur le bloc du segment de données de la table, le bloc de données du segment undo et la table de transaction des segments undo.

Image non disponible


Les entrées redo enregistrent les données que l'on peut utiliser après pour reconstruire touts les changements effectués sur la base, segments undo inclus. De plus, le fichier redo protège aussi les données d'annulation. Quand on restaure la base en utilisant les données redo, la base lit les vecteurs de changements dans les enregistrements redo et applique le changement aux blocs appropriés.

Les enregistrements redo sont mis d'une façon circulaire dans le buffer redo log de la mémoire SGA. Et ils sont écrits dans un seul fichier redo par le processus LGWR. Dès qu'une transaction est validée, LGWR écrit les enregistrements redo de la transaction depuis le buffer redo log du SGA vers le fichier redo, et attribut un SCN pour identifier les enregistrements redo pour chaque transaction validée et ce, seulement lorsque tous les enregistrements redo associés à la transaction donnée sont sans incident sur le disque dans les fichiers redo en ligne et que le processus utilisateur a notifié que la transaction à été validée.

Image non disponible


Les enregistrements redo peuvent aussi être écrits dans le fichier redo avant que la transaction correspondante soit validée. Si le buffer redo log est plein ou une autre transaction à été validée, LGWR vide toutes les entrées redo du buffer redo log dans le fichier redo, bien que certain enregistrements redo ne devrait pas être validés. Si nécessaire, oracle peut annuler ces changements.

I.1.2. Comment Oracle écrit dans les fichiers redo

La base oracle exige au minimum deux fichiers redo.

LGWR écrit dans les fichiers redo d'une façon circulaire. Quand le fichier redo courant est plein, LGWR commence à écrire dans le prochain fichier redo disponible. Quand le dernier est plein, LGWR commence à écrire dans le premier fichier redo.

Image non disponible
Figure 1
  • Si l'archivage est désactivé (la base en mode NOARCHIVELOG), un fichier redo plein est disponible après que les changements enregistrés dedans sont écrits dans les fichiers de données.
  • Si l'archivage est activé (La base est en mode ARCHIVELOG), un fichier redo plein est disponible pour le processus LGWR après que les changements effectués dedans sont écrits dans les fichiers de données et était archivé.

Les fichiers redo Active (Courant) et Inactive

Oracle utilise un seul fichier redo à la fois pour stocker les enregistrements redo depuis le redo log buffer. Le fichier redo dont le processus LGWR est en train d'écrire dedans est appelé le fichier redo courant.

Les fichiers redo nécessaires à la restauration de la base sont appelés les fichiers redo actifs. Les fichiers redo qui ne sont pas nécessaires à la restauration s'appellent les fichiers redo inactifs.

Si on a activé l'archivage (mode ARCHIVELOG), alors la base ne peut pas réutiliser ou réécrire dans le fichier redo en ligne tant que l'un des processus ARCn n'a pas archivé ses contenus. Si l'archivage est désactivé (mode NOARCHIVELOG), alors quand le dernier fichier redo est plein, LGWR continue en sur écrivant le premier fichier actif disponible.

Les Logs Switchs et les numéros de séquence du journal

Un log switch est le point où la base arrête d'écrire dans l'un des fichiers redo en ligne et commence à écrire dans un autre. Normalement, un log switch survient quand le fichier redo courant est complètement rempli et il doit continuer à écrire dans le fichier redo suivant. Pourtant, on peut configurer les logs switchs pour qu'ils se reproduisent à intervalles réguliers, sans soucier si le fichier redo en cours est complètement rempli. On peut aussi forcer les log switch manuellement.

Oracle assigne à chaque fichier redo un nouveau numéro de séquence chaque fois qu'un log switch arrive et que le processus LGWR commence à écrire dedans. Quand oracle archive les fichiers redo, le fichier archivé garde le numéro de séquence du journal. Le fichier redo recyclé, fournit le prochain numéro de séquence du journal disponible.

Chaque fichier redo en ligne ou archivé est identifié uniquement par son numéro de séquence (log sequence).

Durant un crash, l'instance ou une restauration media , la base applique proprement les fichiers redo dans un ordre croissant en utilisant le numéro de séquence du fichier redo archivé nécessaire et des fichiers redo.

I.2. Informations sur les fichiers redo

Les vues V$THREAD, V$LOG, V$LOGFILE et V$LOG_HISTORY fournissent des informations sur les fichiers Redo.

La vue V$THREAD donne les informations sur le fichier redo en cours.

 
Sélectionnez

SQL> desc v$thread
 Nom                                       NULL ?   Type
 ----------------------------------------- -------- ------------

 THREAD#                                            NUMBER
 STATUS                                             VARCHAR2(6)
 ENABLED                                            VARCHAR2(8)
 GROUPS                                             NUMBER
 INSTANCE                                           VARCHAR2(80)
 OPEN_TIME                                          DATE
 CURRENT_GROUP#                                     NUMBER
 SEQUENCE#                                          NUMBER
 CHECKPOINT_CHANGE#                                 NUMBER
 CHECKPOINT_TIME                                    DATE
 ENABLE_CHANGE#                                     NUMBER
 ENABLE_TIME                                        DATE
 DISABLE_CHANGE#                                    NUMBER
 DISABLE_TIME                                       DATE
 LAST_REDO_SEQUENCE#                                NUMBER
 LAST_REDO_BLOCK                                    NUMBER
 LAST_REDO_CHANGE#                                  NUMBER
 LAST_REDO_TIME                                     DATE

SQL> select * from v$thread;

TRD# STAT ENABLED GRPS INST  OPEN     CURRENT SEQ CHECKP  CHECKP   ENABLE  ENABLE   DISABLE DIS  LAST  LAST  LAST    LAST
                                                                                                 REDO  REDO  REDO    REDO       
                             TIME     GROUP#      CHANGE  TIME     CHANGE# TIME     CHANGE# TIME SEQ   BLOCK CHANGE# TIME
---- ---- ------  ---- ----  ----     ------- --- ------- -------- ------- ------   ------- ---- ---- ------ ------- ---------
   1 OPEN PUBLIC     3 b10g2 19/10/05       2  81 3201917 19/10/05  547780 01/09/05       0        81   3755 3203391 19/10/05

La vue V$LOG donne les informations en lisant dans le fichier de contrôle au lieu de lire dans le dictionnaire de données.

 
Sélectionnez

SQL> desc v$log
 Nom                                       NULL ?   Type
 ----------------------------------------- -------- -------------

 GROUP#                                             NUMBER
 THREAD#                                            NUMBER
 SEQUENCE#                                          NUMBER
 BYTES                                              NUMBER
 MEMBERS                                            NUMBER
 ARCHIVED                                           VARCHAR2(3)
 STATUS                                             VARCHAR2(16)
 FIRST_CHANGE#                                      NUMBER
 FIRST_TIME                                         DATE
 
SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS    FIRST_CHANGE#   FIRST_TIME
    ------    -------  ---------      -----    ------- --- ------    -------------   --------

         1          1         41      52428800        1 NO INACTIVE  1867281         18/09/05
         2          1         42      52428800        1 NO CURRENT   1889988         18/09/05
         3          1         40      52428800        1 NO INACTIVE  1845207         18/09/05

Pour voir les noms des membres d'un groupe on utilise la vue V$LOGFILE

 
Sélectionnez

SQL> desc v$logfile
 Nom                                       NULL ?   Type
 ----------------------------------------- -------- ---------------

 GROUP#                                             NUMBER
 STATUS                                             VARCHAR2(7)
 TYPE                                               VARCHAR2(7)
 MEMBER                                             VARCHAR2(513)
 IS_RECOVERY_DEST_FILE                              VARCHAR2(3)
 
SQL> select * from v$logfile;

GROUP# STATUS  TYPE     MEMBER                                             IS_RECOVERY_DEST_FILE
------ ------- -------  -------------------                                ---------------------
     3 STALE   ONLINE   D:\ORACLE\PRODUCT\10.2.0\ORADATA\B10G2\REDO03.LOG  NO
     2         ONLINE   D:\ORACLE\PRODUCT\10.2.0\ORADATA\B10G2\REDO02.LOG  NO
     1 STALE   ONLINE   D:\ORACLE\PRODUCT\10.2.0\ORADATA\B10G2\REDO01.LOG  NO

GROUP# est le numéro du groupe Redo Log.

STATUS prend la valeur INVALID si le fichier est inaccessible, STALE si le fichier est incomplet , DELETED si le fichier n'est plus utilisé et vide si le fichier est en cours d'utilisation.

MEMBER est le nom du membre Redo Log

A partir de la 10g on a une nouvelle colonne dans la vue V$LOGFILE : IS_RECOVERY_DEST_FILE. Cette colonne se trouve dans les vues V$CONROLFILE, V$ARCHIVED_LOG, V$DATAFILE_COPY, V$DATAFILE et V$BACKUP_PIECE, elle prend la valeur YES si le fichier à été créé dans la région de restauration flash.

 
Sélectionnez

SQL> select * from V$LOG_HISTORY;

     RECID      STAMP    THREAD#  SEQUENCE# FIRST_CHANGE# FIRST_TI NEXT_CHANGE#  RESETLOGS_CHANGE#  RESETLOG
---------- ---------- ---------- ---------- ------------- -------- ------------  -----------------  --------
 
         1  567895614          1          1        547780 01/09/05       578189             547780   01/09/05
         2  567900275          1          2        578189 01/09/05       596011             547780   01/09/05
         3  567981823          1          3        596011 01/09/05       650604             547780   01/09/05
         4  568027925          1          4        650604 02/09/05       684588             547780   01/09/05 
         5  568203418          1          5        684588 03/09/05       714521             547780   01/09/05
         6  568233638          1          6        714521 05/09/05       752984             547780   01/09/05             
         7  568244091          1          7        752984 05/09/05       781475             547780   01/09/05
         8  568245159          1          8        781475 05/09/05       803278             547780   01/09/05
         9  568302950          1          9        803278 05/09/05       851785             547780   01/09/05
        10  568324398          1         10        851785 06/09/05       886760             547780   01/09/05

La vue V$LOG_HISTORY contient des informations concernant l'historique des fichiers redo à partir du fichier de contrôle. Le maximum que peut retenir la vue dépends du paramètre MAXLOGHISTORY.

La seule solution pour initialiser cette vue est de recréer le fichier de contrôle. voir Fichiers de Contrôle ou utiliser CONTROL_FILE_RECORD_KEEP_TIME.

Dans cette exemple on a l'erreur oracle suivante :

 
Sélectionnez

kccrsz: denied expansion of controlfile section 9 by 65535 record(s) 
the number of records is already at maximum value (65535) 
krcpwnc: following controlfile record written over: 
RECID #520891 Recno 53663 Record timestamp

On voit que le problème vient de la section 9 ce qui veut dire LOG HISTORY

 
Sélectionnez

SQL> select * from v$controlfile_record_section where type='LOG HISTORY' ;

TYPE 		RECORDS_TOTAL 	RECORDS_USED 	FIRST_INDEX 	LAST_INDEX 	LAST_RECID 
------------- 	------------- 	------------ 		----------- 		---------- 		---------- 
LOG HISTORY 	65535 		65535 		33864 		33863 		520892 

Ce qui montre que RECORD_USED a atteint le maximum autorisé RECORD_TOTAL.

La solution est de mettre le paramètre CONTROL_FILE_RECORD_KEEP_TIME à 0 dans le fichier d'initialisation ou utiliser la commande suivante :

 
Sélectionnez

SQL> alter system set control_file_record_keep_time=0; 

MAXLOGHISTORY augmente dynamiquement quand CONTROL_FILE_RECORD_KEEP_TIME est different de 0 mais il ne depasse jamais la valeur 65535.

Supposons que control_file_record_keep_time = 30 (30 jours) et qu'un fichier redo archivé soit géneré toutes les 30 secondes.

Pour 30 jours, on aura 86400 journaux ce qui dépassera la valeur 65535. Pour corriger le problème on met la paramètre control_file_record_keep_time à 0 et pour l'éviter on augmente la taille des fichiers redo.

I.3. Création des groupes et des membres redo

Pour créer un nouveau groupe de fichier redo ou un membre, on doit avoir le privilège système ALTER DATABASE. La base peut avoir au maximum MAXLOGFILES groupes.

I.3.1. Création des groupes de redo

Pour créer un nouveau groupe de fichiers redo, on utilise la requête ALTER DATABASE avec la clause ADD LOGFILE.

Par exemple :

 
Sélectionnez

ALTER DATABASE
ADD LOGFILE ('/oracle/dbs/log1c.rdo', '/oracle/dbs/log2c.rdo') SIZE 500K;

Il faut spécifier le chemin et le nom complet pour les nouveaux membres, sinon ils seront créés dans le répertoire par défaut ou dans le répertoire courant suivant l'OS.

On peut spécifier le numéro qui identifie le groupe en utilisant la clause GROUP :

 
Sélectionnez

ALTER DATABASE
ADD LOGFILE GROUP 10 ('/oracle/dbs/log1c.rdo', '/oracle/dbs/log2c.rdo')
SIZE 500K;

L'utilisation des numéros de groupes facilite l'administration des groupes de fichiers redo. Le numéro de groupe doit être entre 1 et MAXLOGFILES. Surtout ne pas sauter les numéros de groupes (par exemple 10, 20,30), sinon de l'espace dans les fichiers de contrôle sera consommé inutilement.

I.3.2. Création des membres de fichiers redo

Dans certain cas, il n'est pas nécessaire de créer complètement un groupe de fichiers redo. Le groupe peut déjà exister car un ou plusieurs membres ont été supprimés (par exemple, suite à une panne d'un disque). Dans ce cas, on peut ajouter de nouveaux membres dans le groupe existant.

La base peut avoir au maximum MAXLOGMEMBERS membres.


Pour créer un nouveau membre de fichier redo d'un groupe existant, on utilise la commande ALTER DATABASE avec la clause ADD LOGFILE MEMBER. Dans l'exemple suivant on ajoute un nouveau membre au groupe de redo numéro 2 :

 
Sélectionnez

ALTER DATABASE ADD LOGFILE MEMBER '/oracle/dbs/log2b.rdo' TO GROUP 2;

Notez que le nom du fichier doit être indiqué, mais sa taille n'est pas obligatoire. La taille du nouveau membre est déterminé à partir de la taille des membres existants du groupe.

Quand on utilse ALTER DATABASE, on peut identifier alternativement le groupe cible en spécifiant tous les autres membres du groupe dans la clause TO, comme le montre l'exemple suivant :

 
Sélectionnez

ALTER DATABASE ADD LOGFILE MEMBER '/oracle/dbs/log2c.rdo'
TO ('/oracle/dbs/log2a.rdo', '/oracle/dbs/log2b.rdo');

Il faut spécifier le nom du nouveau membre en entier en indiquant son chemin dans l'OS. Sinon, le fichier sera créé dans le répertoire par défaut ou dans le repertoire courant suivant l'OS. Il faut noter aussi que la statut du nouveau membre est INVALID. C'est normal, il prendra la valeur vide dès sa première utilisation.

I.4. Remplacement et renomination des membres de fichiers redo

On peut utiliser les commandes OS pour déplacer les fichiers redo. Après on utilise la commande ALTER DATABSE pour donner leurs nouveaux noms (emplacement) connus par la base. Cette procèdure est nécessaire, par exemple, si le disque, actuellement utilisé pour certains fichiers redo, doit être retiré, ou si les fichiers de données et certains fichiers redo se trouvent dans un même disque et devraient être séparés pour réduire la contention.

Pour renommer un membre de fichiers redo, on doit avoir le privilège système ALTER DATABASE.

En plus, on doit aussi avoir les privilèges système pour copier les fichiers dans le repertoire désiré et les privilèges pour ouvrir et sauvegarder la base de données.

Avant de déplacer les fichiers redo, ou tous autres changements de structures de la base, sauvegarder complètement la base. Par precaution, après la renommination ou le déplacement d'un ensemble de fichiers redo, effectuer immediatement une sauvegarde du fichier de contrôle.

Pour déplacer les fichiers redo, on utilise les méthodes suivantes :

  • Les fichiers redo sont situés dans deux disques : diska et diskb.
  • Les fichiers redo sont dupliqués : un groupe est constitué des membres /diska/logs/log1a.rdo et /diskb/logs/log1b.rdo, et le second groupe est constitué des membres /diska/logs/log2a.rdo et /diskb/logs/log2b.rdo.
  • les fichiers redo situés dans le disque diska doivent être déplacés dans le diskc. le nouveau nom du fichier reflète le nouveau emplacement : /diskc/logs/log1c.rdo et /diskc/logs/log2c.rdo.

Les étapes à suivre pour renommer les membres des fichiers redo :

1. Arrêter la base.

 
Sélectionnez

SHUTDOWN IMMEDIAT

2. Copier les fichiers redo dans le nouveau emplacement.

On peut utiliser la commande HOST pour lancer des commandes OS sans sortir de SQL*Plus. Sous certains OS on utilise un caractère à la place de HOST. Par exemple, sous UNIX on utilise le point d'exclamation (!).

L'exemple suivant utilise les commandes OS (UNIX) pour déplacer les membres des fichiers redo dans un nouvel emplacement :

 
Sélectionnez

mv /diska/logs/log1a.rdo /diskc/logs/log1c.rdo
mv /diska/logs/log2a.rdo /diskc/logs/log2c.rdo

3. Démarrer la base avec un mount, sans l'ouvrir.

 
Sélectionnez

CONNECT / as SYSDBA
STARTUP MOUNT

4. Renommer le membre du fichier redo.

 
Sélectionnez

ALTER DATABASE
RENAME FILE '/diska/logs/log1a.rdo', '/diska/logs/log2a.rdo'
TO '/diskc/logs/log1c.rdo', '/diskc/logs/log2c.rdo';

5. Ouvrir la base normalement.

La modification du fichier redo prend effet à l'ouverture de la base.

 
Sélectionnez

ALTER DATABASE OPEN;

I.5. Suppression du groupe de fichiers redo

Dans certains cas, on doit supprimer un groupe en entier. Par exemple, on veut réduir le nombre de groupes. Dans d'autres cas, on doit supprimer un ou plusieurs membres. Par exemple, si certains membres se trouvent dans un disque défaillant.

Image non disponible
Suppression d'un groupe


Pour supprimer un groupe de fichiers redo, on doit avoir le privilège système ALTER DATABASE.

Avant de supprimer un groupe de fichiers redo, il faut prendre en considération les restrictions et les précautions suivantes :

  • Une instance réclame au minimum deux groupes de fichiers redo, sans se soucier du nombre de membres dans le groupe. (Un groupe contient un ou plusieurs membres.)
  • On peut supprimer un groupe de fichiers redo, seulement s'il est inactif. Si on a besoin de supprimer le groupe courant, en premier, on force un switch log.
  • S'assurer que le groupe de fichiers redo est bien archivé (si l'archivage est activé) avant de le supprimer.

Pour voir ce qui se passe, utilisez la vue V$LOG.

 
Sélectionnez

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

    GROUP# ARC STATUS
---------- --- ----------------
         1 YES ACTIVE
         2 NO CURRENT
         3 YES INACTIVE
         4 YES INACTIVE

Supprimer un groupe de fichiers redo avec la commande ALTER DATABASE en utilisant la clause DROP LOGFILE.

Dans cette exemple on supprime le groupe numéro 3 :

 
Sélectionnez

ALTER DATABASE DROP LOGFILE GROUP 3;

Quand un groupe est supprimé de la base et que l'on n'utilise pas l'OMF, les fichiers OS ne seront pas supprimés du disque. Il faut utiliser les commandes OS pour les supprimer physiquement.

Quand on utilise OMF, le nettoyage des fichiers OS se fait automatiquement.

I.6. Suppression des membres de fichiers redo

Pour supprimer un membre d'un fichier redo, on doit avoir le privilège système ALTER DATABASE.

Pour supprimer un membre inactive d'un fichier redo, on utilise la commande ALTER DATABASE avec la clause DROP LOGFILE MEMBER.

Image non disponible
Suppression d'un membre


La commande suivante supprime le journal /oracle/dbs/log3c.rdo :

 
Sélectionnez

ALTER DATABASE DROP LOGFILE MEMBER '/oracle/dbs/log3c.rdo';

Quand un membre d'un journal est supprimé, le fichier OS n'est pas supprimé du disque.

Pour supprimer un membre d'un groupe actif, on doit forcer en premier le log switch.

I.7. Forcer les Logs Switchs

Le log switch se produit quand LGWR s'arrête d'écrire dans un groupe de journaux et commence à écrire dans un autre. Par défaut, un log switch se produit automatiquement quand le groupe du fichier redo en cours est rempli.

On peut forcer un log switch pour que le groupe courant soit inactif et disponible pour des opérations de maintenance sur les fichiers redo. Par exemple, on veut supprimer le groupe actuellement actif, mais on est incapable de le supprimer tant qu'il est actif. On doit aussi obliger un switch log si le groupe actuellement actif a besoin d'être archivé à un moment spécifique avant que les membres du groupe soient complètement remplis. Cette option est utile dans des configurations où les fichiers redo sont assez larges et prennent plus de temps pour se remplir.

Pour forcer un log switch, on doit avoir le privilège ALTER SYSTEM. Utilisez la commande ALTER SYSTEM avec la clause SWITCH LOGFILE.

La commande suivante force un log switch:

 
Sélectionnez

ALTER SYSTEM SWITCH LOGFILE;
Avant le log switch Après le log switch
 Image non disponible  Image non disponible

Oracle conseille un switch de fichier redo tous les 30 minutes.

I.8. Vérification des blocs dans les fichiers redo

On peut configurer la base pour utiliser le CHECKSUM, afin que les blocs des fichiers redo soient vérifiés. Si l'on affecte le paramètre d'initialisation DB_BLOCK_CHECKSUM à TRUE, Oracle calcule le checksum pour chaque bloc oracle quand il écrit dans le disque, y compris les blocs des journaux. Le checksum est stocké dans l'en-tête du bloc.

Oracle utilise le checksum pour détecter les blocs corrompus dans les fichiers redo. La base vérifie le bloc du journal quand le bloc est lu à partir du journal archivé durant la restauration et quand il écrit le bloc dans le journal archivé. Une erreur sera détectée et écrite dans le fichier d'alerte si une corruption est détectée.

Si une corruption est détectée dans un bloc du journal pendant son archivage, le système tente de lire le bloc depuis un autre membre dans le groupe. Si le bloc est corrompu dans tous les membres du groupe des journaux, alors l'archivage ne peut pas se poursuivre.

La valeur par défaut du paramètre DB_BLOCK_CHECKSUM est TRUE. La valeur de ce paramètre peut être modifiée dynamiquement en utilisant ALTER SYSTEM

L'activation de DB_BLOCK_CHECKSUM diminue la performance de la base. Il faut bien surveiller les performances de la base pour décider s'il est avantageux d'utiliser le checksum de bloc de données.

I.9. Initialisation des fichiers redo

On peut initialiser un fichier redo sans arrêter la base, par exemple, si le fichier redo est corrompu.

Image non disponible
Initialisation d'un groupe
 
Sélectionnez

ALTER DATABASE CLEAR LOGFILE GROUP (numero du groupe);

On peut utiliser cette commande si on ne peut pas supprimer les fichiers redo , il y a deux situations :

  • S'il y a seulement deux groupes de journaux
  • Le journal corrompu appartient au groupe en cours

Si le fichier redo corrompu n'est pas encore archivé, on utilise la clé UNARCHIVED.

 
Sélectionnez

ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP (numero du groupe);

Cette commande initialise les fichiers redo corrompus et évite leur archivage.

Si l'on initialise le fichier redo nécessaire à la restauration ou à la sauvegarde, on ne peut plus restaurer depuis cette sauvegarde.

Si on initialise un fichier redo non archivé, on devrait faire une autre sauvegarde de la base.

Pour initialiser un fichier redo non archivé qui est nécessaire pour mettre un tablespace hors ligne en ligne, on utilise la clause UNRECOVERABLE DATAFILE dans la commande DATABASE CLEAR LOGFILE.

Si on initialise un fichier redo nécessaire pour mettre un tablespace hors ligne en ligne, on sera incapable de mettre le tablespace en ligne une autre fois. On est obligé de supprimer le tablespace ou effectuer une restauration incomplète. Il faut noter que le tablespace mis hors ligne normalement n'a pas besoin de restauration.

I.10. Test sur les fichiers redo

 T1 Dans une seule instance Oracle, on peut avoir :
 Image non disponible Un seul thread
 Image non disponible Deux threads
 Image non disponible Quatre threads
 Image non disponible Aucun thread
 T2 Les fichiers redo sont remplis par des enregistrements
 Image non disponible Undo
 Image non disponible Redo
 Image non disponible Vecteurs de journaux
 Image non disponible Vecteurs de changements
T3 Les enregistrements redo sont écrits dans le fichier redo par le processus
 Image non disponible DBWR
 Image non disponible CKPT
 Image non disponible LGWR
 Image non disponible RDWR
T4 Les enregistrements redo peuvent aussi être écrits dans le fichier redo avant que
 Image non disponible le buffer redo log soit plein
 Image non disponible Le processus LGWR lui ait attribu un numéro SCN
 Image non disponible la transaction correspondante soit validé.
T5 La base oracle exige au minimum
 Image non disponible trois fichiers de journalisation.
 Image non disponible aucun fichier de journalisation.
 Image non disponible un fichier de journalisation.
 Image non disponible deux fichiers de journalisation.
T6 LGWR commence à écrire dans le prochain fichier journal redo disponible
 Image non disponible Quand tous les fichiers redo sont pleins
 Image non disponible Quand le fichier redo courant est plein
 Image non disponible Quand on fait un switch log
 Image non disponible Quand on arrête la base par un SHUTDOWN IMMEDIATE
T7 Dans une base en mode ARCHIVELOG, un fichier de journalisation plein est disponible pour le processus LGWR après que
 Image non disponible Son contenu soit écrit dans les fichiers de données
 Image non disponible Son contenu soit vidé
 Image non disponible Sans condition
 Image non disponible Son contenu soit écrit dans les fichiers de données et il est bien archivé
T8 Un log switch survient
 Image non disponible quand le fichier de journalisation courant est complètement rempli
 Image non disponible quand le fichier de journalisation courant est 1/3 rempli
 Image non disponible après la commande ALTER SYSTEM SWITCH LOGFILE;
 Image non disponible après la commande ALTER SYSTEM SWITCH LOG FILE;
T9 Chaque fichier de journalisation ou archive est identifié uniquement par
 Image non disponible un RBA
 Image non disponible un SCN
 Image non disponible son numéro de séquence
 Image non disponible son RDBA
T10 Les vues suivantes donnent des informations sur le fichier de journalisation
 Image non disponible V$LOGFILE
 Image non disponible V$LOGFILES
 Image non disponible V$THREADS
 Image non disponible V$THREAD
T11 La seule solution pour initialiser la vue V$LOG_HISTORY
 Image non disponible modifier le paramètre CONTROL_FILE_RECORD_KEEP_TIME
 Image non disponible en ajoutant un nouveau groupe de fichiers redo
 Image non disponible en ajoutant un nouveau membre de fichiers redo
 Image non disponible recréer le fichier de contrôle
 T12 Le numéro de groupe doit être entre
 Image non disponible 1 et MAXLOGMEMBER
 Image non disponible 1 et 10
 Image non disponible 1 et MAXLOGFILES
 Image non disponible 1 et MAXLOGMEMBERS
T13 Pour supprimer un groupe de journaux, on doit avoir le privilège système
 Image non disponible ALTER LOGFILE
 Image non disponible ALTER SYSTEM
 Image non disponible ALTER DATABASE
 Image non disponible Aucun privilège système
 T14 On peut supprimer un groupe de journaux, seulement s'il est
 Image non disponible INACTIF
 Image non disponible OFFLINE
 Image non disponible ACTIF
 Image non disponible sans se soucier s'il est INACTIF, OFFLINE ou ACTIF
 T15 Pour supprimer le groupe 3 physiquement (sans OMF) :
 Image non disponible Avec la commande ALTER DATABASE DROP LOGFILE OS GROUP 3
 Image non disponible les fichiers OS ne seront pas supprimés du disque
 Image non disponible les fichiers OS seront supprimés du disque
 Image non disponible Il faut utiliser les commandes OS pour les supprimer physiquement
T16 La commande suivante supprime le journal /oracle/dbs/log3c.rdo
 Image non disponible ALTER DATABASE DROP MEMBER '/oracle/dbs/log3c.rdo';
 Image non disponible ALTER DATABASE DROP LOGFILE '/oracle/dbs/log3c.rdo';
 Image non disponible ALTER DATABASE DROP LOGFILE MEMBER '/oracle/dbs/log3c.rdo';
 Image non disponible ALTER SYSTEM DROP LOGFILE MEMBER '/oracle/dbs/log3c.rdo';
T17 La commande suivante force un log switch
 Image non disponible ALTER SYSTEM SWITCH LOGFILE;
 Image non disponible ALTER DATABASE SWITCH LOGFILE;
 Image non disponible ALTER SYSTEM SWITCH LOG FILES;
 Image non disponible ALTER DATABASE SWITCH LOG FILES;
T18 Dans 10g la valeur du paramètre DB_BLOCK_CHECKSUM
 Image non disponible la valeur à TRUE augmente la performance de la base
 Image non disponible la valeur à TRUE diminue la performance de la base
 Image non disponible par défaut est FALSE
 Image non disponible par défaut est TRUE
T19 On peut initialiser un fichier de journalisation sans arrêter la base avec la commande
 Image non disponible ALTER DATABASE CLEAR GROUP (numero du groupe);
 Image non disponible ALTER DATABASE INITIALIZE GROUP (numero du groupe);
 Image non disponible ALTER DATABASE INITIALIZE LOGFILE GROUP (numero du groupe);
 Image non disponible ALTER DATABASE CLEAR LOGFILE GROUP (numero du groupe);
T20 Pour initialiser un journal non archivé qui est nécessaire pour mettre un tablespace hors ligne en ligne, on utilise
 Image non disponible la clause UNARCHIVED DATAFILE dans la commande DATABASE CLEAR LOGFILE
 Image non disponible la clause UNRECOVERABLE DATAFILE dans la commande DATABASE CLEAR LOGFILE
 Image non disponible la clause UNARCHIVED LOGFFILE dans la commande DATABASE CLEAR LOGFILE
 Image non disponible la clause UNRECOVERABLE LOGFILE dans la commande DATABASE CLEAR LOGFILE



Solutions :

T1 : A
T2 : B et D
T3 : C
T4 : A et C
T5 : D
T6 : B et C
T7 : D
T8 : A et C
T9 : A
T10 : A et D
T11 : A et D
T12 : C
T13 : C
T14 : A
T15 : B et D
T16 : C
T17 : A
T18 : B et D
T19 : D
T20 : B

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

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.