webleads-tracker

Journal / Blog

Vous êtes ici

Nouveautés Oracle Database 12c - partie 3 : améliorations pour RMAN

DIGORA continue de vous présenter quelques-unes des nouveautés d'Oracle Database 12c. Voici le troisième billet consacré à ces nouveautés. Lorsqu'une nouveauté implique l'Enterprise Edition ou une option payante, nous le préciserons.  Cette partie 3 concerne essentiellement 8 nouvelles fonctionnalités touchant RMAN (Recovery Manager) :
  1. Séparation des tâches pour les DBA : privilège SYSBACKUP
  2. Support de l’interface SQL
  3. Récupération d'une table ou d'une partition jusqu'à un point du passé
  4. Améliorations aux sauvegardes / restaurations pour VLDB
  5. Améliorations pour la duplication d'une base active
  6. Restore/Recover de fichiers de données à travers le réseau
  7. Restore/Recover avec des Snapshots gérés par une baie Disque
  8. Migration de base ou de tablespaces entre systèmes différents
Certaines des fonctionnalités suivantes ont pu déjà être abordées brièvement dans un autre billet de notre Blog; elles seront dans ce cas reprises avec plus de détails.

1. Séparation des tâches pour les DBA : privilège SYSBACKUP

Oracle Database 12c introduit une séparation des tâches DBA en définissant un niveau de privilèges moindre que SYSDBA. Le nouveau privilège SYSBACKUP a pour but de se connecter et d’effectuer des commandes avec RMAN. Dans un environnement Oracle Database Multitenant, le privilège SYSBACKUP peut également être accordé à un utilisateur attaché à une base PDB et l’utilisateur pourra effectuer des sauvegardes de la base PDB en se connectant à cette base PDB comme suit :
$ rman TARGET ‘ "jean@pdb1 AS SYSBACKUP" ‘
Dans ce cas, il faut alors lancer la commande BACKUP DATABASE sans nom de base. La commande BACKUP PLUGGABLE DATABASE est interdite dans ce contexte.

2. Support de l’interface SQL

Dans les versions précédentes, vous deviez utiliser le préfixe SQL et entourer la commande SQL à exécuter avec de simples guillemets pour exécuter cette instruction directement à partir de RMAN. Désormais, vous pouvez exécuter la plupart des ordres SQL directement sous RMAN sans les préfixer par SQL ni les entourer de simples guillemets. Voici quelques exemples montrant comment ajouter un fichier de base de données à un Tablespace existant, afficher la structure d’une table et lancer un SELECT :
RMAN> ALTER TABLESPACE users ADD DATAFILE size 10G;
RMAN> DESC dual;
RMAN> SELECT sysdate FROM dual;  

3. Récupération d’une table ou d’une partition jusqu’à un point du passé

(Cette fonctionnalité nécessite Oracle Enterprise Edition) Avant la version Oracle 12c, il était impossible de récupérer une table ou une partition spécifique à partir des sauvegardes physiques effectuées avec RMAN. La table devait être récupérée à partir d’un export effectué avec DataPump ou en rechargeant la base entière sur le même serveur ou sur un autre serveur, puis en exportant la base et enfin en la rechargeant dans la base cible. De nombreux utilisateurs de bases Oracle attendaient cette amélioration avec impatience. C’est maintenant possible avec Oracle 12c. Voici l’instruction à utiliser : RECOVER TABLE. Les options disponibles sont UNTIL TIMEUNTIL SCN and UNTIL SEQUENCE, pour préciser à quel moment du passé récupérer les données de la table ou de la partition. La technique utilisée est similaire à celle utilisée pour un TABLESPACE IN TIME RECOVERY (TSPITR) qui existe déjà dans des versions plus anciennes d'Oracle. Voici les principaux avantages :
  • Les autres objets de la base ne sont pas impactés
  • La durée et la volumétrie disque nécessaire sont réduites par rapport à la méthode TSPITR

