Sauvegarde et récupération

1. Vue d’ensemble

Assurer la sécurité des données est une des tâches principales de l’administrateur.

Cette sécurité est assurée par :

La protection des fichiers de contrôle et des fichiers de journalisation s’effectue par multiplexage (voir le chapitre Fichiers de contrôle et de journalisation).

Les questions à se poser pour définir la stratégie sont les suivantes :

La réponse à la question "est-il acceptable de perdre des données ?" est rarement "oui". Si exceptionnellement, la réponse est "oui", il faut déterminer jusqu’à quelle limite : 1 jour, 2 jours, 1  semaine ?

Il est également nécessaire de déterminer la nature de l’activité sur la base :

2. L’archivage des fichiers de journalisation

Comme nous l’avons déjà vu, les fichiers de journalisation constituent un journal des modifications apportées à la base. Ils sont organisés en groupes écrits de manière circulaire : les informations sauvegardées sont donc par défaut périodiquement écrasées.

Ces fichiers de journalisation peuvent être réappliqués à une sauvegarde de fichier de données, pour rejouer toutes les modifications survenues entre la sauvegarde...

1. Vue d’ensemble

Activer l’archivage des fichiers de journalisation s’effectue en mettant la base de données dans le mode ARCHIVELOG : ce mode permet de garantir qu’un groupe de fichiers de journalisation ne sera pas réutilisé tant qu’il n’a pas été archivé.

Depuis la version 10, placer la base de données en mode ARCHIVELOG démarre automatiquement plusieurs processus d’archivage lors de l’ouverture de la base de données ; dans les versions précédentes, il fallait le faire explicitement. Par contre, il est toujours opportun, même en version 10, de positionner certains paramètres d’initialisation qui concernent les processus d’archivage.

La base de données peut être créée immédiatement en mode ARCHIVELOG. Généralement, la base de données est créée en mode NOARCHIVELOG puis passée en ARCHIVELOG. Archiver les fichiers de journalisation générés par la création de la base de données présente un faible intérêt (mais un volume d’archives important).

2. Mode opératoire

Le mode opératoire est le suivant :

  SQL> ALTER SYSTEM SET 
    2      log_archive_format='redo_%S_%R_%T.arc' 
    3  SCOPE=SPFILE; 
  SQL> ALTER SYSTEM SET 
    2      log_archive_dest_1='LOCATION=h:\app\oracle\arch\HERMES' 
    3  SCOPE=SPFILE; 

SQL> SHUTDOWN IMMEDIATE 

SQL> STARTUP MOUNT 

SQL> ALTER DATABASE ARCHIVELOG; 

SQL> ALTER DATABASE OPEN; 

1. Introduction

RMAN est un outil ligne de commande qui permet de réaliser des sauvegardes et des récupérations d’une base de données appelée base de données cible (target database).

RMAN utilise un référentiel (repository) pour stocker des informations sur sa configuration, les sauvegardes réalisées, la structure de la base cible, les fichiers de journalisation archivés, etc.

Ce référentiel est toujours stocké dans le fichier de contrôle de la base cible. La durée de conservation des informations dans le fichier de contrôle est déterminée par le paramètre d’initialisation CONTROL_FILE_RECORD_KEEP_TIME (7 jours par défaut). 

Le référentiel peut aussi être stocké dans un catalogue de récupération (recovery catalog) qui se matérialise par un schéma dans une autre base de données. Un seul catalogue de récupération peut être utilisé pour centraliser les référentiels RMAN de plusieurs bases de données cibles. Employer un catalogue de récupération séparé est intéressant car les informations de sauvegarde sont préservées si tous les fichiers de contrôle de la base cible sont perdus.

Si vous définissez une zone de récupération rapide (fast recovery area), à l’aide des paramètres DB_RECOVERY_FILE_DEST et DB_RECOVERY_FILE_DEST_SIZE, vous pouvez bénéficier des fonctionnalités de sauvegarde et de restauration automatiques...

1. Généralités

