/** Ce qui suit a été testé sur une version 10.2.0.3 et est fourni à
** des fins d'informations uniquement !
** Testez et ne faites pas ce qui est écrit sans réfléchir; par exemple,
** quand il est demandé de brûler votre machine et votre baie de
** stockage, réfléchissez d'abord aux conséquences sur
** l'environnement... */
Oracle Recover Manager (RMAN) est "L'"outil de sauvegarde des bases de données Oracle. Vous pouvez faire autrement, et... Ca sera peut-être moins bien ! vous trouverez ci-dessous un scénario simple d'utilisation d'Oracle Recovery Manager et quelques réflexions quant à l'intérêt liés à son utilisation....
Avant d'utiliser RMAN
Une base de données Oracle est constituée de "fichiers" :
- Le fichier de contrôle et ses copies (controlfiles) contiennent l'ensemble de l'information sur les fichiers de la base de données, leur état et bien d'autres aspects
- Les fichiers de données (datafiles) contiennent l'ensemble des données. A moins que la base de données ait été arrêtée "proprement", les données dans les fichiers de données sont incohérentes. Plusieurs versions des données peuvent être contenues ces "datafiles" ; ce sont les images avant contenues dans les UNDO.
- Les fichiers journaux (redologs) contiennent les ordres qui ont modifiés la base de données. Oracle garantit que si les ordres ont été validés par un "commit", ces ordres sont stockés dans les redologs. Les redologs cyclent, c'est à dire qu'une fois le dernier redologs utilisé, Oracle réutilise le premier redolog.
- Les fichiers journaux archivés (archivelogs) sont des copies des redologs. En effet, les instances utilisent les redologs pour garantir qu'en cas de crash, les données nécessaires pour rendre de nouveau le système opérationnel seront bien disponibles. Les transactions ne sont pas forcément toutes historisées. Garder une copie des fichiers redologs (les archivelogs) permet donc de rejouer les transactions après avoir restaurer une base de données. Activer le mode "Archivelog" permet de remonter une base de données à tous les moments de sa vie et permet d'effectuer des sauvegardes la base de données étant ouverte.
Une base de données est gérée par une ou plusieurs (en RAC) instances. Les instances sont consitituées de process et d'une mémoire partagée (la SGA). Elles offrent une image cohérente de la base de données. Elles permettent de résoudre les ordres SQL de manière efficace, les accès concurrents, etc. Pour démarrer une instance, il faut un fichier de paramètres des instances (le SPFILE) !
Des idées répandues et fausses
Lorsqu'on fait une sauvegarde d'une base de données sans passer par Recovery Manager, il faut éviter le phénomène de "split block". Autrement dit, il faut que chaque bloc écrit dans les fichiers de données soit copiés de manière cohérente... Il ne faut pas que les blocs soient corrompus dans la sauvegarde sous peine que la restauration aboutisse à un ensemble inutilisable. Pour cette raison, toutes les techniques de sauvegardes qui n'utilisent pas une lecture directe de la base de données par des processus RMAN nécessite de change le comportement de la base de données par l'ordre ALTER DATABASE BEGIN BACKUP. Lorsque vous finissez votre sauvegarde par un "cp", un "split-mirror" ou par un "backup proxy", il faut que la commande ALTER DATABASE BEGIN BACKUP soit effectuée sur toutes les instances qui gèrent votre base de données.
Plusieurs idées répandues et fausses sont que cette commande "BEGIN BACKUP" empêche les "split blocks", qu'elle fige les I/O sur les datafiles ou même qu'elle passe les tablespaces en lecture seule. En fait, les comportements des instances sont modifiés et, entre autre mais guère plus, les blocs modifiés sont stockés dans les redologs. Ainsi, si pendant une restauration, un "split block" se produit, le processus de recover des transactions pourra reconstituer les blocs altérés par la sauvegarde. Pour en savoir plus quant à ce phénomène de split block, vous trouverez un document intéressant à l'URL qui suit :
http://www.speakeasy.org/~jwilton/oracle/hot-backup.htmlLorsque vous utilisez RMAN (en dehors du cas particulier du backup proxy), les split blocks sont tout simplement prévenus du fait que RMAN est capable de les détecter et de les résoudre. Il n'est donc pas besoin de changer le comportement des instances pendant les sauvegardes RMAN.
Recovery Manager permet d'effectuer des sauvegardes, base de données arrêtée et base de données en mode "noarchivelog". En fait, l'idée contraire relativement répandue elle aussi vient du fait que RMAN à besoin d'une instance pour être utilisé et d'un fichier de contrôle pour sauvegarder les datafiles. C'est le controlfile qui contient les informations d'où se situent les datafiles ; toute méthode qui utilise un autre fichier est à bien valider.
Sauvegarde RMAN
Une fois une base de données créée, il faut effectuer une sauvegarde (avec RMAN, par exemple !). Dans ce qui suit,
- Vous effectuerez la sauvegarde sur disque mais une sauvegarde sur bande n'est pas beaucoup plus compliquée. Il faut alors utiliser un Media Manager (Netbackup, Data Protector, TSM, Oracle Secure Backup, Time Navigator...) et un agent Oracle (la librairie "libobk") pour permettre à RMAN d'envoyer directement les sauvegardes au Media Manager.
- Vous stockerez les informations des sauvegardes dans le controlfile ce qui évite de créer une base de données "catalogue" pour les sauvegardes. Cette méthode a de nombreux intérêts (plus grande rétention, plus grande facilité de restauration en cas de perte du controlfile, reporting global, ...). Pour notre test, utiliser le controlfile est plus rapide et permet de toute façon de montrer comment s'en sortir quand on a TOUT perdu
- Selon le type de d'erreur contre lesquelles, vous voulez se prémunir, l'endroit où vous stockerez les sauvegardes aura de l'importance. Si vous voulez vous prémunir d'une erreur du stockage, évitez de conserver des sauvegardes dans le même environnement de stockage que la base de données. Pour le test, nous voulons nous prémunir d'un ordre "rm -rf oradata" et nous laisserons les sauvegardes dans une autre arborescence du système de fichiers.
1) La première étape de la sauvegarde consiste à paramétrer les options RMAN grâce à la commande CONFIGURE comme ci-dessous.
Il faut d'abord se connecter, avec RMAN, à la base de données (on devrait dire instance mais dans le cas de RAC, on peut lancer les sauvegardes sur plusieurs instances). Pour cela, vous paramétrez les variables d'environnement ORACLE_HOME et ORACLE_SID, ou vous utilisez une chaine de connexion réseau avec un passwordfile. Pour utilisez RMAN, il faut se connecter SYSDBA... voici donc un exemple de connexion RMAN sous Unix ou Linux depuis le compte "oracle" du serveur de base de données. Vous remarquerez que le DBID est affiché si l'instance de base de données est montée sur le controlfile.
$ . oraenv
ORACLE_SID = [ORCL] ?
$ rman target=/ nocatalog
Recovery Manager: Release 10.2.0.3.0 - Production on Sam. Déc.
connecté à la base de données cible : ORCL (DBID=1136510590)
utilisation du fichier de controle de la base de données cible au lieu du catalogue de récupération
Une fois connecté à RMAN, vous allez configurer plusieurs option par défaut de la sauvegarde et en particulier, vous allez indiquer que les sauvegardes par défaut son mise sur les disques en tapant la commande qui suit :
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO DISK;
Ensuite, vous allez paramétrer la sauvegarde automatique des fichiers de contrôle et des spfiles et vous allez indiquer que ces fichiers sont sauvegardés avec le format généré par RMAN (%F) dans l'arborescence qui vous convient sur le disque :
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/u01/oracle/backups/%F';
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
Et puis, vous allez définir l'arborescence dans laquelle vos sauvegardes seront conservées (%U, permet de laisser à RMAN nommer les fichiers de sauvegarde selon ses règles de nommage). On peut également définir certaines propriétés quant aux sauvegardes. Dans ce qui suit, vous indiquerez que les sauvegardes sont compressées par RMAN et que deux process effectuent la sauvegarde, ce qui permet du parallèlisme.
RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/u01/oracle/backups/%U';
RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 2;
Enfin, vous pouvez visualiser l'ensemble de la configuration RMAN en utilisant la commande SHOW ALL comme ceci :
RMAN> SHOW ALL;
2) Une fois RMAN correctement configuré, il suffit de lancer la sauvegarde de la base de données. Par exemple, si vous êtes en mode ARCHIVELOG, il faut saisir la commande suivante pour effectuer une sauvegarde à chaud :
RMAN> backup database plus archivelog delete input;
Cette commande effectue les opérations suivantes (vérifiez en regardant les log RMAN)
- Elle sauvegarde les archivelogs non encore supprimé et les supprime
- Elle sauvegarde l'ensemble de datafiles
- Elle archive le/les redolog(s) courant(s) puis sauvegarde l'ensemble des archivelogs générées depuis le premier point. Cette dernière étape est cruciale puisqu'elle permet d'assurer qu'il y a sur disque un ensemble d'archivelogs qui permettra de restaurer et de faire le recover de la base de données, i.e. toutes les transactions jouées pendant la sauvegarde à chaud sont dans les sauvegardes pour permettre un recover jusqu'à la fin de la sauvegarde des datafiles. Les archivelogs sont ensuite supprimées.
- Si vous êtes en "controlfile autobackup on", ce qui est largement recommandé, les fichiers de contrôle et SPFILE sont ensuite sauvegardés
3) Par ailleurs pour supprimer les anciennes sauvegardes rendues obsolètes par votre nouvelle sauvegarde et ainsi conserver de l'espace disque, vous pouvez utiliser la commande qui suit. Le résultat de cette commande dépend de la politique de rétention des sauvegardes que vous avez choisie (cf "CONFIGURE RETENTION POLICY TO")
RMAN> delete obsolete;
4) Pour vérifiez vos sauvegardes, utilisez la commande list backup, comme ceci :
RMAN> list backup;
ou
RMAN> list backup summary;
ou tout autre option que vous trouverez utile.
5) Sortez de la ligne de commande d'Oracle Recovery Manager :
RMAN> exit;
Ce qui peut vous arriver de pire (quoique...)
Supposons maintenant que vous ayez
tout perdu sur vos disques de production, c'est à dire :
- les datafiles
- les redo logs
- les controlfiles
- les archivelogs
- le spfile
- les tempfiles
- le passwordfile
- la configuration réseau stockée sur la machine
- la distribution Oracle
- le système d'exploitation (et donc Windows le Service Oracle, Sous Unix/Linux le fichier oratab)
- d'éventuels fichiers annexes à la configuration de la base de données comme l'OCR ou les fichiers de configuration du Broker Data Guard
Bref, Il ne vous reste plus qu'un espace de stockage avec les fichiers de sauvegarde qui par chance était sur une autre baie (ou dans votre Media Manager... je n'ose plus dire bande puisque maintenant la plupart des architectures ont des espaces tampon sur disques). Pour simuler ce problème, le mieux est de brûler votre machine de test et les baies de production (Je rigole, ne le faîte pas... Si c'est un p595, ça se discute !). Idéalement pour que votre test soit représentatif, il faut faire, une CROSS RESTAURATION, c'est à dire une restauration sur une autre machine. En particulier lorsque vous utilisez un Media Manager. Pour certains outils, il faut en effet préciser le nom de la machine d'origine dans les paramètres d'allocation des canaux SBT_TAPE RMAN.
Pour effectuer un test représentatif sur la même machine, arrêtez l'instance (et le service sous Windows) et enlevez tous les fichiers de 1 à 11 et toutes les arborescences.
Si c'est juste pour vous entrainer et pas pour valider vos restaurations :
- enlevez tous les fichiers de 1 à 8,
- supprimez la ligne de l'instance dans le fichier oratab (ou sous windows, le service de l'instance grâce à l'utilitaire en ligne de commande "oradim")
- supprimez les fichiers dr1.dat et dr2.dat si vous utilisez le boker Data Guard
- supprimez toutes les arborescences (e.g. si vous êtes en OFA : $ORACLE_BASE/oradata/{DB_NAME}, $ORACLE_BASE/admin/{DB_NAME}, etc) en cas de problème, il faudra les recréer !
Encore un conseil : avant de supprimer un quelconque fichier réfléchissez au moins 2 fois aux pires conséquences possibles, si votre restaure ne fonctionne pas. Si vous n'avez pas de problème d'espace, préférez toujours renommer les fichiers plutôt que les supprimer !
Restauration complèteImaginons toujours le pire des cas... vos collègues vous ont bien préparé le terrain et vous ne savez absolument rien sur la base de données que vous devez restaurer. Laissez tomber et préparez-vous à passer un sale quart d'heure ! Rappelez-vous du célèbre dicton : "les absents ont toujours tord". En fait, il faut connaître plusieurs choses et notamment (on suppose qu'on n'a pas de catalogue, sinon, c'est plutôt plus simple) :
- La version de la base de données que vous voulez restaurer
- L'endroit où sont stockées les sauvegardes
- l'identifiant de la base de données à restaurer (le DBID)
- Pour ce dernier, si vous avez de la chance, vous pouvez le retrouver... En effet les formats de sauvegardes par défaut de l'autobackup du controlfile est c-IIIIIIIIII-YYYYMMDD-QQ où la zone IIIIIIIIII est le DBID. Si vous ne mettez pas toutes les sauvegardes de vos 500 base de données au même endroit, avec quelques essais, vous arriverez à identifier le bon DBID.
1) Vous allez maintenant restaurer le SPFILE. Pour cela, il faut que vous ayez réinstallé le logiciel Oracle... vous allez ensuite créer une instance pour utiliser RMAN :
- Créez un fichier init.ora pour votre instance temporaire. Si, comme moi, vous êtes un fan de OFA, voici ce que peut-être votre init.ora.
db_name=GARK
sga_target=120M
processes=50
pga_aggregate_target=80M
- Créez un répertoire admin dans ORACLE_BASE qui contient les répertoires
{DB_NAME}/adump
{DB_NAME}/bdump
{DB_NAME}/cdump
{DB_NAME}/udump
{DB_NAME}/pfile
- Indiquez dans le fichier oratab votre instance temporaire comme dans l'exemple ci-dessous (Si vous connaissez le nom de l'instance, utilisez le nom à la place de "GARK", sinon, vous pouvez changer le nom de l'instance... Si votre réseau Oracle utilise une notation JDBC Thin du type host:port:SID ou si vous utilisiez le mots ORACLE_SID dans vos alias TNS où qu'ils soient stockés, vous retrouverez le nom de l'instance, sinon, vous utilisez des services... C'est très bien continuez ! et le nom de l'instance importe peu) :
GARK:/u01/app/oracle/product/10.2.0/db_1:N
ou sous Windows avec l'utilitaire oradim, indiquez l'instance
C:\> oradim -new -sid GARK
- Démarrez l'instance avec SQL*Plus comme dans le script shell ci-dessous
$ . oraenv
ORACLE_SID = [GARK] ?
$ sqlplus / as sysdba
$ startup nomount pfile='/tmp/init.ora';
où l'init est celui que vous venez de créer
- Ensuite, vous allez vous connecter à l'instance avec RMAN comme ceci :
$ . oraenv
ORACLE_SID = [GARK] ?
$ rman target=/ nocatalog
- Vous allez indiquer l'emplacement des fichiers de sauvegarde ainsi que le DBID de la base de données que vous voulez restaurer puis simplement demander de restaurer le SPFILE depuis l'autobackup
RMAN> set DBID 1136510590;
RMAN> run {
2> set CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'D:\u01\oracle\product\10.2.0\backup\%F';
3> restore spfile from autobackup;
4> }
2) Démarrer sur le SPFILE
- Avant d'arrêter l'instance et de démarrer l'instance sur le SPFILE, créez un fichier d'init.ora avec le SPFILE restauré (dans $ORACLE_HOME/dbs sous Unix et %ORACLE_HOME%\database sous Windows). Pour cela, vous pouvez vous connectez à l'instance avec SQL*Plus et utiliser la commande ci-dessous :
$ . oraenv
ORACLE_SID = [GARK] ?
$ sqlplus / as sysdba
SQL> create pfile='/u01/app/oracle/product/10.2.0/admin/GARK/pfile/initGARK.ora' from
2 spfile='/u01/app/oracle/product/10.2.0/db_1/dbs/spfileGARK.ora';
- L'étape précédente vous permet retrouver l'ensemble de l'arborescence utile pour démarrer l'instance sur le SPFILE. Regardez dans l'init.ora ainsi créé l'ensemble des paramètres qui indiquent des fichiers et répertoires et particulièrement les paramètres suivants :
control_files
audit_file_dest
background_dump_dest
core_dump_dest
user_dump_dest
db_create_file_dest
db_create_online_log_dest_n
db_recovery_file_dest
log_archive_dest, log_archive_duplex_dest ou log_archive_dest_n
standby_archive_dest
Vous pouvez maintenant recréer une partie suffisante de l'arborescence pour restaurer le(s) controlfile(s)
- Il faut enfin effectuer la configuration réseau. En particulier, les paramètres local_listener et remote_listener indique, si le LISTENER n'est pas configuré sur le port 1521 sur la machine locale pointent éventuellement sur des alias TNS qui doivent exister. Il faut également regarder les configurations client et positionner un listener en conséquence.
- Ensuite vous pouvez arrêter votre instance et démarrer sur le spfile comme ci-dessous :
$ . oraenv
ORACLE_SID = [GARK] ?
$ sqlplus / as sysdba
SQL> shutdown abort
SQL> startup nomount
3) Restaurer le controlfile
- Pour restaurer le dernier controlfile, il suffit d'utiliser la commande ci-dessous en remplacent le DBID et le répertoire de sauvegarde par ceux qui conviennent :
$ . oraenv
ORACLE_SID = [GARK] ?
$ rman target=/ nocatalog
RMAN> set DBID 1136510590;
RMAN> run {
2> set CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'D:\u01\oracle\product\10.2.0\backup\%F';
3> restore controlfile from autobackup;
4> }
4) Restaurer les datafiles et effectuer le recover
- Avant de restaurer les fichiers de la base de données, il convient de valider que l'arborescence convien pour effectivement les restaurer. Pour celà, on monte l'instance sur le controlfile restauré précédemment. Il est possible de le faure directement depuis RMAN avec la lignde commande qui suit :
RMAN> alter database mount;
RMAN> exit;
$ . oraenv
ORACLE_SID = [GARK] ?
$ rman target=/ nocatalog
RMAN> run {
2> restore database;
3> recover database;
4> }
- Il y a une erreur... bien sur ! Comme vous l'avez compris vous n'êtes pas capable de restaurer toutes les transactions. Les données dans les redologs sont perdus (à moins qu'ils n'est été, eux, multiplexés dans 2 baies). Le message doit ressembler à ce qui suit :
journal d'archivage introuvable
journal d'archivage thread=1 séquence=10
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: Echec de la commande recover à 12/09/2006 xxxxxxxx
RMAN-06054: la récupération après défaillance matérielle requiert un journal inconnu : thread 1 séquence 10 lowscn 586
5) Ouvrir la base de données
- A partir du moment où vous repartez d'une sauvegarde du controlfile, il faut remettre à jour le controlfile et donc ouvrir la base de données en mode resetlogs. Vous pouvez utiliser RMAN pour ouvrir la base de données :
RMAN> alter database open resetlogs;
6) Encore un petit effort, quoique...
- En 10g, 2 bonnes nouvelles :
- après une restauration et un open resetlogs, pas besoin de refaire un backup. Il faut toutefois que les archivelogs aient en paramètre (dans log_archive_format) un %r qui indique le SCN de réincarnation
- après l'ouverture de la base de données, les fichiers temporaires sont recréés alors qu'en 9i, la procédure est manuelle (vérifiez que c'est le cas)
- Que faut-il faire me direz-vous ? Et bien tester !
- Vous devez vous connecter sous un compte utilisateur classique et effectuer quelques requêtes pour valider que ça semble fonctionner. Le faire en local et via le réseau. Si vous utilisez un passwordfile, vérifiez que vous arrivez à vous connecter SYSDBA avec un alias réseau
- Vous devez vérifier l'alert.log pour vérifier qu'il n'y a pas de problème particulier
- Idéalement, il faudrait demander aux administrateurs de l'application de faire une recette de la base de données et rester à disposition le temps que les tests soient terminés. Enfin, si vous en êtes arrivé là, peut-être que la situation n'était déjà pas idéale.
Intérêts de RMAN
Vous me direz, ça n'a pas l'air si simple... et pourtant, passez-y 1 journée et vous trouverez ça tellement confortable que vous vous demanderez pourquoi certains font autrement. En particulier et depuis le début, ce qui est simple c'est de restaurer les données ! il faut dire que ce qui précède correspond à un cas déjà compliqué : vous avez perdu toute votre machine et remontez la base de données sur une autre machine. Pourtant la reconstitution de votre environnement tient en 2 pages? Alors, pourquoi utiliser Recovery Manager ?
- La restauration et le recover sont simples (pas besoin de trouver les fichiers, tout est référencé)... et ceci depuis la 8i ; je n'ose pas dire la 8, j'en ai tellement souffert !
- C'est l'outil standard de sauvegarde des bases de données Oracle; il est installé sur vos configurations; il est inclus dans la licence de la base de données et plus de 60% des DBA Oracle le connaissent bien. Par exemple, les certifications Oracle sont basées uniquement sur RMAN
- RMAN valide les blocs et permet ainsi que garantir la bonne santé de vos bases de données. Si vous n'utilisez pas RMAN, if faut faire des DB Verify ou des exports de manière régulière pour valider l'intégrité des structures de fichiers Oracle
- RMAN est capable de monter en charge. Ca peut sembler facile d'avoir un système de sauvegarde capacle de monter en charge et pourtant... C'est moins fréquent que vous l'imaginez. Mettre en place une architecture capable de sauvegarder 3 TB à l'heure sur des bandes n'a rien d'un challenge insurmontable. Théoriquement et pratiquement, vous vous appercevrez qu'il n'y a pas de contention. Si vous ajoutez plus de matériel, vous aurez plus de puissance. C'est d'autant plus vrai que vous utiliserez ASM pour répartir vos données sur plusieurs baies de stockages de manière homogène.
- L'utilisation d'un catalogue permet une gestion centralisée de toutes les sauvegardes. Il simplifie encore la restauration et permet des stratégies évoluées comme les offload backup : sauvegardes sur une base de données standby ou sur un BCV et référencement des éléments dans l'environnement de production
- RMAN est capable de synchroniser ses informations avec celle du Media Manager et des disques. Si vous supprimez une sauvegarde, RMAN peut mettre à jour son référentiel en conséquence grâce à la commande CROSSCHECK
- RMAN permet de définir des politiques de rétention et donc de conserver 2 sauvegarde ou 10 jour en arrière. Les commandes PURGE prennent en compte vos engagements vis à vis des projets
- RMAN a une connaissance intime de la base de données. Il permet d'effectuer des sauvegardes incrémentale et donc de gagner en espace de sauvegarde. Il peut utiliser le fichier "Block Change Tracking File" et donc ne lire que les données modifiées depuis la dernière sauvegarde. Les temps de sauvegarde sont alors très rapide. Enfin pour accélerer les restauration, vous pouvez fusionner les sauvegardes incrémentales dans une copie de la base de données et ainsi garantir des temps de restauration très rapide
- RMAN est utilisé et intégré à de nombreuses autres technologies d'Oracle 10g :
- la Flashback database et les flashback logs peuvent être utilisés depuis RMAN. Vous pouvez alors (1) Revenir en arrière et, (2) si vous être allé trop loin effectuer un recover...
- DataGuard, vous pouvez instancier une standby sans aucune indisponibilité grâce à RMAN. Vous pouvez sauvegardé une standby physique au lieu de la base de données primaire
- RAC, RMAN est capable de "loadbalancer" la charge des sauvegardes sur plusieurs noeuds d'un RAC
- RMAN permet de manipuler et déplacer des fichier dans ASM (Automatic Storage Management)
- Les Tablespaces Transportables peuvent être pilotés depuis RMAN
- Cross Platform Tablespace Transportable. RMAN permet de changer l'endianess des fichiers et migre d'une plateforme Big Endian à Small Endian un tablespace complet
- RMAN permet de faire du TSPITR (Tablespace Point In Time Recovery). Si vous utilisez des bases de données mutualisées, vous pouvez garantir le retour en arrière d'une partie de la base de données sans impacts pour les autres parties (sous réserve que les tablespaces soient "self content")
- RMAN permet de restaurer 1 bloc corrompu, c'est le Block Media Recovery, sans autre indisponibilité pour le service que ce bloc
- RMAN est utilisé par la Flash Recovery Area pour automatiser les sauvegardes disques et optimisation la gestion de l'espace des sauvegardes
- RMAN permet une des techniques de restauration/recover les plus rapides. Grâce à la commande SWITCH, vous pouvez basculer d'une base de données de production à une sauvegarde "copie" de la base sur disque très rapidement et sans aucune intervention système.
- En 10g, RMAN gère les réincarnations. Si vous faîtes un OPEN RESETLOGS, vous n'êtes plus obligé de faire une sauvegarde avant de ré-ouvrir le service. Toutes les autres techniques nécessite une prise d'image de la production après le recover
- Recovery Manager et Advanced Security Option (ASO) permettent le chiffrement des fichiers de sauvegardes sur les disques.
- Recovery Manager bénéficie de sa connaissance de la base de données pour optimiser les temps de sauvegardes ou le volume d'I/O. Il ne sauvegarde pas les blocs vides de la base de données et est capable de générer des fichiers de sauvegarde compressés
- Recovery Manager peut être utilisé pour construire des clones des bases de données. La commande "DUPLICATE" renomme la base de données, l'arborescence automatiquement et peut enregistrer la nouvelle base de données dans le catalogue des sauvegardes
- Oracle Enterprise Manager Grid Control offre une interface graphique à Recovery Manager
- RMAN permet des stratégies très évoluées. Il peut, avec la commande "PROXY" piloter le Media Manager, et dans le cas de TiNa par exemple, piloter des Split Mirror Backup via des BCV et TimeFinder. Il s'intègre dans l'interface BR*Backup de SAP et permet, si vous utilisez des bases Oracle, une intégration complète et des techniques évoluées sans utiliser BackInt.
J'en oublie sûrement (les archives de tablespaces, ...) ! Sans compter que la 11 va, elle aussi, apporter son lot de nouveautés. Peut-être RMAN assurera lui-même le transfort des fichiers entre les machines, qui sait ?
Les limites de RMAN
Vous auriez du mal à croire qu'il n'y a pas quelques limites à l'utilisation de Recovery Manager. Il y en a probablement quelques unes, quoique...
- D'abord RMAN ne sauvegarde que des bases de données Oracle et après 8i (pour simplifier). Oracle Secure Backup complète le dispositif mais si vous voulez sauvegarder des systèmes complexes en terme d'I/O comme d'autres bases de données, OSB n'est surement pas très adapté utilisé seul. Cela étant, les mécanismes de sauvegarde des bases de données sont très dépendant de leur architecture. Des produits capables de sauvegarder plusieurs SGBD (le plus connu étant sans doute SQL*Backtrack) ont donc des stratégies très différentes pour sauvegarder un SGBD ou un autre. Seule l'interface est identique mais les comportements mathématiques (entendez bugs) seront eux très différents.
- En mode classique, RMAN utilise la bande I/O des serveurs de base de données et le réseau pour envoyer les données sur un Media Manager. Plusieurs choses vont sans doute changer cette contrainte... la convergence des réseaux avec le SAN-IP ou Infiniband, l'enrichissement et l'utilisation de Oracle Secure Backup. Mais c'est vrai que connecter directement le Media Manager dans le SAN peut apporter une vrai capacité à absorber des charges I/O quand RMAN trouve ses limites.
- On reporte ici ou là quelques autres faiblesses. Par exemple, le taux de compression de RMAN en 10g serait-il moins bon que celui d'autres produits ?
Conclusion
Recovery Manager est un outil très puissant qui aide de nombreuses entreprises utilisatrices d'Oracle. L'ignorer encore, parce qu'on a eu des difficultés il y a 6 ou 8 ans, c'est sans doute se priver d'un potentiel intéressant tant en terme de fiabilisation de systèmes que de souplesse pour créer ou migrer des environnements. Je souhaite que ce document vous soit utile pour découvrir ou vous faire une nouvelle opinion.
GarK!