Voici les actions qui sont exécutées automatiquement :
  • Mise en œuvre sur le serveur local d’une base auxiliaire temporaire avec le tablespace SYSTEM et le tablespace requis
  • RESTORE puis RECOVER du tablespace contenant la table ou la partition à récupérer
  • Export de la table ou de la partition à récupérer avec DataPump
  • En option, import et changement de nom de la table/partition dans la base source
  • Suppression de la base auxiliaire temporaire une fois le travail la récupération terminée
Voici un exemple de récupération de la table PRODUIT appartenant au schéma CRM, qui a été supprimée ou remise à zéro involontairement vers 15h le 25 juillet 2013 :
RMAN> RECOVER TABLE CRM.PRODUIT
      UNTIL TIME "TO_CHAR('25/07/2013 15:00:00','dd/mm/yyyy hh24:mi:ss')"
      AUXILIARY DESTINATION '/u03/tmp/rec_product'
      DATAPUMP DESTINATION '/u03/DPUMP'
      DUMP FILE 'recovery_product.dmp'
      NOTABLEIMPORT  REMAP TABLE 'CRM'.'PRODUCT':'PRODUCT2';
L’exemple ci-dessus  effectue les actions suivantes :
  • Récupère la table CRM.PRODUCT jusqu’au 25/7/13 à 15h
  • Les fichiers de la base auxiliaire seront placés sous /u03/tmp/rec_product
  • Le fichier Dump recovery_product.dmp sera stocké dans le répertoire /u01/DPUMP
  • Le paramètre NOTABLEIMPORT empêchera l’import dans la base source
  • L’option REMAP TABLE permet de renommer la table lors de l’import
Voici les conditions nécessaires pour pouvoir effectuer la récupération d’une table jusqu’à un point du passé :
  • La base cible doit être en mode READ WRITE et le mode ARCHIVELOG doit être active
  • Les backups RMAN contenant ces tables/partitions doivent être disponibles
  • La base doit avoir le paramètre d’initialisation COMPATIBLE égal à 12.0 ou supérieur
Voir http://docs.oracle.com/cd/E16655_01/backup.121/e17630/rcmresind.htm Note: Il existe également d’autres méthodes, utilisables avec Oracle 11g pour récupérer une table jusqu’à un point du passé : Oracle Flashback et TSPITR (TSPITR implique le rechargement du tablespace en entier). Elles ne sont pas toujours utilisables. Pour plus d’informations, voir : Chapter 18, "Performing Flashback and Database Point-in-Time Recovery" Chapter 21, "Performing RMAN Tablespace Point-in-Time Recovery (TSPITR)"

4. Améliorations aux sauvegardes/restaurations pour VLDB

Les VLDB (Very Large DataBase) justifient d'une recherche d'optimisation pour effectuer les sauvegardes dans des temps optimum. Un fichier de données Oracle peut occuper jusqu’à 128 To. Par défaut, la plus petite unité de sauvegarde avec RMAN est un fichier de données en entier. Oracle 11g a introduit dans RMAN une nouvelle fonctionnalité permettant d’effectuer des opérations de sauvegarde/restauration de très gros fichiers par sections (partie de fichier de taille définie). Cette approche facilite ces opérations et permet de paralléliser la sauvegarde ou la copie de gros fichiers de données. Cette fonctionnalité connait des améliorations avec Oracle 12c. Il est désormais possible d’utiliser cette fonctionnalité avec le mode image-copie de fichiers de données ainsi qu’avec les sauvegardes en  mode incrémental. Cette fonctionnalité  nécessite de positionner le paramètre COMPATIBLE à 12.0 ou supérieur. Voici la syntaxe à utiliser (mot clé SECTION SIZE) :
RMAN> backup tablespace data SECTION SIZE 5g;

RMAN> backup as copy SECTION SIZE 5g database;