La commande BACKUP permet d’effectuer une sauvegarde. Pour que cette commande fonctionne, il faut que la base de données soit montée ou ouverte car RMAN a besoin d’accéder au fichier de contrôle de la base cible, notamment pour y enregistrer l’existence de la sauvegarde. Les sauvegardes base ouverte de la totalité de la base de données, de fichiers de données ou de tablespace ne sont possibles que si la base de données fonctionne en mode ARCHIVELOG. Si la base de données fonctionne en mode NOARCHIVELOG, pour effectuer une sauvegarde de ce type, il faut au préalable arrêter la base de données (proprement) puis la monter.

SHUTDOWN IMMEDIATE 
STARTUP MOUNT 
BACKUP ... ; 

RMAN peut sauvegarder des fichiers de données, des fichiers de contrôle, des fichiers de journalisation archivés, le fichier de paramètres serveur ou des éléments de sauvegarde (d’une sauvegarde précédente). Comme indiqué précédemment, une sauvegarde RMAN peut être réalisée sous la forme d’une copie image (image copy) ou d’un jeu de sauvegarde (backup set). Par défaut, la sauvegarde s’effectue dans un jeu de sauvegarde.

Lorsque RMAN effectue une sauvegarde de fichiers de données dans un jeu de sauvegarde, il ne sauvegarde pas les blocs jamais utilisés des fichiers, ce qui permet de gagner de la place. En complément, il est possible de compresser le jeu de sauvegarde ; cela ralentit légèrement la sauvegarde, consomme un peu de CPU, mais diminue la taille de la sauvegarde de manière importante (typiquement, division par 5). Ces deux fonctionnalités ne sont pas disponibles dans le cas d’une copie image (copie bit à bit du fichier d’origine).

La syntaxe générale de la commande BACKUP est la suivante :

BACKUP [comment] quoi [option] 

La clause comment peut prendre une ou plusieurs des valeurs suivantes :

INCREMENTAL LEVEL n [CUMULATIVE]

VALIDATE

1. Trouver des informations sur les sauvegardes

LIST cible [ BY FILE | SUMMARY ] [ filtre_sauvegarde ]; 
       - cible 
{ BACKUP | COPY } [ OF objets ] 
BACKUPSET 
       - objets 
DATABASE 
DATAFILE liste_numéros_ou_noms 
TABLESPACE liste_noms 
CONTROLFILE 
SPFILE 
ARCHIVELOG { ALL | filtre_archive } 
       - filtre_archive 
FROM TIME 'date' 
UNTIL TIME 'date' 
TIME BETWEEN 'date1' AND 'date2' 
       - filtre_sauvegarde 
TAG [=] 'nom' 
COMPLETED { AFTER 'date1' 
           | BEFORE 'date2' 
           | BETWEEN 'date1' AND 'date2' } 

LIST { BACKUPSET | BACKUPPIECE } { liste_clés | TAG [=] 'nom' }; 

LIST ARCHIVELOG { ALL | filtre_archive } [info_sauvegarde];  
       - info_sauvegarde 
BACKED UP n TIMES TO DEVICE TYPE [DISK | 'media'] 

LIST BACKUP OF DATABASE ; # n'importe quel fichier de la base 
LIST BACKUP OF DATAFILE 1,'E:\app\oracle\oradata\HERMES\DATA01.DBF' ; 
LIST BACKUP OF TABLESPACE system,sysaux ; 
LIST BACKUP OF CONTROLFILE SPFILE ; 
LIST BACKUP OF ARCHIVELOG ALL ; 
LIST BACKUP OF ARCHIVELOG UNTIL...

1. Vue d’ensemble

La stratégie de récupération dépend de plusieurs facteurs :

Que faire en cas de problème ?

1. identifier la nature du problème ;

2. définir le mode opératoire en tenant compte du mode de fonctionnement de la base et des sauvegardes disponibles.

Depuis la version 11, Oracle propose un conseiller pour la récupération des données (le Data Recovery Advisor) qui permet de diagnostiquer et résoudre facilement les incidents (perte ou corruption) des données sur disque. Cet outil est présenté dans la section Data Recovery Advisor.

Dans la suite du document, les termes "perdu" et "endommagé" seront indifféremment utilisés pour désigner l’incident ; dans la pratique, que le fichier soit perdu ou simplement endommagé, les procédures de restauration sont les mêmes.

