Présentation de l'outil RMAN d'Oracle

RMAN (Recovery MANager) est un utilitaire standard de la base de données Oracle. Il permet aux DBA de gérer les opérations de sauvegarde/restauration de manière souple et optimisée.
RMAN est le successeur de EBU (Enterprise Backup Utility). Il est codé en Pro*C.

Livré en standard depuis la version 8 d'Oracle, il ne nécessite pas d'installation particulière (cf chapitre Mise en œuvre de RMAN). Il offre la possibilité :

• de réaliser des sauvegardes globales de la base, d'espaces disque logiques (tablespace), de fichiers de données (datafiles), de fichiers de contrôle (controlfiles) et de fichiers d'archive (archivelog) ;
• de réaliser des sauvegardes incrémentielles (différentielles ou cumulatives) au niveau bloc de données Oracle ;
• d'éviter de sauvegarder les blocs Oracle vides, ce qui permet un gain significatif de volume de sauvegarde ;
• de s'interfacer avec un outil de sauvegarde externe (gestionnaire de médias) ;
• de garder la trace des sauvegardes soit dans un catalogue de récupération (recovery catalog), soit dans les fichiers de contrôle (cf chapitre Mise en œuvre) ;
• d'effectuer des restaurations globales ou partielles ;
• de paralléliser les opérations de sauvegarde/restauration afin d'accroître les performances ;
• de gérer les périodes de conservation des sauvegardes ;
• de placer les opérations de sauvegarde/restauration courantes dans le catalogue sous forme de scripts (à la condition d'utiliser le catalogue RMAN) ;
• de dupliquer une base de données de manière simple ;
• de mutualiser les scripts de sauvegardes, ils ne sont pas dépendants du système d'exploitation. RMAN dispose de son propre langage de script ;
• d'éditer des rapports ;
• de sauvegarder ou dupliquer les bases de données. Les copies n'ont qu'un intérêt limité par rapport aux copies OS ;
• de vérifier les sauvegardes effectuées en termes de corruption et ne corrompt pas les bases qu'il sauvegarde (contrairement à la copie de fichiers de données sans positionner les tablespaces en mode backup) ce qui est un avantage non négligeable.

RMAN permet donc les types de sauvegardes suivants :

• de type COMPLET (ou FULL) : on sauvegarde tous les blocs ;
• de type DIFFÉRENTIEL : on sauvegarde uniquement les blocs modifiés depuis la précédente sauvegarde de niveau n ou inférieur ;
• de type CUMULATIF : on sauvegarde uniquement les blocs modifiés depuis la précédente sauvegarde de niveau n-1.

RMAN gère trois niveaux de sauvegardes incrémentielles :

• Niveau 0 : base de tous les autres niveaux (Sauvegarde de l'ensemble des blocs contenant des données) ;
• Niveau 1 : sauvegarde tous les blocs qui ont changé depuis la plus récente sauvegarde incrémentielle de niveau 0 ;
• Niveau 2 : sauvegarde tous les blocs qui ont changé depuis la plus récente sauvegarde incrémentielle de niveau 0, 1 ou 2.

Exemple de sauvegarde DIFFÉRENTIELLE :

Exemple de sauvegarde CUMULATIVE :

Dans la plupart des cas, si vous avez besoin de faire des restaurations rapides, les sauvegardes cumulatives sont préférables aux sauvegardes incrémentielles, car il faudra restaurer uniquement la sauvegarde de niveau 0 + une seule cumulative. Prenons un exemple avec deux stratégies de sauvegarde : une en mode différentiel et une en mode cumulatif. Supposons un plantage de la base le mercredi matin. Pour restaurer votre base avec la première stratégie, il faut restaurer la sauvegarde de niveau 0 + 3 sauvegardes incrémentielles de niveau 2 (lundi, mardi et mercredi).Dans le cas de la seconde stratégie en mode cumulatif, on ne restaure que la sauvegarde de niveau 0 + la sauvegarde de niveau 2 du mercredi, ce qui est forcément plus rapide. En revanche, l'espace nécessaire pour la sauvegarde est plus important.

Base de données cible : on appelle base de données cible la base qui est l'objet d'opérations de sauvegarde/restauration, RMAN utilise les fichiers de contrôle de la base cible afin de récupérer les informations sur les objets à sauvegarder.

BackupPiece : c'est une entité physique contenant un ou plusieurs fichiers de données. Un fichier peut très bien être sur plusieurs backup pieces. Leur nombre et leur taille dépendent du paramètre maxpiecesize.

BackupSet : c'est une entité logique contenant un ou plusieurs backup pieces. Il est impossible d'avoir un fichier sur plusieurs backup sets (librairies). Il est impossible de mixer dans une même librairie des fichiers de contrôle et des fichiers d'archive.

Principe de stockage des sauvegardes :

RMAN se lance par la commande du même nom se trouvant sous bin dans l'arborescence du moteur Oracle. C'est cet utilitaire qui interprète les commandes des scripts et appelle les processus serveurs pour exécuter les tâches demandées.
RMAN fonctionne avec des processus serveur :

• un premier appelant les paquetages (packages) pour sauvegardes/restaurations. Les deux paquetages sont SYS.DBMS_RCVMAN et SYS.DBMS_BACKUP_RESTORE. Ces deux paquetages sont créés lors de l'exécution du script catproc.sql ;
• un autre pour la mise à jour des logs internes. On peut visualiser les opérations de sauvegarde en cours à l'aide de la vue v$session_longops (la colonne OPNAME contient le nom de l'opération effectuée).

Ces processus serveur se connectent à la base de données cible par le protocole Net8 d'Oracle. RMAN est donc une application cliente de la base de données cible. Après la connexion, un ou des canaux de communication sont ouverts permettant d'effectuer les opérations de sauvegarde / restauration. Avant la version 9i d'Oracle, il faut allouer explicitement un canal avant d'exécuter les commandes RMAN. Le nombre de canaux (channels) correspond au degré de parallélisme de l'opération à effectuer. Le channel est le canal d'écriture vers le media de sauvegarde (disque ou bande)
Il peut être :

• automatique (défini par commande configure). On crée un jeu de canaux RMAN qui sera utilisé par défaut si dans le script RMAN aucun canal spécifique n'est alloué. Dans le script RMAN, il n'y aura alors pas de commande « allocate channel ». Il utilisera les canaux par défaut. Par exemple, pour vos sauvegardes sur disque, vous pouvez créer un jeu de canaux par défaut ;
• spécifique : alloué spécialement pour la sauvegarde (par la commande allocate). Par exemple, vous faites vos sauvegardes sur bande et vous disposez d'un jeu de canaux par défaut pour le robot de sauvegarde et cette fois vous avez besoin d'une sauvegarde sur disque, alors vous devez explicitement déclarer un canal via la commande « allocate channel » spécifique aux disques.

Pour chaque canal un channel process est défini :

• pour une sauvegarde : ce processus coordonne la lecture des fichiers de données et l'écriture à l'emplacement spécifié ;
• pour une restauration : ce processus coordonne la lecture depuis l'emplacement spécifié lors de la sauvegarde et l'écriture des fichiers de données ;
• deux types de channel : Disk ou Tape.

Les données utilisées par RMAN pour les opérations sont appelées métadonnées RMAN. Elles sont stockées soit dans un fichier de contrôle (controlfile) de la base de données cible soit dans le catalogue RMAN le cas échéant (cf chapitre Fonctionnement avec catalogue de récupération ou fichiers de contrôle).
Principe de communication RMAN :

Le stockage des informations relatives aux sauvegardes effectuées via RMAN peut se faire soit dans un catalogue de récupération (recovery catalog), soit exclusivement dans les fichiers de contrôle des bases de données cibles.
C'est d'ailleurs une des premières choses à décider lors de l'implémentation d'une solution RMAN dans une entreprise. En RMAN 9i, l'option de connexion à RMAN par défaut est nocatalog. Le catalogue de récupération est un composant optionnel de RMAN.

II-B-1. Solution basée sur le catalogue de récupération (Recovery Catalog)▲

II-B-2. Solution basée sur les fichiers de contrôle (controlfiles)▲

RMAN permet de se connecter soit en ligne de commande soit avec une interface graphique grâce à OEM (version 2 et ultérieures).
RMAN ouvre des sessions sur la base de données, deux à son lancement et après autant que de canaux alloués pour les opérations de sauvegarde/restauration.

II-C-1. Connexion à RMAN avec un catalogue de récupération▲

$ rman target u1/p1[@aliastarget] rcvcat u2/p2[@aliascatalog]

$ rman target u1/p1[@aliastarget] catalog u2/p2[@aliascatalog]

II-C-2. Connexion à RMAN sans catalogue de récupération▲

        $ rman target u1/p1[@aliastarget] nocatalog

II-C-3. Options de lancement de la commande RMAN▲

RMAN peut envoyer des sauvegardes sur bande à l'aide d'un media manager (MM) tel que arcserve, backupexec ou time navigator par exemple. Le MM est un outil de sauvegarde externe. Il peut s'interfacer avec RMAN, il permet alors de récupérer les données passées par le channel process de RMAN et de les rediriger vers la bande appropriée. Pour utiliser le MM, le serveur de la base de données doit avoir la partie MM cliente installée. C'est cette partie du logiciel qui fait la connexion avec le MM server. Pour RMAN, en plus du MM client, il faut installer le module ORACLE pour le MM : c'est un composant d'ORACLE RDBMS qui sert à connecter RMAN au MM client. Ce composant est appelé de façon générique la Media Manager Library (MML).
La MML est une simple bibliothèque qui interprète les requêtes issues de RMAN et qui les traduit en requêtes compréhensibles pour le MM client. Cette MML est fournie par le fournisseur du MM. La MML est chargée en mémoire dans Oracle dès qu'un canal de type tape est alloué (allocate channel C1 device type 'sbt_tape'). Donc à l'allocation d'un canal, Oracle 8i va chercher une librairie appelée $ORACLE_HOME/lib/libobk.so : ceci est juste un lien symbolique vers la bibliothèque que l'on doit utiliser. Le nom complet de cette bibliothèque dépend du MM et de l'OS. En Oracle 9i, il n'existe plus de librairie ou de lien libobk.so, il faut créer le lien avec la librairie fournie par le produit tiers; vous pouvez aussi utiliser le paramètre SBT_LIBRARY.

Pour résumer, le Media Manager comprend :

• la MML ;
• le MM Client ;
• le MM Server.

RMAN envoie simplement une demande vers sa MML et c'est le MM logiciel dans son ensemble (partie cliente et partie serveur) qui s'occupe du reste. Il faut cependant avoir à l'esprit qu'en cas de problème au niveau de ces différentes parties du MM, votre sauvegarde (ou restauration) sera bloquée et RMAN sera en attente indéfiniment.

Avant de pouvoir envisager d'utiliser RMAN, il faut configurer proprement son environnement, c'est pourquoi l'ensemble des variables mentionnées ci-dessous doivent être positionnées :

• ORACLE_SID : nom de l'instance ;
• ORACLE_HOME : répertoire d'installation du produit Oracle ;
• PATH : doit contenir le répertoire des binaires Oracle soit $ORACLE_HOME/bin ;
• LD_LIBRARY_PATH (sur Solaris et Digital Unix) (SHLIB_PATH sur HP-UX - LIBPATH sur AIX), il doit contenir le répertoire des librairies Oracle soit $ORACLE_HOME/lib ;
• NLS_LANG si le jeu de caractères (characterset) de la base n'est pas celui par défaut de l'OS.

III-B-1. Création d'un utilisateur propriétaire du catalogue▲

SQL>create tablespace rman_ts_data datafile '/files1/RMAN/rman_ts_data01.dbf' size 50M ;
 
Tablespace Created
 
SQL>create user rman identified by rmanpwd  default tablespace RMAN_TS_DATA;
 
User created.
 
SQL>grant connect, resource, recovery_catalog_owner to rman;
 
Grant succeeded.

III-B-2. Création du catalogue▲

$ rman catalog rman/rmanpwd[@aliascatalog]
RMAN> create catalog tablespace rman_ts_data ;

Dans le cas d'une nouvelle mise en œuvre de sauvegarde de base de données, il faut d'abord enregistrer la base de données sous RMAN. Bien entendu, pour les sauvegardes ultérieures, il est inutile de réenregistrer la base de données; d'ailleurs RMAN refusera de la réenregistrer parce qu'il ne peut y avoir qu'un seul « register » par base de données afin de garantir l'unicité.

III-C-1. Déclaration de la base de données cible dans le catalogue RMAN▲

$rman catalog rman/rmanpwd@aliascatalog target sys/oracle@db1
RMAN>register database ;

$export ORACLE_SID=db1
$rman catalog rman/rmanpwd@aliascatalog target / 
Recovery Manager: Release 9.2.0.1.0 - 64bit Production
 
Copyright (c) 1995, 2002, Oracle Corporation.  All rights reserved.
 
connected to target database: DB1 (DBID=1966171371)
connected to recovery catalog database
 
RMAN> register database; 
 
database registered in recovery catalog
starting full resync of recovery catalog
full resync complete

III-C-2. Sauvegarde de la base de données▲

$rman catalog rman/rmanpwd@aliascatalog target /
Recovery Manager: Release 9.2.0.1.0 - 64bit Production
 
Copyright (c) 1995, 2002, Oracle Corporation.  All rights reserved.
 
connected to target database: DB1 (DBID=1966171371)
connected to recovery catalog database
 
RMAN>run {
    allocate channel t1 type disk;
    backup format '/filesbkp/DB1/df_%d_%t_%s_%p' database;
    sql 'alter system switch logfile';
    backup format '/filesbkp/DB1/al_%d_%t_%s_%p'
    archivelog all delete input;
    backup format '/filesbkp/DB1/ctl_%d_%t_%s_%p' current controlfile;
    }

Le script donné ci-dessous n'est qu'un exemple permettant de restaurer une base de données complète à partir de la dernière sauvegarde valide et de réappliquer les logs (archive et redo) jusqu'au moment du plantage. Il prend comme hypothèse de n'avoir perdu ni les redo logs ni les fichiers de contrôle. De plus, la base cible doit être en mode MOUNT.

$rman catalog rman/rmanpwd@aliascatalog target /
Recovery Manager: Release 9.2.0.1.0 - 64bit Production
 
Copyright (c) 1995, 2002, Oracle Corporation.  All rights reserved.
 
connected to target database: DB1 (DBID=1966171371)
connected to recovery catalog database
 
RMAN>Run {
    allocate channel t1 type disk;
    restore database;
    recover database;
    sql "alter database open";
}

De la même façon que précédemment, on alloue un canal de type disk. On restaure la base de données. Étant donné qu'il n'y a aucun paramètre complémentaire, RMAN prend la dernière sauvegarde valide. Ensuite on applique un recover ayant pour effet de réappliquer l'ensemble des archives et des redo logs actifs. Et enfin on ouvre la base pour la rendre disponible à nouveau.

On peut envisager de faire une restauration à chaud d'un tablespace de données en faisant comme suit :

$rman catalog rman/rmanpwd@aliascatalog target /
Recovery Manager: Release 9.2.0.1.0 - 64bit Production
 
Copyright (c) 1995, 2002, Oracle Corporation.  All rights reserved.
 
connected to target database: DB1 (DBID=1966171371)
connected to recovery catalog database
 
RMAN>Run {
    sql "alter tablespace TBS_DATA offline";
    allocate channel t1 type disk;
    restore tablespace TBS_DATA;
    recover tablespace TBS_DATA;
    sql "alter tablespace TBS_DATA online;";
}

Il faut mettre le tablespace offline avant de pouvoir le restaurer. Ensuite on le restaure et on le remet online.
Les différents types de restauration sont très nombreux, on peut restaurer uniquement un fichier, ou des archives logs, etc.