RMAN> backup increment level 1 SECTION SIZE 5g datafile 10;
En interrogeant la colonne MULTI_SECTION de la vue dynamique V$BACKUP_SET, vous pourrez constater si cette fonctionnalité est utilisée ou pas.

5. Améliorations pour la duplication d’une base active

Grâce à la fonctionnalité ACTIVE DUPLICATE DATABASE, disponible depuis Oracle 11g, vous pouvez cloner une base source en copiant l’image entière de ses fichiers de données vers l’instance auxiliaire à travers le réseau. Cette procédure ne nécessite pas de disposer au préalable d’un Backup de cette base pour la cloner. Avec Oracle 12c, lorsque la fonctionnalité ACTIVE DUPLICATE DATABASE est lancée, plutôt que d’envoyer l’image-copie entière des fichiers de données, RMAN effectue d’abord la sauvegarde des fichiers de données vers des Backups Sets, puis cette sauvegarde est envoyée vers l’emplacement auxiliaire pour y lancer un RESTORE/RECOVER ensuite. Cette fonctionnalité réduira l’impact global sur l’instance source et accélérera la réalisation de la procédure de clonage. Des options telles que Compression, Chiffrage pourront être utilisées.
RMAN> DUPLICATE TARGET DATABASE to testdb
         FROM ACTIVE DATABASE
         SECTION SIZE 5G
         USING COMPRESSED BACKUPSETS;
Sous Oracle 11g, la base clonée s’ouvrait automatiquement à l’issue de l’opération. La nouvelle clause NOOPEN disponible sous Oracle 12c empêchera l’ouverture automatique de la base en fin d’opération. Par suite, la base restera dans le mode MOUNT en fin de procédure, et il vous faudra ouvrir la base manuellement. Exemples d’utilisation :
  • Vous voulez positionner des options supplémentaires avant l’ouverture telles que FlashBack, Incremental Backup, etc…
  • Pour éviter tout problème de démarrage de la base
  • Pour ajuster les paramètres d’initialisation
  • Pour effectuer un UPGRADE et donc démarrer d’abord la base en mode UPGRADE
Voici comment utiliser la clause NOOPEN :
RMAN> DUPLICATE TARGET DATABASE to testdb
        FROM ACTIVE DATABASE
        SECTION SIZE 5G
        USING COMPRESSED BACKUPSETS
        NOOPEN; 

6. Restore/Recover de fichier de données à travers le réseau

La nouvelle clause Oracle 12c RMAN « FROM SERVICE » vous permet de copier des fichiers de données entre une base Primary et une base StandBy à travers le réseau. Grâce à cette fonctionnalité, vous pouvez restaurer une base entière, un fichier de donnée spécifique, un Controlfile, etc… d’une base Primary vers une base StandBy. Cette méthode s’avère très précieuse dans le cas où il s’est produit un écart important entre la base Primary et la base StandBy à cause d’un problème réseau par exemple. La procédure de resynchronisation de la base StandBy à partir de la base Primary s’en trouvera simplifiée en appliquant les procédures appropriées automatiquement. De plus, vous pouvez facilement faire un Restore/Recover d’un fichier de données à partir de la base StandBy vers la base Primary dans le cas d’une perte de fichier par exemple. Voici quelques exemples : Faire un Restore/Recover d’un fichier de données à parti de la StandBy vers la Primary.

Dans cet exemple, le fichier de données 12 sera restauré sur la base Primary à partir de la base StandBy.

RMAN> CONNECT TARGET "dba_rman@tns_primary AS SYSBACKUP";
RMAN> RESTORE DATAFILE 12 FROM SERVICE tns_standby;
Utiliser le Roll-Forward pour resynchroniser une base StandBy à partir d’une base Primary

Dans ce second exemple, la procédure de resynchronisation de la base StandBy (Roll Forward) sera accélérée en lançant sur la base Primary un Backup incremental en le démarrant suivant le SCN courant de la base StandBy. Les backups sets seront ensuite déplacés ou copiés sur le site StandBy à travers le réseau. Enfin, les Backups seront appliqués automatiquement pour resynchroniser la base StandBy.