Une opération de récupération s’effectue essentiellement avec RMAN. Pour certaines étapes, SQL*Plus peut être nécessaire, essentiellement pour interroger quelques vues du dictionnaire de données (mais ce n’est plus nécessaire en version 12 puisque les ordres SELECT peuvent être exécutés directement dans RMAN) ; une connexion AS SYSDBA sera nécessaire si la base n’est pas ouverte.

Dans une opération de "restauration" ou de "récupération", il existe...

1. Vue d’ensemble

Le Data Recovery Advisor est un outil qui permet de simplifier et d’automatiser le diagnostic et la résolution des problèmes (perte ou corruption) sur les fichiers de la base données. Cet outil est apparu en version 11.

Dans la terminologie du conseiller, un échec (failure en anglais) sur un fichier est identifié par un numéro unique et est caractérisé par un statut (OPEN ou CLOSED) et une priorité (LOW, HIGH ou CRITICAL).

Le statut est OPEN tant que le problème n’a pas été résolu ; il passe à CLOSED ensuite.

La priorité est CRITICAL lorsque la base de données est totalement indisponible et HIGH si elle est partiellement indisponible ; dans les deux cas, il convient de résoudre le problème rapidement. La priorité LOW n’est pas attribuée par le conseiller. Par contre, si vous jugez qu’une priorité HIGH a peu d’impact sur le fonctionnement de la base de données et ne nécessite pas de traitement immédiat, vous pouvez descendre manuellement la priorité à LOW.

Les informations relatives aux échecs sont stockées dans le référentiel de diagnostic automatique. Pour fonctionner, le Data Recovery Advisor nécessite que l’instance soit démarrée (mais la base de données peut ne pas être montée ce qui permet de diagnostiquer et résoudre les incidents sur les fichiers de contrôle).

2. Utilisation

Dans RMAN, les étapes pour diagnostiquer et résoudre les problèmes à l’aide du conseiller sont les suivantes :

Au préalable, il est possible d’exécuter la commande VALIDATE DATABASE pour vérifier la totalité de la base de données (mais il faut que la base de données soit montée).

En complément des commandes LIST...

1. Vue d’ensemble

Les techniques de flashback sont un ensemble de fonctionnalités proposées par Oracle qui permettent de voir l’état passé des données ou de ramener une table ou la totalité de la base de données dans le passé.

Les fonctionnalités proposées sont les suivantes :

Seules les fonctionnalités Flashback Query et Flashback Drop sont disponibles dans toutes les éditions de la base de données (et donc notamment en Standard Edition).

La fonctionnalité Flashback Data Archive (Oracle Total Recall) est aussi disponible dans toutes les éditions de la base de données depuis la version 11.2.0.4 (avant cette version, elle nécessitait l’option Oracle Advanced Compression). Par contre, l’optimisation des tables historiques (compression notamment) nécessite toujours cette option (et donc l’Enterprise Edition).

Les autres fonctionnalités de flashback nécessitent l’Enterprise Edition mais sans option supplémentaire.

Ces fonctionnalités...

1. Introduction

Dans le panneau DBA, le dossier Sauvegarde/Récupération RMAN donne accès aux différentes fonctionnalités qui permettent d’utiliser RMAN :

Les différentes fonctionnalités sont réparties dans cinq sous-dossiers :

À la base, les différentes fenêtres de dialogue proposées par Oracle SQL Developer vont permettre de générer des commandes RMAN qui pourront être copiées ou enregistrées dans un fichier pour être exécutées ensuite avec l’outil ligne de commande. En complément, il est possible d’exécuter les commandes RMAN directement à partir d’Oracle SQL Developer, après l’avoir configuré en conséquence.

Les fenêtres de dialogue proposées par Oracle SQL Developer comportent donc des éléments communs qui vont permettre d’effectuer l’action souhaitée.

Exemple

Par défaut, si l’opération le permet, Oracle SQL Developer propose de lancer un travail qui va exécuter un script contenant les commandes relatives à l’opération. Pour cela, il faudra au préalable créer une identification. Nous reviendrons sur ce point ultérieurement. Dans la pratique, cette fonctionnalité est disponible uniquement pour les opérations qui ne nécessitent pas de redémarrage de la base de données. Lorsque la fonctionnalité n’est pas disponible, la liste déroulante Traitement du script n’est pas sélectionnable et propose uniquement d’enregistrer...