Présentation de l'outil RMAN d'oracle

Présentation de l'outil RMAN d'oracle Ce document constitue une première présentation de l'outil RMAN d'oracle permettant de sauvegarder et restaurer des bases de données. L'article abordera également les composants de RMAN et la mise en oeuvre de cet outil. 1. Présentation 1.1. Introduction 1.2. Les fonctions de RMAN 1.3. Les différents types de sauvegardes possibles avec RMAN 1.4. Terminologie 2. Architecture RMAN 2.1. Les composants RMAN 2.2. Fonctionnement avec catalogue de récupération ou fichiers de contrôle 2.2.1. Solution basée sur le catalogue de récupération (Recovery Catalog) 2.2.2. Solution basée sur les fichiers de contrôle (controlfiles) 2.3. Mode d'accès RMAN 2.3.1. Connexion à RMAN avec un catalogue de récupération 2.3.2. Connexion à RMAN sans catalogue de récupération 2.3.3. Options de lancement de la commande RMAN 2.4. RMAN et les unités de sauvegarde 3. Mise en oeuvre de RMAN 3.1. Préparation de l'environnement OS 3.2. Création du catalogue RMAN 3.2.1. Création d'un utilisateur propriétaire du catalogue 3.2.2. Création du catalogue 3.3. Première sauvegarde de base de données avec RMAN 3.3.1. Déclaration de la base de données cible dans le catalogue RMAN 3.3.2. Sauvegarde de la base de données 3.4. Première restauration de base de données avec RMAN

1. Présentation 1.1. Introduction 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. 1.2. Les fonctions de RMAN Livré en standard depuis la version 8 d'oracle, il ne nécessite pas d'installation particulière. 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. 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. 1.3. Les différents types de sauvegardes possibles avec RMAN RMAN permet donc les types de sauvegardes suivants : de type COMPLET (ou FULL) : on sauvegarde tous les blocs de type DIFFERENTIEL : 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 Les sauvegardes différentielles et cumulatives sont dites incrémentielles en opposition aux sauvegardes complètes. RMAN gère 3 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 DIFFERENTIELLE: Exemple de sauvegarde CUMULATIVE:

Attention, dans tous les cas, une sauvegarde de niveau 0 (level 0) est nécessaire avant les sauvegardes de niveau supérieur. Une sauvegarde de niveau 0 est bien différente d'une sauvegarde complète dans le cadre de votre stratégie de sauvegarde. Si physiquement, une sauvegarde de niveau 0 est bien une sauvegarde complète, une sauvegarde complète ne peut être considérée comme une sauvegarde de niveau 0 par RMAN. Par exemple, le dimanche vous faites une sauvegarde complète et une sauvegarde de niveau 0, le lundi vous faites une sauvegarde de niveau 2 (rendue possible grâce à la sauvegarde de niveau 0 de la veille). Si la base doit être restaurée le lundi soir, vous ne pourrez pas utiliser la sauvegarde complète comme parente de la sauvegarde de niveau 2 du lundi. Pour RMAN, la sauvegarde complète n'est pas inscrite dans votre stratégie, c'est donc bien les sauvegardes de niveau 0 et 2 qu'il faudra restaurer. La sauvegarde complète pourra servir éventuellement pour une copie dans un autre environnement. 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 2 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. 1.4. Terminologie 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 1 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 : 2. Architecture RMAN 2.1. Les composants RMAN 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 serveurs : Un premier appelant les paquetages (packages) pour sauvegardes/restaurations. Les 2 paquetages sont SYS.DBMS_RCVMAN et SYS.DBMS_BACKUP_RESTORE. Ces 2 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 serveurs 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 sauvegarde 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. Principe de communication RMAN : 2.2. Fonctionnement avec catalogue de récupération ou fichiers de contrôle 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.

2.2.1. Solution basée sur le catalogue de récupération (Recovery Catalog) Le catalogue est un référentiel (ensemble de tables) pour RMAN contenant des informations sur : Les ensembles de sauvegardes des fichiers de données et archives Les copies de fichiers de données La structure physique de la base de données cible. Les archives logs. Les scripts de travail (si utilisés). Ce catalogue est en fait une base de données qu'il faut créer sur un serveur distinct de la base cible de préférence. Bien que ce soit un composant optionnel, il est vivement conseillé de l'utiliser si l'on veut bénéficier de l'ensemble des fonctionnalités RMAN. L'inconvénient est que ce catalogue est une base de données qu'il faut surveiller et gérer. Dans votre stratégie de sauvegarde doit figurer cette base. Cependant un simple import du schéma suffit pour restaurer ce catalogue. 2.2.2. Solution basée sur les fichiers de contrôle (controlfiles) Il est parfaitement possible de ne pas utiliser le catalogue. Dans ce cas, RMAN va sauvegarder les métadonnées dans les fichiers de contrôle de la base de données cible. L'avantage est de ne pas avoir à gérer le catalogue. Cependant un certain nombre de fonctionnalités de RMAN sont alors indisponibles (par exemple, le stockage des scripts de sauvegarde/restauration ou les fonctions de reporting). De plus, la perte des fichiers de contrôle dans ce cas peut devenir problématique. La solution qui consiste à n'utiliser que le fichier de contrôle comme dépositaire de la liste des sauvegardes effectuées paraît la plus simple à mettre en place. Au niveau sécurité, RMAN9i est beaucoup plus performant que RMAN8i : en effet la nouvelle fonctionnalité CONTROLFILE AUTOBACKUP ON permet de faire une sauvegarde du fichier de contrôle et du spfile à chaque sauvegarde ou modification de structure de la base; de plus en cas de perte des fichiers de contrôle, à travers RMAN on sait de façon simple les récupérer. Enfin, la sauvegarde de ces informations dans les fichiers de contrôle fait qu'ils grossissent. Il faut donc faire attention à définir correctement les périodes de conservation des sauvegardes (CONTROL_FILE_RECORD_KEEP_TIME). On a donc un historique plus important dans le cadre du catalogue de récupération. 2.3. Mode d'accès RMAN 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. D'autre part RMAN fait toujours appel au fichier de contrôle (inaccessible base arrêtée ou non montée), c'est pourquoi il ne peut être utilisé que sur des bases montés ou ouvertes.