RMAN> CONNECT TARGET "dba_rman@tns_standby AS SYSBACKUP";
RMAN> RECOVER DATABASE 
        FROM SERVICE tns_primary 
        USING COMPRESSED BACKUP;
Les transferts de fichiers de données peuvent également bénéficier des fonctionnalités suivantes :
  • Chiffrement (encryption)
  • Utilisation de la clause SECTION SIZE pour découper un fichier de données en morceaux
  • Compression

7. Restore/Recover avec des Snapshots gérés par une baie disque

Oracle RMAN supporte désormais les snapshots gérés par une baie disque (Third-Party Snapshot) pour effectuer un RESTORE/RECOVER d’une base. Auparavant, il fallait passer la base (ou les fichiers sauvegardés) en mode BACKUP pendant le temps de la création d’un Snapshot. La nouvelle technique offre plusieurs avantages :
  • Elimination de la complexité supplémentaire et de l’augmentation momentanée des I/Os pendant la création du Snapshot
  • RESTORE/RECOVER en une seule étape avec la commande RECOVER ... SNAPSHOT TIME. Vous pouvez faire le RECOVER soit jusqu’au présent, soit jusqu’à un point défini dans le passé, postérieur à la date/heure du Snapshot.
Cette approche nécessite trois conditions :
  • La base est en mode Crash Consistent pendant le Snapshot
  • Le Snapshot préserve l’ordre d’écriture pour chaque fichier
  • La technologie Snapshot stocke la date/heure de fin de Snapshot
Les commandes suivantes peuvent être lancées soit avec RMAN, soit avec SQL*Plus (sauf la troisième qui nécessite SQL*Plus, à cause de la clause CANCEL). Pour faire un RECOVER  entier d’une base à partir du dernier SNAPSHOT :
RMAN> RECOVER DATABASE ;
Pour faire un RECOVER  d’une base en précisant le SNAPSHOT à utiliser :

Ce Recover utilise un Snapshot en date du 15 août à 14h00 pour récupérer la base. La clause UNTIL TIME peut spécifier jusqu’à quand le RECOVER doit être effectué.

     RECOVER DATABASE UNTIL TIME '10/15/2012 15:00:00' 
        SNAPSHOT TIME '10/15/2012 14:00:00';
Pour faire un RECOVER  partiel d’une base à l’aide des fichiers Redo Logs archivés :

Ce Recover utilise un Snapshot en date du 15 août à 14h00 pour récupérer la base. Le Recover sera effectué jusqu’au CANCEL.

     RECOVER DATABASE UNTIL CANCEL
        SNAPSHOT TIME '10/15/2012 14:00:00';
Notes importantes :
  • La date et l’heure spécifiées dans la clause SNAPSHOT TIME doivent être légèrement postérieures (quelques secondes) à l’heure de fin de la commande de création du Snapshot (et non pas de sa création physique complète).
  • Prendre en compte le fait que la date et l'heure de la baie peuvent être légèrement différente de la date et heure du serveur Oracle Database
  • Si le Time-Zone de l’heure de la baie n’est pas le même que l'heure du serveur Oracle, il faut convertir l’heure du Snapshot pour être dans le même Time-zone que le serveur Oracle
Liens de références :

http://docs.oracle.com/cd/E16655_01/backup.121/e17630/osbackup.htm#BRADV90019

http://docs.oracle.com/cd/E16655_01/backup.121/e17630/osrecvry.htm#CHDCGFAJ

8. Migration de bases ou tablespaces entre systèmes différents

