Blog ENI : Toute la veille numérique !
💥 Un livre PAPIER acheté
= La version EN LIGNE offerte pendant 1 an !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici

Sauvegarde et récupération

Principes

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 mise en œuvre d’une protection des fichiers sensibles de la base :

  • fichiers de contrôle ;

  • fichiers de journalisation.

  • la mise en place d’une stratégie de sauvegarde/restauration :

  • adaptée aux contraintes de l’entreprise ;

  • testée et documentée.

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 :

  • Est-il acceptable de perdre des données ?

  • Est-il possible d’arrêter périodiquement la base ?

  • Est-il possible de réaliser une sauvegarde complète de la base pendant l’arrêt ?

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 :

  • Les données sont-elles mises à jour quotidiennement par les utilisateurs ? C’est typiquement le cas dans une application transactionnelle.

  • Les données sont-elles mises à jour périodiquement (toutes les nuits, toutes les semaines) et simplement consultées dans la journée ? C’est typiquement le cas avec une application décisionnelle.

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...

Archivage des fichiers de journalisation

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 :

  • Modifier dans le fichier de paramètres serveur les paramètres d’initialisation qui concernent les processus d’archivage :

  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; 
  • Arrêter proprement la base de données (pas ABORT) :

SQL> SHUTDOWN IMMEDIATE 
  • Monter la base de données :

SQL> STARTUP MOUNT 
  • Passer la base de données en mode ARCHIVELOG :

SQL> ALTER DATABASE ARCHIVELOG; 
  • Sauvegarder la base de données (permet une sauvegarde T0 du nouveau mode de fonctionnement de la base de données).

  • Ouvrir la base de données :

SQL> ALTER DATABASE OPEN; 

Le mode ARCHIVELOG/NOARCHIVELOG est une propriété de la base qui se modifie par l’ordre...

Présentation du Recovery Manager

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.

Les fichiers de contrôle sont donc encore plus importants lorsque vous utilisez RMAN sans catalogue de récupération. Si vous perdez tous les fichiers de contrôle de la base cible, RMAN n’a plus d’informations sur les sauvegardes disponibles. Si vous repartez d’une sauvegarde de fichier de contrôle, RMAN n’aura pas d’informations sur les sauvegardes réalisées après la sauvegarde du fichier de contrôle. Si vous n’utilisez pas de catalogue de récupération, vous avez également intérêt à augmenter la valeur du paramètre CONTROL_FILE_RECORD_KEEP_TIME (au moins 10 à 15 jours).

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...

Sauvegarde

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 commande BACKUP propose un très grand nombre d’options. Dans cet ouvrage, nous ne présenterons que les options les plus couramment utilisées.

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

INCREMENTAL LEVEL n [CUMULATIVE]

Indique que la sauvegarde est une sauvegarde incrémentale.

VALIDATE

Indique simplement de vérifier que la sauvegarde...

Le référentiel RMAN

1. Trouver des informations sur les sauvegardes

a. La commande LIST

La commande LIST permet d’interroger le référentiel RMAN pour afficher des informations sur les sauvegardes et les fichiers de journalisation archivés.

Syntaxe 1

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' } 

Syntaxe 2

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

Syntaxe 3

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

Toutes les options possibles ne sont pas présentées ici.

Première syntaxe

La première syntaxe permet d’afficher des informations sur les sauvegardes enregistrées dans le référentiel RMAN.

Par défaut, les commandes LIST BACKUP, LIST COPY et LIST BACKUPSET listent tous les éléments enregistrés dans le référentiel RMAN.

Dans le cas des commandes LIST BACKUP et LIST COPY, il est possible de spécifier un ou plusieurs objets pour n’afficher que les sauvegardes des objets en question.

Exemple

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...

Récupération

1. Vue d’ensemble

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

  • De la nature du(des) fichier(s) endommagé(s) ou perdu(s) :

  • fichier de données ;

  • fichier de contrôle ;

  • fichier de paramètres serveur ;

  • fichier de journalisation.

  • Du mode de fonctionnement de la base :

  • ARCHIVELOG

  • NOARCHIVELOG.

  • Des sauvegardes disponibles.

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.

Surtout, ne vous précipitez pas et n’hésitez pas à vous faire aider par le support Oracle.

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.

Un conseil avant de commencer toute opération de récupération, réalisez si possible une sauvegarde complète de la base endommagée. Cela peut fournir un point de retour en cas d’aggravation de la situation par une mauvaise manipulation. Au minimum, réalisez une sauvegarde du fichier de contrôle et des fichiers de journalisation en ligne (par simple copie au niveau du système d’exploitation).

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

Data Recovery Advisor

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 :

  • Afficher les échecs actuels (statut OPEN) : LIST FAILURE.

  • Déterminer les actions à effectuer pour résoudre le(s) problème(s) : ADVISE FAILURE.

  • Résoudre le(s) problème(s) : REPAIR FAILURE.

  • Retourner à l’étape 1 pour confirmer que les problèmes ont été résolus ou voir s’il reste encore des problèmes.

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...

Les techniques de flashback

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 :

  • Flashback Query : permet de lire les données telles qu’elles étaient à un instant dans le passé (apparu en version 9).

  • Flashback Version Query : permet de voir toutes les versions d’une ligne sur un certain intervalle de temps (apparu en version 10).

  • Flashback Transaction Query : permet de voir les modifications réalisées par une ou plusieurs transactions sur un certain intervalle de temps (apparu en version 10).

  • Flashback Transaction : permet d’annuler les modifications d’une transaction et de ses transactions dépendantes (apparu en version 11).

  • Flashback Data Archive (Oracle Total Recall) : permet de conserver sur le long terme, toutes les modifications apportées à une table (apparu en version 11).

  • Flashback Table : permet de ramener une table dans l’état où elle était, à un certain moment dans le passé (apparu en version 10).

  • Flashback Drop : permet de ramener la table dans l’état où elle était, juste avant sa suppression (apparu en version 10).

  • Flashback Database : permet de ramener la totalité de la base de données dans l’état où elle était à un certain moment dans le passé (apparu en version 11).

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...

Utiliser Oracle SQL Developer

EM Express ne propose aucune page pour effectuer des sauvegardes ou des récupérations. Mais pour cela, il est possible, malgré certaines limites, d’utiliser Oracle SQL Developer.

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 :

images/14RI01N19.png

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

Actions RMAN programmées

Visualisation des travaux RMAN lancés à partir d’Oracle SQL Developer.

Copies d’image

Gestion (visualisation, suppression, contre-vérification) des copies image.

Ensembles de sauvegarde

Gestion (visualisation, suppression, contre-vérification) des jeux de sauvegarde (backup set).

Paramètres RMAN

Configuration de RMAN.

Travaux de sauvegarde

Gestion (consultation, création) des travaux de sauvegarde et de récupération.

À 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

images/14RI02N19.png

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...