2.3.1. Connexion à RMAN avec un catalogue de récupération Commande de connexion en 8.0.x $ rman target u1/p1[@aliastarget] rcvcat u2/p2[@aliascatalog] Commande de connexion en 8.1.x et suivantes $ rman target u1/p1[@aliastarget] catalog u2/p2[@aliascatalog] 2.3.2. Connexion à RMAN sans catalogue de récupération Commande de lancement standard : Commande de connexion RMAN sans catalogue $ rman target u1/p1[@aliastarget] nocatalog L'option permettant de spécifier à RMAN que l'on a choisi d'utiliser le mode de fonctionnnement sans catalogue est nocatalog. 2.3.3. Options de lancement de la commande RMAN Le paramètre target permet de spécifier la base de données cible. L'option nocatalog permet de spécifier que l'on n'utilise pas de catalogue RMAN. L'option catalog u2/p2[@aliascatalog] permet de se connecter au catalogue RMAN. Attention en version 8.0, il faut utiliser le mot clé rcvcat et non catalog pour se connecter au catalogue RMAN. L'option log permet de spécifier un fichier de log où sera tracé l'ensemble des manipulations faites au cours de la session RMAN ainsi que les sorties générées par ces commandes. Enfin, on peut envisager de lancer un script RMAN stocké sur un système de fichiers à l'aide de l'option cmdfile. 2.4. RMAN et les unités de sauvegarde 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. 3. Mise en oeuvre de RMAN 3.1. Préparation de l'environnement OS 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 3.2. Création du catalogue RMAN 3.2.1. Création d'un utilisateur propriétaire du catalogue Nous pouvons utiliser le compte SYS pour faire des backups sans aucune autre configuration. Cependant, pour des sauvegardes d'applications de production, il est préférable de créer un compte de sauvegarde. Création du schéma 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.

Le rôle nécessaire à l'utilisation du catalogue est RECOVERY_CATALOG_OWNER. Il est indispensable que l'utilisateur créé ait ce rôle. 3.2.2. Création du catalogue Il faut se connecter à la base Oracle (dans laquelle le schéma a été créé précédemment) à l'aide de la commande rman : Création du catalogue RMAN $ rman catalog rman/rmanpwd[@aliascatalog] RMAN> create catalog tablespace rman_ts_data ; Le catalogue est à présent créé, RMAN peut fonctionner. 3.3. Première sauvegarde de base de données avec RMAN 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é. 3.3.1. Déclaration de la base de données cible dans le catalogue RMAN La première étape avant de pouvoir sauvegarder une base de données avec RMAN est de la déclarer dans le catalogue. Si la base de données cible n'est pas enregistrée dans le catalogue de restauration, ce dernier ne peut pas être utilisé pour gérer les informations de sauvegardes relatives à cette base. Supposons dans notre cas que nous ayons une base de données db1 à sauvegarder. Enregistrement sous RMAN de la base de données cible $rman catalog rman/rmanpwd@aliascatalog target sys/oracle@db1 RMAN>register database ; Le plus simple est souvent de se connecter sur la machine cible sans mot de passe et de taper : Enregistrement sous RMAN de la base de données cible $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 Lors de l'enregistrement, RMAN affecte un DBid unique à la base de données cible afin de garantir la cohérence du catalogue et des sauvegardes à venir. RMAN enregistre également lors du "register" les informations relatives à la bonne sauvegarde de cette base (fichiers à sauvegarder, emplacements, etc...), informations récupérées des fichiers de contrôle. En outre, RMAN effectue aussi une resynchronisation entre les fichiers de contrôle de la base de données cible et son catalogue. 3.3.2. Sauvegarde de la base de données Le script donné ci-dessous est donné à titre d'exemple et permet de faire une sauvegarde FULL d'une base en mode ARCHIVELOG sur disque. Sauvegarde de la base de données cible $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; } On alloue un canal de type Disk pour effectuer la sauvegarde. Ensuite on sauvegarde l'ensemble de la base de données dans des librairies (backupsets) avec le format donné par les paramètres en %x dans le répertoire /filesbkp/db1/. On change de redo log afin de provoquer un archivage du log courant. On sauvegarde l'ensemble des archives logs utiles dans /filesbkp/db1 sous le format al afin de pouvoir les différencier des librairies des fichiers de données (dfxxx). Enfin on sauvegarde un fichier de contrôle. 3.4. Première restauration de base de données avec RMAN 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. Exemple de script de restauration complète $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. Etant 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 : Exemple de script de restauration de tablespace à chaud $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...