Le point avec les versions Oracle précédant la 12c.
  • Déjà avant Oracle 12c, RMAN sait transporter des bases, des fichiers de données et des tablespaces entre plateformes différentes.
  • Le transport de données entre plateformes ayant un format Endian différent impose le transfert par tablespaces.
  • Si le format Endian est identique entre les systèmes, le transfert peut aussi se faire au niveau de la base entière, avec une conversion pour s’adapter au système cible. Cette conversion peut se faire soit sur une copie effectuée sur le système source, soit sur le système cible. Ces transports de données imposent l’utilisation d’images-copies, avec la commande RMAN CONVERT.
La version Oracle 12c amène quelques nouveautés :
  • Le transport des données entre systèmes différents peut s’effectuer avec des Backups Sets RMAN
  • Il est également possible de créer des backups inter-plateformes non-consistants et stockés dans des images-copies ou dans des Backups Sets. C’est la nouvelle clause ALLOW INCONSISTENT qui offre cette fonctionnalité.
  • L’utilisation de Backup Sets apporte l’utilisation des options Compression et Multi-Section qui diminuent le temps de transfert.
  • Les temps d’interruption d’une application changeant de système sont ainsi diminués.
  • La copie d’une base entière impose que la base soit en ReadOnly
  • La copie par tablespaces permet que la base et les tablespaces copiés soit en Read-Write
Note : les Backups Sets de type Cross Platform ne sont pas stockés dans le Controlfile car ils ne sont pas utilisables pour des RESTORE ordinaires de la base. Voici un schéma de principe :

On peut parler de " Turbo Transportable Tablespace " :

Voici quelques exemples touchant un transfert d'une base entière :
  • Pour sauvegarder une base entière avec conversion à la source vers un système précis :     RMAN> BACKUP TO PLATFORM 'Linux x86 64-bit' FORMAT '/u05/backup/transport.bck' DATABASE;
  • Pour sauvegarder une base entière avec conversion sur la cible :     RMAN> BACKUP FOR TRANSPORT FORMAT '/u05/backup/transport.bck' DATABASE;
  • Pour faire un Restore de la base entière à partir du Backup Set copié sur le système cible     RMAN> RESTORE FOREIGNDATABASE FROM BACKUPSET '/u05/backup/transport.bck';
  Voici quelques exemples touchant un transfert par tablespaces (avec utilisation de Data Pump dans un contexte de tablespace transportable). Une action  préalable consiste à passer le tablespace à transférer en READ-ONLY, à moins d'utiliser la clause ALLOW INCONSISTENT.
  • Sauvegarde d’un tablespace pour transfert avec conversion à la source vers un système précis :         RMAN> BACKUP TO PLATFORM 'Linux x86 64-bit'                 FORMAT '/u05/backup/transport.bck'                 DATAPUMP FORMAT '/u05/backup/transport.dmp'                 TABLESPACE compta;
  • Sauvegarde d’un tablespace avec conversion sur la cible :         RMAN> BACKUP FOR TRANSPORT                 FORMAT '/u05/backup/transport.bck'                 DATAPUMP FORMAT '/u05/backup/transport.dmp'                 TABLESPACE compta;
  • Pour faire un Restore du tablespace à partir du Backup Set et du fichier DMP copié sur le système cible
RMAN> RESTORE FOREIGN TABLESPACE compta 
          FORMAT '/u02/DB01/compta.dbf'
          FROM BACKUPSET '/u05/backup/transport.bck'
          DUMP FILE FROM BACKUPSET '/u05/backup/transport.dmp' ;

Notes:

  • Une restauration inconsistante entre plateformes est également possible avec le transfert par tablespaces en utilisant la clause ALLOW INCONSISTENT
  • Dans ce cas, pour reporter les dernières modifications, les fichiers de données, après RESTORE sur le système cible, pourront faire l’objet d’un RECOVER à partir de la base source en utilisant la fonctionnalité Backup Cross-Platform incrémental. La commande RECOVER FOREIGN DATAFILE COPY sera utilisée pour cela.
----------------------------------------------------------------------------------------------------------------------------------- Vous souhaitez en savoir plus sur ce sujet ? Contactez-nous ici pour de plus amples informations.

Commentaires (0)