D78850FR20 sg1

Oracle Database 12c: Backup
and Recovery Workshop
Manuel du stagiaire – Volume 1

D78850FR20
Edition 2.0 | Septembre 2015 | D91920
Learn more from Oracle University at oracle.com/education/

Auteurs Copyright © 2015, Oracle et/ou ses affiliés. Tous droits réservés.
Maria Billings Avertissement

Donna Keesling
Cette documentation contient des informations qui sont la propriété d'Oracle
Corporation et sont protégées par les lois relatives aux droits d'auteur et à la
Révisions et propriété intellectuelle. Vous ne pouvez copier et imprimer ce document qu'à
contributions techniques des fins d'utilisation personnelle lors de la participation à une formation
dispensée par Oracle. Le document ne peut être modifié ou altéré en
Chris Andrews aucune manière. A l'exception des cas où l'utilisation faite du document
Tim Chien s'inscrit dans le respect des lois relatives aux droits d'auteur, vous ne
pouvez pas utiliser, partager, télécharger, copier, imprimer, afficher,
Donna Cooksey exécuter, reproduire, publier, breveter, diffuser, transmettre ou distribuer ce
Raluca Constantin document, en partie ou en totalité, sans l'autorisation expresse d'Oracle.
Stefan Dolea Les informations fournies dans ce document sont susceptibles de
Gerlinde Frenzen modification sans préavis. Par ailleurs, Oracle Corporation ne garantit pas
Joel Goodman qu'elles soient exemptes d'erreurs et vous invite, le cas échéant, à lui en
faire part par écrit à l'adresse suivante : Oracle University, 500 Oracle
Daniela Hansell Parkway, Redwood Shores, California 94065 USA.
Dominique Jeunot
Restrictions applicables au gouvernement américain : Restricted
Sean Kim Rights Notice
Gwen Lazenby
If this documentation is delivered to the United States Government or
Naoki Kato
anyone using the documentation on behalf of the United States Government,
Olga Krakovna the following notice is applicable:
Cris Pedregal
U.S. GOVERNMENT RIGHTS
Pavan Nisankara Rao The U.S. Government’s rights to use, modify, reproduce, release, perform,
Puneet Sangar display, or disclose these training materials are restricted by the terms of the
applicable Oracle license agreement and/or the applicable U.S. Government
Ron Soltani contract.
Jim Spiller
Branislav Valny Marques
Harald van Breederode Oracle, JD Edwards, PeopleSoft et Siebel sont des marques déposées
Lachlan Williams d'Oracle Corporation et/ou de ses filiales. Tout autre nom de produit ou de
société peut être un marque de son propriétaire.
Rédacteurs
Arijit Ghosh
Malavika Jinka
Smita Kommini
Concepteur graphique
Maheshwari Krishnamurthy
Editeurs
Glenn Austin
Jayanthy Keshavamurthy
Srividya Rameshkumar
Table des matières
1 Introduction
Objectifs 1-2
Contexte du cursus de formation 1-3
Planning recommandé 1-4
Innovations d'Oracle Database 1-5
Cloud computing d'entreprise 1-6
Evaluer vos besoins en matière de récupération 1-7
Catégories de pannes 1-10
Défaillances de données 1-11
Solutions de protection des données Oracle 1-12
Aide sous forme de vues d'ensemble et de conseils 1-13
Solution de sauvegarde complète d'Oracle 1-14
Oracle Recovery Manager (RMAN) intégré 1-15
Oracle Secure Backup 1-16
Module Oracle Secure Backup pour le cloud 1-17
Oracle Data Guard : Présentation 1-18
Base de secours physique : Architecture Redo Apply 1-19
Oracle Active Data Guard 1-20
Base de secours logique : Architecture SQL Apply 1-21
Architecture MAA d'Oracle : Robustesse et intégration de la
protection des données 1-22
Architecture de base de l'atelier 1-23
Quiz 1-24
Synthèse 1-25
Présentation des exercices : Explorer l'environnement du cours 1-26
2 Mise en route
Objectifs 2-2
Noms des composants élémentaires d'un serveur Oracle Database 2-3
Architecture d'un serveur de base de données Oracle : Présentation 2-4
Rappels sur l'architecture de stockage de la base de données 2-6
Noms des structures logiques et physiques d'une base de données 2-8
Rappels sur l'architecture des processus 2-10
Structures des processus 2-11
Revue des processus 2-13
iii
Rappels sur le processus DBWn (Database Writer) 2-14
Rappels sur le processus LGWR (Log Writer) 2-15
Rappels sur le processus CKPT (Checkpoint) 2-17
Rappels sur le processus SMON (System Monitor) 2-18
Rappels sur le processus PMON (Process Monitor) 2-19
Rappels sur le processus ARCn (Archiver) 2-20
Exercice sur les noms de processus 2-21
Mode de journal de la base de données 2-23
Base de données ORCL avec ASM 2-24
Faciliter la gestion de la base de données avec Oracle Restart 2-26
Outils d'administration de base de données Oracle 2-28
Principe de séparation des tâches d'administration 2-30
Se connecter à RMAN et à une base de données cible 2-31
Utilisation du code SQL dans RMAN 2-32
Approche rapide de la résolution d'un problème 2-33
Effectuer la restauration et la récupération d'une base de données en mode
NOARCHIVELOG 2-34
Quiz 2-35
Synthèse 2-36
Présentation des exercices : Mise en route 2-37
3 Configuration en vue de la récupération

Objectifs 3-2
Types de commande RMAN 3-3
Commandes de type travail : Exemple 3-4
Configurer des paramètres persistants pour RMAN 3-5
Visualiser les paramètres persistants 3-6
Gérer les paramètres persistants 3-7
Définir une stratégie de conservation 3-8
Stratégie de conservation avec fenêtre de récupération : Exemple 3-10
Quiz 3-11
Utiliser une zone de récupération rapide 3-12
Configurer la zone de récupération rapide 3-14
Dimensionner la zone de récupération rapide 3-16
Gestion de l'espace dans la zone de récupération rapide 3-18
Multiplexer les fichiers de contrôle 3-20
Sauvegarde automatique du fichier de contrôle 3-21
Recommandation : Multiplexer les fichiers de journalisation 3-23
Multiplexer le fichier de journalisation 3-24
Créer des fichiers de journalisation archivés 3-25
Configurer le mode ARCHIVELOG 3-26
iv
Quiz 3-27
Synthèse 3-28
Présentation des exercices : Configuration en vue de la récupération 3-29
4 Utiliser le catalogue de restauration RMAN

Objectifs 4-2
Stockage des données dans le référentiel RMAN : Différentes options 4-3
Stocker des informations dans le catalogue de restauration 4-4
Avantages d'un catalogue de restauration 4-5
Créer le catalogue de restauration : Trois étapes 4-7
Configurer la base de données du catalogue de restauration 4-8
Créer le propriétaire du catalogue de restauration 4-9
Créer le catalogue de restauration 4-10
Gérer les enregistrements des bases de données cible dans le catalogue de
restauration 4-11
Enregistrer une base de données dans le catalogue de restauration 4-12
Supprimer une base de données cible dans le catalogue de restauration 4-14
Resynchronisation du catalogue de restauration : Concepts 4-15
Resynchroniser manuellement le catalogue de restauration 4-17
Utiliser des scripts stockés RMAN 4-18
Exécuter des scripts stockés RMAN 4-19
Gérer les scripts RMAN stockés 4-20
Sauvegarder le catalogue de restauration 4-21
Créer et utiliser des catalogues privés virtuels 4-22
Créer un catalogue privé virtuel (12.1.0.1) 4-23
Gérer des catalogues privés virtuels 4-24
Créer un catalogue privé virtuel (12.1.0.2) 4-25
Mettre à niveau les catalogues privés virtuels pour la version 12.1.0.2 4-27
Quiz 4-28
Synthèse 4-30
Présentation des exercices : Utiliser le catalogue RMAN 4-31
Présentation des exercices : Préparer l'environnement de formation 4-32
5 Stratégies de sauvegarde et terminologie associée

Objectifs du chapitre 5-2
Solutions de sauvegarde : Présentation 5-3
Terminologie associée à la sauvegarde 5-4
Equilibrer les besoins de sauvegarde et de récupération 5-5
Comparaison de stratégies de sauvegarde 5-7
Option 1 : Sauvegardes complètes et incrémentielles 5-8
Option 2 : Sauvegardes sur disque mises à jour de façon incrémentielle 5-9
v
Option 3 : Délestage des sauvegardes vers une base de secours physique dans un
environnement Data Guard 5-10
Sauvegarder des tablespaces en lecture seule 5-11
Sauvegarde et récupération de data warehouse : Méthodes recommandées 5-12
Terminologie supplémentaire en matière de sauvegarde 5-13
Créer des jeux de sauvegarde 5-14
Créer des copies d'image 5-15
Créer une sauvegarde de l'ensemble de la base de données 5-16
Quiz 5-18
Synthèse 5-21
Présentation des exercices : Mettre au point une stratégie de sauvegarde 5-22
Etude de cas 1 : Protéger une base de données OLTP 5-23
Etude de cas 2 : Protéger une base de données DSS 5-24
Etude de cas 3 : Protéger la base de données du catalogue de restauration 5-25
6 Réaliser des sauvegardes

Objectifs 6-2
Types de sauvegarde RMAN 6-3
Sauvegardes mises à jour de façon incrémentielle 6-5
Sauvegardes mises à jour de façon incrémentielle : Exemple 6-7
Sauvegarde incrémentielle rapide 6-8
Gestion du fichier de suivi des modifications de bloc 6-9
Surveiller le suivi des modifications de bloc 6-10
Sauvegarde et restauration automatiques de disque à disque 6-11
Sauvegarde recommandée par Oracle 6-12
Générer des rapports sur les sauvegardes 6-13
Utiliser les vues dynamiques 6-14
Gérer les sauvegardes : Vérification croisée et suppression 6-15
Quiz 6-16
Synthèse 6-18
Présentation des exercices : Créer des sauvegardes incrémentielles 6-19
7 Améliorer des sauvegardes

Objectifs 7-2
Economiser de l'espace de sauvegarde par compression des blocs inutilisés 7-3
Compresser des sauvegardes 7-4
Utiliser la compression RMAN des sauvegardes 7-5
Quiz 7-6
Utiliser un gestionnaire de support 7-7
Configurer la sauvegarde et la restauration pour les fichiers très volumineux 7-9
Sauvegarder et restaurer des fichiers très volumineux 7-10
vi
Créer des sauvegardes RMAN multisections 7-11
Créer des copies proxy 7-12
Créer des jeux de sauvegarde duplexés à l'aide de la commande
BACKUP COPIES 7-13
Créer des sauvegardes de jeux de sauvegarde 7-14
Concepts relatifs aux sauvegardes d'archivage 7-15
Créer des sauvegardes d'archivage avec RMAN 7-17
Gérer les sauvegardes d'archivage 7-18
Sauvegarder des fichiers de récupération 7-19
Sauvegarder le fichier de contrôle dans un fichier trace 7-20
Enregistrer des fichiers de sauvegarde supplémentaires dans le catalogue 7-21
Sauvegarder les métadonnées de groupes de disques ASM 7-22
Quiz 7-23
Synthèse 7-25
Présentation des exercices : Sauvegarder des fichiers supplémentaires 7-26
8 Utiliser les sauvegardes RMAN cryptées

Objectifs 8-2
RMAN : Cryptage des données de sauvegarde 8-3
Comparaison entre cryptage OSB et cryptage RMAN 8-4
Créer des sauvegardes cryptées via RMAN 8-5
TDE (Transparent Data Encryption) : Définition 8-6
Utiliser le mode de cryptage transparent 8-8
Sauvegarder le fichier de clés 8-10
Configurer le cryptage RMAN 8-11
Utiliser le cryptage basé sur un mot de passe 8-12
Utiliser le mode de cryptage double 8-13
Considérations relatives aux sauvegardes cryptées par RMAN 8-14
Restaurer des sauvegardes cryptées 8-15
Quiz 8-16
Synthèse 8-17
Présentation des exercices : Utiliser les sauvegardes cryptées par RMAN 8-18
9 Diagnostiquer les défaillances

Objectifs 9-2
Réduire le délai de diagnostic des problèmes 9-3
Workflow de diagnostic automatique 9-4
Référentiel ADR 9-5
Outil de ligne de commande ADR (ADRCI) 9-6
Vue V$DIAG_INFO 9-7
Interpréter les messages RMAN 9-8
vii
Option DEBUG 9-9
Interpréter les piles d'erreurs RMAN 9-10
Data Recovery Advisor 9-11
Défaillances de données : Exemples 9-14
Data Recovery Advisor : Interface de ligne de commande RMAN 9-15
Afficher la liste des défaillances de données 9-16
Obtenir un conseil de réparation 9-18
Exécuter les réparations 9-19
Classifier (et fermer) les défaillances 9-20
Vues de la fonction de conseil Data Recovery Advisor 9-21
Quiz 9-22
Définition de la corruption de bloc 9-25
Symptômes d'une corruption de bloc : ORA-01578 9-26
Comment traiter une corruption 9-27
Définir les paramètres pour la détection des corruptions 9-28
Restauration physique de bloc 9-29
Prérequis à la restauration physique de bloc 9-30
Récupérer des blocs individuels 9-31
Méthode recommandée : Vérifications proactives 9-32
Rechercher les corruptions de bloc 9-33
Réparation automatique de blocs : Base principale 9-34
Réparation automatique de blocs : Base de secours physique 9-35
Synthèse 9-36
Présentation des exercices : Diagnostiquer une défaillance de base
de données 9-37
10 Concepts de restauration et de récupération

Objectifs 10-2
Comprendre la perte de fichier 10-3
Techniques de réparation des données 10-4
Restauration et récupération 10-6
Utiliser les commandes RMAN RESTORE et RECOVER 10-7
Echec d'instance 10-8
Comprendre la récupération d'instance 10-9
Phases de la récupération d'instance 10-10
Régler la récupération d'instance 10-11
Utiliser MTTR Advisor 10-12
Défaillance physique 10-13
Comparaison entre récupération complète et récupération incomplète 10-14
Processus de récupération complète 10-15
Récupération jusqu'à un point dans le temps 10-16
viii
Récupération avec l'option RESETLOGS 10-18
Quiz 10-19
Synthèse 10-23
Présentation des exercices : Déterminer des procédures de récupération 10-24
Etude de cas 1 10-25
11 Procéder à une récupération I

Objectifs 11-2
Vérifier que des sauvegardes sont disponibles 11-3
Effectuer une restauration en mode NOARCHIVELOG 11-4
Récupération à l'aide de sauvegardes incrémentielles
en mode NOARCHIVELOG 11-5
Effectuer une récupération complète 11-6
Restaurer des groupes de disques ASM 11-8
Restaurer des groupes de disques ASM : Exemples 11-9
Rappels sur la récupération de copies d'image 11-10
Récupérer des copies d'image : Exemple 11-11
Basculement rapide vers des copies d'image 11-12
Utiliser la commande SET NEWNAME pour basculer vers d'autres fichiers 11-13
Utiliser des points de restauration 11-14
Effectuer une récupération jusqu'à un point dans le temps 11-15
Quiz 11-17
Synthèse 11-18
Présentation des exercices : Récupération après une défaillance physique 11-19
12 Procéder à une récupération II

Objectifs 12-2
Récupération suite à la perte du fichier de paramètres serveur 12-3
Restaurer le fichier de paramètres serveur à partir de la sauvegarde automatique
du fichier de contrôle 12-4
Perte d'un fichier de contrôle 12-5
Récupération suite à la perte de toutes les copies du fichier de contrôle :
Présentation 12-6
Restaurer le fichier de contrôle à partir de la sauvegarde automatique 12-7
Restaurer le fichier SPFILE et le fichier de contrôle 12-8
Quiz 12-9
Récupérer des objets de base de données NOLOGGING 12-10
Perte d'un fichier de journalisation 12-11
Statut d'un groupe de fichiers de journalisation : Rappel 12-13
ix
Récupération suite à la perte d'un groupe de fichiers de journalisation 12-14
Vider un fichier journal 12-15
Recréer un fichier d'authentification par mot de passe 12-16
Récupération suite à la perte d'un tablespace d'index 12-18
Récupérer un tablespace en lecture seule 12-19
Récupération automatique d'un fichier Tempfile 12-20
Restaurer et récupérer la base de données sur un nouvel hôte 12-21
Préparer la restauration de la base de données sur un nouvel hôte 12-22
Restaurer la base de données sur un nouvel hôte 12-23
Effectuer une récupération après sinistre 12-27
Restaurer des sauvegardes cryptées 12-29
Quiz 12-30
Synthèse 12-31
Présentation des exercices : Procéder à des récupérations 12-32
Présentation des exercices : Utiliser le cryptage RMAN 12-33
13 RMAN et Oracle Secure Backup

Objectifs 13-2
Oracle Secure Backup : Présentation 13-3
Options d'interface avec Oracle Secure Backup 13-4
Gérer les données à protéger 13-5
Eléments de sauvegarde et images de sauvegarde 13-7
RMAN et Oracle Secure Backup : Présentation 13-8
RMAN et Oracle Secure Backup : Flux de processus élémentaire 13-9
Quiz 13-10
Commencer à utiliser Oracle Secure Backup 13-11
Exécuter les tâches d'installation 13-12
Vérifier votre installation 13-13
Sécuriser les données et l'accès au domaine de sauvegarde 13-14
Préautorisation 13-15
Définir la conservation des sauvegardes RMAN 13-16
Gestion des supports : Stratégies d'expiration en vue du recyclage automatique
des bandes 13-17
Sélecteur de stockage des sauvegardes de base de données 13-18
Définir les paramètres de gestion des supports dans RMAN 13-19
Récapitulatif de la configuration OSB pour RMAN 13-20
Sauvegarder la zone de récupération rapide sur bande 13-21
Travaux Oracle Secure Backup 13-22
Afficher les fichiers de journalisation et les transcriptions 13-23
Commandes obtool courantes 13-24
Quiz 13-25
x
Synthèse 13-29
Présentation des exercices : Effectuer des sauvegardes et des restaurations RMAN
basées sur un support de bande 13-30
14 Utiliser les technologies Flashback

Objectifs 14-2
Technologies Flashback : Détection et correction d'erreurs 14-3
Rappels : Transactions et informations d'annulation 14-4
Technologie Flashback 14-5
Préparer la base de données pour un flashback 14-7
Garantir la période de conservation des informations d'annulation 14-8
Quiz 14-9
Utiliser la technologie Flashback pour interroger les données 14-10
Flashback Query 14-11
Flashback Version Query 14-12
Flashback Table : Présentation 14-13
Flashback Table 14-14
Flashback Table : Points à prendre en compte 14-15
Flashback Transaction Query 14-16
Flashback Transaction Query : Points à prendre en compte 14-17
Flashback Transaction Backout 14-18
Exécuter un flashback de transaction 14-19
Recommandation : Flashback basé sur les informations d'annulation : Flashback
Query, Flashback Table 14-20
Flashback Drop et la corbeille 14-21
Corbeille 14-22
Ignorer la corbeille 14-23
Utiliser Flashback Data Archive 14-24
Créer un historique et activer l'archivage 14-25
Fonctionnement de Flashback Data Archive 14-26
Collecter le contexte utilisateur dans un historique 14-27
Evolution transparente de schéma 14-28
Evolution complète de schéma 14-29
Validité temporelle et historique 14-30
Utiliser la clause PERIOD FOR 14-31
Filtrage sur les colonnes avec une dimension Période de validité : Exemple 1 14-32
Filtrage sur les colonnes avec une dimension Période de validité : Exemple 2 14-33
Utiliser DBMS_FLASHBACK_ARCHIVE 14-34
Quiz 14-35
Synthèse 14-37
Présentation des exercices : Utiliser les technologies Flashback 14-38
xi
15 Flashback Database
Objectifs 15-2
Flashback Database : Protection permanente des données 15-3
Flashback Database 15-4
Architecture de Flashback Database 15-5
Configurer Flashback Database 15-6
Flashback Database : Exemples 15-7
Flashback Database : Eléments à prendre en compte 15-8
Surveiller les informations Flashback Database 15-9
Points de restauration garantis 15-11
Flashback Database et points de restauration garantis 15-12
Recommandations concernant Flashback Database 15-14
Quiz 15-16
Synthèse 15-18
Présentation des exercices : Flashback Database 15-19
16 Transport de données
Objectifs 16-2
Transport de données entre plates-formes 16-3
Transport de données avec temps d'arrêt minimal 16-4
Transporter un tablespace avec des copies d'image 16-5
Déterminer le format endian d'une plate-forme 16-6
Utiliser la commande RMAN CONVERT 16-7
Quiz 16-8
Transporter des données avec des jeux de sauvegarde 16-9
Etapes de la procédure : 1 16-10
Etapes de la procédure : 2 16-11
Transport de base de données : Utilisation de fichiers de données 16-12
Procédure de transport de base de données 16-13
Transport de base de données : Conversion 16-14
Transport d'une base de données : Exemple 1 16-15
Transport d'une base de données : Exemple 2 16-16
Transport de base de données : Considérations 16-17
Transport d'une base de données avec des jeux de sauvegarde : 1 16-18
Transport d'une base de données avec des jeux de sauvegarde : 2 16-19
Transporter des tablespaces incohérents 16-20
Quiz 16-21
Synthèse 16-23
Présentation de l'exercice 16-24
xii
17 Effectuer une récupération jusqu'à un point dans le temps
Objectifs 17-2
Récupération jusqu'à un point dans le temps 17-3
Quand utiliser une opération TSPITR ? 17-4
Terminologie liée à la récupération PITR 17-5
Récupération de tablespace jusqu'à un point dans le temps (TSPITR) : Architecture
17-6
Préparation d'une opération PITR 17-8
Déterminer le point cible approprié 17-9
Déterminer les tablespaces à inclure dans l'ensemble de récupération 17-10
Identifier les objets qui seront perdus 17-11
Récupération PITR de tablespace (TSPITR) avec RMAN 17-12
Opération TSPITR entièrement automatisée 17-13
Améliorer les performances d'une opération TSPITR 17-14
Effectuer une opération RMAN TSPITR avec une instance auxiliaire gérée par
RMAN 17-15
Effectuer une opération RMAN TSPITR à l'aide de votre propre
instance auxiliaire 17-16
Résoudre les problèmes liés à l'opération TSPITR 17-17
Quiz 17-18
Récupérer des tables à partir de sauvegardes 17-19
Récupération de tables : Résumé en images 17-20
Prérequis et restrictions 17-21
Indiquer le point de récupération 17-22
Etapes d'une récupération de table : 1/2 17-23
Etapes d'une récupération de table : 2/2 17-24
Quiz 17-25
Synthèse 17-26
Présentation de l'exercice 17-27
18 Dupliquer une base de données

Objectifs 18-2
Utiliser une base de données dupliquée 18-3
Choisir la technique de duplication 18-4
Dupliquer une base de données active par "poussée" 18-5
Méthodes de duplication "par poussée" et "par traction" 18-6
Dupliquer une base de données avec une connexion à la cible 18-7
Dupliquer une base de données à l'aide du catalogue de restauration sans
connexion à la cible 18-8
Dupliquer une base de données sans catalogue de restauration ni connexion
à la cible 18-9
xiii
Créer une base de données dupliquée à partir de sauvegardes 18-10
Créer un fichier de paramètres d'initialisation pour l'instance auxiliaire 18-11
Indiquer de nouveaux noms pour la destination 18-12
Utiliser les clauses SET NEWNAME 18-13
Variables de substitution pour SET NEWNAME 18-14
Définir des paramètres pour les noms de fichier 18-15
Démarrer l'instance en mode NOMOUNT 18-17
Vérifier la disponibilité des sauvegardes et des fichiers de journalisation archivés
18-18
Allouer des canaux auxiliaires 18-19
Comprendre l'opération de duplication RMAN 18-20
Indiquer des options pour la commande DUPLICATE 18-22
Utiliser d'autres options de la commande DUPLICATE 18-23
Variables de substitution pour SET NEWNAME 18-24
Quiz 18-25
Synthèse 18-26
Présentation des exercices : Dupliquer une base de données 18-27
19 Dépanner et régler RMAN

Objectifs 19-2
Interpréter les messages RMAN 19-3
Utiliser l'option DEBUG 19-4
Interpréter les piles d'erreurs RMAN 19-5
Traiter une commande RMAN 19-6
Résolution des problèmes avec RMAN 19-7
Détecter un problème 19-8
Identifier les goulets d'étranglement affectant les performances 19-9
Identifier les goulets d'étranglement affectant les performances :
Phase de lecture 19-10
Diagnostiquer un problème intervenant en phase d'écriture 19-11
Identifier les goulets d'étranglement affectant les performances : Phase d'écriture ou
de copie 19-12
Utiliser des vues dynamiques pour diagnostiquer les performances de RMAN 19-13
Surveiller la progression des travaux RMAN 19-14
Identifier les goulets d'étranglement en matière de sauvegarde
et de restauration 19-16
Goulets d'étranglement liés aux E/S asynchrones 19-17
Goulets d'étranglement au niveau des E/S synchrones 19-18
Régler les performances des sauvegardes RMAN 19-19
Exécution en parallèle de jeux de sauvegarde 19-20
Définir le paramètre LARGE_POOL_SIZE 19-22
xiv
Multiplexage RMAN 19-23
Performances de restauration et de récupération : Recommandations 19-25
Quiz 19-26
Synthèse 19-27
Aucun exercice 19-28
20 Présentation de l'atelier
Objectifs 20-2
Structure et démarche de l'atelier 20-3
Exigences associées à la base de données de l'atelier 20-5
Diagnostiquer les défaillances 20-6
Synthèse 20-7
A Recherches personnelles
Présentation A-2
Menus Enterprise Manager Database Express A-5
Traitement des requêtes dans EM Express A-6
Oracle SQL Developer : Connexions A-7
Oracle SQL Developer : Actions de DBA A-8
Autres ressources pour approfondir votre formation A-9
Informations complémentaires A-10
Cours ILT Oracle University recommandés A-11
B Utiliser Enterprise Manager Cloud Control

Objectifs B-2
Principaux challenges pour les administrateurs B-3
Enterprise Manager Cloud Control B-4
Composants de Cloud Control B-6
Composants et flux de communication B-7
Référentiel OMR B-8
Contrôler la structure Enterprise Manager Cloud Control B-9
Démarrer la structure Enterprise Manager Cloud Control B-10
Arrêter la structure Enterprise Manager Cloud Control B-11
Types de cible B-12
Repérage des cibles B-13
Enterprise Manager Cloud Control B-14
Interface utilisateure B-15
Sécurité : Présentation B-16
Gestion sécurisée avec les informations d'identification et de connexion B-17
Types d'informations d'identification et de connexion B-18
Quiz B-20
Présentation des exercices : Utiliser Enterprise Manager Cloud Control B-21
xv
C Cloud computing
Introduction C-2
Présentation du cloud computing C-3
Caractéristiques essentielles du cloud computing C-6
Modèles de services offerts en cloud computing C-7
Modèles de déploiement de cloud computing C-8
Avantages partagés du cloud computing C-9
Pourquoi implémenter un cloud ? C-11
Oracle et le cloud computing C-13
Clouds Enterprise Manager Cloud Control 12c C-14
Cycle de vie de la gestion de cloud C-16
Quiz C-18
xvi
Introduction
Copyright © 2015, Oracle et/ou ses affiliés. Tous droits réservés.

Objectifs
A la fin de ce chapitre, vous pourrez :

• décrire le contexte de cette formation et la configuration
du cours
• évaluer vos besoins en matière de récupération
• décrire les types de défaillance de base de données
• décrire les solutions de sauvegarde et de récupération
Oracle
• décrire les avantages apportés par l'utilisation d'Oracle
Secure Backup et d'Oracle Data Guard
• décrire l'architecture MAA (Maximum Availability
Architecture) d'Oracle
Oracle Database 12c: Backup and Recovery Workshop 1 - 2

Contexte du cursus de formation
Après ce cours, vous pourrez envisager d'approfondir vos connaissances
Avant ce cours : avec des cours spécialisés sur RAC, Data Guard, etc.
• Oracle Database 12c: Administration Workshop

• Oracle Database 12c: Install and Upgrade Workshop
Ce cours traite des sujets suivants :
• Assurer la disponibilité de la base de données par le biais de
stratégies de sauvegarde et de restauration appropriées
• Implémenter des paramètres de sauvegarde et de restauration et
effectuer des opérations de sauvegarde sur disque et sur bande
• Diagnostiquer et réparer les défaillances des données
• Effectuer des restaurations et des récupérations après des
défaillances matérielles ou autres
• Utiliser les technologies Flashback et la duplication des données
pour compléter les procédures de sauvegarde et de récupération
http://education.oracle.com
• Avant de suivre ce cours, vous devez vous assurer d'avoir les connaissances requises sur
Oracle Database 12c, SQL et PL/SQL (pour une utilisation en tant que DBA). Il est
également recommandé d'être familiarisé avec Oracle Enterprise Manager Cloud
Control 12c.
• Pendant ce cours, vous atteindrez les objectifs indiqués dans la diapositive.
• Après ce cours, vous saurez gérer la sauvegarde et la récupération des bases de données
Oracle en général et vous pourrez enrichir votre formation en suivant des cours qui traitent
de la sauvegarde et de la récupération dans certains environnements et pour certaines
options, par exemple :
- Oracle Database 12c: Managing Multitenant
- Oracle Database 12c: RAC Administration
- Oracle Database 12c: Data Guard Administration
- Oracle Database 12c: Security
Pour connaître les offres de formation les plus récentes, consultez le site
http://education.oracle.com.

Planning recommandé
Jour Chapitres Jour Chapitres
1 Module I : Introduction et configuration 3 11. Effectuer une récupération : Partie 1

1. Introduction 12. Effectuer une récupération : Partie 2
2. Mise en route Module IV : Technologies
3. Configuration en vue de la complémentaires
récupération 13. RMAN et Oracle Secure Backup
4. Utiliser le catalogue de restauration 14. Utiliser les technologies Flashback
RMAN
2 Module II : Sauvegarde 4 15. Flashback Database

5. Stratégies et terminologie 16. Transport de données
de sauvegarde 17. Effectuer une récupération jusqu'à
6. Réaliser des sauvegardes un point dans le temps
7. Améliorer les sauvegardes 18. Dupliquer une base de données
8. Crypter des sauvegardes à l'aide 19. Dépanner et régler RMAN
de RMAN
Module III : Récupération
9. Diagnostiquer les défaillances 5 Module V : Scénarios réalistes
10. Concepts de restauration 20. Atelier pratique
et de récupération
Ce planning est simplement un cadre général. L'organisation exacte du cours est fixée par le
formateur.

Innovations d'Oracle Database
Cloud de Bd Dprivé
Protection renforcée
… suite avec Gestion du cycle de vie des informations
Oracle Database 12c Disponibilité permanente
Flex Clusters
Performances et simplicité d'emploi
Oracle Grid Infrastructure
… avec Oracle Database 11g
Real Application Testing
Réglage SQL automatique
Gestion des erreurs
Audit Vault
… avec Oracle
Database Vault
Database 10g
Secure Enterprise Search
Grid Computing
Automatic Storage Mgmt
BdD auto-gérée
BdD XML, Oracle Data Guard, RAC, Requête Flashback, BdD privée virtuelle
Java VM intégrée, prise en charge du partitionnement, messagerie intégrée, prise en charge des objets relationnels,
support multimédia
L'innovation a toujours été au coeur des activités d'Oracle et a permis à l'entreprise de conserver
sa place de leader dans l'industrie, grâce à un large éventail de produits novateurs.
Quelques points marquants de la version Oracle Database 12c sont évoqués ci-après :
• Cloud de bases de données privé
• Protection renforcée d'accès aux données, qui inclut Oracle Data Redaction (protection des
données par occultation) et Real Application Security
• Gestion du cycle de vie des informations (ILM, Information Lifecycle Management)
comprenant une classification des données en données fortement accédées ("chaudes") ou
peu accédées ("froides"), la compression et le déplacement des données en fonction de leur
usage, l'archivage au sein de la base de données et le filtrage des données par période de
validité
• Flex Clusters
• Disponibilité permanente des données avec notamment la fonctionnalité de synchronisation
à diestance de Data Guard afin d'assurer une continuité applicative
• Migrations à moindre coût en temps
• Performances et simplicité d'emploi, avec des optimisation en temps réel, le regroupement
("clustering") d'attributs et (pour Exadata uniquement) une gestion des zones

Cloud computing d'entreprise
Enterprise Manager
Clusters Grilles Cloud Control et
Gestion des
RAC d'équipements consolidation de bases
pour la et de systèmes évolutions à
disponibilité travers de données à travers
de stockage
peu onéreux l'entreprise l'entreprise
Oracle Database 10g était le premier système de gestion de base de données conçu pour le grid
computing.
Oracle Database 11g a consolidé et étendu la capacité unique d'Oracle à fournir les avantages du
grid computing, en transformant les centres de données, véritables silos de ressources
cloisonnés, en pools partagés de serveurs et de ressources de stockage.
Oracle Database 12c et Enterprise Manager Cloud Control sont conçus pour le cloud computing.
Cette technologie crée une solution de cloud privé complète, pré-intégrée et prête à l'emploi qui
permet de transformer rapidement un centre de données d'entreprise en cloud privé.
Les principaux avantages sont les suivants :
• Réduction de la dispersion des serveurs et meilleure exploitation des ressources CPU via la
consolidation sur un nombre moindre de serveurs.
• Réduction du temps passé par les DBA à installer et configurer des bases de données via le
déploiement automatisé de configurations standard.
• Une seule console pour gérer tout le cycle de vie du cloud : planification, installation,
livraison et exploitation.
• Prévention de la monopolisation des ressources via la définition de quotas pour certains
utilisateurs.
• Anticipation des besoins futurs en ressources via l'analyse de rapports de tendances.
• Calcul de refacturation basé sur des mesures de performances et de configuration.

Evaluer vos besoins en matière de récupération
• Identifiez les données cruciales et leurs niveaux de priorité.
• Alignez les besoins en matière de récupération sur l'aspect
critique des données.
– Objectif de point de retour (RPO) : Tolérance de perte de
données
— Quelle doit être la fréquence des sauvegardes ?
— La récupération jusqu'à un point dans le temps doit-elle être
assurée ?
– Objectif de délai de récupération (RTO) : Tolérance de temps
d'arrêt
— Temps d'arrêt = identification du problème + planification de la
récupération + récupération des systèmes
— RTO par niveau de granularité (base de données, tablespace, table,
ligne)
– Déterminez la stratégie de conservation des sauvegardes sur
site, hors site et à long terme.
Pour évaluer correctement vos besoins en matière de récupération, vous devez commencer par
déterminer dans quelle mesure la perte ou l'indisponibilité d'une base de données est grave pour
votre entreprise. Tenez compte des points suivants :
• Combien l'entreprise va-t-elle perdre par heure d'arrêt ?
• Quels seront les pertes en productivité et en coûts de main d'oeuvre si la base de données
est à l'arrêt ?
En quantifiant ces coûts, vous serez en mesure de justifier des dépenses en équipements et en
stockage en vue d'éviter les défaillances de la base et de les récupérer si nécessaire.
L'étape suivante consiste à classer vos bases de données en fonction de leur importance critique.
Prenons l'exemple d'une société gérant un vaste système de reporting en data warehouse qui
peut tolérer 12 heures de données perdues car les chargements en mode batch peuvent être
réexécutés au prix d'un nombre d'heures d'arrêt acceptable pour la communauté des utilisateurs.
Pour ce type de système, une stratégie de sauvegarde sur disque et bande peut être appropriée.

En revanche, une société qui repose sur un système OLTP crucial ne peut pas tolérer plus de
quelques minutes de données perdues et de temps d'arrêt de la base car chaque heure d'arrêt
représente un manque à gagner qui se chiffre en centaines de milliers de dollars. Pour un tel
système, une solution traditionnelle de sauvegarde et de récupération ne sera pas suffisante. Cette
société doit envisager une solution à temps d'arrêt minimal telle qu'Oracle Data Guard.
Déterminez votre objectif de point de retour (Recovery Point Objective, RPO) pour pouvoir quantifier
la perte de données acceptable. Tenez compte des points suivants :
• Certaines bases de données nécessitent-elles des sauvegardes plus fréquentes ?
• Disposez-vous d'espace disque suffisant pour les fichiers de journalisation archivés (en vue
d'une récupération jusqu'à un point dans le temps, par exemple) ?
Déterminez votre objectif de délai de récupération (Recovery Time Objective, RTO), c'est-à-dire le
temps de récupération que vous pouvez tolérer. Se chiffre-t-il en heures ou en minutes ? Gardez à
l'esprit que le RTO peut varier en fonction de la base de données et/ou du serveur. Vous pouvez
avoir besoin d'une stratégie de sauvegarde combinée sur disque et sur bande pour les bases de
données critiques afin de répondre à des RTO plus contraignants. Une fois que vous avez
déterminé les capacités de récupération requises à partir de disques et de bandes, évaluez la
période de conservation des sauvegardes.

Evaluer vos besoins en matière de récupération
• Evaluez les protections à mettre en oeuvre.

– Physiques : catastrophes, coupures de courant, pannes,
corruptions
– Logiques : erreurs humaines ou applicatives
En plus de vos besoins de récupération, vous devez déterminer les types de panne nécessitant
des mesures de protection. Réfléchissez aux pertes physiques de données et aux erreurs
logiques qui peuvent se produire dans l'application et la base de données.

Catégories de pannes
Les pannes peuvent généralement être réparties en plusieurs

catégories :
• Echec d'une instruction
• Echec d'un processus utilisateur
• Défaillance du réseau
• Erreur de l'utilisateur
• Echec d'instance
• Défaillance physique
• Echec d'une instruction : Une seule opération de base de données (sélection, insertion,
mise à jour ou suppression) échoue.
• Echec d'un processus utilisateur : Une seule session de base de données échoue.
• Défaillance du réseau : La connectivité avec la base de données est perdue.
• Erreur de l'utilisateur : Un utilisateur réussit à effectuer une opération, mais celle-ci
(suppression de table, saisie de mauvaises données) est incorrecte.
• Echec d'instance : L'instance de base de données s'arrête inopinément.
• Défaillance physique : Un ou plusieurs fichiers nécessaires au fonctionnement de la base
de données sont perdus (ils ont été supprimés ou le disque est défectueux).

Défaillances de données
• Composants inaccessibles : Fichiers de données

manquants au niveau du système d'exploitation,
permissions d'accès incorrectes, tablespace
hors ligne
• Altérations physiques : Erreurs de checksum de bloc,
valeurs de champ d'en-tête de bloc non valides
• Altérations logiques : Dictionnaire non cohérent, altération
d'un morceau de ligne, d'une entrée d'index ou d'une
transaction
• Problèmes d'incohérence : Fichier de contrôle plus ancien
ou plus récent que les fichiers de données et les fichiers
de journalisation en ligne
• Problèmes d'E/S : Plafond de fichiers ouverts atteint,
canaux inaccessibles, erreur réseau ou erreur d'E/S
La diapositive décrit d'autres types de défaillance qu'il convient d'anticiper. Des méthodes sont
présentées tout au long de ce cours à cet effet.

Solutions de protection de données Oracle
Objectif de sauvegarde Objectif de temps de Solution Oracle
et de récupération récupération
Protection des données Heures/Jours Recovery Manager
physiques Oracle Secure Backup
Protection des données Minutes/Heures Technologies

logiques Flashback
Analyse de la récupération Réduire les délais Data Recovery Advisor

d'identification des
problèmes et de planification
de la récupération
Objectif d'une Objectif de temps de Solution Oracle

récupération après récupération
sinistre
Protection des données Secondes/Minutes Data Guard
physiques Active Data Guard
Oracle offre une solution de protection des données appropriée, adaptée aux objectifs définis en
matière de sauvegarde, de récupération et de temps de récupération :
• Oracle Recovery Manager (RMAN) est le composant central d'Oracle Database qui gère les
processus de sauvegarde, de restauration et de récupération.
• Oracle Secure Backup (OSB) est la solution Oracle de sauvegarde sur bande au niveau
entreprise pour les bases de données comme les systèmes de fichiers.
• Les technologies Flashback d'Oracle Database constituent un ensemble de solutions de
récupération de données qui permettent de récupérer des erreurs humaines en annulant
leurs effets de manière sélective et efficace.
• La fonction de conseil Data Recovery Advisor fournit des méthodes d'identification et de
résolution de problèmes de base de données.
• Data Guard et Active Data Guard permettent aux bases de secours physiques d'être
ouvertes pour l'accès en lecture tout en restant synchronisées avec la base de données de
production via une restauration physique.
Vous trouverez des informations plus détaillées sur ces fonctionnalités et technologies dans la
suite de ce cours.

Aide sous forme de vues d'ensemble et de conseils
Oracle Enterprise Manager Cloud Control 12c (Cloud Control)

• Fonction de conseil MAA Advisor
– Méthodes recommandées pour éliminer ou réduire le temps
d'arrêt
– Fournit l'état de votre configuration
• Console haute disponibilité (HA) :
– Tableau de bord personnalisable
– Aperçu des événements, des consommations et de
l'historique
– Organisée en sections : disponibilité,
sauvegarde/récupération et Data Guard
Oracle Enterprise Manager Cloud Control 12c (Cloud Control) fournit la fonction de conseil MAA
(Maximum Availability Architecture) Advisor. MAA fournit une architecture haute disponibilité (HA,
High Availability) complètement intégrée et validée, avec des recommandations opérationnelles
et de configuration pour éliminer ou réduire le temps d'arrêt.
Dans la page d'accueil de la base de données, accédez à Availability > MAA Advisor.
Conseil : Choisissez All Solutions pour afficher le statut de votre configuration, même si MAA
n'est pas votre but.
La console haute disponibilité de Cloud Control est un tableau de bord personnalisable qui
permet d'obtenir des informations générales et de synthèse. Dans la page d'accueil de la base de
données, sélectionnez Availability > High Availability Console.

Solution de sauvegarde complète d'Oracle
Données des
systèmes de Oracle Secure Backup
fichiers (OSB) Sauvegarde sur
bande
UNIX Linux
Windows NAS
Oracle Recovery Manager

Bases de (RMAN) Zone de
données Oracle récupération rapide
Module OSB pour le cloud Stockage

en cloud
Amazon S3
• Sauvegarde et récupération Oracle pour l'ensemble de

l'environnement informatique
• Plusieurs options de support : disque local, stockage en cloud
distant, bande physique et virtuelle
Oracle Secure Backup permet la gestion centralisée des sauvegardes sur bande pour les
systèmes distribués et hétérogènes de tout un environnement informatique grâce aux
fonctionnalités suivantes :
• Intégration d'Oracle Database avec Recovery Manager (RMAN) prenant en charge les
versions Oracle9i à Oracle Database 12c.
• Protection des données des systèmes de fichiers pour les serveurs UNIX, Windows et
Linux, ainsi que pour les systèmes NAS (Network Attached Storage) via le protocole NDMP
(Network Data Management Protocol).
L'un des composants fondamentaux de la stratégie Oracle de sauvegarde sur disque est la zone
de récupération rapide (FRA - fast recovery area). Il s'agit d'un emplacement de stockage dans un
système de fichiers ou un groupe de disques ASM (Automatic Storage Management) qui organise
tous les fichiers et les activités concernant la récupération pour une base de données Oracle.
Tous les fichiers qui sont nécessaires pour récupérer complètement une base de données après
une défaillance physique peuvent résider dans la zone de récupération rapide : fichiers de
contrôle, journaux archivés, copies de fichiers de données et sauvegardes RMAN.
Pour honorer les contrats de niveau de service (SLA) demandés, envisagez d'utiliser le module
OSB (Oracle Secure Backup) pour le cloud. Avec RMAN et et le module OSB pour le cloud, vous
pouvez envoyer des sauvegardes sur disque local directement à Amazon S3 pour un stockage
hors site.

Oracle Recovery Manager (RMAN) intégré
• Connaissance intrinsèque
Oracle Enterprise des formats de fichier de
Manager base de données et des
procédures de récupération
Oracle Secure – Validation de bloc
Backup – Récupération au niveau bloc en
ligne
RMAN – Récupération de tablespaces et
de fichiers de données
– Sauvegarde multiflux en ligne
– Compression des blocs
Unité de bande inutilisés
– Cryptage natif
• Sauvegarde sur disque, sur
Zone de récupération
rapide
bande ou en cloud intégrée
Base de données
Cloud tirant parti de la zone de
récupération rapide et
d'Oracle Secure Backup
Oracle Recovery Manager (RMAN) est le composant central d'Oracle Database qui gère les
processus de sauvegarde, de restauration et de récupération. RMAN prend en charge des
stratégies configurables de sauvegarde et de récupération et conserve des enregistrements
historiques de toutes les activités de sauvegarde et de récupération de la base de données.
RMAN garantit que tous les fichiers nécessaires à la restauration et à la récupération d'une base
de données sont inclus dans des sauvegardes complètes de cette base. Par ailleurs, dans le
cadre des opérations RMAN de sauvegarde, tous les blocs de données sont vérifiés pour éviter la
propagation de blocs corrompus dans les fichiers de sauvegarde.
Le diagramme de la diapositive présente une configuration possible pour les sauvegardes.
Il suggère que RMAN utilise la zone de récupération rapide à cet effet. Si vous le souhaitez, vous
pouvez passer par Oracle Secure Backup pour effectuer les sauvegardes sur l'unité de bande et
dans le cloud. Les sauvegardes peuvent être effectuées vers d'autres destinations, par exemple
directement sur disque. Ces différentes options sont décrites dans les sections qui suivent.

Oracle Secure Backup
Oracle Enterprise
Manager
• Gestion de la sauvegarde
sur bande à l'échelle de
l'entreprise :
Oracle Secure Backup – Systèmes de fichiers
Données des systèmes Base de données hétérogènes
de fichiers Oracle (UNIX/Linux/Windows) et
périphériques NAS
– Intégration Oracle incluse
Intégration RMAN
– Gestion centralisée dans
des environnements
distribués
Bibliothèque Bibliothèque
de bandes de bandes
virtuelles
(VTL)
Oracle Secure Backup (OSB) est un logiciel de gestion centralisée des sauvegardes sur bande
qui protège la base de données et les systèmes de fichiers Oracle dans les environnements
UNIX, Linux, Windows et NAS (Network Attached Storage) distribués. OSB assure la sauvegarde
sur bande des fichiers d'application comme de la base de données.
OSB est intégré à RMAN et fournit la couche de gestion des supports pour les sauvegardes
RMAN sur bande.
OSB permet d'automatiser la gestion des sauvegardes sur bande par le biais de stratégies
définies par l'utilisateur tout au long du cycle de vie de la bande de sauvegarde.
A partir d'une console centrale, vous pouvez facilement gérer les serveurs et les unités de bande
distribués au sein du domaine de sauvegarde.
Le cours Oracle Secure Backup fournit des informations détaillées sur l'installation et l'utilisation
d'OSB.
Remarque : Reportez-vous au document Oracle Secure Backup Licensing Information pour plus
de détails sur les fonctionnalités disponibles avec Oracle Secure Backup et Oracle Secure
Backup Express.

Module Oracle Secure Backup pour le cloud
RMAN Module OSB pour le cloud

Amazon S3
Compression/
cryptage
Fichiers de base Sauvegarde sur disque local/
de données zone de récupération rapide
Sauvegarde de bases de données vers le cloud Amazon :
• Fournit des sauvegardes hors site fiables
• Complète la sauvegarde sur disque local et/ou sur bande
• Peut éliminer la charge de gestion informatique d'un site
de récupération après sinistre
Le module OSB pour le cloud est indépendant de la solution OSB sur bande, bien qu'il
appartienne à la même famille de produits et soit entièrement intégré à la fonctionnalité RMAN.
Avec RMAN et le module OSB pour le cloud, vous pouvez envoyer des sauvegardes sur disque
local directement vers Amazon S3 pour un stockage hors site. Le module OSB pour le cloud peut
également être utilisé pour transmettre les sauvegardes en continu vers le cloud. Cette méthode
est particulièrement utile lorsque la base de données s'exécute dans le cloud, à l'aide de services
comme Amazon Elastic Compute Cloud (EC2).
Basé sur des disques, le stockage S3 est plus fiable qu'un stockage sur bande. Si votre stratégie
de sauvegarde est censée compléter les sauvegardes sur disque ou bande locales par des
sauvegardes hors site fiables et que vous voulez éviter les coûts de gestion informatique associés
à la maintenance d'un site distinct de récupération après sinistre, vous pouvez consulter les
contrats de niveau de service relatifs au temps de disponibilité des systèmes Amazon S3 pour
déterminer si cette technologie répond à vos besoins.
Le module OSB pour le cloud est compatible avec toutes les versions d'Oracle Database prises
en charge. Pour effectuer des sauvegardes vers le cloud, vous utilisez des outils familiers comme
Enterprise Manager et RMAN.

Oracle Data Guard : Présentation
Base Transport des infos Base

principale de journalisation de secours
Oracle Net
Base de données Copie de la base

de données
Oracle Data Guard est un composant central dans une solution Oracle Database haute
disponibilité (HA). Il permet aux organisations de maintenir une activité continue en réduisant au
minimum les différents types de temps d'arrêt planifiés et non planifiés.
Oracle Data Guard est une infrastructure logicielle de gestion, de surveillance et d'automatisation
qui fonctionne avec une base de données de production et une ou plusieurs bases de secours
pour protéger les données contre les pannes, les erreurs et les corruptions susceptibles
d'entraîner des pertes. La protection des données est assurée par des fonctionnalités qui
automatisent la création, la gestion et la surveillance des bases de données et des autres
composants de la configuration. La tenue à jour d'une copie de la base Oracle de production (ou
base de secours) est automatisée. Cette base de secours peut être utilisée si la base de
production doit être mise hors ligne pour des opérations de maintenance régulière ou si elle est
endommagée.
Dans une configuration Data Guard, la base de données de production est appelée base
principale. Une base de secours est une copie de la base principale. A partir d'une copie de
sauvegarde de la base principale, vous pouvez créer jusqu'à 30 bases de secours. Les bases de
secours et la base principale constituent une configuration Data Guard.
Toutes les bases de secours Data Guard permettent l'accès en lecture aux données qu'elles
contiennent pendant l'application des informations de journalisation reçues de la base principale.
Elles sont donc particulièrement intéressantes pour délester la base principale de la charge de
gestion des interrogations et des rapports en lecture seule.

Base de secours physique :
Architecture Redo Apply
Base de Base de secours
production physique
Transport Redo
des infos de Apply
journalisation
Flux des
infos de
journalisation
Sauvegarde
Base Base de secours

principale physique
Le mode Redo Apply de Data Guard s'applique aux bases de secours physiques. L'architecture
correspondante comprend les éléments suivants :
• Une base de données (principale) de production, liée à une ou plusieurs bases de secours
(30 au maximum) qui lui sont identiques. La limite de 30 bases de secours est imposée par
le paramètre LOG_ARCHIVE_DEST_n. En effet, ce dernier admet au maximum 31
destinations. L'une d'elle est utilisée en tant que destination d'archivage locale, ce qui laisse
30 destinations possibles pour des bases de secours.
Remarque : Vous pouvez utiliser la fonctionnalité de mise en cascade des destinations de
fichiers de journalisation pour incorporer plus de 30 bases de secours dans votre
configuration.
• La base de secours, qui est mise à jour par les informations de journalisation transférées
automatiquement à partir de la base principale. Les informations de journalisation peuvent
être transférées lorsqu'elles sont générées ou archivées dans la base principale. Elles sont
appliquées à chaque base de secours à l'aide des techniques de restauration physique
d'Oracle. Pendant une période d'arrêt planifiée, vous pouvez permuter la base principale et
une base de secours (switchover). Lorsqu'une panne se produit, vous pouvez effectuer un
basculement vers une des bases de secours (failover). La base de secours physique peut
également être utilisée pour sauvegarder la base principale.

Oracle Active Data Guard
Transport des infos

de journalisation
Sync / Async Base de secours
Base Active Data Guard
principale
• Disponibilité et protection des données pour Oracle Database

• Réparation automatique des blocs sans temps d'arrêt de
l'application
• Base de secours utilisée pour les interrogations, les rapports,
les tests ou les sauvegardes Active Data Guard permet d'interroger
des données temps réel.
• Interrogations à jour et obsolètes
• Active Data Guard permet aux bases de secours physiques d'être ouvertes en lecture
pendant qu'elles subissent une restauration physique pour rester synchronisées avec la
base de production. La base de secours physique est accessible en lecture seule tandis que
le transport des informations de journalisation et leur application à la base de secours
continuent d'être actifs.
• Active Data Guard répare automatiquement et en ligne les blocs corrompus en utilisant la
base de secours active.
• Normalement, les interrogations exécutées sur les bases de secours actives renvoient des
résultats à jour. En raison de délais potentiels dans le transport des informations de
journalisation ou dans leur application aux bases de secours, il se peut qu'une base de
secours "prenne du retard" sur la base principale. Elle risque alors de renvoyer des résultats
obsolètes.
• Il est possible de configurer les sessions Active Data Guard avec un délai maximum
d'interrogation (en secondes). Si la base de secours dépasse ce délai, Active Data Guard
renvoie une erreur à l'application, laquelle peut alors réitérer l'interrogation ou la rediriger de
manière transparente vers la base principale.

Base de secours logique :
Architecture SQL Apply
Base de Base de secours
production logique
Transport des infos SQL
de journalisation Apply
Conversion des
infos de
journalisation en
instructions SQL
Rapports
Base Base de secours

principale logique
Dans une configuration qui comprend une base de secours logique, la fonctionnalité SQL Apply
de Data Guard utilise les informations de journalisation transportées depuis le système principal.
Toutefois, contrairement au mode Redo Apply utilisé pour les bases de secours physiques, le
mode SQL Apply transforme les données de journalisation en instructions SQL équivalentes, à
l'aide de la technologie LogMiner. Ce sont ces instructions SQL qui sont ensuite appliquées à la
base de secours logique. La base de secours logique est ouverte en mode de lecture/écriture et
elle est disponible pour les fonctions liées aux rapports.
La base de secours logique peut offrir une certaine protection à différents niveaux : base de
données, schéma ou même objet.
Une base de secours logique peut être utilisée pour effectuer des mises à niveau non
simultanées de la base. Cela permet de réduire le temps d'arrêt lors du passage à de nouveaux
jeux de patches ou à une version supérieure complète de la base.

Architecture MAA d'Oracle :
Robustesse et intégration de la protection des données
Active Data Guard
Réplique entièrement
Site de production active en cas Site de secours
de basculement
Base de données
Base de données
Data Recovery
Advisor Stockage
Analyse de
récupération guidée Stockage
et intelligente
Recovery Manager (RMAN) et
Technologies Flashback
Oracle Secure Backup (OSB)
Correction des erreurs
Sauvegarde et récupération à faible
par remontée dans le temps
coût et hautes performances
L'architecture MAA (Maximum Availability Architecture) d'Oracle est le modèle de base des
meilleures pratiques Oracle et s'appuie sur des technologies et des recommandations qui ont fait
leurs preuves en matière de haute disponibilité. Le but de cette architecture est d'obtenir le taux
de disponibilité le plus élevé possible, à moindre coût et sans surcroît de complexité.
MAA intègre les fonctionnalités d'Oracle Database liées à la haute disponibilité, notamment Real
Application Clusters (RAC), Data Guard, GoldenGate, ASM, RMAN et Enterprise Manager.
L'architecture MAA recommande certaines méthodes en ce qui concerne les composants
d'infrastructure essentiels comme les serveurs, le stockage et le réseau. Au-delà de la
technologie, le modèle de base MMA couvre des recommandations spécifiques de conception et
de configuration qui ont été testées pour assurer une disponibilité et une fiabilité optimales des
systèmes. Les entreprises qui exploitent MAA dans leur infrastructure informatique constatent
qu'elles arrivent à déployer rapidement et efficacement des applications qui répondent à leurs
besoins en matière de disponibilité.
RMAN peut également être utilisé avec des produits de sauvegarde sur bande qui ne sont pas
fournis par Oracle. Toutefois, ces produits n'offrent pas forcément des capacités d'optimisation
des performances de sauvegarde équivalentes à celles d'Oracle Secure Backup.
Pour obtenir des informations détaillées sur MAA, consultez le site Web OTN
(Oracle Technology Network) :
(http://www.oracle.com/technetwork/database/features/availability/index.html).

Architecture de base de l'atelier
orcl
rcat
Exemple de
schéma
Système de
fichiers
emrep Enterprise
Manager
Cloud Control
Oracle Secure
Backup :
Bibliothèque de Oracle
bandes virtuelle Net
Pour les exercices pratiques, les instances illustrées sur la diapositive sont préinstallées sur un
système d'exploitation Linux : orcl, rcat et emrep sont des instances d'Oracle Database 12c.
Vous allez ajouter des éléments à cette configuration tout au long de ce cours.

Quiz
Pour planifier la protection de vos données, vous devez en

premier lieu déterminer le niveau d'importance de chaque base
de données. A cet effet, quelles valeurs quantitatives évaluez-
vous ?
a. Perte de recettes engendrée par les temps d'arrêt
b. Coûts de maintenance du matériel
c. Perte de productivité consécutive aux temps d'arrêt
d. Coûts de maintenance du logiciel
Réponses : a, c

Synthèse
Ce chapitre vous a permis d'apprendre à :

• décrire le contexte de cette formation et la configuration du
cours
• évaluer vos besoins en matière de récupération
• décrire les types de défaillance de base de données
• décrire les solutions de sauvegarde et de récupération
Oracle
• décrire les avantages apportés par l'utilisation d'Oracle
Secure Backup et d'Oracle Data Guard
• décrire l'architecture MAA (Maximum Availability
Architecture) d'Oracle

Présentation des exercices :
Explorer l'environnement du cours
Dans cet exercice, vous allez :
• vérifier que les trois instances de base de données sont
démarrées
• vérifier que le processus d'écoute (listener) est démarré
• vérifier le paramètre LOG_MODE de la base de données
ORCL
Vous pouvez éventuellement consulter la démonstration
Oracle Database 12c: Using SYSBACKUP Privilege and
Predefined User.
Cet exercice vous permet d'explorer l'environnement du cours.

Mise en route

Objectifs

• décrire l'architecture de base de données dans une
perspective de sauvegarde et de récupération
• décrire votre base de données ORCL en mode
NOARCHIVELOG
• identifier les outils Oracle servant à la sauvegarde et à la
récupération
• effectuer une sauvegarde et une récupération
élémentaires (en mode NOARCHIVELOG)
Ce chapitre rappelle les concepts essentiels de la base de données Oracle qui présentent une
importance critique pour la sauvegarde et la récupération. Il présente ensuite les outils
disponibles (utilisés tout au long du cours). L'exposé théorique est suivi d'un exercice pratique
(susceptible de soulever des questions à résoudre dans le chapitre suivant). Vous devez
comprendre comment effectuer la sauvegarde et la récupération en mode NOARCHIVELOG (avec
les limites potentielles de cette approche).
Oracle Database 12c : Backup and Recovery Workshop 2 - 2

Noms des composants élémentaires
d'un serveur Oracle Database
Instance
PGA
Proc essus
Structures mémoire
serveur Mémoire SGA
Connexion
...
Serveur
Processus ut
ilisateur
ou client
Utilisateur
Base de données (structures de stockage)
Session Client
Pour commencer, essayez de répondre aux questions suivantes :

1. Les deux composants principaux d'un système Oracle Database élémentaire sont
_________________________ et _______________________
2. Une instance se compose de processus _____________________ et
_____________________.
3. Les trois structures principales de l'architecture d'un serveur Oracle Database sont
_______________, _______________ et ____________.
4. Une session est une connexion d'un utilisateur à un _______________ via un
______________.
5. Un élément particulièrement intéressant pour les tâches de sauvegarde et de récupération
est la mémoire tampon ___________ réutilisable (qui sert pour la récupération d'instance).
La récupération d'instance est le processus qui consiste à appliquer les enregistrements du
fichier de journalisation en ligne aux fichiers de données pour reconstituer les modifications
effectuées après le plus récent point de reprise.

Architecture d'un serveur de base de données
Oracle : Présentation
Instance
PGA
Processus Structures mémoire
Instance
serveur Mémoire SGA
Base de
Connexion
données
...
Informations de journalisation
Serveur
Structure des processus
Processus
utilisateur
ou client
Utilisateur
Base de données (structures de stockage)
Session Client
Les trois structures principales de l'architecture d'un serveur Oracle Database sont les structures
mémoire, les processus et les structures de stockage. Un système de base de données
élémentaire se compose d'une base de données Oracle et d'une instance de base de données.
La base de données est constituée de structures physiques et de structures logiques. Comme
les structures physiques et logiques sont séparées, le stockage physique des données peut être
géré sans affecter l'accès aux structures de stockage logiques.
Une instance se compose de structures mémoire et de processus en arrière-plan.
• A chaque démarrage d'une instance, une zone de mémoire partagée appelée mémoire
SGA (System Global Area) est allouée et les processus en arrière-plan sont lancés. L'un
des éléments particulièrement intéressants pour la sauvegarde et la récupération est le
tampon de journalisation. Il met en mémoire cache les informations de journalisation
(utilisées pour la récupération d'instance) jusqu'à ce qu'elles puissent être écrites dans les
fichiers de journalisation (fichiers redo log) physiques stockés sur le disque.

• Les processus sont des travaux qui s'exécutent dans la mémoire des ordinateurs.
Un processus peut être défini comme un "thread de contrôle" ou comme un mécanisme du
système d'exploitation capable d'exécuter un ensemble d'étapes. Lorsqu'une instance est
démarrée, le logiciel Oracle l'associe à une base de données précise. Cette opération est
appelée montage de la base de données. La base est alors prête à être ouverte, ce qui la
rend accessible aux utilisateurs autorisés.
Quand un utilisateur lance une transaction, par exemple une opération DML, les anciennes
données sont écrites depuis le cache de tampons vers le tablespace d'annulation et les détails
des modifications sont placés dans les fichiers de journalisation.
Remarque : Oracle Automatic Storage Management (ASM) utilise le concept d'instance pour les
composants de mémoire et de traitement, mais sans l'associer à une base de données spécifique.
Les concepts de connexion et de session sont étroitement liés aux processus utilisateur, mais ils
correspondent à des notions très différentes.
Une connexion est une voie de communication entre un processus utilisateur et une instance
Oracle Database. Elle est établie à l'aide des mécanismes de communication interprocessus
disponibles (sur un ordinateur qui exécute à la fois le processus utilisateur et Oracle Database) ou
via un logiciel réseau (lorsque différents ordinateurs exécutent l'application de base de données et
Oracle Database en communiquant via un réseau).
Une session représente l'état d'une connexion utilisateur en cours à l'instance de base de
données. Par exemple, quand un utilisateur démarre SQL*Plus, il doit fournir un nom utilisateur et
un mot de passe valides. Une session est alors établie spécialement pour lui. La durée d'une
session va du moment où l'utilisateur se connecte jusqu'au moment où il se déconnecte ou quitte
l'application de base de données.
Plusieurs sessions peuvent être créées et exister simultanément pour un même utilisateur de la
base de données Oracle sous le même nom utilisateur. Ainsi, un utilisateur peut se connecter
plusieurs fois à la même instance Oracle Database avec le nom utilisateur HR et le mot de passe
oracle_4U.

Rappels sur l'architecture de stockage
de la base de données
Fichiers de Fichiers de
contrôle Fichiers de journalisation
données en ligne
Fichier de
Fichiers de
paramètres
Fichiers de journalisation
sauvegarde archivés
Fichier de Fichiers trace et

mots de passe fichier d'alertes
Les fichiers constituant une base de données Oracle sont organisés de la façon suivante :
• Fichiers de contrôle : Ils contiennent des données relatives à la base elle-même (c'est-à-
dire des informations propres à la structure de base de données physique). Ces fichiers sont
d'une importance capitale pour la base. Sans eux, vous ne pouvez pas ouvrir les fichiers de
données de la base. Le fichier de contrôle peut également contenir des métadonnées
relatives aux sauvegardes.
• Fichiers de données : Ils contiennent les données d'utilisateur ou d'application de la base
de données ainsi que des métadonnées et le dictionnaire de données.
• Fichiers de journalisation en ligne : Ils permettent la récupération d'instance de la base
de données. Si le serveur de base de données tombe en panne et ne perd aucun fichier de
données, l'instance peut utiliser ces fichiers pour récupérer la base de données.
Les autres fichiers indiqués ci-dessous sont essentiels au bon fonctionnement de la base de
données :
• Fichier de paramètres : Il sert à définir comment l'instance est configurée lorsqu'elle
démarre.
• Fichier de mots de passe : Il permet aux utilisateurs sysdba, sysoper, sysbackup et
sysasm de se connecter à distance à la base de données et d'effectuer des tâches
d'administration.

• Fichiers de sauvegarde : Ils sont utilisés pour récupérer la base de données. En général,
vous restaurez un fichier de sauvegarde lorsque le fichier d'origine a été endommagé ou
supprimé à la suite d'une panne matérielle ou d'une erreur de l'utilisateur.
Fichiers de journalisation archivés : Ils contiennent l'historique des modifications de données
(informations de journalisation) à mesure qu'elles sont générées par l'instance. A l'aide de ces
fichiers et d'une sauvegarde de la base de données, vous pouvez récupérer un fichier de données
perdu. Autrement dit, les fichiers de journalisation archivés permettent de récupérer un état plus
récent des fichiers de données restaurés.
Pour les tâches de surveillance et de diagnostic, vous utilisez les fichiers suivants :
• Fichiers trace : Chaque processus serveur ou d'arrière-plan peut écrire dans un fichier
trace spécifique. Lorsqu'un processus détecte une erreur interne, il effectue un dump des
informations sur l'erreur dans son fichier trace. Certaines informations écrites dans un fichier
trace sont destinées à l'administrateur de base de données, et d'autres au Support
technique Oracle.
• Fichier d'alertes : Il contient des entrées de trace spéciales. Le fichier d'alertes d'une base
de données est un journal chronologique des messages et des erreurs. Oracle recommande
de le consulter périodiquement.

Noms des structures logiques et physiques
d'une base de données
Logique Physique
Base de
données
4 Fichier de
Tablespace
données
3 Segment Système de stockage ASM :
Système de fichiers : • Partition locale

• LUN (unités logiques de
2 Extent • Local
stockage)
• LUN
• Disques de grille Exadata
• NFS
• Fichiers NFS avec zéros de
1 remplissage
Une base de données comprend des structures logiques et des structures physiques.
1. Au niveau de détail le plus élevé, les données d'une base Oracle sont stockées dans des
_______________.
2. Un __________ est un nombre précis de blocs de données Oracle qui sont contigus
logiquement, même s'ils peuvent être physiquement distants sur le disque (à cause des
implémentations de technologie RAID et de système de fichiers).
3. Le niveau logique de stockage immédiatement supérieur à un ________ est appelé un
__________.
4. Une base de données est divisée en unités de stockage logiques appelées ____________
qui regroupent des structures logiques ou des fichiers de données connexes. (Une stratégie
de sauvegarde et de récupération est censée contenir des dispositions spéciales
concernant cette unité de stockage logique.)

Noms des structures logiques et physiques
d'une base de données
Logique Physique
Base de données
Fichier de
Tablespace
données
Segment Système de stockage ASM :
Système de fichiers : • Partition locale
• Local • LUN (unités logiques de

Extent stockage)
• LUN
• Disques de grille Exadata
• NFS
Bloc de données • Fichiers NFS avec zéros de
remplissage
Oracle
Une base de données comprend des structures logiques et des structures physiques.
1. Au niveau de détail le plus élevé, les données d'une base Oracle sont stockées dans des
blocs de données.
2. Un extent est un nombre précis de blocs de données Oracle qui sont contigus logiquement,
même s'ils peuvent être physiquement distants sur le disque (à cause des implémentations
de technologie RAID et de système de fichiers).
3. Le niveau logique de stockage immédiatement supérieur à un extent est appelé
un segment.
4. Une base de données est divisée en unités de stockage logiques appelées tablespaces qui
regroupent des structures logiques ou des fichiers de données connexes. (Une stratégie de
sauvegarde et de récupération est censée contenir des dispositions spéciales concernant
cette unité de stockage logique.)

Rappels sur l'architecture des processus
• Processus utilisateur
– Application ou outil qui se connecte à l'instance Oracle
Database
• Processus de base de données
– Processus serveur : Il se connecte à l'instance Oracle et
démarre lorsqu'un utilisateur établit une session
– Processus en arrière-plan :
— Lancés au démarrage d'une instance Oracle
— Exécutent des E/S pour écrire des données depuis et vers le disque
— Effectuent une récupération au démarrage de l'instance
(si nécessaire)
— Effectuent d'autres tâches
• Processus de démon et d'application
– Processus d'écoute réseau
– Démons d'Oracle Grid Infrastructure
Les processus d'un système Oracle Database peuvent être classés en trois grandes catégories :
• Processus utilisateur qui exécutent le code des applications ou des outils Oracle
• Processus Oracle Database qui exécutent le code du serveur de base de données Oracle
(et comprennent des processus serveur et des processus en arrière-plan)
• Processus de démons et d'applications Oracle qui ne sont pas spécifiques à une seule base
de données
Lorsqu'un programme d'application ou un outil Oracle (SQL*Plus, par exemple) est lancé par un
utilisateur, il constitue un processus utilisateur. Ce processus ne se trouve pas nécessairement
sur l'ordinateur du serveur de base de données. Oracle Database crée aussi un processus
serveur pour exécuter les commandes émises par le processus utilisateur. En outre, le serveur
Oracle crée, pour une instance donnée, un ensemble de processus en arrière-plan qui
interagissent les uns avec les autres, mais aussi avec le système d'exploitation, afin de gérer les
structures mémoire, d'effectuer des opérations d'E/S asynchrones pour écrire des données sur le
disque et de réaliser d'autres tâches requises. La structure des processus varie d'une
configuration Oracle Database à une autre. Elle dépend du système d'exploitation et des options
choisies pour Oracle Database.

Structure des processus
Instances (ASM et base de données à part)
Mémoire SGA
PGA
Processus Processus en arrière-plan
serveur
Requis : DBWn CKPT LGWR SMON PMON
Processus RECO LREG MMON MMNL Autres

d'écoute
Facultatifs : ARCn ASMB RBAL Autres
Processus d'Oracle Grid Infrastructure

(ASM et Oracle Restart)
Processus ohasd ocssd diskmon
utilisateur
orarootagent oraagent cssdagent
Processus serveur
Oracle Database crée des processus serveur pour gérer les demandes des processus utilisateur
connectés à l'instance. Un processus utilisateur représente une application ou un outil qui se
connecte à la base de données Oracle. Il peut être sur la même machine que la base, ou bien
exister sur un client distant et utiliser un réseau pour accéder à la base. Le processus utilisateur
communique tout d'abord avec un processus d'écoute (listener) qui crée un processus serveur
dans un environnement dédié.
Les processus serveur créés pour le compte de l'application de chaque utilisateur peuvent
effectuer une ou plusieurs des tâches suivantes :
• Analyser et exécuter des instructions SQL émises via l'application.
• Lire les blocs de données nécessaires dans des fichiers de données sur disque et les
transférer dans les tampons de base de données partagés de la mémoire SGA (si ces blocs
ne se trouvent pas déjà en mémoire SGA).
• Renvoyer des résultats que l'application sera en mesure de traiter.
Processus en arrière-plan
Pour optimiser les performances et prendre en charge un grand nombre d'utilisateurs, un système
Oracle Database multiprocessus utilise des processus Oracle Database supplémentaires appelés
processus en arrière-plan. Une instance Oracle Database peut comprendre plusieurs de ces
processus

Dans les environnements qui n'utilisent ni RAC (Real Application Clusters), ni ASM (Automatic
Storage Management), les processus en arrière-plan les plus courants sont les suivants :
• Processus d'écriture dans la base de données (DBWn)
• Processus d'écriture des informations de journalisation (LGWR)
• Processus de point de reprise (CKPT)
• Processus de surveillance du système (SMON)
• Processus de surveillance des processus (PMON)
• Processus de récupération (RECO)
• Processus d'enregistrement de processus d'écoute (LREG)
• Processus de surveillance de gestion (MMON)
• Processus léger de surveillance de gestion (MMNL)
• Coordinateur de file d'attente de travaux (CJQ0)
• Processus esclaves de travail (Jnnn)
• Processus d'archivage (ARCn)
• Processus de surveillance de file d'attente (QMNn)
Les configurations plus avancées (RAC notamment) peuvent inclure d'autres processus en
arrière-plan. Interrogez les vues V$PROCESS et V$BGPROCESS pour plus d'informations.
Certains processus en arrière-plan sont créés automatiquement au démarrage d'une instance ;
d'autres sont lancés à la demande.
D'autres structures de processus ne sont pas propres à une base de données unique, mais
peuvent être partagées par plusieurs bases hébergées sur le même serveur. Cette catégorie
contient notamment les processus Grid Infrastructure et de mise en réseau.
Les processus Oracle Grid Infrastructure disponibles sur les systèmes Linux et UNIX sont
les suivants :
• ohasd : Démon Oracle High Availability Service qui est chargé de démarrer les processus
Oracle Clusterware.
• ocssd : Démon Cluster Synchronization Service
• diskmon : Démon Disk Monitor qui est chargé d'isoler les entrées et les sorties pour
le serveur HP Oracle Exadata Storage Server
• cssdagent : Démarre et arrête le démon CSS (ocssd) et vérifie son état
• oraagent : Etend le clusterware pour prendre en charge des exigences et des ressources
complexes propres à Oracle
• orarootagent : Ce processus agent spécialisé d'Oracle facilite la gestion des ressources
appartenant à la racine, par exemple le réseau
Remarque : Pour obtenir la liste détaillée des processus en arrière-plan disponibles, reportez-
vous au manuel Oracle Database Reference.

Revue des processus
Par rapport au cours

prérequis
PMON CKPT
Fichiers SMON
de contrôle
Point de reprise
System Monitor
DBWn
Cache de tampons Database

de la BdD Writer Fichiers de
données
LGWR ARCn
Informations de
journalisation Processus Fichiers de Processus Fichiers de
Log Writer d'archivage journalisation
Tampon de journalisation
en ligne archivés
journalisation
Les sections suivantes consacrées aux processus Oracle en arrière-plan sont importantes pour
bien comprendre les stratégies de sauvegarde et de récupération. Elles sont extraites d'un cours
prérequis et sont incluses ici à l'intention des stagiaires qui souhaitent y revenir. Sauf demande
expresse, il n'est pas nécessaire de revoir tous les détails en classe.
Vous pouvez passer directement à la diapositive "Compléter les noms de processus" pour vérifier
vos connaissances sur les sujets suivants :
• Processus DBWn (Database Writer)
• Processus LGWR (Log Writer)
• Processus CKPT (Checkpoint)
• Processus SMON (System Monitor)
• Processus PMON (Process Monitor)
• Processus ARCn (Archiver)

Rappels sur le processus DBWn
(Database Writer)
Il écrit sur le disque les tampons qui ont été modifiés ("dirty")
dans le cache de tampons de la base de données :
• de manière asynchrone pendant l'exécution d'un autre
traitement
• pour faire avancer le point de reprise
DBWn
Cache de tampons Processus Fichiers de

de la BdD Database Writer données
Quand un tampon du cache de la base de données est modifié, il est désigné comme "dirty" et
ajouté en tête de la file d'attente des points de reprise, laquelle est triée par numéro SCN (System
Change Number). L'ordre des tampons dans la file d'attente correspond donc à l'ordre dans
lequel les informations de journalisation (redo) sont écrites dans les journaux pour ces tampons
modifiés.
Lorsque le nombre de tampons disponibles dans le cache est inférieur à un seuil interne (au point
que les processus serveur ont du mal à obtenir des tampons disponibles), le processus DBWn
écrit les tampons modifiés ("dirty") qui sont rarement utilisés dans les fichiers de données, en
commençant par la fin de la liste LRU (Least Recently Used), afin que les processus puissent
remplacer des tampons en cas de besoin. Par ailleurs, DBWn écrit à partir de la fin de la file
d'attente des points de reprise pour faire avancer le point de reprise.
La mémoire SGA contient une structure mémoire qui inclut l'adresse RBA (Redo Block Address)
indiquant la position (dans le flux de données de journalisation) à partir de laquelle la récupération
doit commencer en cas d'échec de l'instance. Cette structure joue le rôle de pointeur dans les
informations de journalisation. Elle est consignée dans le fichier de contrôle par le processus
CKPT toutes les trois secondes. Comme le processus DBWn écrit les tampons "dirty" dans l'ordre
des numéros SCN (System Change Number), il fait avancer le pointeur en mémoire SGA à
chaque fois qu'il écrit des tampons de la liste LRU. De la sorte, si une récupération d'instance est
nécessaire, elle lira les informations de journalisation à partir d'un emplacement
approximativement correct, évitant ainsi des E/S inutiles. On parle de points de reprise
incrémentiels.
Dans tous les cas, DBWn effectue des opérations d'écriture (multiblocs) en mode batch pour plus
d'efficacité. Le nombre de blocs écrits dans une opération d'écriture multibloc est variable d'un
système d'exploitation à l'autre.

Rappels sur le processus LGWR (Log Writer)
• Il écrit le tampon de journalisation dans un fichier de

journalisation sur le disque :
• Les opérations d'écriture ont lieu dans les cas suivants :
– Quand un processus utilisateur valide une transaction.
– Quand un tiers du tampon de journalisation est plein.
– Avant qu'un processus DBWn n'écrive les tampons modifiés
sur le disque.
– Toutes les trois secondes.
LGWR
Informations de
journalisation
Processus Log Writer
Fichiers de
Tampon de
journalisation
journalisation
en ligne
Le processus LGWR gère le tampon de journalisation en écrivant ses entrées dans un fichier de
journalisation sur disque. Il écrit toutes les entrées de journalisation qui ont été copiées dans le
tampon depuis la dernière opération d'écriture qu'il a effectuée.
Le tampon de journalisation est réutilisable. Une fois que le processus LGWR a écrit son contenu
dans un fichier de journalisation sur le disque, il peut recevoir de nouvelles données provenant
des processus serveur. Normalement, la vitesse d'écriture du processus LGWR est suffisante
pour que le tampon comporte toujours suffisamment d'espace pour de nouvelles entrées, même
lorsque le fichier de journalisation fait l'objet de nombreux accès. LGWR écrit sur le disque une
seule portion contiguë du tampon.
LGWR effectue une opération d'écriture :
• Quand un processus utilisateur valide une transaction.
• Quand un tiers du tampon de journalisation est plein.
• Avant qu'un processus DBWn n'écrive les tampons modifiés sur le disque (si nécessaire).
• Toutes les trois secondes.

Pour que le processus DBWn puisse écrire un tampon modifié, il faut que tous les enregistrements
de journalisation associés aux modifications soient écrits sur disque (protocole d'écriture anticipée).
Si DBWn détecte des enregistrements de journalisation qui n'ont pas encore été écrits sur le disque,
il le signale au processus LGWR et attend que ce dernier ait terminé l'opération d'écriture pour vider
les tampons de données. LGWR écrit dans le groupe de journaux en cours. Si l'un des fichiers du
groupe est défectueux ou indisponible, LGWR continue d'écrire dans d'autres fichiers du groupe et
consigne une erreur dans le fichier trace LGWR ainsi que dans le fichier d'alertes système. Si tous
les fichiers d'un groupe sont endommagés, ou si le groupe n'est pas disponible parce qu'il n'a pas
été archivé, LGWR ne peut pas continuer de fonctionner.
Quand un utilisateur lance une instruction COMMIT, LGWR place un enregistrement de validation
dans le tampon de journalisation et l'écrit immédiatement sur le disque avec les entrées de
journalisation de la transaction. L'écriture des modifications apportées aux blocs de données est
différée jusqu'au moment opportun. On parle de mécanisme de validation rapide. L'écriture atomique
de l'entrée de journalisation contenant l'enregistrement de validation de la transaction est le seul
événement qui indique si la transaction a été validée. Oracle Database renvoie un code de réussite
à la transaction en cours de validation bien que les tampons de données n'aient pas encore été
écrits sur le disque.
Si le processus LGWR a besoin de plus d'espace de mémoire tampon, il écrit parfois les entrées de
journalisation avant que la transaction ne soit validée. Ces entrées ne deviennent permanentes que
si la transaction est validée ultérieurement. Lorsqu'un utilisateur valide une transaction, celle-ci reçoit
un numéro SCN (System Change Number) qui est enregistré par Oracle Database avec les entrées
de journalisation associées à la transaction dans le fichier de journalisation. Comme les numéros
SCN sont enregistrés dans le fichier de journalisation, les opérations de récupération peuvent être
synchronisées dans les bases de données RAC (Real Application Clusters) et distribuées.
Dans les périodes de forte activité, le processus LGWR peut écrire dans le fichier de journalisation
via des validations groupées. Supposons, par exemple, qu'un utilisateur valide une transaction.
LGWR doit écrire les entrées de journalisation associées à la transaction sur le disque. Pendant ce
temps, d'autres utilisateurs lancent des instructions COMMIT. LGWR ne peut pas consigner ces
transactions dans le fichier de journalisation tant qu'il n'a pas terminé l'opération d'écriture
précédente. Une fois que les entrées relatives à la première transaction ont été écrites dans le
fichier de journalisation, la liste complète des entrées relatives aux transactions en attente (pas
encore validées) peut être écrite sur le disque en une seule opération, ce qui représente moins d'E/S
qu'avec une gestion individuelle des transactions. De cette façon, Oracle Database réduit les E/S
disque et augmente les performances du processus LGWR. Si les demandes de validation
continuent de se succéder à un rythme élevé, chaque opération d'écriture (par LGWR) à partir du
tampon de journalisation peut contenir plusieurs enregistrements de validation.

Rappels sur le processus CKPT (Checkpoint)
A quel numéro SCN la récupération
d'instance doit-elle commencer ?
Point de reprise :
• Global : Enregistré dans le fichier de contrôle et l'en-tête
des données
• Incrémentiel : Enregistré dans le fichier de contrôle
Fichier de
CKPT contrôle
Processus
CKPT
Fichiers de
données
Un point de reprise (checkpoint) est à la fois un concept et un mécanisme. Il en existe différents

types. Les plus importants dans le cadre de ce cours sont les points de reprise globaux et les
points de reprise incrémentiels. La position du point de reprise définit le numéro de modification
système (SCN) auquel la récupération d'instance doit commencer dans le thread de
journalisation.
Le numéro SCN auquel un point de reprise global s'est produit est consigné à la fois dans les en-
têtes des fichiers de données et dans le fichier de contrôle. Le numéro SCN auquel un point de
reprise incrémentiel s'est produit est stocké dans le fichier de contrôle uniquement (dans une
structure appelée enregistrement de progression du point de reprise)
Le processus CKPT met à jour les fichiers de contrôle et les en-têtes de tous les fichiers de
données pour enregistrer les informations relatives au point de reprise (comme l'illustre le
schéma). En revanche, ce processus n'écrit pas les blocs sur le disque ; c'est le rôle du
processus DBWn. Les numéros SCN enregistrés dans les en-têtes de fichier garantissent que
toutes les modifications apportées aux blocs de base de données avant un numéro SCN
spécifique ont été écrites sur le disque.

Rappels sur le processus SMON (System Monitor)
• Il effectue les opérations de récupération au démarrage

de l'instance.
• Il nettoie les segments temporaires inutilisés
Instance
SMON
Processus
SMON
Segment
temporaire
Le processus SMON effectue une récupération au démarrage de l'instance si nécessaire.

Il assure également le nettoyage des segments temporaires qui ne sont plus utilisés. Si des
transactions terminées ont été ignorées pendant la récupération d'instance à cause d'erreurs liées
aux fichiers ou d'erreurs de mise hors ligne (offline), le processus SMON les récupère quand le
tablespace ou le fichier correspondant est remis en ligne (online).
SMON vérifie régulièrement s'il a besoin d'intervenir. Les autres processus peuvent appeler
SMON s'ils en détectent la nécessité.

Rappels sur le processus PMON
(Process Monitor)
• Il assure la récupération des processus utilisateur qui ont
échoué
– Il nettoie le cache de tampons de la base de données
– Il libère les ressources utilisées par le processus utilisateur
• Il surveille les sessions pour détecter tout dépassement
du délai d'inactivité.
Processus
serveur
PMON
Utilisateur
Processus Processus Cache de

utilisateur en PMON tampons de la
échec BdD
Le processus PMON assure la récupération de processus lorsqu'un processus utilisateur échoue.

Il est chargé de nettoyer le cache de tampons de la base de données et de libérer les ressources
bloquées par les processus utilisateur en échec. Par exemple, il réinitialise le statut de la table de
transactions actives, libère des verrous et supprime des ID dans la liste de processus actifs.
PMON vérifie périodiquement le statut des processus répartiteur et des processus serveur et les
redémarre s'ils se sont arrêtés (sauf ceux qui ont été arrêtés volontairement par Oracle
Database).
Comme SMON, le processus PMON vérifie régulièrement s'il doit intervenir. Il peut être appelé si
un autre processus en détecte la nécessité.

Rappels sur le processus ARCn (Archiver)
• Il copie les fichiers de journalisation sur le périphérique

de stockage désigné après un changement de fichier
de journalisation.
• Il peut collecter les données de journalisation des
transactions et les transmettre à des destinations
de secours
ARCn
Processus Copies des Destination

d'archivage fichiers de d'archivage
journalisation
Les processus ARCn ne sont présents que lorsque la base de données est en mode
ARCHIVELOG.
Les processus d'archivage copient les fichiers de journalisation sur le périphérique de stockage
désigné après un changement de fichier de journalisation. Ceci offre davantage d'opportunités de
récupération, car vous pouvez enregistrer, sauvegarder et restaurer l'ensemble des fichiers de
journalisation archivés (archive redo logs) qui ont été générés.
Si vous prévoyez une charge d'archivage importante (un chargement de données en masse, par
exemple), vous pouvez augmenter le nombre maximal de processus d'archivage. Par ailleurs, il
peut y avoir plusieurs destinations de fichiers de journalisation archivés. Il est recommandé
d'avoir au moins un processus d'archivage par destination. La valeur par défaut est d'avoir quatre
processus d'archivage.
Les fichiers de journalisation en ligne étant utilisés de façon cyclique, un protocole permet de
contrôler leur réutilisation. En mode ARCHIVELOG, la base de données ne commence à écrire
dans un fichier de journalisation en ligne que si une copie de ce dernier a été archivée.
L'archivage de chaque fichier de journalisation est ainsi garanti.

Exercice sur les noms de processus
1. Le processus ______écrit les tampons A. CKPT (Checkpoint)
"dirty" dans les fichiers de données. B. SMON (System
2. Le processus ______écrit les entrées Monitor)
de journalisation dans les fichiers de C. LGWR (Log Writer)
journalisation en ligne.
D. ARCn (Archiver)
3. Le processus ______écrit les informations
de point de contrôle dans le fichier de E. DBWn (Database
contrôle et dans l'en-tête de chaque fichier Writer)
de données. F. PMON (Process
4. Le processus ______assure la Monitor)
récupération lors du démarrage de
l'instance.
5. Le processus ______copie les fichiers
de journalisation sur le périphérique de
stockage indiqué.
6. Le processus ______assure la
récupération lors de l'échec d'un processus
utilisateur.

Exercice sur les noms de processus
1. Le processus DBWn écrit les tampons A. CKPT (Checkpoint)
"dirty" dans les fichiers de données. B. SMON (System
2. Le processus LGWR écrit les entrées Monitor)
de journalisation dans les fichiers de C. LGWR (Log Writer)
journalisation en ligne.
D. ARCn (Archiver)
3. Le processus CKPT écrit les informations
de point de contrôle dans le fichier de E. DBWn (Database
contrôle et dans l'en-tête de chaque fichier Writer)
de données. F. PMON (Process
4. Le processus SMON assure la Monitor)
récupération lors du démarrage de
l'instance.
5. Le processus ARCn copie les fichiers
de journalisation sur le périphérique de
stockage indiqué.
6. Le processus PMON assure la
récupération lors de l'échec d'un processus
utilisateur.
Solution : 1E, 2C, 3A, 4B, 5D, 6F

Mode de journal de la base de données
Segment
Données du d'annulation
Annuler les données "anciennes"
cache de dans le tablespace d'annulation
tampons
UPDATE Nouvelles modifications

dans les fichiers de journalisation
Opérations DML Informations de
journalisation Toutes les bases de
Fichiers de
Tampon de données du cours sont Fichiers de
journalisation
journalisation actuellement en mode journalisation
en ligne
NOARCHIVELOG. archivés
Mode NOARCHIVELOG Mode ARCHIVELOG

Base de données fermée Base de données ouverte
Pas de récupération jusqu'à la dernière transaction validée Récupération jusqu'à la dernière

transaction validée
Convient aux environnements de formation et de test, Convient aux environnements de

aux data warehouses où les charges sont peu fréquentes production
A mesure que des modifications sont effectuées sur les données de la base, les données
"anciennes" sont stockées dans le tablespace d'annulation et les informations sur les nouvelles
modifications sont placées dans les fichiers de journalisation en ligne (voir l'illustration graphique
ci-dessus). les informations d'annulation sont également dans le flux des informations de
journalisation. Le contenu du fichier de journalisation en ligne comprend des transactions non
validées et des instructions de gestion de schéma et d'objet. La base de données gère des
fichiers de journalisation en ligne en vue d'éviter tout risque de perte de données. Après une
panne d'instance, par exemple, les fichiers de journalisation en ligne permettent à Oracle
Database de récupérer les données validées qui n'ont pas encore été écrites dans les fichiers de
données.
Les fichiers de journalisation en ligne étant utilisés de façon cyclique, un protocole permet de
contrôler leur réutilisation. En mode ARCHIVELOG, la base de données ne commence à écrire
dans un fichier de journalisation en ligne que si une copie de ce dernier a été archivée.
L'archivage de chaque fichier de journalisation est ainsi garanti.
Il est possible d'effectuer n'importe quel type de sauvegarde (complète ou incrémentielle) d'une
base de données en mode NOARCHIVELOG (à condition, bien sûr, que la base ne soit pas
ouverte). Lorsque la base est en mode NOARCHIVELOG, vous devez restaurer tous les fichiers de
données avant d'exécuter une opération de récupération. Notez que la récupération est limitée au
moment de la dernière sauvegarde. La base de données ne peut être récupérée jusqu'à la
dernière transaction validée que si elle est en mode ARCHIVELOG.
Les cas d'utilisation des deux modes sont décrits dans le tableau de la diapositive.

Base de données ORCL avec ASM
Oracle Grid Infrastructure pour un serveur autonome :
• Installé à partir des supports du clusterware, distincts de
ceux du logiciel de base de données
• Contient Oracle Automatic Storage Management (ASM)
• Contient la solution de haute disponibilité Oracle Restart
(réservée aux bases de données non clusterisées)
– Oracle Restart peut surveiller et redémarrer les composants
suivants :
— Instances de base de données
orcl +ASM
— Processus d'écoute Oracle Net
— Services de base de données
— Instances ASM (Automatic Storage
DATA
Management)
FRA
— Groupes de disques ASM (DATA et FRA)
— Oracle Notification Services (ONS/eONS)
pour Data Guard
Oracle Grid Infrastructure pour un serveur autonome est installé à partir des supports du
clusterware, distincts de ceux du logiciel de base de données Oracle. Oracle Automatic Storage
Management et Oracle Restart sont inclus. Si Oracle Grid Infrastructure est installé avant Oracle
Database, les bases de données créées sont automatiquement configurées avec Oracle Restart.
Oracle Restart est conçu pour améliorer la disponibilité de votre base de données Oracle. Cette
solution de haute disponibilité est réservée aux environnements mono-instances (non
clusterisés). Pour les environnements Oracle Real Application Cluster (RAC), la fonctionnalité de
redémarrage automatique des composants est fournie par le clusterware. Oracle Restart peut
surveiller le fonctionnement des composants suivants et les redémarrer automatiquement :
• Instances de base de données, (ORCL dans l'exemple de la diapositive)
• Processus d'écoute Oracle Net
• Services de base de données
• Instance ASM (par exemple, +ASM)
• Groupes de disques ASM (par exemple, DATA et FRA)
• Oracle Notification Services (ONS/eONS) pour Data Guard (hors du cadre de ce cours)

Oracle Restart assure le démarrage des composants dans l'ordre approprié, selon leurs
dépendances. Si un composant doit être arrêté, il veille à arrêter les composants dépendants au
préalable.
Pour référence, voici quelques définitions :
• Une instance de base de données est une combinaison de la mémoire SGA (System
Global Area) et de processus en arrière-plan. Chaque instance est associée à une seule
base. Dans une configuration Oracle Real Application Clusters, plusieurs instances
accèdent simultanément à une même base.
• Un processus d'écoute Oracle Net est un processus qui surveille les demandes de
connexions entrantes des clients et gère le trafic réseau à destination de la base.
• Un service de base de données est un service créé par un utilisateur qui est géré par
Oracle Clusterware. Il peut être proposé sur une ou plusieurs instances RAC et il est géré au
niveau instance (en ce qui concerne les procédures de démarrage et d'arrêt). Seuls les
services gérés par Oracle peuvent faire partie d'une classe de performances. Les services
créés avec le package DBMS_SERVICE ne sont pas gérés par Oracle Clusterware.
• Une instance ASM est fondée sur la même technologie qu'une instance Oracle Database.
Elle comprend une mémoire SGA (System Global Area) et des processus en arrière-plan
similaires à ceux d'Oracle Database. Cependant, étant donné qu'ASM effectue moins de
tâches qu'une base de données, la mémoire SGA associée est beaucoup plus petite. Les
instances ASM montent des groupes de disques pour mettre les fichiers ASM à la
disposition des instances de base de données. Les instances ASM ne montent pas les
bases de données.
• Un groupe de disques ASM est un ensemble constitué d'un ou de plusieurs disques Oracle
ASM qui sont gérés comme une unité logique. Les E/S concernant un groupe de disques
sont réparties automatiquement entre les disques du groupe.
• Un service ONS est un service de notification de type publication/abonnement permettant
de transmettre des informations sur les événements FAN (Fast Application Notification).

Faciliter la gestion de la base de données
avec Oracle Restart
• Redémarrer les composants Oracle lorsque l'ordinateur
hôte redémarre ou après une défaillance matérielle ou
logicielle
• Surveiller les composants et les redémarrer si nécessaire
• Pour les environnements mono-instances
• Tenir compte des dépendances entre composants :
– Monter les groupes de disques et démarrer l'instance ASM
avant de démarrer l'instance de base de données
– Gérer la faible interdépendance entre la base de données et
le processus d'écoute
• Démarrer Oracle Restart avec l'utilitaire crsctl
• Gérer les composants d'Oracle Restart avec
l'utilitaire srvctl
$ srvctl stop database –d orcl –o abort
• Oracle Restart permet aux composants Oracle d'être automatiquement redémarrés après
une défaillance matérielle ou logicielle, ou lors du redémarrage de l'ordinateur hébergeant la
base de données.
• Oracle Restart effectue des vérifications périodiques pour surveiller l'état de ces
composants. Si un contrôle échoue pour un composant, celui-ci est arrêté et redémarré.
• Oracle Restart n'est utilisé que dans les environnements mono-instances (non clusterisés).
Pour les environnements Oracle Real Application Cluster (RAC), la fonctionnalité de
redémarrage automatique des composants est fournie par le clusterware.
• Oracle Restart tient compte des dépendances entre composants pour démarrer ceux-ci
dans l'ordre adéquat. Par exemple, si les fichiers de base de données sont stockés dans
des groupes de disques ASM, Oracle Restart vérifie que l'instance est démarrée et que les
groupes de disques sont montés avant de démarrer l'instance de base de données. Si un
composant doit être arrêté, il veille à arrêter les composants dépendants au préalable.

• Par ailleurs, Oracle Restart gère la faible interdépendance existant entre les instances de
base de donnée et le processus d'écoute Oracle Net. Lorsqu'une instance de base de
données est démarrée, Oracle Restart tente de démarrer le processus d'écoute. Si le
démarrage du processus d'écoute échoue, la base reste démarrée. Si le processus d'écoute
échoue ensuite, Oracle Restart n'assure pas l'arrêt puis le redémarrage des instances de
base de données.
• Vous lancez Oracle Restart avec l'utilitaire crsctl (Clusterware Control).
• Oracle Restart comprend l'utilitaire srvctl (Server Control) qui permet de démarrer et
d'arrêter les composants qu'il gère.
Remarque : L'utilitaire srvctl se trouve à la fois dans le répertoire $ORACLE_HOME/bin
du logiciel Oracle Grid Infrastructure et dans le répertoire $ORACLE_HOME/bin du logiciel Oracle
Database. Utilisez la version liée à Oracle Database pour le démarrage de la base de données
Oracle. Utilisez la version liée à Oracle Grid Infrastructure pour le démarrage de l'instance ASM
ou du processus d'écoute (listener).

Outils d'administration
de base de données Oracle
Pour les tâches liées à la sauvegarde et la récupération :
• Client RMAN
• SQL*Plus
• SQL Developer
• srvctl : pour les composants d'Oracle Restart et
les environnements clusterisés
• asmcmd : pour toutes les tâches d'administration ASM
• Enterprise Manager Cloud Control
– Interface graphique vers RMAN et OSB
– Assistants utilisés pour de nombreuses tâches
• obtool : interface de ligne de commande vers Oracle
Secure Backup
• Enterprise Manager Database Express (EM Express)
• Le client RMAN est un outil en mode ligne de commande qui permet d'exécuter des
commandes RMAN pour gérer l'environnement de sauvegarde, créer des sauvegardes et
effectuer des opérations de récupération.
• SQL*Plus est également une interface de ligne de commande pour exécuter du code SQL
et SQL*Plus. Vous pouvez l'utiliser pour beaucoup de tâches de DBA, notamment pour
configurer des paramètres persistants de sauvegarde et de récupération.
• Oracle SQL Developer est une version graphique de SQL*Plus. Il permet d'exécuter des
instructions et des scripts SQL, d'éditer et de déboguer du code PL/SQL, de manipuler et
d'exporter des données. Pour plus d'informations, reportez-vous au manuel Oracle SQL
Developer User’s Guide.
• L'utilitaire srvctl facilite la gestion des composants d'Oracle Restart et des
environnements clusterisés. Pour plus d'informations, reportez-vous au manuel Oracle
Database Administrator’s Guide.
• ASMCMD est un utilitaire de ligne de commande qui permet de gérer les instances ASM, les
groupes de disques, le contrôle d'accès aux fichiers pour les groupes de disques, les
fichiers et les répertoires au sein de groupes de disques, les modèles associés aux groupes
de disques et les volumes. Pour plus d'informations, reportez-vous au manuel Oracle
Automatic Storage Management Administrator’s Guide.

• Enterprise Manager (EM) fournit une interface graphique vers les fonctionnalités RMAN les
plus couramment utilisées. Des assistants facilitent un grand nombre d'opérations RMAN.
- EM fournit également des liens vers l'interface graphique d'Oracle Secure Backup
(OSB).
- RMAN est intégré avec OSB, ce qui assure une gestion centralisée des sauvegardes
sur disque, protégeant ainsi les données du système de fichiers et les fichiers Oracle
Database.
• obtool est l'interface de ligne de commande utilisée pour OSB.
• Oracle Enterprise Manager Database Express (EM Express) est un produit de gestion via le
Web qui propose des pages d'administration de base, notamment la page d'accueil de la
base de données. Il prend en charge des tâches liées à la configuration, au stockage et aux
performances, mais pas les opérations de sauvegarde et de récupération. Pour plus
d'informations, reportez-vous à Oracle Database 2 Day DBA.
Remarque : Un seul de ces outils est utilisé dans les exercices même si d'autres sont
capables d'effectuer la même tâche.

Principe de séparation des tâches
d'administration
Privilège administratif SYSBACKUP :
• Il inclut des droits pour la sauvegarde et la récupération
(connexion à une base de données fermée).
• Il ne comprend pas de privilèges d'accès aux données tels
que SELECT ANY TABLE
• Il est accordé à l'utilisateur SYSBACKUP créé pendant
l'installation de la base de données
• Il peut être utilisé de manière explicite dans les connexions
RMAN par un utilisateur avec privilèges SYSBACKUP
$ rman target "'/ as sysbackup'"
connected to target database: ORCL (DBID=1297344416)
Remarque : Evitez d'utiliser le privilège SYSDBA si ce n'est pas

absolument nécessaire.
Oracle Database 12c (et les versions ultérieures) prend en charge la séparation des tâches de
DBA pour la base Oracle, avec des privilèges administratifs spécifiques aux tâches et de niveau
moindre qui ne nécessitent pas le privilège administratif SYSDBA. Le privilège qui permet de se
connecter et d'exécuter des commandes dans RMAN est SYSBACKUP.
• Connectez-vous explicitement avec ce rôle :
rman target "'/ as sysbackup'"
Notez les apostrophes incluses entre les guillemets.
• Pour des raisons de compatibilité amont, rman target / se connecte en tant que
SYSDBA.

Se connecter à RMAN et à une base de données cible
. oraenv
orcl
$ rman target "'/ as sysbackup'"
RMAN> BACKUP DATABASE;

Starting backup at 10-OCT-12
.
.
RMAN> LIST BACKUP;
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ------- ----------- ------------ ---------------
1 Full 1.06G DISK 00:01:49 10-OCT-12
.
.
RMAN> DELETE OBSOLETE;
.
Do you really want to delete the above objects (enter YES or NO)? YES
deleted archived log
.
.
L'environnement Linux du cours comprend plus d'une base de données locale. Utilisez .
oraenv pour définir vos variables d'environnement (comme illustré sur la diapositive).
Lancez RMAN depuis la ligne de commande, en indiquant les options appropriées. Les options
couramment utilisées sont :
• target : chaîne de connexion pour la base de données cible.
• catalog : chaîne de connexion pour un catalogue de restauration.
• nocatalog : indique l'absence de catalogue de restauration. Il s'agit de l'option par défaut.
• cmdfile : nom d'un fichier de commande d'entrée.
• log : nom du fichier journal des messages de sortie.
L'appel de RMAN rman target / établit la connexion à la base de données locale en tant que
cible. L'exemple de la diapositive illustre la connexion par défaut avec le privilège SYSBACKUP.
A l'invite RMAN, vous pouvez soumettre des commandes RMAN pour gérer votre environnement
de sauvegarde et créer des sauvegardes de diverses manières, en fonction de vos besoins. La
diapositive présente des commandes permettant d'effectuer une sauvegarde de la base de
données, d'afficher la liste des sauvegardes existantes (LIST BACKUP) et de supprimer les
sauvegardes obsolètes (DELETE OBSOLETE).
Remarque : Pour plus d'informations sur le mode d'exécution de RMAN, reportez-vous au
manuel Oracle Database Backup and Recovery User's Guide. Pour obtenir la liste complète des
commandes RMAN et de leurs options, reportez-vous au manuel Oracle Database Backup and
Recovery Reference.

Utilisation du code SQL dans RMAN
A partir de la ligne de commande RMAN
• Exécutez des commandes SQL et des procédures
PL/SQL.
• Utilisez le préfixe facultatif SQL pour éliminer toute
ambiguïté.
• Utilisez la commande DESCRIBE pour répertorier les
colonnes d'une table ou d'une vue. Syntaxe :
DESCRIBE (CATALOG) (schema.) table (@dblink);
RMAN> SELECT NAME, DBID, LOG_MODE

2> FROM V$DATABASE;
NAME DBID LOG_MODE

--------- ---------- ------------
ORCL 1297344416 NOARCHIVELOG
• Vous pouvez exécuter des commandes SQL et des procédures PL/SQL à partir de la ligne
de commande RMAN. Dans les versions antérieures à Oracle Database 12.1, il fallait
utiliser le préfixe SQL et des guillemets.
• Le mot-clé SQL est facultatif, mais il vaut mieux l'ajouter pour éliminer toute ambiguïté, en
particulier pour quelques commandes qui existent à la fois dans RMAN et dans SQL mais
avec des usages différents.
• La commande RMAN DESCRIBE fournit la même fonctionnalité que la commande SQL*Plus
DESCRIBE. Vous pouvez utiliser la forme abrégée DESC ou la forme complète DESCRIBE
pour lister les définitions de colonne d'une table ou d'une vue. Pour accéder à une table ou
une vue appartenant à un autre schéma, vous devez avoir des privilèges SELECT sur l'objet
ou vous connecter en mode SYSDBA.

Approche rapide de la résolution d'un problème
Création d'un scénario de test :

1. Sauvegardez la base de données en mode
NOARCHIVELOG.
2. Créez un tablespace, un utilisateur et une table de test.
3. Simulez une défaillance.
4. Forcez une récupération d'instance avec SHUTDOWN
ABORT.
Quelles situations peuvent résulter de ce scénario ?
Que doit faire la base de données pour assurer la cohérence
transactionnelle ?
Si une instance d'une base de données ouverte connaît une défaillance, à cause d'une instruction
SHUTDOWN ABORT ou d'une fin anormale, les situations suivantes peuvent se présenter :
• Les blocs de données validés par une transaction ne sont pas écrits dans les fichiers
de données et apparaissent uniquement dans le fichier de journalisation en ligne. Ces
modifications doivent être réappliquées à la base de données.
• Les fichiers de données contiennent des modifications qui n'avaient pas encore été validées
au moment de la défaillance de l'instance. Ces modifications doivent être annulées pour
assurer la cohérence transactionnelle.
La récupération d'instance utilise uniquement les fichiers de journalisation en ligne et les fichiers
de données en ligne en cours pour synchroniser les fichiers de données et vérifier qu'ils sont
cohérents.

Effectuer la restauration et la récupération d'une
base de données en mode NOARCHIVELOG
Si la base de données est en mode NOARCHIVELOG et qu'un
fichier de données est perdu, procédez de la manière suivante :
1. Arrêtez l'instance si elle est encore active.
2. Restaurez l'intégralité de la base à partir de la sauvegarde,
y compris tous les fichiers de données et de contrôle.
3. Ouvrez la base de données.
4. Informez les utilisateurs qu'ils doivent entrer à nouveau
toutes les modifications qu'ils ont effectuées depuis la
dernière sauvegarde.
La perte d'un fichier de données (quel qu'il soit) dans une base de données en mode
NOARCHIVELOG nécessite une restauration complète de la base, y compris des fichiers de
contrôle et de tous les fichiers de données.
Lorsque la base est en mode NOARCHIVELOG, il n'est possible de récupérer que l'état de la plus
récente sauvegarde. Par conséquent, les utilisateurs doivent de nouveau entrer toutes les
modifications qui ont été apportées depuis cette sauvegarde.
Pour effectuer ce type de récupération :
2. Dans la page Maintenance Properties, cliquez sur Perform Recovery.
3. Sélectionnez le type de récupération Whole Database.
Si vous avez une base de données en mode NOARCHIVELOG qui utilise une stratégie
de sauvegarde incrémentielle, RMAN restaure d'abord le niveau 0 le plus récent, puis la
récupération RMAN applique les sauvegardes incrémentielles.

Quiz
Lorsque la base est en mode NOARCHIVELOG, vous devez

restaurer tous les fichiers de données avant d'exécuter une
opération de récupération.
a. Vrai
b. Faux
Réponse : a

Synthèse

• décrire l'architecture de base de données dans une
perspective de sauvegarde et de récupération
• décrire votre instance ORCL en mode NOARCHIVELOG
• identifier les outils Oracle servant à la sauvegarde et à la
récupération
• effectuer une sauvegarde et une récupération
élémentaires (en mode NOARCHIVELOG)

Mise en route
Dans ces exercices, vous allez :
1. effectuer une sauvegarde de base de données en mode
NOARCHIVELOG
2. créer un cas de test
3. effectuer une récupération en mode NOARCHIVELOG
Dans les exercices de ce chapitre, vous allez effectuer votre première sauvegarde, puis créer un
cas de test, simuler une défaillance et procéder à la récupération de la base. Après avoir simulé
la défaillance, vous devez absolument mener à bien l'exercice de récupération.

Configuration en vue de la récupération

Objectifs

• configurer et gérer les paramètres RMAN
• configurer la zone de récupération rapide
• configurer le fichier de contrôle pour garantir une
protection appropriée
• configurer les fichiers de journalisation en vue de
la récupération
• configurer le mode ARCHIVELOG et les fichiers de
journalisation archivés en vue de la récupération

Types de commande RMAN
Les commandes RMAN peuvent être de différents types :

• Une commande autonome :
– est exécutée individuellement à l'invite RMAN
– ne peut pas apparaître sous forme de sous-commande de
la commande RUN
• Une commande de type travail :
– doit être incluse entre les accolades de la commande RUN
– est exécutée en tant que groupe
Certaines commandes peuvent être exécutées dans les deux
types.
Vous pouvez exécuter deux principaux types de commande RMAN : des commandes autonomes
et des commandes de type travail.
Les commandes autonomes sont exécutées à l'invite RMAN et se suffisent généralement à elles-
mêmes.
Les commandes de type travail sont généralement regroupées et exécutées de manière
séquentielle dans un bloc de commande. Si l'une quelconque des commandes du bloc échoue,
RMAN interrompt le traitement. Aucune autre commande du bloc n'est exécutée. Les effets des
commandes déjà exécutées sont toutefois maintenus ; ils ne sont en rien annulés.
La commande ALLOCATE CHANNEL, par exemple, ne peut être exécutée qu'en tant que
commande de type travail. Elle ne peut pas être exécutée en tant que commande autonome
parce que le canal est alloué uniquement pour l'exécution du travail associé. Certaines
commandes peuvent être exécutées à l'invite ou dans un bloc de commande RUN, notamment
BACKUP DATABASE. Lorsque vous exécutez des commandes autonomes, RMAN alloue les
canaux nécessaires en utilisant la fonctionnalité d'allocation automatique des canaux.
Vous pouvez exécuter des commandes autonomes et des commandes de type travail en mode
interactif ou en mode batch.

Commandes de type travail : Exemple
Les commandes de type travail apparaissent dans un bloc de

commande RUN :
RMAN> RUN
2> {
3> ALLOCATE CHANNEL c1 DEVICE TYPE DISK
4> FORMAT "/disk2/%U";
5> BACKUP AS BACKUPSET DATABASE;
6> SQL 'alter system archive log current';
7> }
L'exécution de l'ensemble du bloc commence

lorsque cette ligne est entrée.
Libération après exécution du bloc RUN
Contrairement aux commandes autonomes, les commandes de type travail doivent apparaître
entre les accolades de la commande RUN. Les commandes placées à l'intérieur d'un bloc RUN
(comme illustré dans la diapositive) sont exécutées en tant qu'unité de commandes unique. Toute
configuration effectuée à l'intérieur du bloc s'applique au bloc tout entier et remplace tout
paramétrage effectué précédemment. Voici des exemples de commandes de ce type qui doivent
apparaître au sein d'un bloc RUN :
• ALLOCATE CHANNEL
• SWITCH
RMAN exécute les commandes de type travail de manière séquentielle au sein d'un bloc de
commande RUN. Si l'une quelconque des commandes du bloc échoue, RMAN interrompt le
traitement. Aucune autre commande du bloc n'est exécutée. En effet, la commande RUN définit
une unité d'exécution de commande. Lorsque la dernière commande d'un bloc RUN se termine, la
base de données Oracle libère les ressources côté serveur, notamment les mémoires tampon
(buffers) d'entrée/sortie (E/S) ou les processus esclaves d'E/S alloués dans le bloc.
Remarque : La commande SQL de la ligne 6 est seulement un exemple. Il NE s'agit PAS d'une
commande requise pour l'opération de sauvegarde.

Configurer des paramètres persistants pour RMAN
• RMAN est préconfiguré avec des paramètres par défaut.

• Utilisez la commande CONFIGURE pour :
– configurer des canaux automatiques
– préciser la stratégie de conservation des sauvegardes
– indiquer le nombre de copies de sauvegarde à créer
– définir le type de sauvegarde par défaut BACKUPSET ou COPY
– limiter la taille des éléments de sauvegarde
– exclure un tablespace de la sauvegarde
– activer et désactiver l'optimisation de la sauvegarde
– configurer les sauvegardes automatiques des fichiers de contrôle
– définir la stratégie relative à la suppression des journaux archivés
– indiquer le parallélisme pour un périphérique
– définir les paramètres de cryptage et de compression à utiliser
pour les sauvegardes
Afin de simplifier l'utilisation courante de RMAN pour la sauvegarde et la récupération, RMAN

vous permet de définir plusieurs paramètres de configuration persistants pour chaque base de
données cible. Ces paramètres contrôlent divers aspects du comportement de RMAN. Vous
pouvez sauvegarder les informations de configuration persistantes telles que les paramètres
relatifs aux canaux, le parallélisme et le type de périphérique par défaut dans le référentiel RMAN.
Ces paramètres sont toujours stockés dans le fichier de contrôle et dans la base de données du
catalogue de restauration (si elle existe).
Ces paramètres ont des valeurs par défaut, ce qui vous permet d'utiliser RMAN immédiatement.
Vous pouvez être amené à les modifier afin de mettre en place une stratégie de sauvegarde et de
récupération plus complexe. La commande CONFIGURE permet de configurer des paramètres
persistants pour les travaux de sauvegarde, de restauration, de duplication et de maintenance de
RMAN. Ces paramètres s'appliquent à toutes les sessions RMAN jusqu'au moment où vous
supprimez ou modifiez votre configuration personnalisée.
Remarque : Les paramètres de configuration peuvent être modifiés dans un travail (ou une
session) RMAN pour la durée de celui-ci (ou de la session) à l'aide de la commande SET.
Remarque concernant Enterprise Manager : Les mêmes règles s'appliquent à l'utilisation de
RMAN via l'interface Enterprise Manager. Les paramètres de sauvegarde sont des paramètres
par défaut pour toutes les sauvegardes réalisées. Lors de la création d'une sauvegarde, il est
possible de remplacer certains de ces paramètres pour la sauvegarde considérée.

Visualiser les paramètres persistants
Pour consulter les paramètres RMAN persistants associés

à une base de données :
• Utilisez la commande RMAN SHOW ALL pour afficher tous
les paramètres de configuration
• Interrogez la vue V$RMAN_CONFIGURATION pour afficher
des paramètres de configuration qui ont été définis
explicitement
Vous pouvez afficher tous les paramètres persistants de RMAN en vous connectant à la cible et
en exécutant la commande RMAN SHOW ALL. Vous pouvez interroger la vue
V$RMAN_CONFIGURATION de la base de données cible pour afficher les paramètres de
configuration qui ont été définis explicitement.

Gérer les paramètres persistants
• Utiliser plusieurs flux de données à destination et en
provenance d'un périphérique :
RMAN> CONFIGURE DEVICE TYPE sbt PARALLELISM 3;
• Utiliser la commande SHOW pour obtenir la liste des
paramètres actuels :
RMAN> SHOW CONTROLFILE AUTOBACKUP FORMAT;
RMAN> SHOW EXCLUDE;
RMAN> SHOW ALL;
• Utiliser l'option CLEAR de la commande CONFIGURE pour

restaurer
RMAN> la valeur
CONFIGURE par défaut
BACKUP des paramètres
OPTIMIZATION CLEAR;persistants :
RMAN> CONFIGURE MAXSETSIZE CLEAR;
RMAN> CONFIGURE DEFAULT DEVICE TYPE CLEAR;
Le parallélisme désigne le nombre de flux de données pouvant être utilisés pour la lecture et
l'écriture sur un périphérique donné. Il détermine le nombre de canaux effectivement alloués
lorsqu'un périphérique configuré est utilisé par RMAN. Par exemple, si un gestionnaire de
supports dispose de deux lecteurs de bande, un parallélisme de 2 permet l'utilisation simultanée
de ces deux lecteurs pour les commandes BACKUP à l'aide de ce gestionnaire. Le parallélisme
concernant le type de périphérique Disk est utile si vous souhaitez répartir une sauvegarde sur
plusieurs disques.
Indiquez le parallélisme à utiliser sur le périphérique à l'aide de la clause PARALLELISM, de la
manière suivante :
CONFIGURE DEVICE TYPE <device> PARALLELISM <n>
où <n> est la valeur de parallélisme.
La commande RMAN SHOW permet d'afficher les paramètres de configuration de RMAN. Si vous
exécutez SHOW ALL en étant connecté à une base de données cible, seules les configurations
spécifiques à des noeuds et les configurations de base de données s'affichent.
Vous pouvez rétablir la valeur par défaut pour n'importe quelle commande CONFIGURE en
exécutant la même commande avec l'option CLEAR.

Définir une stratégie de conservation
• Une stratégie de conservation décrit les sauvegardes
à conserver et la durée de conservation.
• Il existe deux types de stratégie de conservation :
– Fenêtre de récupération (recovery window) : Définit une
période pendant laquelle la récupération jusqu'à un point
dans le temps doit rester possible
Sauvegarde Fenêtre de
récupération SYSDATE
– Redondance (redundancy) : Définit un nombre fixe de

sauvegardes devant être conservées
Sauvegarde 1 Sauvegarde 2
SYSDATE
• Les stratégies de conservation sont mutuellement exclusives.
Une stratégie de conservation définit quelles sauvegardes conserver et pendant combien

de temps. Vous pouvez définir sa valeur à l'aide de la commande RMAN CONFIGURE ou
d'Enterprise Manager.
Stratégie de conservation avec fenêtre de récupération
Il est recommandé de définir la durée pendant laquelle il sera possible de repérer les erreurs
logiques et de réparer les objets endommagés en effectuant une récupération jusqu'à un point
dans le temps situé juste avant l'erreur. Cette période est appelée fenêtre de récupération
(recovery window). Elle est définie en nombre de jours. Pour chaque fichier de données, il doit
toujours exister au moins une sauvegarde satisfaisant à la condition suivante :
SYSDATE – backup_checkpoint_time >= recovery_window
Vous pouvez utiliser la syntaxe de commande suivante pour configurer une stratégie de
conservation avec fenêtre de récupération :
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF <days> DAYS;
où <days> est la taille de la fenêtre de récupération.

Si vous n'utilisez pas de catalogue de restauration, la fenêtre de récupération (recovery window) doit
être inférieure ou égale à la valeur du paramètre CONTROL_FILE_RECORD_KEEP_TIME pour éviter
le remplacement des sauvegardes plus anciennes dans le fichier de contrôle. Si vous utilisez un
catalogue de restauration, en revanche, veillez à ce que la valeur de
CONTROL_FILE_RECORD_KEEP_TIME soit supérieure à la période entre les resynchronisations du
catalogue. Des resynchronisations se produisent dans les cas suivants :
• Vous créez une sauvegarde. Dans ce cas, la synchronisation est effectuée de façon implicite.
• Vous exécutez la commande RESYNC CATALOG.
Les catalogues de restauration sont traités plus en détail dans le chapitre "Utiliser le catalogue de
restauration RMAN".
Stratégie de conservation tenant compte de la redondance
Si vous devez conserver un nombre spécifique de sauvegardes, vous pouvez définir la stratégie de
conservation sur la base de l'option de redondance. Cette option nécessite qu'un nombre donné de
sauvegardes soit catalogué pour qu'il soit possible d'identifier certaines d'entre elles comme
obsolètes. La stratégie de conservation par défaut a une redondance égale à 1, ce qui signifie
qu'une seule sauvegarde d'un fichier doit exister à un moment donné. Une sauvegarde est
considérée comme obsolète lorsqu'une version plus récente du même fichier est sauvegardée.
Vous pouvez utiliser la commande suivante pour reconfigurer une stratégie de conservation tenant
compte de la redondance :
RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY <copies>;
où <copies> est le nombre de copies nécessaires pour satisfaire à la stratégie.
Désactiver la stratégie de conservation
Vous pouvez souhaiter désactiver la stratégie de conservation dans son ensemble. Cela peut être le
cas si vous disposez d'un système extérieur à RMAN qui sauvegarde vos disques sur bande. Si
vous désactivez la stratégie de conservation, aucune sauvegarde n'est considérée comme obsolète
par RMAN. En effet, RMAN n'a pas besoin de décider quand supprimer une sauvegarde du disque
(un autre utilitaire s'en charge) et il est donc inutile de le configurer pour cette prise de décision.
Dans ce cas, les enregistrements de chaque sauvegarde sont conservés pendant la durée indiquée
par le paramètre d'initialisation CONTROL_FILE_RECORD_KEEP_TIME. Pour désactiver la stratégie
de conservation, utilisez la commande suivante :
RMAN> CONFIGURE RETENTION POLICY TO NONE;
Remarque : Vous pouvez préciser qu'une sauvegarde constitue une exception à la stratégie
de conservation que vous avez définie en créant une sauvegarde d'archive.

Stratégie de conservation avec fenêtre
de récupération : Exemple
Journal 100 Journal 200 Journal 300 Journal 400 Journal 500
Sauvegarde A Sauvegarde B Sauvegarde C
Maintenant
Sauvegarde Obsolète Fenêtre de récupération de 7 jours
Sauvegarde Non obsolète
La sauvegarde B et les fichiers de journalisation archivés 201 à 500

sont nécessaires pour satisfaire à cette stratégie de conservation.
La stratégie de conservation illustrée par la diapositive implique la possibilité d'effectuer une

récupération jusqu'à n'importe quel moment au cours des sept derniers jours. Certains journaux
et sauvegardes sont obsolètes car ils ne sont pas nécessaires à une récupération jusqu'à un
point donné au sein de la fenêtre de sept jours. Cette stratégie de conservation est configurée
ainsi :
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
Considérant les sauvegardes et les fichiers de journalisation archivés à disposition, les seules
données nécessaires pour effectuer une récupération jusqu'à un point situé dans la fenêtre de
récupération sont la sauvegarde B et les journaux 201 à 500 inclus. La sauvegarde A n'est pas
utile parce qu'il existe une sauvegarde ultérieure (B) qui demeure antérieure à la fenêtre de
récupération. En outre, la sauvegarde C ne peut pas être la seule sauvegarde à être conservée
car elle ne permettrait pas d'effectuer une récupération jusqu'à un point donné situé au début de
la fenêtre de récupération. Les données de récupération nécessaires sont donc la dernière
sauvegarde réalisée avant le début de la fenêtre de récupération ainsi que tous les journaux
écrits depuis cette sauvegarde.

Quiz
Les paramètres de configuration RMAN ne peuvent pas être

modifiés pour une session RMAN spécifique.
a. Vrai
b. Faux
Réponse : b

Utiliser une zone de récupération rapide
• Eléments permanents :
– Copies multiplexées du fichier
de contrôle en cours
– Copies multiplexées des fichiers
Base de
de journalisation en ligne données
• Eléments transitoires :
– Fichiers de journalisation archivés
– Copies des fichiers de données
– Copies de fichier de contrôle
– Sauvegardes automatiques du fichier
de contrôle
– Eléments de sauvegarde
– Journaux Flashback Zone de
récupération rapide
L'un des composants fondamentaux de la stratégie Oracle de sauvegarde sur disque est la zone
de récupération rapide (FRA - fast recovery area). Il s'agit d'un emplacement de stockage dans un
système de fichiers ou un groupe de disques ASM (Automatic Storage Management) qui organise
tous les fichiers et les activités concernant la récupération pour une base de données Oracle.
Tous les fichiers qui sont nécessaires pour récupérer complètement une base de données après
une défaillance de support peuvent résider dans la zone de récupération rapide : fichiers de
contrôle, journaux archivés, copies de fichiers de données et sauvegardes RMAN.
La zone de récupération rapide ne se contente pas de conserver vos sauvegardes sur disque :
elle assure une gestion proactive de l'espace de stockage. Un emplacement lui est affecté, mais
aussi un quota qui représente la quantité maximum d'espace disque qu'elle peut utiliser à un
moment donné. Par exemple, lorsque de nouvelles sauvegardes sont créées dans la zone de
récupération rapide et que l'espace est insuffisant pour les contenir, les sauvegardes et les
journaux archivés qui ne sont pas indispensables pour la conformité aux paramètres de
configuration de RMAN (notamment en matière de stratégie de conservation et de stratégie de
suppression des fichiers de journalisation archivés) sont automatiquement supprimés pour libérer
de l'espace. Le fichier d'alertes contient des informations sur le moment où la consommation
d'espace disque s'approche du quota alloué alors qu'il est impossible de supprimer d'autres
fichiers. Vous pouvez alors intervenir pour corriger la situation en ajoutant de l'espace disque, en
sauvegardant des fichiers sur bande ou en modifiant la stratégie de conservation.

Les fichiers liés à la récupération sont de deux types : fichiers permanents et fichiers transitoires.
Les fichiers permanents sont utilisés activement par l'instance. Les fichiers transitoires n'ont d'utilité
que pour certains types d'opérations de récupération.
Eléments permanents
• Fichier de contrôle : En fonction de la valeur de plusieurs paramètres d'initialisation, une
copie du fichier de contrôle est créée dans la zone de récupération rapide lorsque vous
créez une base de données ou un fichier de contrôle. Pour plus d'informations, reportez-vous
à la section "Semantics" de la commande CREATE CONTROLFILE dans le manuel Oracle
Database SQL Language Reference.
• Copies multiplexées de fichiers de journalisation en ligne : Une copie miroir de chaque
groupe de fichiers de journalisation peut se trouver ici. Lorsque vous créez une base de
données, vous pouvez indiquer l'emplacement des fichiers de journalisation en ligne à l'aide
de la clause LOGFILE. Si vous n'incluez pas cette clause, les emplacements sont définis en
fonction des valeurs des paramètres d'initialisation suivants :
- DB_CREATE_ONLINE_LOG_DEST_n : Si une ou plusieurs de ces variables sont
définies, il s'agit des seuls emplacements utilisés.
- DB_CREATE_FILE_DEST : Si ce paramètre est défini, il s'agit de l'emplacement
principal pour les fichiers.
- DB_RECOVERY_FILE_DEST : Si ce paramètre est défini en plus de
DB_CREATE_FILE_DEST, il détermine l'emplacement miroir.
Pour plus d'informations sur l'effet de ces variables sur l'emplacement des fichiers de journalisation
en ligne, reportez-vous à la clause LOGFILE de l'instruction CREATE DATABASE dans le manuel
Oracle Database SQL Language Reference.
Eléments transitoires
• Fichiers de journalisation archivés : Lorsque la zone de récupération rapide est
configurée, son emplacement est automatiquement affecté au paramètre
LOG_ARCHIVE_DEST_1. Le processus d'archivage en arrière-plan crée des fichiers
de journalisation archivés dans la zone de récupération rapide et dans d'autres
emplacements configurés par des paramètres LOG_ARCHIVE_DEST_n. Si aucun
emplacement LOG_ARCHIVE_DEST_n n'est défini, les fichiers de journalisation archivés sont
stockés par défaut dans la zone de récupération rapide.
• Journaux Flashback : Les journaux Flashback sont générés lorsque la base de données
Flashback est activée.
• Sauvegardes automatiques du fichier de contrôle : La zone de récupération rapide est
l'emplacement par défaut des sauvegardes automatiques de fichier de contrôle créées par
RMAN et des sauvegardes automatiques générées par le serveur de base de données
Oracle.
• Copies des fichiers de données : La commande BACKUP AS COPY crée des copies
d'image des fichiers de données dans la zone de récupération rapide.
• Fichiers RMAN : La zone de récupération rapide est l'emplacement par défaut utilisé par
RMAN pour les sauvegardes et la restauration du contenu des journaux archivés à partir
d'une bande lors d'une opération de récupération.
Remarque : Si vous voulez que la zone de récupération rapide présente de bonnes performances,
envisagez de lui affecter des disques physiques et des contrôleurs distincts.

Configurer la zone de récupération rapide
• Fonctions de la zone de récupération rapide :
– Elle simplifie la gestion du stockage des sauvegarde
– Il s'agit d'un espace de stockage (par opposition aux fichiers de base de
données actifs)
– Son emplacement est défini par le
paramètre DB_RECOVERY_FILE_DEST
– Sa taille est définie par le paramètre Une zone de récupération
rapide peut être utilisé par
DB_RECOVERY_FILE_DEST_SIZE plusieurs bases de données.
– Assez grande pour recevoir les sauvegardes, les journaux archivés,
les journaux flashback, les fichiers de contrôle multiplexés et
les fichiers de journalisation multiplexés
– Gérée automatiquement conformément aux stratégies de conservation
des sauvegardes et de suppression des journaux archivés
• Déterminez l'emplacement, la taille et les stratégies de conservation
des sauvegardes et de suppression des fichiers de journalisation
archivés à configurer.
La zone de récupération rapide est un espace réservé sur le disque pour le stockage des fichiers
de journalisation archivés (archived redo logs), des sauvegardes, des journaux flashback ainsi
que des fichiers de contrôle et de journalisation multiplexés. Il est fortement recommandé de
l'utiliser, car elle simplifie la gestion du stockage des sauvegardes. Placez de préférence la zone
de récupération rapide à un emplacement de stockage distinct de celui des fichiers de base de
données, des fichiers de journalisation en ligne majeurs et du fichier de contrôle.
La quantité d'espace disque à allouer à la zone de récupération rapide dépend de la taille et du
niveau d'activité de la base de données. En règle générale, la zone de récupération rapide est
d'autant plus utile que sa taille est importante. Dans l'idéal, la zone de récupération rapide doit
être assez grande pour recevoir les copies de vos fichiers de données et de contrôle, ainsi que
les fichiers journaux Flashback, en ligne et archivés nécessaires à la récupération de la base à
partir des sauvegardes, conformément à votre stratégie de conservation. (En résumé, la taille de
la zone de récupération rapide doit être au moins double de la taille de la base de données, de
façon à pouvoir accueillir une sauvegarde et plusieurs fichiers de journalisation archivés.)
La gestion de l'espace dans la zone de récupération rapide est régie par les stratégies de
conservation des sauvegardes et de suppression des fichiers de journalisation archivés. Une
stratégie de conservation des sauvegardes détermine le moment où les fichiers deviennent
obsolètes et ne sont par conséquent plus utiles pour récupérer les données. Le serveur de base
de données Oracle gère automatiquement cet espace de stockage en supprimant les fichiers qui
ne sont plus nécessaires.

La stratégie de suppression des fichiers de journalisation archivés détermine le moment où la
suppression de ces fichiers peut être envisagée. Elle s'applique à toutes les destinations
d'archivage, y compris la zone de récupération rapide. Les fichiers de journalisation archivés
peuvent être supprimés automatiquement par le serveur de base de données ou à la suite de
commandes RMAN lancées par l'utilisateur. La suppression automatique s'applique uniquement aux
fichiers de journalisation archivés dans la zone de récupération rapide. Le serveur de base de
données conserve les fichiers de journalisation archivés dans la zone de récupération rapide aussi
longtemps que possible et il supprime automatiquement ceux qui peuvent l'être lorsqu'il a besoin de
récupérer de l'espace disque.
Si la zone de récupération rapide n'est pas assez spacieuse pour contenir les journaux Flashback et
les fichiers nécessités par la stratégie de conservation, les journaux Flashback remontant à des
SCN anciens peuvent être supprimés afin de libérer de l'espace pour d'autres fichiers
Si votre structure de stockage est conçue pour que plusieurs bases de données partagent la même
zone de récupération rapide, la seule tâche à accomplir consiste à allouer suffisamment d'espace à
cette zone. Les diverses bases de données gèrent ensuite leurs propres informations dans des
répertoires distincts. (Pas de tâches d'administration supplémentaires.)

Dimensionner la zone de récupération rapide
• Sauvegardes de fichier de contrôle et fichiers de

journalisation archivés : Estimez la taille des journaux
archivés générés entre les sauvegardes successives
pendant les journées d'activité maximale et multipliez par 2
pour tenir compte des pics d'activité
• Journaux Flashback : Taux de journalisation x durée cible
de conservation en mémoire Flashback x 2
• Sauvegardes incrémentielles : Taille estimée
• Copie d'image sur disque : Taille de la base de données
diminuée de la taille des fichiers temporaires
• Jeux de sauvegarde : Taille de la sauvegarde diminuée du
nombre de blocs non utilisés (ignorés)
Comme indiqué précédemment, vous pouvez utiliser la zone de récupération rapide pour stocker
des fichiers liés à la récupération. Cette zone est associée à un emplacement spécifique
(répertoire de système de fichiers ou groupe ASM) et sa taille est plafonnée par un quota.
En cas de manque d'espace dans la zone de récupération rapide, les fichiers qui sont jugés
"inutiles" sont supprimés automatiquement. Un fichier est "inutile" si :
• Il a été sauvegardé sur bande via RMAN
• Il est obsolète au regard de la stratégie de conservation RMAN
Pour calculer la taille de départ de la zone de récupération rapide, commencez par identifier les
fichiers liés à la récupération que vous souhaitez conserver. Tenez compte des recommandations
suivantes à ce stade :
• Si vous prévoyez de conserver uniquement les sauvegardes automatiques du fichier de
contrôle et les fichiers de journalisation archivés, vous pouvez déterminer la taille initiale de
la zone de récupération rapide en additionnant les tailles de tous les journaux archivés
générés entre les sauvegardes successives lors des journées de plus forte activité. La zone
de récupération rapide a juste besoin de l'espace nécessaire pour contenir les fichiers de
journalisation archivés qui sont générés entre deux sauvegardes successives. Multipliez
cette estimation par 2 pour tenir compte des pics inattendus de génération d'informations de
journalisation. Les sauvegardes automatiques du fichier de contrôle prennent généralement
peu d'espace.

• Si vous souhaitez conserver les journaux archivés et les journaux Flashback, multipliez par 2
la taille des journaux archivés pour obtenir une première estimation. Les journaux Flashback
sont en principe créés en proportion des fichiers de journalisation archivés qui sont générés au
cours de la même période de conservation. Multipliez le taux de journalisation par la durée
cible de conservation en mémoire Flashback et doublez le résultat.
• La taille des sauvegardes incrémentielles dépend de la quantité de modifications entre les
sauvegardes. Vous pouvez effectuer un test d'exécution de votre stratégie de sauvegarde
incrémentielle pour déterminer des valeurs représentatives d'espace sur une certaine période.
Intégrez ensuite ces valeurs au calcul de la taille de la zone de récupération rapide à prévoir
en mode de production.
• Si vous envisagez de conserver une sauvegarde d'image disque dans la zone de récupération
rapide, ajoutez la taille de la base de données diminuée de la taille des fichiers temporaires.
RMAN ne sauvegarde pas les fichiers temporaires. Une sauvegarde de copie d'image disque
permet une récupération plus rapide (par rapport à une récupération à partir d'une bande). En
outre, elle peut être utilisée telle quelle à la place du fichier de données du stockage de
production.
• Pour le stockage de jeux de sauvegarde, calculez la taille de la sauvegarde (au maximum, la
taille de la base de données diminuée de la taille des blocs inutilisés ou ignorés).

Gestion de l'espace dans la zone
de récupération rapide
La limite d'espace
est atteinte et un
Sauvegarde de Zone de Les fichiers qui
récupération nouveau fichier
fichiers de base ne sont plus
rapide doit être écrit dans
de données nécessaires sur
la zone de
1 récupération le disque sont
rapide. supprimés.
2
3 Manque
4 d'espace détecté
Avertissement
RMAN met à jour envoyé à
1
la liste des fichiers l'utilisateur
2
pouvant être supprimés.
Fichiers de
sauvegarde
à supprimer
Chaque fois que RMAN crée un fichier dans la zone de récupération rapide, la liste des fichiers
qui ne sont plus nécessaires sur le disque est mise à jour. En fonction de la valeur de
DB_REOVERY_FILE_DEST_SIZE, vous êtes averti lorsque la zone de récupération rapide
manque d'espace ou qu'il reste peu d'espace libre et qu'aucun fichier ne peut être supprimé. Le
serveur de base de données Oracle et RMAN continuent de créer des fichiers dans la zone de
récupération rapide jusqu'à ce que la totalité de l'espace disque alloué soit utilisé.
Lorsque vous définissez le paramètre DB_RECOVERY_FILE_DEST_SIZE, veillez à allouer
suffisamment d'espace pour contenir les fichiers de récupération, y compris les sauvegardes qui
attendent d'être stockées sur bande. Les fichiers qui sont obsolètes ou qui ont été sauvegardés
sur bande peuvent généralement être supprimés pour libérer de l'espace. Si l'écriture d'un fichier
dans la zone de récupération rapide nécessite de l'espace supplémentaire, le serveur de base de
données Oracle supprime un fichier parmi ceux signalés comme obsolètes. Chaque fois qu'un
fichier est écrit ou supprimé dans la zone de récupération rapide, une notification est consignée
dans le fichier d'alertes.
La stratégie de conservation des sauvegardes et la stratégie de suppression des fichiers de
journalisation archivés affectent également la gestion de l'espace dans la zone de récupération
rapide.
Remarque : Lorsque l'espace de la zone de récupération rapide est utilisé à 85 %, un
avertissement est émis. Lorsqu'il est utilisé à 97 %, une alerte critique est générée. Ces seuils
sont définis en interne. Il est impossible de les modifier.

Vous pouvez exécuter l'interrogation suivante pour déterminer l'action à entreprendre :
SQL> SELECT object_type, message_type, message_level,
2 reason, suggested_action
3 FROM dba_outstanding_alerts;
Vous pouvez, au choix, ajouter de l'espace disque supplémentaire, sauvegarder les fichiers sur un
périphérique tiers, supprimer des fichiers de la zone de récupération rapide à l'aide de RMAN ou
envisager de changer de stratégie de conservation RMAN.

Multiplexer les fichiers de contrôle
Pour protéger votre base de données contre les pannes, vous devez
conserver plusieurs copies du fichier de contrôle.
Système de stockage ASM Stockage dans le système
de fichiers
Recom- Une copie sur chaque groupe de Au moins deux copies stockées sur des
mandation disques (+DATA et +FRA, par disques différents (dont au moins une sur
exemple) un contrôleur de disque distinct)
Procédure Aucune copie supplémentaire du 1. Mettez à jour le fichier SPFILE à

à suivre fichier de contrôle n'est requise. l'aide de la commande ALTER
pour créer SYSTEM SET control_files.
des fichiers 2. Arrêtez la base de données.
de contrôle 3. Copiez le fichier de contrôle à un
supplément autre emplacement.
aires 4. Ouvrez la base de données et
vérifiez que le nouveau fichier de
contrôle a été ajouté.
Un fichier de contrôle est un petit fichier binaire qui décrit la structure de la base de données. Il
doit être accessible en écriture par le serveur Oracle chaque fois que la base est montée ou
ouverte. La base de données ne peut pas être montée sans ce fichier. S'il est perdu, il est
nécessaire de le récupérer ou de le recréer. Une base de données doit être dotée d'au moins
deux fichiers de contrôle conservés sur des périphériques de stockage distincts afin de réduire
l'impact de la perte de l'un d'eux.
La perte d'un seul fichier de contrôle entraîne une panne d'instance, car tous les fichiers de
contrôle doivent être disponibles à tout moment. Il suffit toutefois de copier l'un des fichiers de
contrôle encore disponibles pour récupérer l'instance. La perte de tous les fichiers de contrôle
pose un problème plus difficile à résoudre, mais elle n'est généralement pas catastrophique.

Sauvegarde automatique
du fichier de contrôle
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
Méthode recommandée : Oracle recommande d'activer la

sauvegarde automatique du fichier de contrôle.
Vous pouvez utiliser Oracle Enterprise Manager Cloud Control pour définir les paramètres de
sauvegarde d'une instance. Dans la page d'accueil de la base de données, sélectionnez
Availability > Backup & Recovery > Backup Settings.
Pour procéder facilement à une récupération suite à la perte de toutes les copies du fichier de
contrôle, vous devez configurer RMAN afin d'effectuer des sauvegardes automatiques du fichier
de contrôle. La sauvegarde automatique du fichier de contrôle est effectuée indépendamment de
toute sauvegarde du fichier de contrôle en cours demandée de manière explicite dans la
commande de sauvegarde. Si vous utilisez RMAN en mode NOCATALOG, il est vivement conseillé
d'activer la sauvegarde automatique du fichier de contrôle. Sinon, en cas de perte du fichier de
contrôle, votre base de données risque d'être irrécupérable.
Pour configurer la sauvegarde automatique du fichier de contrôle, modifiez la stratégie de
sauvegarde de la base de données via Enterprise Manager ou à l'aide de la commande
CONFIGURE CONTROLFILE AUTOBACKUP ON.
Par défaut, la sauvegarde automatique du fichier de contrôle est désactivée. Si vous l'activez,
RMAN sauvegarde automatiquement le fichier de contrôle et le fichier de paramètres serveur
actuel (s'il est utilisé pour démarrer la base de données) dans les cas suivants :
• A la fin de l'exécution d'un script.
• Lorsqu'une sauvegarde réussie est enregistrée dans le référentiel RMAN.
• En cas de modification structurelle de la base de données (le noyau Oracle effectue la
sauvegarde).

Le nom du fichier de sauvegarde automatique du fichier de contrôle présente le format par défaut %F
pour tous les types de périphérique, de sorte que RMAN peut déduire l'emplacement du fichier et le
restaurer sans référentiel. Ce format de variable correspond à c-IIIIIIIIII-YYYYMMDD-QQ, où :
• IIIIIIIIII représente l'identificateur de la base de données (DBID).
• YYYYMMDD est un horodatage indiquant le jour de génération de la sauvegarde.
• QQ est un numéro de séquence hexadécimal, compris entre 00 et FF.
Pour modifier ce format par défaut, utilisez la commande CONFIGURE CONTROLFILE AUTOBACKUP
FORMAT FOR DEVICE TYPE type TO 'string'. La valeur string doit comprendre la variable de
substitution %F et ne peut en contenir aucune autre. Exemple :
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT
FOR DEVICE TYPE DISK TO '/u01/oradata/cf_ORCL_auto_%F';
Sauf indication contraire, les sauvegardes automatiques du fichier de contrôle sont stockées dans la
zone de récupération rapide.
La sauvegarde automatique du fichier de contrôle permet à RMAN de récupérer la base de données
même si le fichier de contrôle, le catalogue de restauration et le fichier de paramètres serveur
(SPFILE) sont inaccessibles. Etant donné que le chemin utilisé pour stocker la sauvegarde
automatique respecte un format spécifique, RMAN peut rechercher et restaurer le fichier de
paramètres serveur ou le fichier de contrôle à partir de cette sauvegarde automatique.

Recommandation : Multiplexer les fichiers
de journalisation
Multiplexez les groupes de fichiers de journalisation pour
vous prémunir contre les défaillances physiques et la perte
de données. Il s'ensuit une augmentation des E/S de la base.
Suggestion concernant les groupes de fichiers de journalisation :
• Au moins deux membres
(fichiers) par groupe Membre Membre Membre
+DATA a a a
• Chaque membre est :
+FRA
– Sur un disque et un contrôleur Membre Membre Membre
b b b
distincts en cas de stockage
dans un système de fichiers Groupe 1 Groupe 2 Groupe 3
– Dans un groupe de disques distinct (+DATA et +FRA par

exemple) en cas d'utilisation d'ASM
Remarque : Le multiplexage des fichiers de journalisation peut avoir un
impact sur les performances générales de la base de données.
Un groupe de fichiers de journalisation est constitué d'un ou de plusieurs fichiers de

journalisation. Chaque fichier de journalisation d'un groupe est la copie des autres. Oracle
Corporation recommande que chaque groupe de fichiers de journalisation comporte au moins
deux membres. Avec la technique de stockage dans un système de fichiers chaque membre doit
être placé sur un disque ou un contrôleur distinct pour éviter que la défaillance d'un équipement
ne détruise tout un groupe de fichiers de journalisation. Avec la technique de stockage ASM
(Automatic Storage Management), chaque membre doit être placé dans un groupe de disques
distinct, par exemple +DATA et +FRA.
La perte d'un groupe de fichiers de journalisation entier est l'une des défaillances physiques les
plus graves, car elle peut entraîner la perte de données. La perte d'un membre unique d'un
groupe de fichiers de journalisation en comportant plusieurs n'est pas grave et n'affecte pas le
fonctionnement de la base. Elle donne simplement lieu à la publication d'une alerte dans le fichier
d'alertes.
Rappelez-vous que le multiplexage des fichiers de journalisation peut avoir un impact important
sur les performances de la base de données, car aucune validation ne peut être effectuée tant
que les informations relatives à la transaction n'ont pas été écrites dans les fichiers de
journalisation. Placez les fichiers de journalisation sur les disques les plus rapides, gérés par les
contrôleurs les plus rapides. Si possible, ne placez aucun autre fichier de base de données sur
les mêmes disques que les fichiers de journalisation, sauf si vous utilisez ASM. Comme un seul
groupe à la fois est sollicité en écriture, le fait d'avoir des membres de plusieurs groupes sur le
même disque n'a pas d'impact sur les performances.

Multiplexer le fichier de journalisation
Si vous sélectionnez
File System dans le
champ Storage Type,
vous êtes invité à
indiquer un nom de
fichier et un répertoire.
Vous pouvez multiplexer votre fichier de journalisation en ajoutant un membre à un groupe de

journaux existant. Procédez de la manière suivante pour chaque groupe à multiplexer :
1. Sélectionnez Enterprise Manager > Server > Redo Log Groups.
2. Sélectionnez un groupe et cliquez sur le bouton Edit, ou cliquez sur le lien correspondant au
numéro du groupe. La page Edit Redo Log Group apparaît.
3. Dans la région Redo Log Members, cliquez sur Add. La page Add Redo Log Member
apparaît.
4. Choisissez le type de stockage approprié dans le champ Storage Type, puis entrez les
informations requises. Pour le type de stockage ASM (Automatic Storage Management),
choisissez un groupe de disques et précisez éventuellement un modèle et un alias. Pour le
stockage dans le système de fichiers, précisez le nom du fichier et le répertoire. Cliquez sur
Continue.
L'exemple suivant illustre la syntaxe SQL à utiliser pour ajouter un membre au groupe de fichiers
de journalisation 1 (utilisant ASM) :
SQL> ALTER DATABASE ADD LOGFILE MEMBER '+DATA' TO GROUP 1;
Lorsque vous ajoutez le membre au groupe de fichiers de journalisation, le statut du membre est
INVALID (comme l'indique la vue V$LOGFILE). Il s'agit de l'état attendu, car le nouveau membre
du groupe n'a pas encore fait l'objet d'une opération d'écriture. Lorsqu'un changement de fichier
de journalisation se produit et que le groupe contenant le nouveau membre prend le statut
CURRENT, le statut du membre devient NULL.

Créer des fichiers de journalisation archivés
Pour préserver les informations de
journalisation, créez des copies archivées
des fichiers de journalisation en procédant
de la façon suivante :
1. Indiquez la convention d'appellation
des fichiers de journalisation archivés.
2. Indiquez un ou plusieurs
emplacements d'archivage.
3. Placez la base de données en mode
ARCHIVELOG.
Processus
d'archivage
(ARCn)
Fichiers de Fichiers de
journalisation journalisation
en ligne archivés
L'instance considère les groupes de fichiers de journalisation en ligne comme une mémoire
tampon (buffer) réutilisable dans laquelle sont stockées les informations relatives aux
transactions, en remplissant un groupe et en passant au suivant. Une fois que tous les groupes
sont pleins, l'instance commence à remplacer les informations du premier groupe.
Pour configurer la base de données en vue de bénéficier de possibilités de récupération
maximales, vous devez lui ordonner de créer une copie des groupes de fichiers de journalisation
en ligne avant d'autoriser leur remplacement. Ces copies sont appelées fichiers de journalisation
archivés.
Pour faciliter la création de fichiers de journalisation archivés :
1. Indiquez une convention d'appellation pour ces fichiers.
2. Indiquez une ou plusieurs destinations pour le stockage des fichiers de journalisation
archivés.
3. Placez la base de données en mode ARCHIVELOG.
Remarque : Les étapes 1 et 2 ne sont pas nécessaires si vous utilisez une zone de récupération
rapide.
La destination doit exister avant le passage de la base de données au mode ARCHIVELOG. Si
vous indiquez un répertoire comme destination, insérez une barre oblique à la fin de son nom.

Configurer le mode ARCHIVELOG
Pour placer la base de données en mode ARCHIVELOG,

procédez de la manière suivante :
• Avec Enterprise Manager Cloud Control :
1. Cochez la case ARCHIVELOG Mode et cliquez sur Apply. La
base de données ne peut passer au mode ARCHIVELOG
qu'à partir de l'état MOUNT.
2. Redémarrez l'instance de base de données en cliquant sur
Yes à l'invite.
• Avec des commandes SQL :
– Montez la base de données.
– Exécutez la commande ALTER DATABASE ARCHIVELOG.
– Ouvrez la base de données.
Le fait de placer la base de données en mode ARCHIVELOG empêche le remplacement des

fichiers de journalisation tant qu'ils n'ont pas été archivés.
Dans Enterprise Manager Cloud Control, accédez à Availability > Backup & Recovery > Recovery
Settings et cochez la case ARCHIVELOG Mode. Redémarrez ensuite la base de données.
Avant d'exécuter la commande SQL de passage au mode ARCHIVELOG, assurez-vous que la
base est en mode MOUNT. Si la base est ouverte, arrêtez-la proprement (sans effectuer
d'abandon), puis remontez-la.
Si vous utilisez Oracle Restart (dans le cadre d'Oracle Grid Infrastructure), faites appel à l'utilitaire
Server Control pour gérer votre instance de base de données.
Lorsque la base est en mode NOARCHIVELOG (mode par défaut), la récupération peut
uniquement rétablir l'état de la plus récente sauvegarde. Toutes les transactions effectuées
ultérieurement sont perdues.
En mode ARCHIVELOG, il est possible de récupérer la base jusqu'au moment de la dernière
validation d'écriture (commit). La plupart des bases de données de production sont exploitées en
mode ARCHIVELOG.
Remarque : Sauvegardez votre base de données après l'avoir basculée en mode ARCHIVELOG
car elle n'est récupérable qu'à partir de la première sauvegarde effectuée dans ce mode.

Quiz
Quels paramètres de configuration de RMAN régissent la

gestion de l'espace dans la zone de récupération rapide ?
a. RETENTION POLICY
b. BACKUP OPTIMIZATION
c. ARCHIVELOG DELETION POLICY
d. CONTROLFILE AUTOBACKUP
Réponses : a, c

Synthèse

• configurer la zone de récupération rapide pour répondre
à vos besoins en matière de récupération
• configurer le fichier de contrôle pour garantir une
protection appropriée
• configurer les fichiers de journalisation en vue de
la récupération
• configurer le mode ARCHIVELOG et les fichiers de
journalisation archivés en vue de la récupération

• Dans l'exercice 3-1, vous allez :
– configurer ou vérifier la destination et la taille par défaut de
la sauvegarde
– configurer le mode ARCHIVELOG
— configurer la destination des fichiers de journalisation archivés
— placer la base de données en mode ARCHIVELOG
• Dans l'exercice 3-2, vous définirez le format de date
et d'heure pour RMAN.
– sauvegarder automatiquement le fichier de contrôle et
le fichier SPFILE
– vous assurer qu'une seule sauvegarde redondante est
conservée
Remarque : Il est indispensable d'avoir réussi ces exercices pour effectuer tous les autres. A tout
moment du cours, si le formateur et vous-même décidez qu'il vaut mieux repartir avec une
nouvelle base de données, vous devrez réexécuter tous les exercices de ce chapitre.

– configurer des fichiers de contrôle
– utiliser des outils d'administrateur de base de données :
EM Express et SQL*Plus
• Dans l'exercice 3-5, vous étudierez les paramètres de
récupération dans Cloud Control.
• Dans l'exercice 3-6, vous allez configurer des fichiers
de journalisation (dans Cloud Control).
Remarque : Il est indispensable d'avoir réussi ces exercices
pour effectuer tous les autres.
Démonstration (facultative) : Configurer les paramètres
de base de la sauvegarde et de la récupération
d'une base de données dans Cloud Control 12c.
L'utilisation des outils de DBA comprend :

• Utiliser Enterprise Manager Database Express 12 (EM Express) pour afficher les fichiers de
contrôle existants (en tant que SYSDBA).
• Utiliser SQL*Plus et un éditeur pour mettre à jour le paramètre CONTROL_FILES dans le
fichier de paramètres d'initialisation (en tant que SYSDBA).

Utiliser le catalogue de restauration RMAN

Objectifs

• décrire l'utilisation du catalogue de restauration RMAN
• créer le catalogue de restauration RMAN
• enregistrer une base de données dans le catalogue de
restauration RMAN

Stockage des données dans le référentiel RMAN :
Différentes options
Fichier de contrôle : Catalogue de restauration :
• Administration plus simple • Réplique les données du fichier
• Option par défaut de contrôle
• Enregistre un historique plus
étendu des sauvegardes
• Dessert plusieurs cibles
• Contient les scripts RMAN
• Offre davantage d'options de
protection pour les métadonnées
Métadonnées
Liste de jeux de sauvegarde
Liste de copies d'image
.
.
.
Les données du référentiel RMAN sont toujours stockées dans le fichier de contrôle de la base
cible. Toutefois, elles peuvent également être stockées séparément dans un catalogue de
restauration.
Un catalogue de restauration conserve les informations de sauvegarde dans une base de
données distincte, ce qui peut se révéler utile en cas de perte d'un fichier de contrôle. Cela vous
permet de stocker un historique des sauvegardes plus long qu'avec un référentiel basé sur le
fichier de contrôle. Un catalogue de restauration peut stocker des informations concernant
plusieurs bases de données cible. En outre, le catalogue peut contenir des scripts RMAN stockés,
qui sont des séquences de commandes RMAN.
Si vous avez besoin d'effectuer des tâches de gestion de sauvegarde très simples, Oracle vous
recommande d'opter pour le fichier de contrôle plutôt que pour un catalogue de restauration. En
effet, un catalogue de restauration implique la gestion et la sauvegarde
d'une base de données supplémentaire. Par conséquent, utilisez-en un uniquement si ses
avantages vous sont bénéfiques, notamment si vous avez besoin d'une durée de conservation
des sauvegardes plus longue.
Un catalogue de restauration est nécessaire lorsque vous utilisez RMAN dans une configuration
Data Guard.

Stocker des informations dans le catalogue
de restauration
Recovery
Manager
(RMAN)
Structure de la base
de données
Fichier de contrôle Fichiers de journalisation Base de données
archivés
de la base cible du catalogue
Jeux de sauvegarde
de restauration
Copies des fichiers
de données
Après n'importe quelle opération mettant à jour le référentiel, ainsi qu'avant certaines opérations,
RMAN propage dans le catalogue de restauration des informations concernant la structure de la
base de données, les fichiers de journalisation archivés (archived redo logs), les jeux de
sauvegarde et les copies des fichiers de données, à partir du fichier de contrôle de la base cible.

Avantages d'un catalogue de restauration
• Peut stocker plus d'informations historiques que le fichier

de contrôle
• Permet d'utiliser des scripts stockés RMAN
• Permet de créer des rapports personnalisés pour toutes
les cibles enregistrées
• Permet d'utiliser la clause KEEP FOREVER clause de la
commande BACKUP
• Permet de répertorier les fichiers de données et
tablespaces figurant dans la base de données ou qui y
figuraient à un instant donné
• Facilite considérablement la restauration et la récupération
après une perte du fichier de contrôle, grâce à la
préservation des métadonnées du référentiel RMAN
Il est possible de n'utiliser que le fichier de contrôle comme référentiel RMAN, mais il dispose d'un
espace limité pour les enregistrements d'activités de sauvegarde. Lorsque vous utilisez un
catalogue de restauration, vous pouvez stocker un historique de sauvegardes bien plus long.
Cela vous permet d'effectuer une récupération jusqu'à un point dans le temps plus éloigné
qu'avec le fichier de contrôle.
Pour pouvoir utiliser des scripts stockés RMAN, vous devez recourir à un catalogue de
restauration.
Lorsque vous utilisez un catalogue de restauration, les informations de sauvegarde et de
récupération de toutes les cibles enregistrées figurent dans un même emplacement. Vous pouvez
créer des rapports personnalisés en vous connectant en tant que propriétaire du catalogue et en
interrogeant les différentes vues RC_. Si vous n'utilisez pas de catalogue de restauration, vous
devez vous connecter séparément à chaque instance de base de données cible et interroger les
vues V$ appropriées pour obtenir les informations RMAN à partir du fichier de contrôle de la cible.
Remarque : Enterprise Manager Cloud Control permet également de consulter les informations
de sauvegarde de plusieurs bases de données sans utiliser de catalogue de restauration.
Vous pouvez utiliser la commande BACKUP ... KEEP pour créer une sauvegarde qui est
conservée pendant une période différente de celle qui est indiquée par la stratégie de
conservation configurée. La clause KEEP FOREVER indique que la sauvegarde ou la copie
n'expire jamais et nécessite l'utilisation d'un catalogue de restauration pour que les
enregistrements de sauvegarde puissent être conservés indéfiniment.

La commande REPORT SCHEMA répertorie les tablespaces et les fichiers de données de la base
cible. Si vous ajoutez l'option AT [time|scn|logseq], vous pouvez consulter ces informations à
un instant du passé. Toutefois, l'option AT n'est disponible que si vous utilisez un catalogue de
restauration.

Créer le catalogue de restauration : Trois étapes
Configurez la base Créez le

de données du propriétaire du Créez le catalogue
catalogue de catalogue de de restauration.
restauration. restauration.
Pour créer un catalogue de restauration, effectuez les trois opérations suivantes :

1. Configurez la base de données où vous souhaitez que le catalogue de restauration soit
stocké.
2. Créez le propriétaire du catalogue de restauration.
3. Créez le catalogue de restauration.

Configurer la base de données du catalogue
de restauration
• Allouez de l'espace pour le catalogue de restauration.
Prenez en compte :
– Nombre de bases de données prises en charge par le
catalogue de restauration
– le nombre de fichiers de journalisation archivés et de
sauvegardes enregistrés
– l'utilisation de scripts stockés RMAN
• Créez un tablespace pour le catalogue de restauration.
Il deviendra le tablespace par défaut du propriétaire du
catalogue.
SQL> CREATE TABLESPACE rcat_ts DATAFILE <data file name>
SIZE 15M;
Déterminez la base de données dans laquelle vous allez installer le schéma du catalogue de
restauration. Prenez soin d'implémenter des procédures de sauvegarde et de récupération
appropriées pour cette base.
L'espace requis par le schéma du catalogue de restauration dépend du nombre de bases de
données surveillées par ce catalogue. Cet espace augmente en même temps que le nombre de
fichiers de journalisation archivés et de sauvegardes pour chaque base. Si vous utilisez des
scripts stockés RMAN, vous devez leur allouer de l'espace. Chaque base de données enregistrée
dans le catalogue de restauration requiert généralement 15 Mo d'espace.

Créer le propriétaire du catalogue de restauration
• Créez le propriétaire du catalogue de restauration.

• Octroyez-lui le rôle RECOVERY_CATALOG_OWNER.
SQL> CREATE USER rcowner IDENTIFIED BY rcpass

2 TEMPORARY TABLESPACE temp
3 DEFAULT TABLESPACE rcat_ts
4 QUOTA UNLIMITED ON rcat_ts;
SQL> GRANT recovery_catalog_owner TO rcowner;
Créez un utilisateur destiné à être le propriétaire du catalogue de restauration. Indiquez comme

tablespace par défaut de cet utilisateur le tablespace que vous avez créé pour le catalogue de
restauration. Accordez à cet utilisateur un quota UNLIMITED sur ce tablespace. Après avoir créé
l'utilisateur, octroyez-lui le rôle RECOVERY_CATALOG_OWNER.
Ce rôle fournit les privilèges système requis au propriétaire du catalogue de restauration,
à savoir : ALTER SESSION, CREATE CLUSTER, CREATE DATABASE LINK, CREATE PROCEDURE,
CREATE SEQUENCE, CREATE SESSION, CREATE SYNONYM, CREATE TABLE, CREATE TRIGGER,
CREATE TYPE et CREATE VIEW.
Pour créer l'utilisateur et lui octroyer le rôle de propriétaire du catalogue, vous pouvez utiliser des
commandes SQL ou bien Enterprise Manager.

Créer le catalogue de restauration
• Connectez-vous à la base de données du catalogue de

restauration en tant que propriétaire du catalogue :
$ rman
RMAN> CONNECT CATALOG username/password@net_service_name
• Exécutez la commande CREATE CATALOG :
RMAN> CREATE CATALOG;
Après avoir créé le propriétaire du catalogue, exécutez la commande RMAN CREATE CATALOG
pour créer les tables du catalogue dans le tablespace par défaut du propriétaire du catalogue.
Remarque : Comme pour toute base de données, si la valeur de la variable d'environnement
ORACLE_SID est le SID de la base de données du catalogue, il est inutile d'indiquer le nom du
service dans l'instruction CONNECT.

Gérer les enregistrements des bases de données
cible dans le catalogue de restauration
• Enregistrer une base de données cible dans le catalogue
de restauration
• Enregistrer des fichiers de sauvegarde supplémentaires
dans le catalogue
• Annuler l'enregistrement d'une base de données cible
dans le catalogue de restauration
La plupart des informations sont propagées automatiquement du fichier de contrôle vers le

catalogue de restauration, mais il est parfois nécessaire d'exécuter quelques opérations pour
gérer les enregistrements des bases de données cible dans le catalogue.

Enregistrer une base de données dans
le catalogue de restauration
• RMAN effectue les opérations suivantes quand une base de données
est enregistrée :
– Il crée des lignes dans les tables du catalogue de restauration pour
la base de données cible
– Il copie les données du fichier de contrôle de la base cible dans les tables
du catalogue de restauration
– Il synchronise le catalogue de restauration avec le fichier de contrôle
• Enregistrer une base de données à l'aide de la ligne de commande
RMAN :
$ rman TARGET / CATALOG
username/password@net_service_name
RMAN> REGISTER DATABASE;
• Enregistrer une base de données à l'aide d'Enterprise Manager :
1. Accédez à la page Recovery Catalog Settings.
2. Ajoutez le catalogue de restauration à la configuration s'il n'y figure pas
déjà.
3. Indiquez la base de données cible utilisant le catalogue de restauration.
Après avoir créé le catalogue de restauration, vous devez y enregistrer les bases de données
cible.
Vous pouvez effectuer cette opération à partir de la ligne de commande RMAN en procédant de
la manière suivante :
1. Appelez RMAN et connectez-vous à la base de données du catalogue de restauration et à
la base de données cible. Par exemple :
% rman TARGET / CATALOG rman/rman@reccatdb
2. Assurez-vous que la base cible est montée ou ouverte.
3. Exécutez la commande REGISTER pour enregistrer la base de données cible dans le
catalogue de restauration :
RMAN> REGISTER DATABASE;
Dans Enterprise Manager, pour enregistrer une base de données dans un catalogue de
restauration, vous devez d'abord ajouter le catalogue à la configuration EM. Exécutez Enterprise
Manager sur la base de données cible et sélectionnez ce catalogue comme étant celui de la base
cible.
Si vous utilisez RMAN pour enregistrer la base de données et n'effectuez pas les opérations
indiquées sur la diapositive dans Enterprise Manager, les opérations de sauvegarde et de
récupération effectuées à l'aide d'Enterprise Manager n'utiliseront pas le catalogue de
restauration. Par conséquent, même si vous avez exécuté la commande RMAN REGISTER
DATABASE, effectuez aussi les opérations d'enregistrement dans Enterprise Manager si vous
envisagez de l'utiliser.

Procédez de la manière suivante dans Enterprise Manager Cloud Control pour enregistrer votre
base de données :
1. Dans la page d'accueil Enterprise Manager de la base de données, sélectionnez Availability >
Backup & Recovery > Recovery Catalog Settings.
2. Cliquez sur Add Recovery Catalog pour indiquer l'hôte, le port et le SID d'une base de
données contenant un catalogue de restauration existant.
3. Après avoir défini la base de données du catalogue de restauration, sélectionnez "Use
Recovery Catalog" dans la page Recovery Catalog Settings pour enregistrer la base dans la
base de données du catalogue de restauration. Lorsque vous cliquez sur OK, la base de
données est enregistrée dans le catalogue.

Supprimer une base de données cible dans
le catalogue de restauration
• Cette opération supprime du catalogue de restauration les
informations concernant une base de données cible.
• Utilisez-la lorsque vous ne voulez plus qu'une base cible
spécifique soit définie dans le catalogue de restauration.
$ rman TARGET / CATALOG

username/password@net_service_name
RMAN> UNREGISTER DATABASE;
Lorsque vous annulez l'enregistrement d'une base de données du catalogue de restauration, tous
les enregistrements correspondants du référentiel RMAN figurant dans ce catalogue sont
supprimés. Vous pouvez ré-enregistrer la base de données. Les enregistrements du catalogue
concernant cette base sont alors fondés sur le contenu du fichier de contrôle au moment du
nouvel enregistrement.
En règle générale, vous annulez l'enregistrement d'une base de données cible si vous ne
souhaitez plus utiliser le catalogue de restauration pour celle-ci ou si la base de données n'existe
plus.
Remarque : Si vous avez utilisé Enterprise Manager Cloud Control pour enregistrer votre base
de données, vous devez l'utiliser aussi pour annuler l'enregistrement.

Resynchronisation du catalogue
de restauration : Concepts
Partielle : Fichiers de journalisation archivés
Jeux de sauvegarde
Copies des fichiers de données
Fichier de contrôle Catalogue de restauration

de la base cible
Complète : Partielle + structure de la base de données

Cliché du
fichier de contrôle
Lorsque RMAN effectue une resynchronisation, il compare le catalogue de restauration avec le

fichier de contrôle actuel de la base de données cible, ou avec un fichier de contrôle de
sauvegarde/secours, puis il le met à jour avec les informations manquantes ou modifiées.
Une resynchronisation peut être partielle ou complète.
• Dans le cas d'une resynchronisation partielle, RMAN compare le fichier de contrôle au
catalogue de restauration, puis il met à jour ce dernier avec toutes les métadonnées
concernant les sauvegardes, les fichiers de journalisation archivés, les copies des fichiers
de données, etc.
• Dans le cas d'une resynchronisation complète, RMAN crée d'abord un cliché (snapshot),
c'est-à-dire une copie temporaire, du fichier de contrôle. Il utilise ensuite ce cliché pour
établir une comparaison avec le catalogue de restauration. Cette comparaison (et les mises
à jour qui en découlent éventuellement) traite les mêmes données que lors d'une
resynchronisation partielle, mais inclut également les aspects structurels de la base de
données. Par exemple, les modifications de schéma et les nouveaux tablespaces ne sont
pris en compte que dans une resynchronisation complète.
Vous pouvez préciser l'emplacement du cliché de fichier de contrôle à l'aide du paramètre de
configuration SNAPSHOT CONTROLFILE NAME. Le nom de fichier par défaut du cliché de fichier de
contrôle dépend de la plate-forme et donc du répertoire d'origine Oracle home de chaque base de
données cible. Dans une configuration Oracle RAC, le cliché du fichier de contrôle doit
obligatoirement être accessible par toutes les instances de la configuration.

Pour plus d'informations sur la configuration de l'emplacement des clichés de fichier de contrôle
dans une configuration RAC, reportez-vous au manuel Oracle Real Application Clusters
Administration and Deployment Guide.
Si les seules modifications apportées au fichier de contrôle sont les enregistrements régis par le
paramètre CONTROL_FILE_RECORD_KEEP_TIME, une resynchronisation partielle est effectuée.
Sinon, une resynchronisation complète est mise en oeuvre. La commande RESYNC CATALOG
génère également une resynchronisation complète.

Resynchroniser manuellement le catalogue
de restauration
Resynchronisez manuellement le catalogue de restauration
dans les cas suivants :
• Le catalogue de restauration n'est pas disponible pour
une resynchronisation automatique par RMAN.
• Vous effectuez des sauvegardes peu fréquentes de
la base de données cible.
• Vous avez apporté des modifications à la structure
physique de la base de données cible.
RMAN> RESYNC CATALOG;
Procédez à une resynchronisation manuelle du catalogue de restauration dans les cas suivants :
• Le catalogue de restauration n'était pas disponible lorsque vous avez exécuté des
commandes RMAN et une resynchronisation partielle a eu lieu.
• Vous effectuez des sauvegardes peu fréquentes de la base de données cible. Le catalogue
de restauration n'est donc pas mis à jour automatiquement lors des basculements et des
archivages des fichiers de journalisation.
• Vous avez apporté des modifications à la structure physique de la base de données cible.
Remarque : Pour plus d'informations sur les enregistrements mis à jour pendant une
resynchronisation, reportez-vous au manuel Backup and Recovery User's Guide.

Utiliser des scripts stockés RMAN
Scripts stockés :
• Ils constituent une alternative aux fichiers de commandes.
• Ils sont à la disposition de n'importe quel client RMAN qui peut
se connecter à la base de données cible et au catalogue de
restauration. CREATE SCRIPT script_name
• Ils peuvent être de deux types : { <RMAN commands>}
– Script local : Lors de sa création,
il est rattaché à la base de données cible à laquelle RMAN est
connecté. CREATE GLOBAL SCRIPT script_name
– Script global : Il peut être { <RMAN commands> }
exécuté sur n'importe quelle base de données enregistrée dans
le catalogue de restauration.
• Ils peuvent être créés à partir d'un fichier texte (option additionnelle).
CREATE [GLOBAL] SCRIPT script_name FROM FILE 'file_name';
Vous pouvez utiliser des scripts stockés RMAN (plutôt que des fichiers de commandes) pour
gérer des séquences de commandes RMAN utilisées fréquemment. Contrairement aux fichiers de
commandes qui sont disponibles uniquement sur le système où ils se trouvent, les scripts stockés
sont accessibles à tout client RMAN capable de se connecter à la base de données cible et au
catalogue de restauration.
Les scripts stockés sont soit globaux, soit locaux. Lorsqu'un script stocké local est créé, il est
associé à la base de données cible à laquelle RMAN est connecté. Il ne peut être exécuté que
lorsque vous êtes connecté à cette base. Un script stocké global peut être exécuté sur n'importe
quelle base de données enregistrée dans le catalogue de restauration. Il suffit que le client RMAN
soit connecté au catalogue de restauration et à la base cible.
Créer des scripts stockés RMAN
Pour créer un script stocké, connectez-vous à la base de données cible et au catalogue de
restauration, puis exécutez la commande CREATE SCRIPT.

Exécuter des scripts stockés RMAN
• Pour exécuter un script :

RUN { EXECUTE SCRIPT
script_name
; }
• Pour exécuter un script global :

RUN { EXECUTE GLOBAL SCRIPT
script_name
; }
Pour exécuter un script stocké, connectez-vous à la base de données cible et au catalogue de

restauration, puis entrez la commande EXECUTE SCRIPT. Notez que la commande EXECUTE
SCRIPT requiert un bloc RUN. Si une commande RMAN du script échoue, les commandes RMAN
suivantes du script ne sont pas exécutées.
Lorsque vous exécutez un script, ce dernier utilise les canaux automatiques configurés. Utilisez
des commandes ALLOCATE CHANNEL dans le script si vous souhaitez remplacer
les canaux configurés, comme dans l'exemple suivant :
RMAN> RUN
{
ALLOCATE CHANNEL ch1 DEVICE TYPE DISK;
EXECUTE SCRIPT full_backup;
}

Gérer les scripts RMAN stockés
• Pour afficher un script :
PRINT [GLOBAL] SCRIPT script_name;
• Pour transférer le contenu d'un script vers un fichier :
PRINT [GLOBAL] SCRIPT script_name TO FILE 'file_name';
• Pour afficher les noms des scripts définis :
LIST [GLOBAL] SCRIPT NAMES;
• Pour mettre à jour un script :
REPLACE [GLOBAL] SCRIPT script_name
{ <RMAN commands> ; }
• Pour mettre à jour un script à partir d'un fichier :
REPLACE [GLOBAL] SCRIPT script_name FROM FILE
'file_name';
• Pour supprimer un script :
DELETE SCRIPT script_name;
Pour afficher un script stocké ou l'écrire dans un fichier, connectez-vous à la base de données
cible et au catalogue de restauration, puis lancez la commande PRINT SCRIPT.
Utilisez la commande LIST SCRIPT NAMES pour afficher les noms des scripts définis dans le
catalogue de restauration. Cette commande affiche les noms de tous les scripts stockés (scripts
globaux et scripts locaux) qui peuvent être exécutés pour la base cible à laquelle vous êtes
connecté.
Pour mettre à jour un script stocké, connectez-vous à la base de données cible et au catalogue
de restauration, puis lancez la commande REPLACE SCRIPT. RMAN crée le script s'il n'existe
pas.
Pour supprimer un script stocké du catalogue de restauration, connectez-vous au catalogue et à
une base de données cible, puis utilisez la commande DELETE SCRIPT.

Sauvegarder le catalogue de restauration
Recovery
Manager
(RMAN)
Catalogue de restauration
Fichier de contrôle
Le catalogue de restauration est un schéma au sein d'une base de données Oracle. Il est
important de sauvegarder la base de données du catalogue de restauration et Oracle
recommande d'utiliser RMAN à cet effet. Ne stockez jamais le catalogue de restauration
contenant le référentiel RMAN d'une base de données cible dans cette même base ou sur le
même disque que cette base. En effet, un catalogue de restauration n'est efficace que s'il est
stocké à un endroit distinct des données qu'il est censé protéger.
Configurez la sauvegarde automatique du fichier de contrôle de sorte que ce dernier soit
enregistré à chaque sauvegarde du catalogue de restauration. Chaque fois que vous effectuez
une sauvegarde dans la base de données cible, sauvegardez le catalogue de restauration juste
après. L'enregistrement de la dernière sauvegarde est ainsi protégé.
Voici un résumé de la configuration du catalogue de restauration pour la sauvegarde et la
récupération :
• Configurez le mode ARCHIVELOG.
• Attribuez à la stratégie de conservation une valeur REDUNDANCY supérieure à 1.
• Sauvegardez le catalogue de restauration sur disque et sur bande.
• Pour effectuer les sauvegardes, utilisez la commande BACKUP DATABASE PLUS
ARCHIVELOG.
• Utilisez comme référentiel RMAN le fichier de contrôle (NOCATALOG), et non un autre
• Activez la sauvegarde automatique du fichier de contrôle (ON).

Créer et utiliser des catalogues privés virtuels
Bases de données enregistrées dans le catalogue RMAN
Catalogue Amélioration de la sécurité

de base par limitation de l'accès
RMAN aux métadonnées
Catalogues privés virtuels
Les catalogues privés virtuels (VPC) permettent de consolider les référentiels RMAN. Ils
permettent aussi de séparer les responsabilités, ce qui est une condition de base pour assurer la
sécurité.
Le catalogue RMAN inclut la possibilité de créer des catalogues privés virtuels (VPC) pour des
groupes de bases de données et d'utilisateurs. Dans Oracle Database 12c Release 1 (12.1.0.2) le
catalogue de restauration RMAN est créé et géré à l'aide d'Oracle Virtual Private Database
(VPD), ce qui améliore les performances et l'évolutivité dans le cas d'un grand nombre de
catalogues privés virtuels.
Le propriétaire du catalogue peut accorder l'accès à une base de données enregistrée et octroyer
le privilège REGISTER au propriétaire du catalogue virtuel. Le propriétaire du catalogue virtuel
peut alors se connecter à ce catalogue pour une cible particulière ou enregistrer une base de
données cible. Après cette configuration, le catalogue privé virtuel peut être utilisé par son
propriétaire comme un catalogue de base standard.
Le propriétaire du catalogue peut accéder à toutes les informations concernant les bases de
données enregistrées dans le catalogue. Vous pouvez obtenir la liste de ces bases à l'aide de la
commande SQL*Plus suivante :
SELECT DISTINCT db_name FROM DBINC;
Le propriétaire d'un catalogue virtuel voit uniquement les bases de données auxquelles l'accès lui
a été accordé.
Remarque : Si le rôle SYSDBA ou SYSOPER n'a pas été octroyé au propriétaire du catalogue sur
la base de données cible, la plupart des opérations RMAN ne peuvent pas être effectuées.

Créer un catalogue privé virtuel (12.1.0.1)
1. Créez le propriétaire du catalogue privé virtuel (VPC) et accordez
des privilèges à l'utilisateur.
A. Dans SQL*Plus, connectez-vous à la base de données du
B. Créez le propriétaire du catalogue privé virtuel.
C. Accordez le rôle RECOVERY_CATALOG_OWNER à cet utilisateur.
D. Utilisez RMAN pour vous connecter au catalogue de restauration
en tant que propriétaire du catalogue de base.
E. Octroyez des privilèges au propriétaire du catalogue privé virtuel
(accès aux métadonnées, capacité d'enregistrer de nouvelles
bases cible).
2. Créez le catalogue privé virtuel.
A. Utilisez RMAN pour vous connecter au catalogue de restauration
en tant que propriétaire du catalogue privé virtuel.
B. Créez le catalogue privé virtuel à l'aide de la commande CREATE
VIRTUAL CATALOG.
La procédure à suivre pour créer un catalogue privé virtuel est variable selon que vous utilisez
Oracle Database 12c Release 1 version 12.1.0.1 ou version 12.1.0.2. Les étapes décrites dans
cette page s'appliquent à la version 12.1.0.1. Reportez-vous au manuel Oracle Database Backup
and Recovery User's Guide 12c Release 1 (12.1) pour obtenir des informations plus détaillées et
des exemples de syntaxe.

Gérer des catalogues privés virtuels
• Si nécessaire, supprimez l'accès aux métadonnées :
RMAN> REVOKE CATALOG FOR DATABASE prod1 FROM vpc1;
• Pour supprimer un catalogue privé virtuel :
RMAN> DROP CATALOG;
Pour supprimer l'accès à une base spécifique, connectez-vous à la base de données

du catalogue de restauration en tant que propriétaire de celui-ci :
RMAN> REVOKE CATALOG FOR DATABASE prod1 FROM vpc1;
Pour supprimer un catalogue privé virtuel, connectez-vous à la base de données
du catalogue de restauration en tant que propriétaire du catalogue privé virtuel :
RMAN> DROP CATALOG;

1. Créez le propriétaire du catalogue privé virtuel (VPC)

et accordez des privilèges à l'utilisateur.
A. Dans SQL*Plus, connectez-vous à la base de données du
B. Créez le propriétaire du catalogue privé virtuel.
C. Accordez le privilège CREATE SESSION à cet utilisateur.
D. Utilisez RMAN pour vous connecter au catalogue de
restauration en tant que propriétaire du catalogue de base.
E. Octroyez des privilèges au propriétaire du catalogue privé
virtuel (accès aux métadonnées, capacité d'enregistrer de
nouvelles bases cible).
Dans Oracle Database 12c Release 1 (12.1.0.2), les catalogues privés virtuels sont implémentés
via Oracle Virtual Private Database (VPD). VPD fourni la possibilité de créer
des stratégies de sécurité pour contrôler l'accès aux bases de données au niveau ligne et au
niveau colonne. Pour plus d'informations sur Oracle VPD, reportez-vous au manuel Oracle
Database Security Guide 12c Release 1 (12.1).
Les étapes décrites sur cette page et la suivante s'appliquent à la version 12.1.0.2. Reportez-vous
au manuel Oracle Database Backup and Recovery User’s Guide12c Release 1 (12.1) pour
obtenir des informations plus détaillées et des exemples de syntaxe.

2. Enregistrez une base de données auprès d'un catalogue

privé virtuel (VPC) pour y stocker les métadonnées de
sauvegarde.
A. A l'aide de RMAN, connectez-vous à la base de données
du catalogue de restauration en tant que propriétaire du
VPC et connectez-vous à la base de données que vous
souhaitez enregistrer comme cible.
B. Enregistrez la base de données auprès du propriétaire
du VPC à l'aide de la commande REGISTER DATABASE.
C. Utilisez la commande BACKUP pour sauvegarder la base de
données et stocker les métadonnées correspondantes dans
le VPC.

Mettre à niveau les catalogues privés virtuels
pour la version 12.1.0.2
1. Utilisez SQL*Plus pour vous connecter à la base de données
du catalogue de restauration en tant qu'utilisateur SYS doté
du privilège SYSDBA.
2. Octroyez des privilèges supplémentaires au rôle
RECOVERY_CATALOG_OWNER en exécutant le script
$ORACLE_HOME/rdbms/admin/dbmsrmansys.sql.
3. Utilisez RMAN pour vous connecter au catalogue de
restauration de base et le mettre à niveau à l'aide de la
commande UPGRADE CATALOG.
4. Utilisez SQL*Plus pour vous connecter de nouveau à la base
de données du catalogue de restauration en tant
qu'utilisateur SYS doté du privilège SYSDBA.
5. Mettez à niveau les schémas de catalogue privé virtuel vers
le modèle VPD en exécutant le script
$ORACLE_HOME/rdbms/admin/dbmsrmanvpc.sql.
A partir de la version Oracle Database 12c Release 1 (12.1.0.2), RMAN utilise Oracle Virtual
Private Database (VPD) pour implémenter des catalogues privés virtuels. Si vous avez créé un
catalogue de restauration et des catalogues privés virtuels dans une version antérieure, vous
devez procéder à leur mise à niveau vers VPD comme indiqué dans la diapositive. Vous
trouverez des exemples de syntaxe dans le manuel Oracle Database Backup and Recovery
User’s Guide12c Release 1 (12.1).

Quiz
Une fois qu'une base de données est enregistrée dans un

catalogue de restauration, RMAN ne stocke plus d'informations
dans le fichier de contrôle de la base de données.
a. Vrai
b. Faux
Réponse : b

Quiz
Sélectionnez les étapes à accomplir en vue d'utiliser un

catalogue de restauration pour une base de données spécifique.
a. Créez le schéma du catalogue de restauration dans
la base de données concernée.
b. Enregistrez la base de données dans le catalogue
de restauration.
c. Copiez le fichier de contrôle de la base de données vers
la base du catalogue de restauration.
Réponse : b

Synthèse

• décrire l'utilisation du catalogue de restauration RMAN
• créer le catalogue de restauration RMAN
• enregistrer une base de données dans le catalogue de
restauration RMAN

Utiliser le catalogue RMAN
– créer le propriétaire du catalogue de restauration
– octroyer des privilèges au propriétaire du catalogue
de restauration
• Dans l'exercice 4-2, vous allez créer le catalogue
de restauration RMAN.
• Dans l'exercice 4-3, vous enregistrerez la base de données
orcl dans le catalogue de restauration.
• L'exercice 4-4 consiste à configurer Enterprise Manager
pour le catalogue RMAN.
– configurer le catalogue de restauration pour la récupération
– sauvegarder la base de données RCAT
1. Dans cette série d'exercices, vous commencez par créer un utilisateur et vous lui octroyez
les privilèges appropriés.
2. Ensuite, vous créez le catalogue de restauration RMAN dans une base de données prévue
à cet effet dans votre environnement de cours.
3. L'exercice suivant consiste à enregistrer la base de données ORCL dans le catalogue
de restauration que vous venez de créer.
4. Pour finir, vous configurez le mode ARCHIVELOG, vous définissez la stratégie de
conservation du catalogue de restauration et vous sauvegarder la base de données
de ce dernier en utilisant la stratégie de sauvegarde des sauvegardes incrémentielles
appliquées aux copies d'image. Cette méthode garantit une restauration rapide en basculant
vers la copie d'image au lieu de copier les sauvegardes vers l'emplacement d'origine.

Préparer l'environnement de formation
• L'exercice 4-6 vous apprend à préparer votre
environnement de formation en effectuant une sauvegarde
à froid (base fermée) de la base de données ORCL.
Vous devez préparer votre environnement de formation en effectuant une sauvegarde à froid de
la base de données ORCL. Cette sauvegarde vous permettra de restaurer la base de données si
vous n'arrivez pas à exécuter correctement les exercices à venir.

Stratégies de sauvegarde et terminologie associée

Objectifs

• décrire les solutions de sauvegarde Oracle
• décrire les types de sauvegarde RMAN
• décrire et comparer les stratégies de sauvegarde
et déterminer la vôtre
• planifier des sauvegardes conformément à votre stratégie
• effectuer des sauvegardes totales
Vous abordez le premier chapitre du module "Sauvegarde" qui en comprend quatre au total,
à savoir :
• Chapitre 5 : Stratégies de sauvegarde et terminologie associée
• Chapitre 6 : Réaliser des sauvegardes
• Chapitre 7 : Améliorer des sauvegardes
• Chapitre 8 : Utiliser les sauvegardes RMAN cryptées

Solutions de sauvegarde : Présentation
Fichiers de
Sauvegarde gérée Zone de Copies d'image
données
par l'utilisateur récupération
rapide ou
autres zones Eléments de sauvegarde
Fichiers de sur disque
journalisation RMAN
archivés Données de sauvegarde
Sauvegarde
sur disque Sauvegarde
avec un
Fichier de Sauvegarde dans RMAN gestionnaire
de support
contrôle le canal SBT tiers
BdD cible
Gestion des supports
(Exemple : Oracle Secure Backup)
Oracle Sauvegarde sur bande
Secure
Fichiers non BdD
Backup
Recovery Manager (RMAN) est l'outil recommandé pour sauvegarder une base de données
Oracle. Il permet d'effectuer des sauvegardes sur disque ou dans un canal de type SBT (System
Backup to Tape, sauvegarde sur bande de systèmes). Oracle conseille de stocker les
sauvegardes sur disque dans la zone de récupération rapide (FRA, Fast Recovery Area).
Oracle Secure Backup complète les fonctionnalités existantes en permettant la sauvegarde sur
bande et la sauvegarde des données du système de fichiers. Il interagit avec RMAN de manière
transparente. Des gestionnaires de support tiers peuvent aussi être utilisés pour les sauvegardes
sur bande.
Les sauvegardes gérées par l'utilisateur sont effectuées en dehors de RMAN, par exemple à
l'aide d'un utilitaire du système d'exploitation. Elles sont souvent basées sur des scripts écrits par
un DBA. Cette option est en cours d'abandon car elle exige davantage de travail.

Terminologie associée à la sauvegarde
• Une stratégie de sauvegarde peut englober :
– Une base de données entière (sauvegarde totale)
– Une partie d'une base de données (sauvegarde
partielle)
• Un type de sauvegarde peut indiquer l'inclusion
des élément suivants :
– Tous les blocs de données des fichiers choisis (sauvegarde complète)
– Uniquement les informations qui ont subi des modifications depuis une
sauvegarde précédente (sauvegarde incrémentielle)
— Sauvegarde cumulative (modifications depuis le dernier niveau 0)
— Sauvegarde différentielle
(modifications depuis la dernière

sauvegarde incrémentielle)
• Le mode de sauvegarde peut être : Fichiers
de
Fichiers de
journalisation
contrôle
– Base fermée (sauvegarde Fichiers en ligne
de données
cohérente, à froid)
– Base ouverte (sauvegarde non cohérente, à chaud)
• Sauvegarde totale de la base de données : Elle inclut tous les fichiers de données et au
moins un fichier de contrôle. (Souvenez-vous que tous les fichiers de contrôle d'une base de
données sont identiques.)
• Sauvegarde partielle de la base de données : Elle peut inclure certains tablespaces et
fichiers de données, voire un fichier de contrôle.
• Sauvegarde complète : Copie de chaque bloc contenant des données et appartenant aux
fichiers soumis à la sauvegarde.
• Sauvegarde incrémentielle : Copie de tous les blocs de données qui ont subi des
modifications depuis une précédente sauvegarde. La base de données Oracle prend en
charge deux niveaux de sauvegarde incrémentielle (0 et 1). Une sauvegarde incrémentielle
de niveau 1 peut être cumulative ou différentielle. Une sauvegarde cumulative enregistre
toutes les modifications effectuées depuis la dernière sauvegarde de niveau 0. Une
sauvegarde différentielle conserve toutes les modifications effectuées depuis la dernière
sauvegarde incrémentielle (niveau 0 ou niveau 1). Le suivi des modifications effectué par
RMAN prend en charge les sauvegardes incrémentielles.
• Sauvegarde hors ligne (aussi appelée "sauvegarde à froid", "sauvegarde base fermée" ou
"sauvegarde cohérente") : Il s'agit d'une sauvegarde effectuée lorsque la base de données
est fermée. Elle est cohérente parce qu'au moment de sa création, le numéro SCN figurant
dans les en-têtes de fichier de données correspond à celui des fichiers de contrôle.
• Sauvegarde en ligne (aussi appelée "sauvegarde à chaud", "sauvegarde base ouverte" ou
"sauvegarde incohérente") : Il s'agit d'une sauvegarde effectuée lorsque la base de données
est ouverte. Ces sauvegardes sont incohérentes car, lorsque la base est ouverte, il n'est pas
certain que les fichiers de données soient synchronisés avec les fichiers de contrôle.

Equilibrer les besoins de sauvegarde et de récupération
Point à considérer Impact sur les performances
Stratégie de sauvegarde • Améliore les performances de sauvegarde, mais avec un effet négatif sur
incrémentielle les performances de récupération.
• Suivi des modifications de bloc pour des sauvegardes incrémentielles plus
rapides.
• Sauvegardes incrémentielles, cumulatives et différentielles.
• L'option de "sauvegarde incrémentielle à vie" nécessite une sauvegarde
complète au départ.
Multiplexage • Sauvegarde des fichiers en parallèle par canal pour améliorer les
performances.
• Niveau de multiplexage = min (FILESPERSET, MAXOPENFILES). Définissez
MAXOPENFILES = 1 pour les fichiers de données SAME ou ASM.
• Définissez un nombre de canaux RMAN égal au nombre d'unités de bande.
Matériel/Réseau/ • Evaluez les ressources en termes d'hôtes, d'E/S disque en situation de

Stockage production, de réseau/HBA et de débit des unités de bande.
• Toute déficience au niveau de ces composants se traduit par une dégradation
des performances.
Stratégie de sauvegarde incrémentielle

Les sauvegardes incrémentielles prennent généralement moins d'espace que les sauvegardes
complètes et leur création est normalement plus rapide. Il est en principe plus rapide de récupérer
une base à partir de sauvegardes incrémentielles qu'en appliquant des fichiers de journalisation à
une sauvegarde initiale.
En mettant des sauvegardes à jour de façon incrémentielle, vous pouvez éviter le travail qui
consiste à effectuer des copies d'image complètes, mais aussi réduire le temps nécessaire à la
récupération matérielle de la base de données.
La fonctionnalité de suivi des modifications de blocs associée aux sauvegardes incrémentielles
peut améliorer les performances de sauvegarde en enregistrant les morceaux de blocs modifiés
pour chaque fichier de données. Si le suivi des modifications des blocs est activé sur une base
principale ou de secours, RMAN utilise un fichier de suivi des modifications de blocs pour
identifier un morceau de blocs modifiés à des fins de sauvegardes incrémentielles. La lecture de
ce fichier bitmap de petite taille évite à RMAN d'analyser tous les blocs du fichier en cours de
sauvegarde.
Lors d'une sauvegarde incrémentielle différentielle, tous les blocs modifiés après la plus récente
sauvegarde incrémentielle de niveau 1 ou 0 sont sauvegardés. Lors d'une sauvegarde
incrémentielle cumulative, tous les blocs modifiés après la plus récente sauvegarde
incrémentielle de niveau 0 sont sauvegardés. Lorsque le délai de récupération est plus important
que l'espace disque, les sauvegardes cumulatives sont à privilégier car elles supposent un
nombre réduit de sauvegardes incrémentielles à appliquer.

Multiplexage RMAN
Un canal RMAN représente un seul flux de fichiers de sauvegarde. Il peut lire plusieurs fichiers de
données ou fichiers de journalisation archivés et les placer dans un jeu de sauvegardes multiplexé,
ou bien lire un un fichier à la fois pour une sauvegarde de copie d'image En augmentant le nombre
de canaux RMAN, vous augmentez le parallélisme et pouvez donc réduire le temps de création de
la sauvegarde.
Le multiplexage RMAN fait référence au nombre de fichiers de données ou de fichiers de
journalisation archivés qui sont lus simultanément par un même canal. La configuration par défaut
est min (FILESPERSET, MAXOPENFILES). FILESPERSET est défini dans la commande BACKUP ; sa
valeur par défaut est 64. MAXOPENFILES est défini dans la commande CONFIGURE CHANNEL ; sa
valeur par défaut est 8. Cela veut dire que par défaut, un même canal va lire au maximum huit
fichiers à un instant donné.
Pour les technologies de stockage SAME (Stripe and Mirror Everything (SAME) et ASM (Automatic
Storage Management), MAXOPENFILES doit avoir la valeur 1 parce que tous les fichiers sont
partitionnés correctement entre des disques disponibles et que RMAN peut les lire efficacement.
N'utilisez pas le multiplexage de gestion des médias (plusieurs canaux par lecteur de bande). La
restauration des éléments de sauvegarde RMAN ne serait pas efficace à cause de leur
entrelacement sur le même volume qui risque de nécessiter le déplacement de la bande vers l'avant
et vers l'arrière.

Comparaison de stratégies de sauvegarde
Stratégie Facteurs de sauvegarde Facteurs de récupération
Option 1 : Sauvegardes incrémentielles Commencer par restaurer la

Sauvegardes rapides sauvegarde complète, puis appliquer
complètes et Economie d'espace grâce à la des sauvegardes incrémentielles et
incrémentielles compression des fichiers de journalisation archivés
Stockage sur bande peu coûteux Lecture séquentielle des sauvegardes
sur bande
Option 2 : Sauvegarde incrémentielle Lecture des sauvegardes en accès

Sauvegardes sur assortie d'une réimplémentation aléatoire
disque mises à de modifications pour aboutir à Récupération sans restauration à l'aide
jour de façon une copie à jour de la commande SWITCH
incrémentielle Compter 1 fois le stockage de
production pour la copie
Option 3 : Avantages ci-dessus + base Basculement rapide vers la base de

Chargement des principale capable de gérer des secours en cas de panne
sauvegardes vers charges supplémentaires Les sauvegardes constituent un dernier
une base de Compter une fois le matériel et le recours en cas de défaillance des deux
secours physique stockage de la base de sites
production pour la base de
secours
Les options de stratégie de sauvegarde énoncées dans la diapositive sont décrites en détail dans
les pages suivantes.
Leurs avantages respectifs sont les suivants :
• Option 1 : Economique en termes d'espace de stockage et de coût
• Option 2 : Efficacité de la récupération
• Option 3 : Avantages des options 1 et 2, plus la possibilité de déporter la charge de
production
Les exemples proposés ci-après devraient vous aider à mettre au point votre propre stratégie de
sauvegarde et récupération, en combinant éventuellement les différentes options en fonction de
vos besoins spécifiques de récupération et de votre infrastructure disponible (bandes, disques,
etc.).

Option 1 : Sauvegardes complètes et incrémentielles
• Convient dans les situations suivantes :
– Bases de données pouvant tolérer des délais de récupération (RTO)
en heures/jours
– Environnement privilégiant les disques comme support de stockage
– Modifications faiblement à moyennement fréquentes entre les sauvegardes
(< 20 %)
• Stratégie de sauvegarde :
– Niveau 0 hebdomadaire et sauvegardes incrémentielles différentielles
une fois par jour sur bande, avec compression éventuelle
– Activation du suivi des modifications au niveau bloc pour que seuls les
blocs modifiés soient lus et écrits pendant les sauvegardes incrémentielles
– Sauvegarde et conservation sur disque des fichiers de journalisation
archivés, le cas échéant
Fichiers de
….
Fichiers de
journalisation archivés journalisation archivés
Niveau 0 (sauvegarde complète) Niveau 1 (sauvegarde incrémentielle)
Cette option consiste à effectuer des sauvegardes incrémentielles de niveau 0 hebdomadaires et

des sauvegardes incrémentielles différentielles journalières.
Vous pouvez également tirer parti des fonctionnalités RMAN de compression binaire des jeux de
sauvegarde. Toutefois, si votre périphérique de bande est doté d'un gestionnaire qui effectue sa
propre compression, n'utilisez pas en plus la compression RMAN. Dans la plupart des cas, la
compression fournie par le gestionnaire de support est plus efficace.
Lorsque vous activez le suivi des modifications de bloc, RMAN gère un fichier qui identifie les
blocs modifiés en vue des sauvegardes incrémentielles. Au lieu de parcourir tous les blocs du
fichier de données en cours de sauvegarde, il lit uniquement ce petit fichier bitmap pour
déterminer les blocs modifiés.

Option 2 : Sauvegardes sur disque mises
à jour de façon incrémentielle
– Bases de données qui ne tolèrent pas plus de quelques heures de délai
de récupération (RTO)
– Environnements permettant d'allouer de l'espace disque correspondant
à la taille de la base de données ou des tablespaces les plus critiques
– Copie d'image initiale dans la zone de récupération rapide, puis sauvegardes
incrémentielles quotidiennes
– Nouvelle copie sur disque appliquant les mises à jour des sauvegardes
incrémentielles
– Sauvegarde complète archivée sur bande (le cas échéant)
– Fichiers de journalisation archivés, sauvegardés et conservés sur disque
(le cas échéant)
– Récupération rapide à partir du disque ou commande SWITCH pour utiliser
les copies d'image
Fichiers de journalisation Fichiers de journalisation Fichiers de journalisation
….
archivés archivés archivés
Niveau 0 (sauvegarde Niveau 1 Réimplémentation des modifications

complète) + archive sur bande dans la copie d'image + niveau 1
Cette option consiste à créer des sauvegardes mises à jour de façon incrémentielle. Vous créez
une copie d'image de chaque fichier de données, puis vous y appliquez les sauvegardes
journalières de niveau 1 pour les mettre à jour. Vous évitez ainsi de créer des copies d'image
complètes des fichiers de données tout en conservant la possibilité d'utiliser les copies
incrémentielles pour gagner du temps lors d'une opération de récupération.

Option 3 : Délestage des sauvegardes vers une base de
secours physique dans un environnement Data Guard
– Bases de données qui n'ont pas besoin de plus de quelques
minutes de récupération en cas de panne
– Environnements qui peuvent allouer de préférence des
équipements et de l'espace de stockage symétriques à une base
de secours physique
– Environnements dotés d'une infrastructure de stockage sur bande
pouvant être partagée entre sites principal et de secours
– Sauvegardes complètes et incrémentielles délestées vers la base
de secours physique
– Sauvegarde incrémentielle rapide sur la base de secours avec
Active Data Guard
– Sauvegardes restaurées sur la base principale ou de secours
– Sauvegardes effectuées sur chaque base de données pour une
protection locale optimale
Dans un environnement Data Guard, vous pouvez délester les sauvegardes incrémentielles vers
une base de secours physique. Les sauvegardes incrémentielles d'une base de secours et d'une
base principale sont interchangeables. Vous pouvez appliquer une sauvegarde incrémentielle
d'une base de secours à la base principale et inversement.
Remarque : L'option Oracle Active Data Guard est indispensable pour le suivi des modifications
au niveau bloc sur la base de secours physique.

Sauvegarder des tablespaces en lecture seule
Remarques relatives à la sauvegarde de tablespaces en

lecture seule :
• L'optimisation de la sauvegarde impose à RMAN de
sauvegarder des tablespaces en lecture seule uniquement
s'il n'existe aucune sauvegarde satisfaisant à la stratégie
de conservation.
• Si vous rendez un tablespace accessible en
lecture/écriture, sauvegardez-le immédiatement.
• Vous pouvez utiliser l'option SKIP READONLY de la
commande RMAN BACKUP pour ignorer les tablespaces
ou les fichiers de données en lecture seule.
Contrairement aux tablespaces en lecture/écriture, il est inutile de sauvegarder en permanence

les tablespaces qui ne font pas l'objet d'écritures. L'option SKIP READONLY de la commande
BACKUP indique à RMAN de ne pas sauvegarder les tablespaces en lecture seule.

Sauvegarde et récupération de data warehouse :
Méthodes recommandées
• Tirez parti du partitionnement et du statut de lecture seule des
tablespaces :
– Les partitions anciennes peuvent être déplacées vers des tablespaces
en lecture seule.
– Sauvegardez les tablespaces en lecture seule une première fois, puis
effectuez des sauvegardes périodiques conformément à votre stratégie de
conservation.
• Répartissez la charge d'une sauvegarde complète sur plusieurs jours.
• Tirez parti de la compression (des fichiers de base de données et des
sauvegardes).
• Gagnez du temps en effectuant des sauvegardes au niveau tablespace.
– Sauvegardez les tablespaces d'index moins fréquemment que les
tablespaces de données.
– Sauvegardez moins fréquemment les tablespaces rarement utilisés.
– Réduisez le temps de récupération des tablespaces critiques en les
regroupant dans des sauvegardes distinctes.
• Effectuez une sauvegarde incrémentielle à la fin d'opérations
NOLOGGING pour garantir qu'elles pourront être récupérées.
À l'aide d'une commande similaire à la suivante, vous pouvez répartir la charge globale de
sauvegarde complète entre plusieurs jours :
BACKUP DATABASE NOT BACKED UP SINCE ‘SYSDATE-3’ DURATION 06:00 PARTIAL
MINIMIZE TIME;
Lorsque vous lancez cette commande (le premier jour), une sauvegarde complète débute et va
s'exécuter pendant six heures. Le jour suivant, la même commande s'exécute à nouveau. Elle
commence par le dernier fichier non sauvegardé la veille, puis une sauvegarde complète reprend
dans la même fenêtre de six heures. La base de données entière va ainsi être sauvegardée en
l'espace de quelques jours.

Terminologie supplémentaire en matière
de sauvegarde
Les sauvegardes peuvent être stockées sous diverses formes :
• Copies d'image
• Jeux de sauvegarde
Fichier de données 1 Fichier de Fichier de
données 1 données 2
Fichier de données 2
Fichier de Fichier de
Fichier de données 3 données 3 données 4
Fichier de données 4 données 5 données 6
Fichier de données 5 Jeu de sauvegarde
(Fichiers binaires au format
Fichier de données 6
propriétaire Oracle)
Copies d'image
(Duplication des fichiers de journalisation et de
données au format du système d'exploitation)
• Copies d'image : Ce sont des doubles des fichiers de données ou de journalisation

archivés (tels que vous pourriez les obtenir avec les commandes de copie des systèmes
d'exploitation).
• Jeux de sauvegarde : Ce sont des ensembles de fichiers binaires qui contiennent un ou
plusieurs fichiers de données, fichiers de contrôle, fichiers de paramètres serveur ou fichiers
de journalisation archivés. Ils ne contiennent pas les blocs de données vides,
ce qui fait qu'ils occupent moins d'espace sur le support (disque ou bande). Les jeux de
sauvegarde peuvent être compressés pour un moindre encombrement sur le support.
Les copies d'image doivent être sauvegardées sur disque Les jeux de sauvegarde peuvent être
envoyés sur le disque ou directement vers la bande.
L'avantage d'une copie d'image est une meilleure granularité pour l'opération de restauration. Il
est possible d'extraire les fichiers concernés à partir de l'emplacement de sauvegarde.
Le jeu entier doit être extrait de l'emplacement de sauvegarde, après quoi des fichiers spécifiques
peuvent être récupérés.
L'avantage des jeux de sauvegarde est une utilisation plus efficace de l'espace. Dans la plupart
des bases, au moins 20 % des blocs de données sont vides. Les copies d'image sauvegardent
tous les blocs de données, même s'ils sont vides. Les jeux de sauvegarde limitent
considérablement l'espace requis. Dans la plupart des systèmes, les jeux de sauvegarde
présentent plus d'avantages que les copies d'image.

Créer des jeux de sauvegarde
RMAN> BACKUP AS BACKUPSET

2> FORMAT '/BACKUP/df_%d_%s_%p.bus'
3> TABLESPACE hr_data;
Tablespace Jeu de
HR_DATA
sauvegarde
RMAN peut stocker ses sauvegardes dans un format qui lui est exclusif, appelé jeu de
sauvegarde. Un jeu de sauvegarde est un ensemble de fichiers appelés éléments de sauvegarde
qui contiennent chacun une ou plusieurs sauvegardes de fichiers de base de données.
Remarque : Le paramètre FORMAT indique un modèle à utiliser lors de la création d'un nom de
fichier pour les éléments de sauvegarde créés par cette commande. La spécification FORMAT
peut également être fournie via les commandes ALLOCATE CHANNEL et CONFIGURE.

Créer des copies d'image
RMAN> BACKUP AS COPY DATAFILE '/ORADATA/users_01_db01.dbf';

RMAN> BACKUP AS COPY ARCHIVELOG LIKE '/arch%';
Copie du fichier
Fichier de Fichier de de données 3
Copie du fichier de
journalisation archivé
journalisation journalisation
archivé archivé
Une copie d'image est un clone représentant un seul fichier de données, fichier de journalisation
archivé ou fichier de contrôle. Elle peut être créée à l'aide de la commande BACKUP AS COPY ou
d'une commande du système d'exploitation. Lorsque vous créez la copie d'image avec la
commande RMAN BACKUP AS COPY, la session serveur valide les blocs du fichier et enregistre
les informations sur la copie dans le fichier de contrôle.
Une copie d'image présente les caractéristiques suivantes :
• Une copie d'image ne peut être écrite que sur disque. Avec des fichiers volumineux, le
processus de copie peut prendre plus de temps, mais le temps de restauration est
considérablement réduit puisque la copie est disponible sur le disque.
• Si les fichiers sont stockés sur disque, ils peuvent être utilisés immédiatement à l'aide de la
commande SWITCH de RMAN, qui est l'équivalent de l'instruction SQL ALTER DATABASE
RENAME FILE.
• Dans une copie d'image, tous les blocs sont copiés, qu'ils contiennent ou non des données,
parce qu'un processus de base de données Oracle copie le fichier et effectue d'autres
opérations telles que la recherche des blocs endommagés et l'enregistrement de la copie
dans le fichier de contrôle.
• Pour accélérer le processus de copie, vous pouvez utiliser le paramètre NOCHECKSUM. Par
défaut, RMAN calcule un checksum pour chaque bloc sauvegardé et le stocke avec la
sauvegarde. Le checksum est vérifié lors de la restauration de la sauvegarde.
• Une copie d'image peut faire partie d'une sauvegarde complète ou incrémentielle de
niveau 0 car elle inclut toujours tous les blocs. Utilisez l'option "level 0" si la copie doit être
utilisée avec un jeu de sauvegardes incrémentielles.

Créer une sauvegarde de l'ensemble
de la base de données
RMAN> BACKUP DATABASE

PLUS ARCHIVELOG;
Fichier de
contrôle
Copies des fichiers de Copies des fichiers SPFILE
journalisation archivés de données
Une sauvegarde totale de la base comprend des jeux de sauvegardes ou des copies d'image
pour l'ensemble des fichiers de données et doit en outre comprendre le fichier de contrôle (inclus
automatiquement). Vous pouvez mentionner le fichier de paramètres serveur (SPFILE) et les
fichiers de journalisation archivés. Pour réaliser une copie d'image de tous les fichiers de la base
de données à l'aide de Recovery Manager (RMAN), il suffit de monter ou d'ouvrir la base, de
lancer RMAN et d'entrer la commande BACKUP illustrée dans la diapositive.
Vous pouvez éventuellement ajouter l'option DELETE INPUT pour sauvegarder des fichiers de
journalisation archivés. Ainsi, RMAN supprimera ces fichiers après les avoir sauvegardés. Cette
méthode est particulièrement utile en l'absence de zone de récupération rapide. En effet, celle-ci
gère automatiquement l'espace en supprimant des fichiers au besoin. Voici un exemple :
RMAN> BACKUP DATABASE PLUS ARCHIVELOG DELETE INPUT;
Pour effectuer la sauvegarde comme décrit précédemment, vous devez avoir exécuté les
commandes CONFIGURE suivantes :
• CONFIGURE DEFAULT DEVICE TYPE TO disk;
• CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY;
• CONFIGURE CONTROLFILE AUTOBACKUP ON;

Pour effectuer séparément une sauvegarde du fichier SPFILE, vous devez l'exporter dans un fichier
texte à l'aide de la commande SQL suivante :
• CREATE PFILE FROM SPFILE;
Vous pouvez également créer une sauvegarde (jeu de sauvegarde ou copie d'image) à partir de
copies d'image antérieures de tous les fichiers de données et de contrôle de la base, en exécutant la
commande suivante :
RMAN> BACKUP COPY OF DATABASE;
Par défaut, RMAN exécute chaque commande BACKUP séquentiellement. Vous pouvez toutefois
exécuter les opérations de copie en parallèle :
• A l'aide de la commande CONFIGURE DEVICE TYPE DISK PARALLELISM n, où n représente
le degré de parallélisme souhaité
• En allouant plusieurs canaux
• En lançant une seule commande BACKUP AS COPY mais en répertoriant plusieurs fichiers

Quiz
Oracle assure la gestion de l'espace pour la zone

de récupération rapide.
a. Vrai
b. Faux
Réponse : a

Quiz
Une sauvegarde complète et une sauvegarde de la base

de données totale sont toujours identiques.
a. Vrai
b. Faux
Réponse : b

Quiz
Quelles propositions sont vraies concernant les copies d'image

RMAN ?
a. Les copies d'image ne contiennent pas de blocs vides.
b. Les copies d'image sont des copies bit-à-bit des fichiers
de données.
c. Les copies d'image peuvent être sauvegardées sur bande.
d. Les copies d'image ne peuvent être sauvegardées que sur
disque.
e. Les copies d'image peuvent être traitées comme
des sauvegardes à plusieurs sections.
f. Lors d'une restauration, il est nécessaire d'extraire
les fichiers de données à partir des copies d'image.
Réponse : b, d, e

Synthèse

• décrire les solutions de sauvegarde Oracle
• décrire les types de sauvegarde RMAN
• décrire et comparer les stratégies de sauvegarde et
déterminer la vôtre
• planifier des sauvegardes conformément à votre stratégie
• effectuer des sauvegardes totales

Mettre au point une stratégie de sauvegarde
• Dans l'exercice 5-1, vous allez concevoir la stratégie de
sauvegarde d'une entreprise en fonction de ses besoins
particuliers.
• Dans l'exercice 5-2, vous créerez une sauvegarde
programmée à l'aide d'Enterprise Manager.
Dans ces exercices, vous allez développer des stratégies de sauvegarde pour divers types de
base de données présentant des besoins différents et vous allez mettre en oeuvre un programme
de sauvegarde à l'aide d'Enterprise Manager.

Etude de cas 1 : Protéger une base de données OLTP
Ce premier cas d'étude concerne une base de données OLTP

(traitement de transactions en ligne) qui gère un grand nombre
de transactions par jour. Les exigences de l'entreprise sont les
suivantes : aucune perte de données et temps d'arrêt
minimaux. Le temps de restauration et de récupération doit être
inférieur à une heure. La base de données occupe 300 Go.
Plusieurs To d'espace disque sont disponibles pour les
sauvegardes. Tous les disques disponibles ont les mêmes
propriétés (taille, taux d'E/S, latence). Une sauvegarde sur
bande est possible.
HYPOTHESE : Toute la panoplie Oracle d'outils de sauvegarde et de restauration est disponible.

1. Question : Quelles mesures prenez-vous pour protéger la base de données (mode
ARCHIVELOG par exemple) ?
2. Question : Combien d'espace disque vous faut-il ?
3. Question : Quelle est la stratégie de conservation ?
4. Question : Utiliserez-vous une zone de récupération rapide ?
5. Question : Utiliserez-vous des jeux de sauvegarde ou des copies d'image ?
6. Question : Utiliserez-vous des sauvegardes complètes ou incrémentielles ?
7. Question : Quelle méthode de récupération envisagez-vous ?

Etude de cas 2 : Protéger une base de données DSS
La base de données est un système d'aide à la décision (DSS).

Les données sont chargées via SQL*Loader toutes les nuits,
à partir de plusieurs bases de données transactionnelles.
Le système DSS conserve des données pendant 10 ans.
Les bases de données transactionnelles conservent une année
de données seulement. Les données sont mises à jour dans
les bases de transactions uniquement, après quoi elles sont
remplacées dans la base DSS. Seuls les enregistrements
nouveaux et mis à jour sont transférés vers la base DSS.
La base DSS a une taille de 10 To. Des tablespaces distincts
sont utilisés pour stocker les données par année. Il y a environ
200 tablespaces.

1. Question : De quoi d'autre avez-vous besoin pour concevoir une stratégie de sauvegarde ?
Exemples : Quels sont le coût, la disponibilité et la vitesse du stockage sur disque ?
2. Question : Quelles mesures devez-vous prendre pour protéger la base de données ?
3. Question : Combien d'espace (sur disque ou bande) vous faut-il ?
6. Question : Utiliserez-vous des jeux de sauvegarde ou des copies d'image ?
7. Question : Utiliserez-vous des sauvegardes complètes ou incrémentielles ?

Etude de cas 3 : Protéger la base de données
La base de données est un catalogue de restauration contenant les
informations du catalogue RMAN pour plus de 20 bases de données
dans l'entreprise. Des opérations de sauvegarde et de restauration
peuvent se produire à tout moment. Les bases de données ont une
importance cruciale.
1. Question : Comment les bases sont-elles récupérées si le
catalogue de restauration n'est pas disponible ?
4. Question : Utiliserez-vous des jeux de sauvegarde ou des copies
d'image ?
5. Question : Utiliserez-vous des sauvegardes complètes ou
incrémentielles ?

Réaliser des sauvegardes

Objectifs

• exécuter des sauvegardes complètes et incrémentielles
• utiliser une stratégie de sauvegarde suggérée par Oracle
• surveiller et gérer les sauvegardes
• commencer à affiner vos sauvegardes de base :
– configurer le suivi des modifications de bloc
– effectuer une sauvegarde incrémentielle de niveau 1
– récupérer une sauvegarde incrémentielle de niveau 0 avec
une sauvegarde incrémentielle de niveau 1
Vous abordez le deuxième chapitre du module "Sauvegarde" qui en comprend quatre au total, à
savoir :

Types de sauvegarde RMAN
• Une sauvegarde complète contient tous
Sauvegarde complète ou
les blocs de fichier de données utilisés. "incrémentielle de niveau 0"
• Une sauvegarde incrémentielle de
niveau 0 équivaut à une sauvegarde
complète qui a été marquée comme
étant de niveau 0.
Sauvegarde incrémentielle
• Une sauvegarde incrémentielle de
cumulative
niveau 1 cumulative contient
uniquement les blocs qui ont été
modifiés depuis la dernière sauvegarde
incrémentielle de niveau 0.
• Une sauvegarde incrémentielle de Sauvegarde incrémentielle
niveau 1 différentielle contient différentielle
uniquement les blocs qui ont été
modifiés depuis la dernière sauvegarde
incrémentielle.
Sauvegardes complètes
Une sauvegarde complète est différente d'une sauvegarde de l'ensemble de la base de données.
En effet, une sauvegarde de fichier de données complète est une sauvegarde incluant chaque
bloc de données utilisé dans le fichier. RMAN copie tous les blocs dans le jeu de sauvegarde ou
dans la copie d'image, en ignorant uniquement les blocs qui ne sont pas inclus dans un segment
existant. Dans le cadre d'une copie d'image complète, tout le contenu du fichier est reproduit
exactement. Une sauvegarde complète ne peut pas faire partie d'une stratégie de sauvegarde
incrémentielle ; elle ne peut pas être le parent d'une sauvegarde incrémentielle ultérieure.
Sauvegardes incrémentielles
Une sauvegarde incrémentielle est soit une sauvegarde de niveau 0, qui inclut chaque bloc des
fichiers de données à l'exception des blocs qui n'ont jamais été utilisés, soit une sauvegarde de
niveau 1, qui inclut uniquement les blocs modifiés depuis une précédente sauvegarde. Une
sauvegarde incrémentielle de niveau 0 est physiquement identique à une sauvegarde complète.
La seule différence est que la sauvegarde de niveau 0 (de même qu'une copie d'image) peut
servir de point de départ pour une sauvegarde de niveau 1, tandis qu'une sauvegarde complète
ne peut jamais être utilisée pour effectuer une sauvegarde de niveau 1.

Vous demandez une sauvegarde incrémentielle à l'aide du mot-clé INCREMENTAL de la commande
BACKUP. Indiquez INCREMENTAL LEVEL [0 | 1].
Recovery Manager peut créer des sauvegardes incrémentielles à plusieurs niveaux :
• Sauvegarde incrémentielle différentielle : C'est le type de sauvegarde incrémentielle par
défaut. Il inclut tous les blocs qui ont été modifiés depuis la plus récente sauvegarde
incrémentielle de niveau 1 ou de niveau 0.
• Sauvegarde incrémentielle cumulative : Elle inclut tous les blocs qui ont été modifiés depuis
la plus récente sauvegarde de niveau 0.
Exemples
• Pour effectuer une sauvegarde incrémentielle de niveau 0, utilisez la commande suivante :
RMAN> BACKUP INCREMENTAL LEVEL 0 DATABASE;
• Pour effectuer une sauvegarde incrémentielle différentielle, utilisez la commande suivante :
RMAN> BACKUP INCREMENTAL LEVEL 1 DATABASE;
• Pour effectuer une sauvegarde incrémentielle cumulative, utilisez la commande suivante :
RMAN> BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;
Par défaut, RMAN effectue des sauvegardes complètes si aucun des mots-clés FULL ou
INCREMENTAL n'est précisé. Avec la compression des blocs inutilisés, les blocs n'ayant jamais fait
l'objet d'écritures sont ignorés lors de la sauvegarde des fichiers de données dans les jeux de
sauvegarde, y compris pour les sauvegardes complètes.
Une sauvegarde complète n'a pas d'effet sur les sauvegardes incrémentielles ultérieures et elle n'est
pas considérée comme faisant partie d'une stratégie de sauvegarde incrémentielle. Vous pouvez
néanmoins mettre à jour une sauvegarde complète de copie d'image de façon incrémentielle en
appliquant des sauvegardes incrémentielles à l'aide de la commande RECOVER.
Remarque : Il est possible d'effectuer n'importe quel type de sauvegarde (complète ou
incrémentielle) d'une base de données en mode NOARCHIVELOG (à condition, bien sûr, que la base
ne soit pas ouverte). Notez que la récupération est limitée au moment de la dernière sauvegarde. La
base de données ne peut être récupérée jusqu'à la dernière transaction validée que si elle est en
mode ARCHIVELOG.

Sauvegardes mises à jour de façon incrémentielle
• Les copies d'image sont mises à jour avec toutes les
modifications intervenues jusqu'au SCN de la sauvegarde
incrémentielle.
• La sauvegarde incrémentielle réduit le temps requis pour
la restauration physique.
• Avec des sauvegardes mises à jour de façon
incrémentielle, vous pouvez utiliser la commande SWITCH
pendant l'opération de récupération.
RMAN> RECOVER COPY OF
2> DATAFILE {n|'file_name'}
Fichiers de
sauvegarde
incrémentielle
Copie d'image d'un
fichier de données
Vous pouvez utiliser RMAN pour appliquer des sauvegardes incrémentielles à des copies
d'image de fichiers de données.
BACKUP AS COPY INCREMENTAL LEVEL 0 DATABASE;
Avec des sauvegardes mises à jour de façon incrémentielle, vous pouvez utiliser la commande
SWITCH pendant l'opération de récupération.
RMAN peut réimplémenter les modifications pour récupérer une copie d'image jusqu'à un point
spécifique dans le temps en lui appliquant les sauvegardes incrémentielles. La copie d'image est
mise à jour avec toutes les modifications jusqu'au numéro SCN au niveau duquel la sauvegarde
incrémentielle a été effectuée. RMAN utilise ensuite le fichier de données actualisé résultant pour
effectuer la restauration physique, comme il utiliserait une copie d'image complète prise au niveau
de ce numéro SCN. Cependant, cela permet d'éviter la surcharge liée à l'exécution quotidienne
d'une copie d'image complète de la base de données. L'application de sauvegardes
incrémentielles aux copies d'image de fichiers de données présente les avantages suivants :
• La restauration physique (à l'aide de fichiers journaux archivés) est plus rapide, car il suffit
d'appliquer uniquement les fichiers journaux qui ont été archivés depuis la dernière
sauvegarde incrémentielle.
• Il est inutile d'effectuer une copie d'image complète après la restauration incrémentielle.

Si le processus de récupération échoue lors de l'application du fichier de sauvegarde incrémentielle,
il vous suffit de le relancer. RMAN détermine automatiquement les fichiers de sauvegarde
incrémentielle à appliquer : ceux-ci peuvent être antérieurs à la copie d'image du fichier de données
et s'échelonner jusqu'au moment où vous voulez arrêter le processus de récupération. S'il existe
plusieurs versions d'une copie d'image dans le catalogue RMAN, RMAN utilise automatiquement la
dernière. RMAN signale une erreur s'il n'est pas en mesure de fusionner un fichier de sauvegarde
incrémentielle avec une copie d'image.

Sauvegardes mises à jour de façon
incrémentielle : Exemple
Si vous exécutez ces commandes quotidiennement :
RMAN> recover copy of database with tag 'daily_inc';
RMAN> backup incremental level 1 for recover of copy
2> with tag 'daily_inc' database;
Le résultat est le suivant :

RECOVER BACKUP
Jour 1 Rien Création de copies

d'image
Jour 2 Rien Création du niveau

d'incrément 1
A partir du Récupération de copies à Création du niveau

jour 3 partir d'une sauvegarde d'incrément 1
incrémentielle
Si vous exécutez quotidiennement les commandes illustrées sur la diapositive, vous disposez à
tout moment de copies d'image à jour pour l'ensemble des fichiers de données de la base.
Le tableau indique les conséquences de chaque exécution. Notez que cet algorithme requiert une
configuration initiale ; la stratégie ne se réalise qu'après le jour 3.
• Jour 1 : La commande RECOVER ne fait rien. Il n'existe aucune copie d'image à récupérer.
La commande BACKUP crée les copies d'image.
• Jour 2 : La commande RECOVER ne fait toujours rien. En effet, il n'existe pas de sauvegarde
incrémentielle. Comme des copies d'image de référence ont été créées le jour 1, la
commande BACKUP crée la sauvegarde incrémentielle.
• Jour 3 : La commande RECOVER applique les modifications aux copies d'image à partir de
la sauvegarde incrémentielle. La commande BACKUP effectue une autre sauvegarde
incrémentielle qui sera utilisée pour récupérer les copies d'image le jour 4, et ainsi de suite.
Lors de l'implémentation de ce type de stratégie de sauvegarde, il est important d'utiliser des
balises. Celles-ci permettent de relier des sauvegardes incrémentielles particulières aux copies
d'image réalisées. Sans balise, la sauvegarde incrémentielle la plus récente (peut-être incorrecte)
serait utilisée pour récupérer les copies d'image.

Sauvegarde incrémentielle rapide
Elle est implémentée par la fonctionnalité de suivi des modifications de blocs :
• Celle-ci conserve un enregistrement des morceaux de blocs modifiés
depuis la dernière sauvegarde.
• Elle écrit cet enregistrement dans un fichier lors de la génération
d'informations de journalisation.
• Elle est automatiquement consultée lors de la réalisation d'une
sauvegarde, ce qui peut accélérer celle-ci.
• Elle est optimisée pour huit sauvegardes incrémentielles au maximum.
• Elle est recommandée si les modifications représentent moins de 20 %.
Morceau de blocs 10110010 Fichier

modifiés
CTWR (Change Tracking Writer) 00011101 de suivi des
10101011 modifications
SGA Fichier de
Génération des infos journalisation
de journalisation
Vous pouvez effectuer une sauvegarde incrémentielle rapide en activant la fonctionnalité de suivi
des modifications de blocs (BCT, Block Change Tracking). Le fichier de suivi peut contenir au
maximum huit bitmaps. La sauvegarde ne peut donc pas être optimisée si plus de huit
sauvegardes incrémentielles ont eu lieu depuis la création de la sauvegarde parent servant de
base à la nouvelle sauvegarde incrémentielle. Tenez compte de cette limite de huit bitmaps
lorsque vous concevez votre stratégie de sauvegarde incrémentielle. Par exemple, si vous
réalisez une sauvegarde de niveau 0 suivie de sept sauvegardes incrémentielles différentielles, le
fichier de suivi des modifications de bloc a déjà atteint sa limite. Si vous effectuez ensuite une
sauvegarde incrémentielle de niveau 1 cumulative, RMAN ne peut plus assurer l'optimisation car
le bitmap correspondant à la sauvegarde parent (niveau 0) est alors remplacé par le bitmap de
suivi des modifications actuelles.
Lorsque vient le moment d'effectuer la sauvegarde incrémentielle, RMAN consulte le fichier de
suivi pour déterminer les morceaux de blocs modifiés et il sauvegarde uniquement ces derniers. Il
n'a pas à analyser chaque bloc pour savoir s'il a changé depuis la dernière sauvegarde. Cela
peut réduire la durée de la sauvegarde incrémentielle.
L'utilisation de la fonctionnalité de suivi des modifications de bloc est recommandée lorsque les
modifications ne représentent pas plus de 20 %.
La maintenance du fichier de suivi est entièrement automatique et ne requiert pas votre
intervention. La taille minimale du fichier de suivi est de 10 Mo. L'espace supplémentaire requis
est alloué par incréments de 10 Mo. Par défaut, le serveur de base de données Oracle
n'enregistre pas les informations relatives aux modifications de bloc.

Gestion du fichier de suivi des modifications de bloc
• La destination par défaut est fournie par le paramètre

d'initialisation DB_CREATE_FILE_DEST.
• Pour activer ou désactiver cette fonctionnalité :
ALTER DATABASE
{ENABLE|DISABLE} BLOCK CHANGE TRACKING
[USING FILE '...']
• Pour renommer le fichier de suivi, utilisez la commande
ALTER DATABASE RENAME (la base de données doit être
dans l'état MOUNT).
Vous pouvez activer le suivi des modifications de bloc dans plusieurs outils
Dans Cloud Control, par exemple, accédez à la page d'accueil de l'instance de base de données
et sélectionnez Availability > Backup & Recovery > Backup Settings > Policy. Il n'est pas
nécessaire de préciser la destination du fichier de suivi si le paramètre d'initialisation
DB_CREATE_FILE_DEST est défini. Vous avez néanmoins la possibilité d'indiquer le nom de
fichier et l'emplacement de votre choix.
Vous pouvez également activer ou désactiver la fonctionnalité de suivi à l'aide de la commande
ALTER DATABASE. Si le fichier de suivi se trouve dans la même zone de stockage que les fichiers
de base de données, il est supprimé lorsque vous désactivez la fonctionnalité de suivi des
modifications.
Vous pouvez renommer le fichier de suivi à l'aide de la commande ALTER DATABASE RENAME.
Pour cela, il faut que la base de données soit dans l'état MOUNT. La commande ALTER DATABASE
RENAME FILE met à jour le fichier de contrôle pour qu'il renvoie au nouvel emplacement. Pour
modifier l'emplacement du fichier de suivi des modifications de blocs, vous pouvez utiliser la
syntaxe suivante :
ALTER DATABASE RENAME FILE '...' TO '...';
Remarque : RMAN ne prend pas en charge la sauvegarde et la récupération du fichier de suivi
des modifications de blocs. Vous ne devez donc pas placer ce fichier dans la zone de
récupération rapide.

Surveiller le suivi des modifications de bloc
SQL> SELECT filename, status, bytes

2 FROM v$block_change_tracking;
SQL> SELECT file#, avg(datafile_blocks),

2 avg(blocks_read),
3 avg(blocks_read/datafile_blocks)
4 * 100 AS PCT_READ_FOR_BACKUP,
5 avg(blocks)
5 FROM v$backup_datafile
6 WHERE used_change_tracking = 'YES'
7 AND incremental_level > 0
8 GROUP BY file#;
Les résultats fournis par la vue V$BLOCK_CHANGE_TRACKING indiquent l'emplacement du fichier

de suivi des modifications de blocs, le statut de la fonctionnalité de suivi (ENABLED/DISABLED) et
la taille du fichier de suivi (en octets).
L'interrogation de la vue V$BACKUP_DATAFILE permet de vérifier l'efficacité du suivi en ce qui
concerne la réduction des E/S de la sauvegarde incrémentielle (colonne
PCT_READ_FOR_BACKUP). Une valeur élevée indique que RMAN lit la plupart des blocs dans le
fichier de données lors d'une sauvegarde incrémentielle. Vous pouvez réduire ce ratio en
diminuant le délai entre les sauvegardes incrémentielles.
Un exemple de sortie formatée résultant d'une interrogation de la vue V$BACKUP_DATAFILE est
illustré ci-après :
FILE# BLOCKS_IN_FILE BLOCKS_READ PCT_READ_FOR_BACKUP BLOCKS_BACKED_UP
----- -------------- ----------- ------------------- ----------------
1 56320 4480 7 462
2 3840 2688 70 2408
3 49920 16768 33 4457
4 640 64 10 1
5 19200 256 1 91

Sauvegarde et restauration automatiques
de disque à disque
• Sauvegarde/récupération
Stratégie de sauvegarde suggérée de disque à disque
par Oracle :
Sauvegarde complète
intégrée : Utilisation de
+ sauv. incr. journalière disques peu onéreux pour
= nouvelle sauvegarde "complète" la zone de récupération
+ fichiers de journalisation archivés
quotidiens pour la récupération
rapide
• Sauvegardes
incrémentielles rapides :
Seuls les blocs modifiés
sont sauvegardés
De nuit
• Sauvegarde
Zone de base Zone de Hebdomadaire
de données Application récupération Archivage incrémentielle nocturne
de sauv. incr. rapide sur bande actualisant la sauvegarde
validée
de la zone de
récupération rapide :
Stratification intégrée du stockage des sauvegardes
Sauvegardes complètes
rendues inutiles
RMAN assure de manière complètement automatique la sauvegarde et la récupération sur disque

en utilisant une configuration de stockage par niveaux dont un exemple est illustré dans la
diapositive ci-dessus. Vous pouvez utiliser différents types de stockage pour les fichiers de base
de données et la zone de récupération rapide.
Avec la stratégie de sauvegarde suggérée par Oracle, vous effectuez d'abord une sauvegarde
complète de votre base de données (copie d'image de chaque fichier de données). Vous
configurez ensuite des sauvegardes incrémentielles nocturnes qui sont stockées dans la zone de
récupération rapide. Seuls les blocs de données modifiés sont sauvegardés, d'où une économie
considérable de l'espace de stockage. Vous pouvez implémenter la fonctionnalité de suivi des
modifications de blocs pour plus d'efficacité dans le repérage des blocs modifiés. Les
sauvegardes incrémentielles effectuées la nuit peuvent servir à actualiser la sauvegarde de la
base de données (en appliquant une sauvegarde incrémentielle de niveau 1) et à créer
automatiquement une sauvegarde complète.
Cette procédure permet des sauvegardes plus rapides en propageant les modifications vers la
zone de récupération rapide En outre, les restaurations vont plus vite car les fichiers de
sauvegarde sont copiés depuis la zone de récupération rapide ou d'une copie du fichier dans
celle-ci. (Si une récupération est nécessaire, il suffit d'appliquer les fichiers de journalisation
archivés quotidiennement à la sauvegarde complète de la veille.)

Sauvegarde recommandée par Oracle
• Stratégie de sauvegarde prédéfinie basée sur la
destination de sauvegarde
• Configure une fenêtre de récupération pour la gestion
des sauvegardes
• Planifie des sauvegardes récurrentes et immédiates :
Sauvegarde complète
+ sauv. incr. journalière
= nouvelle sauvegarde "complète"
+ fichiers de journalisation
archivés quotidiens pour la récupération
Enterprise Manager permet d'implémenter facilement la stratégie de sauvegarde suggérée par

Oracle, qui protège les données et permet une récupération efficace. Par défaut, elle assure une
fenêtre de récupération de 24 heures à partir de disques. La stratégie conseillée par Oracle utilise
les fonctions de sauvegarde incrémentielle et de sauvegarde mise à jour de façon incrémentielle.
Elle permet d'effectuer la récupération plus rapidement qu'avec l'application de modifications de
base de données à partir des fichiers de journalisation archivés.
Pour instaurer une stratégie suggérée par Oracle, accédez à la page d'accueil de la base de
données et sélectionnez Availability > Backup & Recovery > Schedule Backup. Dans la section
Backup Strategies, vous avez le choix entre la sauvegarde recommandée par Oracle (Oracle-
suggested) et une sauvegarde personnalisée (Customized). La stratégie conseillée par Oracle
effectue une copie de l'ensemble de la base de données en tant que première sauvegarde.
Envisagez d'effectuer cette sauvegarde en période de moindre activité. Ensuite, une sauvegarde
incrémentielle sur disque est effectuée chaque jour. Une sauvegarde sur bande hebdomadaire
peut éventuellement être effectuée pour tous les fichiers nécessaires à la récupération.
Les sauvegardes sur disque étant conservées, vous pouvez toujours effectuer une récupération
de la base complète ou une récupération jusqu'à un point dans le temps particulier au cours des
dernières 24 heures (au minimum). Le point de récupération par défaut peut remonter au
maximum jusqu'à 48 heures. En effet, pour un jour n donné, tant que vous n'avez pas réalisé la
sauvegarde quotidienne, la précédente (datant du début du jour n–1) existe toujours.
Vous pouvez modifier cette fenêtre en fonction de vos capacités de disque ; trois jours (et jusqu'à
sept) sont des valeurs fréquemment pratiquées.

Générer des rapports sur les sauvegardes
Commandes RMAN :
• LIST affiche des informations sur les jeux de sauvegarde,
les copies proxy et les copies d'image enregistrées dans
le référentiel.
• REPORT produit une analyse détaillée du référentiel.
• REPORT NEED BACKUP répertorie tous les fichiers de
données qui nécessitent une sauvegarde.
• REPORT OBSOLETE identifie les fichiers qui ne sont plus
nécessaires pour répondre aux stratégies de conservation
des sauvegardes.
Enterprise Manager Cloud Control :
• Interface graphique personnalisable
• La commande RMAN LIST permet d'afficher des informations sur les jeux de sauvegarde,
les copies proxy (déléguées à un système tiers) et les copies d'image enregistrées dans le
référentiel (repository). Il existe divers moyens d'afficher des informations sur les
sauvegardes.
• La commande RMAN REPORT permet d'analyser de façon plus détaillée les informations
figurant dans le référentiel RMAN.
• La commande REPORT NEED BACKUP est utilisée pour identifier tous les fichiers de données
qui nécessitent une sauvegarde. Le rapport est généré en supposant que la sauvegarde la
plus récente sera utilisée en cas de restauration.
• La commande REPORT OBSOLETE renvoie les fichiers qui ne sont plus nécessaires au
regard des stratégies de conservation des sauvegardes. Par défaut, cette commande
signale les fichiers qui sont obsolètes dans le cadre de la stratégie de conservation en
vigueur. Il est possible de générer des rapports sur les fichiers obsolètes en fonction de
diverses stratégies de conservation. Vous disposez à cet effet des options REDUNDANCY et
RECOVERY WINDOW avec la commande REPORT OBSOLETE.

Utiliser les vues dynamiques
Interrogez les vues dynamiques suivantes dans la base

de données cible pour obtenir des informations sur vos
sauvegardes :
• V$BACKUP_SET : jeux de sauvegarde créés
• V$BACKUP_PIECE : éléments de sauvegarde existants
• V$DATAFILE_COPY : copies des fichiers de données sur
disque
• V$BACKUP_FILES : informations sur tous les fichiers
créés lors des sauvegardes
De nombreuses vues fournissent des informations sur les sauvegardes. Les plus couramment
utilisées sont indiquées dans la diapositive ci-dessus.
Si vous utilisez un catalogue de restauration, vous pouvez interroger des vues contenant les
mêmes informations pour chaque base de données cible enregistrée dans la base du catalogue.
Elles portent le même nom, sauf que le préfixe V$ est remplacé par RC_. En outre, elles figurent
dans le schéma du propriétaire du catalogue de restauration. Par exemple, pour obtenir les
informations décrites sur la diapositive ci-dessus, vous devrez consulter les vues vues du
catalogue du restauration RC_BACKUP_SET, RC_BACKUP_PIECE, RC_DATAFILE_COPY et
RC_BACKUP_FILES.
Pour interroger la vue RC_BACKUP_FILES, vous devez d'abord exécuter la commande suivante
dans la base de données du catalogue de restauration :
SQL> CALL DBMS_RCVMAN.SETDATABASE(null,null,null,<dbid>);
où <dbid> est le DBID d'une base de données cible.

Gérer les sauvegardes : Vérification croisée
et suppression
Utilisez les commandes RMAN suivantes pour gérer vos
sauvegardes :
• CROSSCHECK : vérifie le statut des sauvegardes et copies
enregistrées dans le référentiel RMAN par rapport à un
média tel qu'un disque ou une bande
• DELETE EXPIRED : supprime uniquement les fichiers dont
le statut dans le référentiel est EXPIRED
• DELETE OBSOLETE : supprime les sauvegardes qui ne
sont plus utiles
Utilisez la commande CROSSCHECK pour vous assurer que les données relatives aux
sauvegardes dans le catalogue de restauration ou le fichier de contrôle sont synchronisées avec
les fichiers réels présents sur le disque ou dans le catalogue de gestion des supports. Elle opère
uniquement sur les fichiers enregistrés dans le référentiel RMAN.
La commande CROSSCHECK ne vérifie que les objets marqués comme AVAILABLE ou EXPIRED.
Elle examine les fichiers situés sur le disque pour les canaux DISK ou elle interroge le
gestionnaire de support pour les canaux sbt. Lorsqu'elle ne trouve pas un fichier, elle affecte le
statut EXPIRED à l'enregistrement correspondant du référentiel. Elle ne supprime pas le fichier.
La commande DELETE peut supprimer tout fichier sur lequel les commandes LIST et
CROSSCHECK peuvent opérer. Par exemple, vous pouvez supprimer des jeux de sauvegarde, des
fichiers de journalisation archivés (archived redo logs) et des copies de fichiers de données. Elle
supprime à la fois le fichier physique et l'enregistrement de catalogue correspondant au fichier. La
commande DELETE OBSOLETE supprime les sauvegardes qui ne sont plus utiles. Elle utilise les
mêmes options REDUNDANCY et RECOVERY WINDOW que la commande REPORT OBSOLETE.
Si vous supprimez des sauvegardes sans utiliser RMAN, vous pouvez utiliser la commande
UNCATALOG pour supprimer les fichiers du catalogue de restauration, ou encore les commandes
CROSSCHECK et DELETE EXPIRED.
Pour obtenir des informations détaillées sur la syntaxe, reportez-vous au manuel Oracle
Database Backup and Recovery Reference.

Quiz
La sauvegarde incrémentielle rapide active RMAN en lecture

seule sur les blocs référencés dans le fichier de suivi des
modifications de blocs lors d'une sauvegarde incrémentielle.
a. Vrai
b. Faux
Réponse : a

Quiz
Avec des sauvegardes mises à jour de façon incrémentielle,

vous pouvez utiliser la commande SWITCH pendant l'opération
de récupération.
a. Vrai
b. Faux
Réponse : a

Synthèse

• exécuter des sauvegardes complètes et incrémentielles
• utiliser une stratégie de sauvegarde suggérée par Oracle
• surveiller et gérer les sauvegardes
• commencer à affiner vos sauvegardes de base :
– configurer le suivi des modifications de bloc
– effectuer une sauvegarde incrémentielle de niveau 1

Créer des sauvegardes incrémentielles
• Dans l'exercice 6-1, vous allez configurer le suivi des
modifications de blocs pour les sauvegardes
incrémentielles rapides.
• L'exercice 6-2 vous permettra de :
– créer une sauvegarde incrémentielle de niveau 0 de la base
de données entière
– créer une sauvegarde incrémentielle de niveau 1

Améliorer des sauvegardes

Objectifs
• compresser des sauvegardes
• utiliser un gestionnaire de support
• créer des sauvegardes multisections pour des fichiers
très volumineux
• créer des copies proxy
• créer des jeux de sauvegarde duplexés
• créer des sauvegardes d'archivage
• sauvegarder d'autres fichiers :
– sauvegarder un fichier de contrôle dans un fichier trace
– sauvegarder des fichiers de journalisation archivés
– enregistrer des fichiers de sauvegarde supplémentaires
dans le catalogue
– sauvegarder les métadonnées ASM
Vous abordez le troisième chapitre du module "Sauvegarde" qui en comprend quatre au total, à
savoir :

Economiser de l'espace de sauvegarde par
compression des blocs inutilisés
Les blocs suivants peuvent être
ignorés pendant certains types
Non alloués
d'opérations de sauvegarde :
• Blocs non alloués : Blocs HWM
situés au-dessus du repère
high-water mark (HWM) du
Inutilisés
fichier de données.
• Blocs inutilisés : Blocs qui ont
été alloués mais Alloués
n'appartiennent plus à un Fichier de
segment. données
Pour certains types de sauvegarde, RMAN peut ignorer des blocs particuliers. C'est notamment le
cas des blocs qui ne sont pas alloués, situés au-dessus de la marque HWM. Par ailleurs, certains
blocs alloués n'appartenant plus à un segment (et donc inutilisés) peuvent être ignorés si les
conditions suivantes sont satisfaites :
• Aucun point de restauration garanti n'est défini.
• Le fichier de données contient des données associées uniquement à des tablespaces gérés
localement.
• Le fichier de données est sauvegardé dans un jeu dans le cadre d'une sauvegarde
complète ou d'une sauvegarde incrémentielle de niveau 0.
• La sauvegarde est effectuée sur disque ou Oracle Secure Backup assure la gestion des
supports.

Compresser des sauvegardes
RMAN peut réaliser une compression binaire de n'importe quelle
sauvegarde générée.
• Cette compression peut être réalisée en plus de celle des
blocs inutilisés.
• Les algorithmes de compression disponibles sont HIGH,
MEDIUM, LOW et BASIC.
• La restauration d'une sauvegarde compressée ne nécessite
aucune opération supplémentaire de la part du DBA.
CONFIGURE COMPRESSION ALGORITHM 'HIGH/MEDIUM/LOW/BASIC'
run {
SET COMPRESSION ALGORITHM 'HIGH/MEDIUM/LOW/BASIC';
.. }
BACKUP AS COMPRESSED BACKUPSET DATABASE PLUS ARCHIVELOG;
Tandis que la compression des blocs inutilisés réduit le nombre de blocs écrits dans la
sauvegarde, la compression binaire peut compresser les données écrites au moyen d'un
algorithme. Les algorithmes de compression disponibles sont HIGH, MEDIUM, LOW et BASIC. Si
vous voulez une compression binaire pour un périphérique spécifique, précisez le mot-clé
COMPRESSED après la clause BACKUP TYPE TO.
La restauration d'une sauvegarde compressée ne requiert aucune opération supplémentaire.
Toutefois, il faut noter que les opérations de compression et de décompression mobilisent des
ressources de la CPU. Il est donc fort probable que la création et la restauration d'une
sauvegarde compressée va demander plus de temps et consommer davantage de ressources
système.
Lors du choix d'un algorithme, prenez en compte l'espace disque et les ressources système
dynamiques (CPU et mémoire, notamment).
Vous pouvez configurer la compression par type de périphérique ou pour chaque jeu de
sauvegarde comme indiqué dans la diapositive ci-dessus.

Utiliser la compression RMAN des sauvegardes
Taux ou niveau Points à prendre en compte Requiert l'option
de compression de compression
avancée
LOW Le plus rapide. Idéal pour les contraintes
relatives aux ressources CPU.
MEDIUM Rapide. Bon équilibre entre l'utilisation

de la CPU et le taux de compression.
HIGH Meilleur taux de compression, mais

au prix d'une consommation élevée
de CPU. Idéal pour les contraintes liées
au réseau.
BASIC Equilibré. Taux de compression

comparable à l'option MEDIUM, mais
avec une consommation supérieure
de CPU.
Taux de compression compris entre
MEDIUM et HIGH.
Comme l'indique la diapositive, la compression binaire des sauvegardes est prise en charge au
moyen de paramètres d'algorithme. Tous les modes à l'exception de BASIC requièrent l'option
Oracle Advanced Compression Database.
Etant donné que les différents niveaux de compression dépendent de la nature des données de la
base, de la configuration réseau, des ressources système, du type de système informatique et de
ses capacités, Oracle Corporation ne peut pas fournir de statistiques de performances
universelles. Pour choisir le niveau le plus adapté à votre système, tenez compte de l'équilibre
entre la bande passante de la CPU et la vitesse réelle de la CPU. Il est vivement recommandé
d'effectuer des tests avec différents niveaux. Le choix d'un niveau de compression adapté à votre
environnement, au trafic réseau (charge globale) et au jeu de données est le seul moyen de
répondre aux besoins de performances de votre organisation et aux exigences des contrats de
niveau de service en vigueur.
Les taux disponibles sont les suivants :
• LOW : Il s'agit du niveau le plus rapide. Il sollicite au minimum les ressources CPU mais
assure une compression inférieure au niveau MEDIUM.
• MEDIUM : Ce niveau assure un bon équilibre entre l'utilisation de la CPU et le taux de
compression.
• HIGH : Ce niveau offre le meilleur taux de compression, mais au prix d'une consommation
maximale de CPU.
• BASIC : Ce niveau offre un taux de compression comparable à celui de l'option MEDIUM
mais consomme davantage de ressources CPU.

Quiz
La compression binaire est utilisée pour compacter

les données écrites dans le fichier de sauvegarde.
a. Vrai
b. Faux
Réponse : a

Utiliser un gestionnaire de support
Recovery Session
Manager serveur
(RMAN) (canal)
Bibliothèque
de gestion
des supports
Oracle Secure Ou
Backup avec
MML intégré Logiciel serveur
de gestion
des supports
Pour sauvegarder la base de données sur bande, Recovery Manager a besoin d'Oracle Secure
Backup ou d'un gestionnaire de support.
Un gestionnaire de support est un utilitaire permettant de charger, de libeller et de décharger des
supports séquentiels (tels que des bandes) pour la sauvegarde, la restauration et la récupération
des données. Le serveur de base de données Oracle appelle des routines logicielles MML (Media
Management Library) pour sauvegarder les fichiers de données sur les supports contrôlés par le
gestionnaire de support, ainsi que pour les restaurer à partir de ces supports.
Notez qu'il n'est pas nécessaire que le serveur de base de données Oracle se connecte au
logiciel MML lors de la sauvegarde sur disque.
Le programme Oracle BSP (Backup Solutions Program) offre un large éventail de produits de
gestion des supports compatibles avec la spécification MML d'Oracle. Les logiciels compatibles
avec l'interface MML permettent à une session de base de données Oracle de sauvegarder les
données sur un gestionnaire de support et de demander à ce dernier de restaurer les
sauvegardes. Contactez votre fabricant de supports afin de déterminer s'il est membre du
programme Oracle BSP.
Pour pouvoir utiliser RMAN avec un gestionnaire de support, vous devez installer le logiciel de
gestion des supports et vous assurer que RMAN peut communiquer avec lui. Les instructions
relatives à cette procédure sont généralement fournies dans la documentation du logiciel de
gestion des supports.

Procédez comme suit (la procédure exacte dépend du produit installé) :
1. Installez et configurez le logiciel de gestion des supports sur l'hôte cible ou sur le réseau de
production. Aucune intégration RMAN n'est requise à ce stade.
2. Assurez-vous que les sauvegardes non RMAN des fichiers du système d'exploitation
peuvent être effectuées sur l'hôte de la base de données cible. Cette opération facilite
ultérieurement la résolution des problèmes éventuels. Consultez la documentation de votre
logiciel de gestion des supports pour savoir comment sauvegarder des fichiers sur le
gestionnaire de support.
3. Procurez-vous le module de gestion de support tiers à intégrer à la base de données Oracle
et installez-le. Ce module doit contenir la bibliothèque chargée par le serveur de base de
données Oracle lors de l'accès au gestionnaire de support.
Opérations de sauvegarde et de restauration à l'aide d'un gestionnaire de support
Le script Recovery Manager suivant procède à la sauvegarde d'un fichier de données sur un
lecteur de bande contrôlé par un gestionnaire de support :
run {
# Allocating a channel of type 'sbt' for serial device
ALLOCATE CHANNEL ch1 DEVICE TYPE sbt;
BACKUP DATAFILE 3;
}
Lorsque Recovery Manager exécute cette commande, il envoie la demande de sauvegarde à la
session de base de données Oracle qui exécute la sauvegarde. La session de base de données
Oracle identifie le canal de sortie en tant que périphérique de gestion des supports et demande au
gestionnaire de support de charger une bande et d'écrire la sortie.
Le gestionnaire de support immatricule et répertorie la bande. Il enregistre aussi le nom des
fichiers de chaque bande. Il gère par ailleurs les opérations de restauration. La restauration d'un
fichier comporte les étapes suivantes :
1. Le serveur de base de données Oracle demande la restauration d'un fichier particulier.
2. Le gestionnaire de support identifie la bande contenant le fichier et la lit.
3. Le gestionnaire de support renvoie les informations à la session de la base de données
Oracle.
4. Le serveur de base de données Oracle écrit le fichier sur disque.
RMAN prend également en charge la fonctionnalité de copie proxy qui permet à un gestionnaire
de support de gérer complètement le transfert des données entre un disque et un support de
sauvegarde. RMAN fournit une liste des fichiers à sauvegarder ou restaurer. Le gestionnaire de
support détermine ensuite comment et quand transférer les données.

Configurer la sauvegarde et la restauration
pour les fichiers très volumineux
Les sauvegardes multisections d'un fichier unique :
• sont créées par RMAN, avec la taille indiquée
• sont traitées de manière indépendante (en série ou en parallèle)
• produisent des jeux de sauvegarde et des copies d'image à plusieurs
éléments
• améliorent les performances de la sauvegarde
Canal 1
Section 1
Canal 2
Section 2
Canal 3
Section 3
Canal 4
Section 4
Fichier de données Jeu de sauvegarde
volumineux à plusieurs éléments
La taille d'un fichier de données Oracle peut atteindre 128 To. Normalement, la plus petite unité
d'une sauvegarde RMAN est un fichier entier, ce qui n'est pas pratique avec des fichiers aussi
gros. RMAN peut éventuellement diviser les fichiers volumineux en sections, puis sauvegarder et
restaurer ces dernières indépendamment. Cette fonctionnalité est intégrée dans RMAN. Pour
l'utiliser, créez des sauvegardes multisections : les fichiers générés pour le jeu de sauvegarde
sont ainsi divisés en plusieurs fichiers distincts. Cette méthode s'applique aux jeux de sauvegarde
et aux copies d'image.
Chaque section correspond à une plage contiguë de blocs d'un fichier. Les différentes sections
d'un fichier peuvent être traitées de manière indépendante, en série ou en parallèle. L'utilisation
de sections peut améliorer les performances des opérations de sauvegarde et permettre de
redémarrer des sauvegardes de fichiers volumineux.
Un travail de sauvegarde multisection produit un jeu de sauvegarde à plusieurs éléments.
Chaque élément contient une section du fichier. Toutes les sections d'une sauvegarde
multisection ont la même taille (à l'exception peut-être de la dernière). Chaque fichier est divisé
au maximum en 256 sections.

Sauvegarder et restaurer des fichiers très volumineux
Les sauvegardes multisections d'un fichier de données :
• sont créées par RMAN avec la taille de section que vous indiquez
• permettent de créer des jeux de sauvegarde ou des copies
d'image
• conviennent aux sauvegardes complètes et incrémentielles
Avantages :
• Réduction du temps nécessaire pour créer les copies d'image
• Traitement indépendant des sections (en série ou en parallèle)
• Méthode intéressante notamment dans les environnements
Exadata
Besoins et restrictions :
• COMPATIBLE=12.0
• Ne convient pas aux fichiers de contrôle ou de mots de passe
• Ne permet pas d'appliquer une valeur de parallélisme élevée
Quels sont les avantages ?

Les copies d'image multisections réduisent le temps de création des copies d'image dans le cas
de fichiers de données volumineux, notamment dans les environnements Exadata. Ce type de
copie peut également réduire le temps d'exécution pour les utilisations autres que la sauvegarde,
par exemple la copie d'un fichier dans le cadre d'une procédure de tablespace transportable ou la
création d'un clone avec duplication de la base de données active.
Les différentes sections d'un fichier peuvent être traitées de manière indépendante, en série ou
en parallèle. L'utilisation de sections peut améliorer les performances des opérations de
sauvegarde et permettre de redémarrer des sauvegardes de fichiers volumineux.
Besoins et restrictions concernant les sauvegardes multisections
• Pour créer des sauvegardes multisections en vue d'obtenir des copies d'image et des
sauvegardes incrémentielle, il faut que le paramètre COMPATIBLE ait au minimum la valeur
12.0.
• Vous ne pouvez créer des sauvegardes multisections incrémentielles que pour des fichiers
de données. Ce type de sauvegarde ne s'applique pas aux autres fichiers de base de
données tels que les fichiers de contrôle ou les fichiers de mots de passe.
• N'appliquez pas de valeur de parallélisme élevée pour sauvegarder un fichier volumineux se
trouvant sur un faible nombre de disques : cela irait à l'encontre de l'objectif même de
l'opération en parallèle. En effet, plusieurs accès simultanés au même périphérique de
disque entreraient en concurrence.

Créer des sauvegardes RMAN multisections
Syntaxe de la commande RMAN :

BACKUP <options> SECTION SIZE <integer> [K | M | G]
VALIDATE DATAFILE <options> SECTION SIZE <integer> [K | M | G]
Exemple :
RMAN> BACKUP DATAFILE 5 SECTION SIZE = 25M TAG 'section25mb';
backing up blocks 1 through 3200
piece handle=/u01/.../o1_mf_nnndf_SECTION25MB_382dryt4_.bkp
tag=SECTION25MB comment=NONE
...
backing up blocks 9601 through 12800
piece handle=/u01/.../o1_mf_nnndf_SECTION25MB_382dsto8_.bkp
tag=SECTION25MB comment=NONE
Les commandes BACKUP et VALIDATE DATAFILE acceptent l'option suivante :

SECTION SIZE <integer> [K | M | G]
Utilisez cette dernière pour indiquer la taille prévue pour chaque section de sauvegarde. Il s'agit
d'une option à la fois de niveau commande de sauvegarde et de niveau spécification de
sauvegarde ; vous pouvez ainsi appliquer différentes tailles de section à différents fichiers au sein
du même travail de sauvegarde.
Dans l'exemple de la diapositive, une sauvegarde du fichier de données 5 est réalisée et la taille
de section indiquée est de 25 Mo. Le fichier de données comportant 100 Mo, quatre sections sont
créées. Notez que, comme indiqué par les plages de blocs, la continuité des blocs est préservée
lors de leur écriture dans les fichiers de section.
Afficher les métadonnées relatives à une sauvegarde multisection
• Les vues V$BACKUP_SET et RC_BACKUP_SET présentent une colonne MULTI_SECTION
qui indique s'il s'agit ou non d'une sauvegarde multisection.
• Les vues V$BACKUP_DATAFILE et RC_BACKUP_DATAFILE comportent une colonne
SECTION_SIZE qui indique le nombre de blocs dans chaque section d'une sauvegarde
multisection. La valeur zéro indique qu'il s'agit d'une sauvegarde de l'ensemble du fichier.

Créer des copies proxy
Session
Recovery Manager serveur
(RMAN) (canal)
Bibliothèque
de gestion
des supports
Logiciel serveur
de gestion
des supports
Réseau de stockage (SAN)
Utilisez l'option PROXY de la commande RMAN BACKUP pour inviter une bibliothèque de gestion
des supports (MML, Media Management Library) à réaliser la copie des fichiers.
Syntaxe :
BACKUP [AS BACKUPSET] … PROXY [ONLY] DATABASE|TABLESPACE....
L'option PROXY ONLY est utile pour les gestionnaires de support et les réseaux de stockage pour
lesquels le trafic est notablement réduit lorsque la sauvegarde est effectuée par le proxy.
Certains produits de gestion des supports peuvent gérer totalement l'ensemble des déplacements
entre les fichiers de données Oracle et les périphériques de sauvegarde. Certains produits qui
utilisent des connexions haute vitesse entre les sous-systèmes de stockage et de support
peuvent réduire considérablement la charge de sauvegarde sur le serveur de base de données
principal. L'avantage réside dans le fait que la copie a lieu via le réseau SAN au lieu du réseau
LAN. Dans ce cas, RMAN n'est plus impliqué dans l'opération, excepté pour communiquer le
statut sur le réseau local et en provenance de la bibliothèque de gestion des supports.
Vous pouvez utiliser la commande RMAN LIST BACKUP pour afficher des informations sur la
copie proxy. La vue V$PROXY_DATAFILE contient les descriptions des sauvegardes de copies
proxy des fichiers de données et fichiers de contrôle.

Créer des jeux de sauvegarde duplexés
à l'aide de la commande BACKUP COPIES
Exemple créant deux copies du jeu de sauvegarde sur bande :
RMAN> BACKUP AS BACKUPSET DEVICE TYPE sbt

2> COPIES 2
3> INCREMENTAL LEVEL 0
4> DATABASE;
Copie de Copie de
sauvegarde 1 sauvegarde 2
Vous pouvez utiliser la commande BACKUP avec l'option COPIES pour modifier les autres
paramètres COPIES ou DUPLEX afin de créer des jeux de sauvegarde duplexés.
Pour duplexer une sauvegarde à l'aide de la commande BACKUP COPIES, procédez comme suit :
1. Indiquez le nombre de copies identiques à effectuer à l'aide de l'option COPIES de la
commande BACKUP.
2. Exécutez une commande LIST BACKUP pour vérifier votre sauvegarde.
Les sauvegardes duplexées nécessitent des ressources supplémentaires. Par exemple, si une
sauvegarde sur bande non duplexée utilise trois canaux RMAN (réclamant chacun une unité de
bande), la même sauvegarde duplexée (générant deux copies) requiert six unités de bande (voir
l'illustration de la diapositive).
Un trait de soulignement et un numéro (_1, _2, et ainsi de suite) sont ajoutés au nom de l'élément
de sauvegarde pour signaler qu'il s'agit d'une copie duplexée.

Créer des sauvegardes de jeux de sauvegarde
RMAN> BACKUP DEVICE TYPE DISK AS BACKUPSET

2> DATABASE PLUS ARCHIVELOG;
RMAN> BACKUP DEVICE TYPE sbt BACKUPSET ALL;
Fichier de
données 2
Fichier de
données 2 Fichier de
données 3
Fichier de
données 3
Fichiers de
journalisation
Fichiers de archivés
journalisation
archivés Jeux de sauvegarde
Utilisez la commande RMAN BACKUP BACKUPSET pour sauvegarder des jeux de sauvegarde
créés précédemment. Seuls les jeux de sauvegarde créés sur le type de périphérique DISK
peuvent être sauvegardés via RMAN. Il est possible d'utiliser n'importe quel type de périphérique
pour sauvegarder les jeux de sauvegarde.
La commande BACKUP BACKUPSET utilise le canal de disque par défaut pour copier des jeux de
sauvegarde entre disques. Pour effectuer une sauvegarde entre un disque et une bande,
configurez ou allouez manuellement un canal autre qu'un canal de disque.

Concepts relatifs aux sauvegardes d'archivage
Sauvegarde
d'archivage
Journal 250 Journal 900
Sauvegarde A Sauvegarde B Sauvegarde S
Maintenant
Fin du 1er trimestre Fenêtre de récupération de 7 jours
Journal nnn et Sauvegarde Inutiles pour la stratégie de conservation
Sauvegarde Nécessaire pour la stratégie de conservation
Si vous avez besoin de conserver une sauvegarde base ouverte pendant un certain temps,
RMAN suppose que vous risquez à tout moment de vouloir effectuer une récupération en utilisant
cette sauvegarde comme point de départ. Pour satisfaire ce scénario, RMAN conserve les fichiers
de journalisation archivés pour la période définie. Toutefois, vous pouvez simplement vouloir
conserver une sauvegarde spécifique (ainsi que tous les éléments associés requis pour sa
cohérente et sa récupération) pendant une durée donnée (deux ans, par exemple). Vous n'avez
pas l'intention d'effectuer une récupération jusqu'à un point dans le temps ultérieur à partir de
cette sauvegarde, mais souhaitez simplement être en mesure de remonter au moment exact de la
sauvegarde. En outre, vous souhaitez préserver une stratégie de conservation qui garantisse
l'accessibilité de votre zone de sauvegarde. Il n'est donc pas acceptable pour vous de remonter
jusqu'à deux ans en arrière. Un tel besoin naît souvent des impératifs d'exploitation ou des
obligations légales en matière de conservation des données.
Une sauvegarde d'archivage permet d'y répondre. Si vous marquez une sauvegarde comme
étant une sauvegarde d'archivage, cet attribut passe outre n'importe quelle stratégie de
conservation configurée pour cette sauvegarde. Vous pouvez conserver des sauvegardes
d'archivage de manière à ce qu'elles ne soient jamais considérées comme obsolètes ou
uniquement au-delà de la durée indiquée. Dans le premier cas, vous devez utiliser un catalogue
de restauration.

La clause KEEP crée une sauvegarde d'archivage qui est un cliché de la base de données à un
moment spécifique.
Seuls sont conservés les fichiers de journalisation qui sont nécessaires pour la restauration de la
sauvegarde dans un état cohérent. La clause RESTORE POINT lancée après l'exécution de la
sauvegarde détermine le nombre de fichiers de journalisation à conserver (suffisant pour restaurer la
sauvegarde jusqu'au moment RESTORE POINT).
Une sauvegarde d'archivage garantit également l'inclusion de l'ensemble des fichiers nécessaires
pour restaurer la sauvegarde. RMAN inclut les fichiers de données, SPFILE, les fichiers de
journalisation archivés (uniquement ceux nécessaires pour récupérer une sauvegarde base ouverte)
et les fichiers de sauvegarde automatique pertinents. Tous ces fichiers doivent être envoyés vers la
même famille de supports (ou le même groupe de bandes).
Vous pouvez aussi indiquer un point de restauration à créer qui porte le même SCN que la
sauvegarde d'archivage. Un nom significatif est ainsi affecté à l'instant où la sauvegarde a été
réalisée.
Une fois créée, une sauvegarde d'archivage est conservée pendant la durée définie. Elle est
préservée d'office, même si vous disposez d'une fenêtre de conservation bien plus courte et que
vous exécutez la commande DELETE OBSOLETE.
Cette sauvegarde est un cliché de la base de données à un instant spécifique et peut servir à
restaurer la base sur un hôte distinct à des fins de test par exemple.
Remarque : Les sauvegardes d'archivage ne peuvent pas être écrites dans la zone de récupération
rapide. Si vous utilisez une zone de récupération rapide, vous devez fournir une clause FORMAT
pour indiquer un emplacement différent.

Créer des sauvegardes d'archivage avec RMAN
• Lorsque la base est en ligne, l'indication de la clause KEEP

entraîne l'inclusion des jeux de sauvegarde de fichiers de
données et de fichiers de journalisation archivés :
KEEP {FOREVER | UNTIL TIME [=] ' date_string '}
NOKEEP
[RESTORE POINT rsname]
• Répertorier tous les points de restauration détectés par
le référentiel RMAN :
LIST RESTORE POINT ALL;
• Afficher un point de restauration spécifique :
LIST RESTORE POINT 'rsname';
Pour créer une sauvegarde d'archivage à l'aide de RMAN, utilisez la syntaxe suivante :
BACKUP ... KEEP {FOREVER|UNTIL TIME 'SYSDATE + <n>'} RESTORE POINT
<restore_point_name>
La clause UNTIL TIME vous permet d'indiquer à partir de quand la sauvegarde d'archivage sera
soumise à la stratégie de conservation. Vous pouvez éventuellement indiquer FOREVER. Dans ce
cas, la sauvegarde est une sauvegarde d'archivage et le demeure tant que vous n'effectuez
aucune opération pour modifier la situation.
Vous pouvez éventuellement utiliser la clause RESTORE POINT pour nommer le point de
restauration à associer à cette sauvegarde. La clause RESTORE POINT crée un point de
"cohérence" dans le fichier de contrôle. Elle affecte un nom à un SCN spécifique. Le SCN est
capturé juste après la fin de la sauvegarde du fichier de données. La sauvegarde d'archivage
peut être restaurée et récupérée pour ce point dans le temps. Cela permet d'ouvrir la base de
données. A l'inverse, la clause UNTIL TIME définit la date jusqu'à laquelle la sauvegarde doit être
conservée.

Gérer les sauvegardes d'archivage
1 Archiver une sauvegarde de base de données :

RMAN> CONNECT TARGET /
RMAN> CONNECT CATALOG rman/rman@catdb
RMAN> CHANGE BACKUP TAG 'consistent_db_bkup'
2> KEEP FOREVER;
2 Modifier le statut d'une copie de base de données :

RMAN> CHANGE COPY OF DATABASE CONTROLFILE NOKEEP;
La commande CHANGE modifie le statut d'exemption d'une sauvegarde ou copie par rapport à la
stratégie de conservation configurée. Par exemple, vous pouvez indiquer CHANGE ... NOKEEP
pour qu'une sauvegarde actuellement exempte de la stratégie de conservation devienne
admissible pour le statut OBSOLETE.
Le premier exemple transforme une sauvegarde cohérente en sauvegarde d'archivage (que vous
envisagez de stocker hors site). Comme la base de données est cohérente et par conséquent ne
nécessite aucune restauration, vous n'avez pas besoin d'enregistrer les fichiers de journalisation
archivés avec la sauvegarde.
Le second exemple indique que les copies d'image à long terme des fichiers de données et des
fichiers de contrôle ne sont plus des exceptions et peuvent devenir obsolètes en fonction de la
stratégie de conservation existante. En résumé, cette instruction supprime l'attribut d'archivage
des fichiers de sauvegarde. Si vous n'indiquez aucune balise, comme dans le cas présent,
l'exécution de la commande CHANGE s'applique à l'ensemble des sauvegardes du type indiqué.
Vous devez indiquer une balise pour modifier uniquement les fichiers de sauvegarde souhaités.
Remarque : L'option RESTORE POINT n'est pas valide avec la commande CHANGE car il est
impossible de créer le point de restauration pour un instant passé (qui correspondrait à la date de
création de la sauvegarde).

Sauvegarder des fichiers de récupération
• Sauvegarder uniquement les fichiers de la zone de

récupération rapide :
RMAN> BACKUP RECOVERY AREA
• Sauvegarder tous les fichiers de récupération :

RMAN> BACKUP RECOVERY FILES
Zone de récupération rapide
Il existe deux méthodes de sauvegarde des données de récupération. La commande BACKUP

RECOVERY AREA sauvegarde tous les fichiers figurant dans la zone de récupération rapide active
ainsi que dans les zones précédentes. La commande BACKUP RECOVERY FILES sauvegarde
tous les fichiers de récupération, même s'ils ne figurent pas dans la zone de récupération rapide.
Elle offre ainsi une protection accrue contre les pertes de données car elle sauvegarde, par
exemple, toutes les copies miroir des fichiers de contrôle ou des fichiers de données ne figurant
pas dans la zone de récupération rapide.
Par défaut, l'optimisation de la sauvegarde est activée pour ces deux commandes, même si vous
l'avez désactivée à l'aide de la commande CONFIGURE. Seuls les fichiers de récupération qui
n'ont pas encore été sauvegardés sont donc concernés. Vous pouvez forcer la sauvegarde de
tous les fichiers à l'aide de l'option FORCE.
Vous ne pouvez indiquer DEVICE TYPE DISK pour aucune de ces deux commandes.
Remarque : RMAN ne sauvegarde que les fichiers de base de données : fichiers de données,
fichiers de contrôle, fichiers SPFILE, fichiers de journalisation archivés et sauvegardes de ces
fichiers. Lorsqu'un fichier du système d'exploitation est placé dans la zone de récupération rapide,
il est inclus dans les sauvegardes de cette zone.

Sauvegarder le fichier de contrôle
dans un fichier trace
• Une telle sauvegarde contient l'instruction SQL nécessaire

pour recréer les fichiers de contrôle si toutes les copies
sont perdues.
• Elle est recommandée après chaque modification de la
structure physique de la base de données.
• Les fichiers trace ainsi créés sont utiles en cas de perte de
tous les fichiers de contrôle.
• Choisissez votre outil de DBA : EM Express, Cloud Control
ou ligne de commande.
Les fichiers trace sont des copies des fichiers de contrôle. Une telle sauvegarde contient
l'instruction SQL nécessaire pour recréer les fichiers de contrôle si toutes les copies sont perdues.
Même si ce scénario est très peu probable dans une base de données correctement configurée
(avec plusieurs copies du fichier de contrôle placées sur des disques et des contrôleurs distincts),
il reste néanmoins possible. C'est pourquoi vous devez sauvegarder le fichier de contrôle dans un
fichier trace après chaque modification de la structure physique de la base de données (ajout de
tablespaces ou de fichiers de données).
Vous pouvez effectuer cette tâche dans EM Express, dans Cloud Control ou de la manière
suivante à partir ligne de commande :
SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
Le fichier trace de sauvegarde est créé à l'emplacement indiqué par le paramètre d'initialisation
DIAGNOSTIC_DEST.

Enregistrer des fichiers de sauvegarde
supplémentaires dans le catalogue
Utilisez la commande CATALOG :
• Pour ajouter au catalogue des fichiers de sauvegarde existants qui
ne sont plus répertoriés dans le fichier de contrôle en vue d'une
opération RMAN de restauration
• Pour ajouter les types de fichier suivants au catalogue de
restauration :
– CONTROLFILECOPY : copies du fichier de contrôle
– DATAFILECOPY : copies de fichiers de données
– BACKUPPIECE : éléments de sauvegarde
– ARCHIVELOG : fichiers de journalisation archivés
• Avec l'option START WITH :
RMAN> CATALOG ARCHIVELOG '/disk1/arch_logs/archive1_731.log',
'/disk1/arch_logs/archive1_732.log';
RMAN> CATALOG START WITH '/tmp/arch_logs/';
Si vous disposez de copies supplémentaires pour le fichier de contrôle et les fichiers de données
ainsi que d'autres éléments de sauvegarde ou fichiers de journalisation archivés sur disque, vous
pouvez les enregistrer dans le catalogue de restauration à l'aide de la commande CATALOG. Si
des sauvegardes ont été retirées du fichier de contrôle en raison de leur ancienneté, vous pouvez
les enregistrer dans le catalogue afin que RMAN puisse les utiliser lors d'une opération de
restauration. L'exemple suivant enregistre dans le catalogue tous les fichiers de la zone de
récupération rapide active :
RMAN> CATALOG RECOVERY AREA NOPROMPT;
Utilisez l'option START WITH pour enregistrer dans le catalogue tous les fichiers figurant dans
l'arborescence de répertoires indiquée. Fournissez un préfixe indiquant le répertoire et
éventuellement un préfixe de fichier à rechercher. Vous ne pouvez pas utiliser de caractères
génériques ; il s'agit seulement d'un préfixe.
Le deuxième exemple illustré dans la diapositive enregistre dans le catalogue tous les types de
fichier de sauvegarde figurant dans le répertoire /tmp/arch_logs.
Supposons que vous souhaitiez être sûr de n'enregistrer dans le catalogue que les fichiers du
répertoire /tmp dont le nom commence par la chaîne bset. La commande suivante permet de le
faire :
RMAN> CATALOG START WITH '/tmp/bset';
Cette commande catalogue aussi les fichiers de sauvegarde qui figurent dans les répertoires dont
le chemin commence par /tmp/bset.
La commande CATALOG peut être utilisée sans connexion à un catalogue de restauration.

Sauvegarder les métadonnées de groupes
de disques ASM
• La commande ASMCMD md_backup permet de créer un fichier
de sauvegarde contenant les métadonnées associées à un ou
plusieurs groupes de disques.
• En cas de perte d'un groupe de disques ASM, le fichier de
sauvegarde peut être utilisé pour le reconstruire ainsi que ses
métadonnées.
• En l'absence du fichier de sauvegarde des métadonnées,
le groupe de disques doit être re-créé manuellement s'il est perdu.
• Sauvegarder tous les groupes de disques montés :
ASMCMD> md_backup /backup/asm_metadata
• Sauvegarder le groupe de disques DATA :
ASMCMD> md_backup /backup/asm_metadata –G data
Vous pouvez utiliser la commande ASMCMD md_backup pour créer un fichier de sauvegarde
des métadonnées d'un groupe de disques ASM. En cas de perte du groupe de disques, ce fichier
permet de le reconstruire ainsi que ses métadonnées. En l'absence de fichier de sauvegarde des
métadonnées, vous devriez re-créer le groupe de disques ASM manuellement.
Le premier exemple de la diapositive ci-dessus montre comment utiliser la commande
md_backup pour sauvegarder les métadonnées de tous les groupes de disques montés. L'option
–G permet de nommer des groupes de disques spécifiques à sauvegarder.
Si vous ne précisez pas de chemin complet pour le fichier de sauvegarde, il est enregistré dans le
répertoire de travail en cours.

Quiz
Il est possible de réaliser des sauvegardes multisections de

copies d'image et de jeux de sauvegarde en vue de
sauvegardes complètes et incrémentielles.
a. Vrai
b. Faux
Réponse : a

Quiz
Les sauvegardes ne doivent être réalisées que pour les fichiers

de données. Les sauvegardes d'autres fichiers ne sont pas
prises en compte dans une stratégie de sauvegarde et de
récupération.
a. Vrai
b. Faux
Réponse : b

Synthèse
• compresser des sauvegardes
• utiliser un gestionnaire de support
• créer des sauvegardes multisections pour des fichiers très
volumineux
• créer des copies proxy
• créer des jeux de sauvegarde duplexés
• créer des sauvegardes d'archivage
• sauvegarder d'autres fichiers :
– sauvegarder un fichier de contrôle dans un fichier trace
– sauvegarder des fichiers de journalisation archivés
– enregistrer des fichiers de sauvegarde supplémentaires dans le
catalogue
– sauvegarder les métadonnées ASM

Sauvegarder des fichiers supplémentaires
– sauvegarder le fichier de contrôle
– sauvegarder les fichiers de journalisation archivés
– sauvegarder le fichier de contrôle dans un fichier trace
• Dans l'exercice facultatif 7-2, vous allez :
– créer une sauvegarde d'archivage
– examiner les sauvegardes existantes dans Cloud Control
Dans ces exercices, vous créez des sauvegardes des fichiers de base de données importants qui
ne font pas partie du jeu de sauvegarde par défaut.

Utiliser les sauvegardes RMAN cryptées

Objectifs

• décrire et créer des sauvegardes cryptées par RMAN
• comparer et utiliser différents modes :
– cryptage transparent
– cryptage basé sur les mots de passe
– cryptage combinant les deux modes
Vous abordez le dernier chapitre du module "Sauvegarde" qui en comprenait quatre au total, à
savoir :
Remarque : Vous trouverez des détails supplémentaires sur la fonctionnalité de cryptage
transparent des données (TDE, Transparent Data Encryption) dans le cours Oracle Database
12c: Security et le manuel Oracle Database Advanced Security Guide.

RMAN : Cryptage des données de sauvegarde
Cryptage des données

sur disque
(Oracle Advanced
RMAN Security)
Cryptage des données

sur bande
Fichiers de données
(Oracle Secure
Backup)
Mot de passe
Dès lors que l'infrastructure de gestion des clés requise est disponible, Recovery Manager
(RMAN) peut créer des sauvegardes cryptées sur bande ou sur disque. Le cryptage effectué à
l'aide de RMAN peut utiliser soit une clé basée sur un mot de passe soit une clé générée stockée
dans le portefeuille Oracle.
RMAN crypte les données, puis les transmet au périphérique de stockage (unité de disque ou de
bande). Aucune autre opération de cryptage n'est effectuée.
Le cryptage des données de sauvegarde à l'aide de RMAN est disponible uniquement dans
Oracle Database Enterprise Edition. En outre, la valeur 10.2.0 ou supérieure doit être affectée au
paramètre COMPATIBLE. L'option Oracle Advanced Security (ASO) est requise pour les
sauvegardes cryptées par RMAN.
Si vous utilisez Oracle Secure Backup (OSB) pour assurer le cryptage, les clés de cryptage sont
gérées par OSB. Le mécanisme est différent du cryptage RMAN.

Comparaison entre cryptage OSB et cryptage RMAN
Pour plus de détails, voir le cours et la Via Oracle
documentation sur Oracle Secure Backup. Advanced Security
Cryptage OSB Cryptage RMAN

Pour la sauvegarde Pour les données des Uniquement les données de sauvegardes
RMAN systèmes de fichiers RMAN
Niveau global ou hôte Niveau global, hôte, Niveau base de données ou tablespace
sauvegarde ou volume
Cryptage des données sur l'hôte client Cryptage des données dans la base : aucun
cryptage supplémentaire
Clés de cryptage OSB : Clés de cryptage RMAN :

- Gérées par OSB - Gérées par une base de données
- Stockées dans des banques de clés cryptées - Stockées dans un portefeuille de base de
spécifiques aux hôtes sur un serveur d'administration données
Algorithmes de cryptage : AES128, AES192 (par Algorithmes de cryptage AES jusqu'à 256 bits
défaut) et AES256
Décryptage transparent au sein d'un domaine Mot de passe fourni par l'utilisateur pour le
décryptage
Le cryptage des sauvegardes d'Oracle Database peut être effectué selon deux méthodes :
• Cryptage OSB :
- à la fois pour les données de sauvegarde RMAN (Oracle 9i et versions ultérieures) et
pour les données des systèmes de fichiers
- Oracle Secure Backup crypte les données sur l'hôte client. (Aucune installation de
logiciel client n'étant disponible sur NAS, les données NAS ne peuvent pas être
cryptées par OSB.) Le cryptage a lieu en dehors de la base de données, mais les
données sont cryptées avant leur transfert via le réseau ou avant leur écriture sur un
périphérique de bande rattaché localement. Le décryptage au sein du même domaine
n'a pas besoin de phrase de passe.
- La technologie SSL incorporée assure le transport sécurisé des données de
sauvegarde et des messages entre serveurs authentifiés bidirectionnellement.
• Cryptage RMAN (disponible avec Oracle Advanced Security) :
- RMAN peut crypter les sauvegardes d'une base de données Oracle au niveau base de
données ou tablespace. Il crypte les données au sein de la base de données. Le
processus est généralement plus rapide que le cryptage OSB. Les clés de cryptage
RMAN sont stockées dans des fichiers de clés et contrôlées par la base de données.
- Les sauvegardes cryptées RMAN requièrent Oracle Advanced Security.
• Si OSB rencontre des sauvegardes cryptées par RMAN, il n'effectue aucun cryptage
supplémentaire.

Créer des sauvegardes cryptées via RMAN
RMAN prend en charge trois modes de cryptage :

• Transparent :
– Utilise une clé TDE (Transparent Data Encryption)
– Exige la configuration préalable d'un fichier de clés
• Avec mot de passe : Requiert l'utilisation de la commande
SET ENCRYPTION ON IDENTIFIED BY password ONLY
dans les scripts RMAN
• Double : Requiert l'utilisation de la commande SET
ENCRYPTION ON IDENTIFIED BY password dans les
scripts RMAN
Pour renforcer la sécurité, vous pouvez crypter les sauvegardes RMAN créées en tant que jeux
de sauvegarde. Cette information apparaît dans la colonne ENCRYPTED de la vue
V$BACKUP_PIECE.
En revanche, les sauvegardes de copie d'image ne peuvent pas être cryptées.
Les sauvegardes cryptées sont décryptées automatiquement au cours des opérations de
restauration et de récupération, tant que les clés de décryptage nécessaires sont disponibles, au
moyen d'un mot de passe entré par l'utilisateur ou de la clé TDE. La clé TDE est stockée dans un
fichier de clés qui constitue un conteneur protégé par mot de passe et qui était appelé portefeuille
(wallet) dans les versions précédentes.
RMAN prend en charge trois modes de cryptage :
• Transparent
• Avec mot de passe
• Double
Chaque mode est décrit en détail dans les pages qui suivent.

TDE (Transparent Data Encryption) : Définition
3. Décrytage des données 2. Clé de table appliquée
5454 5454 5454 5454 5. Clé de table appliquée
5500 0000 0000 0004
SELECT 5555 5555 5555 1111 Texte de chiffrement
/ INSERT 5555 5555 5555 4444
(privilèges) 3///?.?OYzJdfvQf
6. Cryptage des
1. SELECT ccn FROM emp; 2368{]]}.:oz§§!! données
§/.?564#{[|`\^@@ 2çàéèù*%I&456A/.!
4. INSERT ccn INTO emp
@~[|12effs”éèàù°
VALUES (4222222222222);
• Crypte les données dans :

– les fichiers de données (tablespaces, colonnes, index)
– les fichiers de journalisation et les fichiers de journalisation
archivés
– la mémoire (uniquement pour le cryptage au niveau colonne)
– les sauvegardes de fichiers
• Gère les clés automatiquement
• N'impose aucune modification de l'application
Le mode de cryptage transparent TDE (Transparent Data Encryption) est disponible avec Oracle
Advanced Security. Facile à utiliser, il protège vos données sans que vous ayez à modifier vos
applications. TDE permet de crypter les données sensibles figurant dans des colonnes
spécifiques ou dans la totalité d'un tablespace sans avoir à gérer de clés de cryptage. TDE n'a
aucune incidence sur les contrôles d'accès, qui sont configurés à l'aide de rôles de base de
données, de rôles d'application sécurisés, de privilèges système et de privilèges sur les objets, de
vues, de Virtual Private Database (VPD), d'Oracle Database Vault et d'Oracle Label Security.
Toute application ou tout utilisateur qui disposait d'un accès à une table conserve l'accès à la
version cryptée par TDE de cette même table.
TDE est conçu pour protéger les données stockées, mais ne se substitue en aucun cas à un
contrôle d'accès adéquat.
TDE est transparent pour les applications existantes. Le cryptage et le décryptage des données
peuvent être effectués au niveau tablespace ou colonne. Dans les deux cas, les valeurs cryptées
ne sont ni affichées ni traitées par l'application. Considérons par exemple une application conçue
pour afficher des numéros de carte de crédit à 16 chiffres. Vous n'avez pas besoin de la recoder,
même si les chaînes qu'elle doit traiter comportent bien plus de 16 caractères une fois cryptées
par TDE.

Grâce à TDE, vous retirez la possibilité à toute personne disposant d'un accès direct aux fichiers
de données d'accéder à ces données par détournement des mécanismes de contrôle d'accès de
la base. Même les utilisateurs disposant d'un accès aux fichiers au niveau du système
d'exploitation ne peuvent pas afficher les données sous une forme non cryptée. TDE stocke la clé
maître en dehors de la base de données, dans un module de sécurité externe, ce qui réduit
considérablement le risque de violation des informations personnelles et des clés de cryptage.
TDE ne décrypte les données que si les conditions d'accès à la base sont remplies.

Utiliser le mode de cryptage transparent
1. Créez un répertoire pour le fichier de clés.

2. Indiquez l'emplacement du fichier de clés dans sqlnet.ora.
ENCRYPTION_WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY =
/u01/app/oracle/admin/orcl/wallet)))
Emplacement du fichier Clé maître Table de clés

de clés d'accès :
sqlnet.ora
Pour que la base de données puisse utiliser le mode de cryptage transparent (TDE), il doit exister
un fichier de clés. TDE crée une clé pour chaque table comprenant des colonnes cryptées et une
clé pour chaque tablespace crypté. La clé de la table est stockée dans le dictionnaire de données,
tandis que les clés des tablespaces sont stockées dans les fichiers de données des tablespaces.
Les clés des tablespaces et des tables sont cryptées à l'aide d'une clé maître. Celle-ci est unique
pour la base de données.
Pour créer un fichier de clés logiciel et une clé maître, procédez comme suit :
1. Créez le répertoire destiné à contenir le fichier de clés. Il doit être accessible par le
propriétaire du logiciel Oracle.
2. Indiquez l'emplacement du fichier de clés utilisé pour stocker la clé maître de cryptage en
ajoutant une entrée dans le fichier $ORACLE_HOME/network/admin/sqlnet.ora,
comme illustré dans la diapositive.
Remarque : Cette entrée respecte les indentations et les espaces.

Utiliser le mode de cryptage transparent
3. Connectez-vous avec le privilège SYSKM (ou SYSDBA).
4. Créez le fichier de clés logiciel.
5. Ouvrez le fichier de clés logiciel.
6. Créez la clé de cryptage maître.
SQL> CONNECT / AS SYSKM

SQL> ADMINISTER KEY MANAGEMENT CREATE KEYSTORE
'/u01/app/oracle/admin/orcl/wallet'
IDENTIFIED BY keystore_password;
SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN

SQL> ADMINISTER KEY MANAGEMENT SET KEY

IDENTIFIED BY keystore_password
WITH BACKUP USING 'for_12c' ;
3. Connectez-vous à l'instance de base de données en tant qu'utilisateur doté du privilège

ADMINISTER KEY MANAGEMENT ou SYSKM.
4. Créez le fichier de clés logiciel.
5. Ouvrez le fichier de clés logiciel.
6. Créez la clé de cryptage maître, laquelle est stockée dans le fichier de clés. Utilisez la
clause WITH BACKUP pour sauvegarder le fichier de clés. Vous devez utiliser cette option
pour les fichiers de clés basés sur des mots de passe. Vous pouvez éventuellement ajouter
la clause USING pour indiquer une brève description de la sauvegarde. Cet identifiant est
ajouté au fichier de clés désigné.
Normalement, vous ne devez régénérer la clé maître que dans le cas où elle a été compromise.
Toutefois, la modification périodique de la clé maître peut être une obligation réglementaire. La
régénération de la clé maître n'entraîne pas le recryptage des données. La clé maître est utilisée
pour crypter les clés de table utilisées pour le cryptage de colonnes, ainsi que les clés de
tablespace. Les clés de table servent à crypter les données des colonnes. Les clés de tablespace
servent à crypter les blocs des tablespaces. La modification de la clé maître entraîne le
recryptage des clés de table et de tablespace. Il s'agit d'une opération relativement rapide, mais
les données de colonne et les blocs de tablespace ne sont pas recryptés.
Toutes les anciennes clés maître sont contenues dans le fichier de clés : les clés antérieures sont
disponibles si les anciennes données sont récupérées à partir d'une sauvegarde ou si la base de
données est récupérée jusqu'à un point dans le temps antérieur à la régénération de la clé.

Sauvegarder le fichier de clés
Sauvegarder le fichier de clés en cours :
SQL> ADMINISTER KEY MANAGEMENT BACKUP KEYSTORE

Les clés maître sont nécessaires pour accéder aux données cryptées. Vous devez donc les
protéger au moyen de sauvegardes. Comme elles se trouvent dans un fichier de clés, il est
nécessaire de sauvegarder celui-ci périodiquement dans un emplacement sécurisé avec les
fichiers de données de la base. Vous devez sauvegarder une copie du fichier de clés de cryptage
chaque fois que vous définissez une nouvelle clé maître.
De la sorte, si vous perdez le fichier contenant la clé maître, vous pourrez toujours restaurer
l'accès aux données cryptées en copiant la version sauvegardée du fichier de clés à
l'emplacement approprié. Si le fichier de clés restauré a été archivé après la dernière
régénération de la clé maître, aucune autre action n'est requise.
En revanche, s'il ne contient pas la clé maître la plus récente, vous ne pouvez récupérer que les
données antérieures au changement de clé. Toutes les modifications apportées aux colonnes
cryptées après la modification de la clé maître sont perdues.
Chaque fois que le fichier de clés est ouvert, deux fichiers peuvent être disponibles : celui qui est
basé sur un mot de passe, identifié par l'extension p12, et un fichier de clés de connexion
automatique nommé cwallet.sso. Le fichier de clés de connexion automatique change lors de
chaque ouverture du fichier de clés ; il n'est donc pas utile de l'inclure dans les sauvegardes. En
revanche, le fichier de clés d'accès basé sur un mot de passe contient les clés maître actuelles et
antérieures et vous devez l'inclure dans les sauvegardes.
Des fichiers de clés d'accès distincts sont utilisés pour le cryptage par Recovery Manager
(RMAN) et par Oracle Secure Backup (OSB).

Configurer le cryptage RMAN
1. Configurez le niveau de cryptage de RMAN (base de

données, tablespace ou base de données à l'exclusion
des tablespaces) :
RMAN> CONFIGURE ENCRYPTION FOR DATABASE ON
RMAN> CONFIGURE ENCRYPTION FOR TABLESPACE

<tablespace_name> ON
2. Si nécessaire, définissez l'algorithme de cryptage :
RMAN> SET ENCRYPTION ALGORITHM 'algorithm name'
1. Configurez le niveau de cryptage de RMAN. La commande CONFIGURE ENCRYPTION est

utilisée pour définir les paramètres de cryptage de la base de données ou des tablespaces
de la base. Ces paramètres sont appliqués tant qu'ils ne sont pas modifiés au moyen de la
commande SET. Les options définies pour un tablespace spécifique ont la priorité sur celles
qui sont définies pour l'ensemble de la base.
2. Au besoin, définissez un algorithme de cryptage. Interrogez la vue
V$RMAN_ENCRYPTION_ALGORITHMS pour obtenir la liste des algorithmes de cryptage pris
en charge par RMAN. L'algorithme de cryptage par défaut est AES 128 bits.

Utiliser le mode de cryptage basé sur un mot de passe
• Cas d'utilisation : Sécuriser le transport des sauvegardes

vers un site distant
• Activez le cryptage basé sur un mot de passe :
– Valable uniquement pendant la durée d'une session RMAN
SET ENCRYPTION ON IDENTIFIED BY password ONLY
– Impose la fourniture d'un mot de passe pour créer une

sauvegarde
– Impose la fourniture d'un mot de passe pour restaurer une
sauvegarde
Lorsque vous utilisez ce mode, vous devez indiquer un mot de passe pour créer et restaurer des
sauvegardes cryptées. Lorsque vous restaurez une sauvegarde qui a été cryptée avec un mot de
passe, vous devez fournir le même mot de passe que celui qui a été utilisé pour créer la
sauvegarde. Le cryptage avec mot de passe est la meilleure solution pour les sauvegardes qui
sont restaurées sur des sites distants et qui doivent rester sécurisées lors du transport.
Pour activer le cryptage basé sur un mot de passe, utilisez la commande SET ENCRYPTION ON
IDENTIFIED BY password ONLY dans vos scripts RMAN. Ce mode de cryptage ne peut pas
être configuré de façon permanente.
L'interface Enterprise Manager insère la commande appropriée dans les scripts de sauvegarde
RMAN qu'elle génère.
Remarque : Pour des raisons de sécurité, il est impossible de configurer de manière permanente
un environnement de sauvegarde de sorte que les sauvegardes RMAN soient cryptées avec mot
de passe. Vous ne pouvez activer le cryptage des sauvegardes avec mot de passe que pour la
durée d'une session RMAN.

Utiliser le mode de cryptage double
• Les sauvegardes cryptées en mode double peuvent être

restaurées de manière transparente ou avec un mot de
passe.
• Activez le cryptage avec mot de passe dans votre session
RMAN :
SET ENCRYPTION ON IDENTIFIED BY password
Les sauvegardes cryptées en mode double peuvent être restaurées de manière transparente ou
avec un mot de passe. Le mode double est utile lorsque vous créez des sauvegardes qui sont
censées être restaurées à l'aide du portefeuille de cryptage Oracle mais qui doivent aussi pouvoir
être restaurées lorsque ce portefeuille n'est pas disponible.
Pour créer des jeux de sauvegarde cryptés en mode double, insérez la commande SET
ENCRYPTION ON IDENTIFIED BY password dans vos scripts RMAN.

Considérations relatives aux sauvegardes
cryptées par RMAN
• Les sauvegardes de copie d'image ne peuvent pas être
cryptées.
• La vue V$RMAN_ENCRYPTION_ALGORITHMS contient la
liste des algorithmes de cryptage possibles.
RMAN> CONFIGURE ENCRYPTION ALGORITHM 'algorithmname'
RMAN> SET ENCRYPTION ALGORITHM 'algorithmname'
• Une nouvelle clé de cryptage est utilisée pour chaque

nouvelle sauvegarde cryptée.
• Vous pouvez améliorer les performances du disque en
utilisant plusieurs canaux.
• Vous pouvez modifier la clé maître à tout moment sans
affecter les sauvegardes cryptées en mode Transparent.
• Vous pouvez crypter n'importe quelle sauvegarde RMAN créée sous forme de jeu
de sauvegarde. En revanche, les copies d'image ne peuvent pas être cryptées.
• La vue V$RMAN_ENCRYPTION_ALGORITHMS fournit la liste des algorithmes de cryptage
pris en charge par RMAN. Si aucun algorithme de cryptage n'est indiqué, l'algorithme utilisé
par défaut est AES 128 bits. Vous pouvez changer d'algorithme à l'aide des commandes
indiquées dans la diapositive ci-dessus.
• Le serveur de base de données Oracle utilise une nouvelle clé de cryptage pour chaque
sauvegarde cryptée. La clé de cryptage de la sauvegarde est ensuite cryptée à l'aide du mot
de passe et/ou de la clé maître de la base de données, en fonction du mode de cryptage
sélectionné. Les clés de cryptage et les mots de passe des sauvegardes ne sont jamais
stockés en texte clair.
• Le cryptage peut affecter les performances de la sauvegarde sur disque. En effet, les
sauvegardes cryptées utilisent davantage la CPU que les sauvegardes non cryptées. Vous
pouvez améliorer les performances des sauvegardes cryptées sur disque en faisant appel à
plusieurs canaux RMAN.

Restaurer des sauvegardes cryptées
• Avant de lancer la restauration, configurez la session RMAN

de façon à pouvoir décrypter les sauvegardes.
• Pour restaurer un jeu comprenant des sauvegardes créées
avec des mots de passe différents, indiquez tous les mots de
passe nécessaires dans la commande SET DECRYPTION.
SET DECRYPTION IDENTIFIED BY '<password_1>'
{, '<password_2>',…,'<password_n>' }
Remarques
• Si vous perdez le mot de passe d'une sauvegarde cryptée
en mode Mot de passe, vous ne pouvez pas la restaurer.
• Si vous perdez le fichier contenant la clé d'une sauvegarde
cryptée en mode Transparent, vous ne pouvez pas restaurer
cette sauvegarde.
Utilisez la commande SET DECRYPTION pour indiquer le(s) mot(s) de passe de décryptage à
utiliser lors de la lecture de sauvegardes ayant fait l'objet d'un cryptage en mode double ou d'un
cryptage avec mot de passe. Lorsque RMAN lit un élément de sauvegarde crypté, il essaie
chaque mot de passe figurant dans la liste jusqu'à ce qu'il trouve celui qui lui permet de décrypter
l'élément. Une erreur est générée si aucune des clés indiquées n'est correcte.
Si vous perdez le mot de passe d'une sauvegarde cryptée en mode Mot de passe, vous ne
pouvez pas restaurer cette sauvegarde.
Etant donné que l'infrastructure Oracle de gestion des clés archive toutes les clés maître
précédentes dans le fichier de clés d'accès (ou portefeuille de cryptage), la modification ou la
réinitialisation de la clé maître de la base de données en cours n'affecte pas la capacité de
restauration des sauvegardes cryptées effectuées à l'aide d'une ancienne clé maître. Vous
pouvez recréer la clé maître de la base de données à tout moment. Mais RMAN pourra toujours
restaurer toutes les sauvegardes cryptées créées par cette base.
Si vous perdez le fichier contenant la clé d'une sauvegarde cryptée en mode Transparent, vous
ne pouvez plus restaurer cette sauvegarde. Comme le fichier de clés d'accès contient toutes les
clés de cryptage des sauvegardes antérieures, vous pouvez en restaurer une sauvegarde pour
récupérer les sauvegardes qui ont été cryptées antérieurement. En revanche, les sauvegardes
cryptées après la sauvegarde du fichier de clés d'accès resteront inaccessibles.
Méthode recommandée : Sauvegardez fréquemment le fichier de clés d'accès.

Quiz
Vers quel type de support pouvez-vous créer des sauvegardes

cryptées par RMAN ?
a. Disque
b. Bande, via un gestionnaire de support tiers
c. Bande, via Oracle Secure Backup
Réponses : a, c

Synthèse

• décrire et créer des sauvegardes cryptées par RMAN
• comparer et utiliser différents modes :
– cryptage transparent
– cryptage basé sur les mots de passe
– cryptage combinant les deux modes

Utiliser les sauvegardes cryptées par RMAN
• Dans l'exercice 8-1, vous allez crypter une sauvegarde
avec RMAN.
• Dans l'exercice 8-2, vous restaurerez une sauvegarde
cryptée.
Le premier exercice utilise le cryptage par mot de passe, technique appropriée pour les
sauvegardes destinées à être restaurées sur un site distant.
Le second est un exercice facultatif de mise à l'épreuve, dans la mesure où le cours n'a
probablement pas encore traité des opérations de restauration et de récupération. Il ne doit être
tenté que s'il reste du temps par rapport à la chronologie du cours.

Diagnostiquer les défaillances

Objectifs

• détecter une corruption de la base de données et y
remédier
• utiliser le référentiel ADR (Automatic Diagnostic
Repository)
• analyser la récupération d'instance avec l'outil de ligne de
commande ADRCI
• interroger et interpréter les piles de messages et d'erreurs
• utiliser la fonction de conseil Data Recovery Advisor
• rechercher proactivement et traiter les corruptions de blocs
Vous abordez le premier chapitre du module "Récupération" qui en comprend quatre, à savoir :
• Chapitre 9 : Diagnostiquer les défaillances
• Chapitre 10 : Concepts de restauration et de récupération
• Chapitre 11 : Procéder à une récupération I
• Chapitre 12 : Procéder à une récupération II

Réduire le délai de diagnostic des problèmes
Outils Oracle pour la réparation des
Analyse et données :
planification
• RMAN en cas de perte ou de corruption
de support physique
• Flashback pour les erreurs logiques
• Data Guard pour les problèmes
physiques
• Data Recovery Advisor dans les cas
suivants :
Récupération – Diagnostic des problèmes (pour éviter
les erreurs et la perte de temps lors
du choix de la solution)
– Choix inappropriés (essentiellement
Time to Repair dans les situations d'urgence)
Des études montrent que les administrateurs de base de données passent une grande partie de
leur temps de "réparation" à essayer de déterminer quelles données ont été altérées, pourquoi et
de quelle manière. Ils peuvent ainsi être amenés à analyser des fichiers d'erreurs, d'alertes et de
trace. Data Recovery Advisor permet d'identifier les problèmes d'une base de données de façon
intelligente et peut réduire le temps d'arrêt global du système en éliminant ou réduisant le temps
passé par l'administrateur de base de données à rechercher l'origine des problèmes.
Par ailleurs, Data Recovery Advisor diminue l'incertitude et la confusion qui se produisent souvent
pendant une indisponibilité de la base de données. Il utilise un référentiel spécial appelé ADR
(Automatic Diagnostic Repository).

Workflow de diagnostic automatique
Erreur critique Référentiel ADR
DBA
My Oracle Support
Alerte du DBA Contrôles
Création d'incident
1 automatique 2 ciblés de l'état général
Rédaction assistée d'une SR
Capture de la première erreur
Non
Bug connu ?
DBA
My Oracle Support Oui
Support Workbench
Packaging des infos Support Workbench :
4 sur l'incident Application de patch/ 3
DBA
Réparation des données réparation de données
Un utilitaire de suivi en mémoire, toujours activé, permet aux composants de la base de données
de capturer des données de diagnostic relatives aux erreurs critiques dès le premier échec. Le
référentiel ADR (Automatic Diagnostic Repository) est mis à jour automatiquement afin de
contenir les informations de diagnostic concernant les erreurs critiques. Ces informations peuvent
être utilisées par Data Recovery Advisor, mais aussi pour créer des packages sur les incidents à
destination des services de support technique Oracle.
Voici un workflow standard de session de diagnostic qui inclut les services de support technique
Oracle :
1. Un incident entraîne le déclenchement d'une alerte dans Enterprise Manager (EM).
2. L'administrateur de base de données (DBA) peut afficher cette alerte dans la page Alert de
Cloud Control.
3. Il peut afficher les détails de l'incident et du problème.
4. Le DBA (ou le support technique) peut décider (ou demander) de packager ces informations
et de les envoyer au support technique Oracle via la plate-forme My Oracle Support. Le
DBA peut ajouter des fichiers aux données automatiquement incluses dans le package.

Référentiel ADR
DIAGNOSTIC_DEST
$ORACLE_BASE
$ORACLE_HOME/log
Base
ADR Support Workbench
diag
rdbms
Nom de
BdD
Dumps noyau ADR
SID métadonnées Traces des processus
Home
de premier plan et
Fichier d'alertes d'arrière-plan et données
alert cdump incpkg incident hm trace (autres) du fichier d'alertes
Dumps d'incident
incdir_1 … incdir_n
ADRCI log.xml alert_SID.log Vue V$DIAG_INFO
Le référentiel ADR (Automatic Diagnostic Repository) est un référentiel basé sur des fichiers. Il
est destiné aux données de diagnostic de la base de données telles que les traces, les dumps et
packages d'incident, le fichier d'alertes, les rapports Health Monitor, les dumps noyau (core
dumps), etc. Il possède une structure de répertoires unifiée couvrant plusieurs instances et
plusieurs produits qui est stockée en dehors de toute base de données. Il est donc accessible
pour le diagnostic des problèmes lorsque la base est arrêtée.
Depuis la version Oracle Database 11g R1, la base de données, la fonction ASM (Automatic
Storage Management), CRS (Cluster Ready Services) et d'autres produits ou composants Oracle
stockent l'ensemble des données de diagnostic dans le référentiel ADR. Chaque instance de
chaque produit stocke les données de diagnostic dans son propre répertoire ADR Home. Par
exemple, dans un environnement Real Application Clusters doté d'une zone de stockage
partagée et d'ASM, chaque instance de base de données et chaque instance ASM dispose d'un
répertoire d'origine au sein du référentiel ADR. La structure de répertoires unifiée du référentiel
ADR, les formats de données de diagnostic cohérents pour tous les produits et instances, et un
ensemble d'outils homogène permettent aux clients et au support technique Oracle de corréler et
d'analyser les données de diagnostic sur plusieurs instances.
Le répertoire racine du référentiel ADR est appelé base ADR. Son emplacement est défini par le
paramètre d'initialisation DIAGNOSTIC_DEST. Si ce paramètre est omis ou laissé vide, la base de
données définit DIAGNOSTIC_DEST au démarrage, de la façon suivante : Si la variable
d'environnement ORACLE_BASE est définie, DIAGNOSTIC_DEST prend la valeur
$ORACLE_BASE. Si la variable d'environnement ORACLE_BASE n'est pas définie,
DIAGNOSTIC_DEST prend la valeur $ORACLE_HOME/log.

Outil de ligne de commande ADR (ADRCI)
• ADRCI permet d'interagir avec le référentiel ADR à partir
d'une invite du système d'exploitation.
• Grâce à ADRCI, vous pouvez consulter les données de
diagnostic figurant dans le référentiel ADR.
$ adrci
ADRCI: Release 12.1.0.1.0 - Production on Thu Nov 29 21:15:27 2012
Copyright (c) 1982, 2012, Oracle and/or its affiliates. All rights
reserved.
ADR base = "/u01/app/oracle" ADRCI> set editor gedit
ADRCI> ADRCI> show alert
ADRCI> show incident
. . .
ADR Home = /u01/app/oracle/diag/rdbms/em12rep/em12rep:
*************************************************************************
INCIDENT_ID PROBLEM_KEY CREATE_TIME
----------- ----------------- ------------------------
4985 ORA 4031 2012-11-21 00:57:43.823000 +00:00
5161 ORA 4031 2012-11-21 00:58:17.284000 +00:00
2 incident info records fetched
ADRCI est un outil de ligne de commande qui fait partie de l'infrastructure permettant
l'établissement de diagnostics de panne pour les bases de données. ADRCI vous permet de :
• consulter les données de diagnostic au sein du référentiel ADR
• regrouper les informations relatives aux incidents et aux problèmes dans un fichier ZIP à
transmettre au support technique Oracle.
ADRCI peut être utilisé en mode interactif ou à l'aide de scripts. De plus, ADRCI peut exécuter
des scripts de commandes ADRCI de la même manière que SQL*Plus exécute des scripts de
commandes SQL et PL/SQL. Aucune étape de connexion à ADRCI n'est requise, car il n'a pas
été prévu de sécuriser les données figurant dans le référentiel ADR. Ces données sont
uniquement sécurisées par les autorisations du système d'exploitation affectées aux répertoires
ADR.
Le moyen le plus simple de packager et de gérer les données de diagnostic est d'utiliser
l'interface Support Workbench d'Enterprise Manager (qui aide à résoudre les erreurs de base de
données et les erreurs ASM).
ADRCI fournit une alternative en mode ligne de commande à la plupart des fonctionnalités de
Support Workbench et ajoute d'autres fonctions telles que la consignation et la recherche dans
les fichiers trace. L'exemple de la diapositive illustre une session ADRCI dans laquelle vous
répertoriez tous les incidents ouverts stockés dans le référentiel ADR.
Remarque : Pour plus d'informations sur ADRCI et Support Workbench, reportez-vous au manuel
Oracle Database Utilities.

Vue V$DIAG_INFO
SQL> SELECT NAME, VALUE FROM V$DIAG_INFO;
NAME VALUE
------------------- -------------------------------------------------
Diag Enabled TRUE
ADR Base /u01/app/oracle
ADR Home /u01/app/oracle/diag/rdbms/orcl/orcl
Diag Trace /u01/app/oracle/diag/rdbms/orcl/orcl/trace
Diag Alert /u01/app/oracle/diag/rdbms/orcl/orcl/alert
Diag Incident /u01/app/oracle/diag/rdbms/orcl/orcl/incident
Diag Cdump /u01/app/oracle/diag/rdbms/orcl/orcl/cdump
Health Monitor /u01/app/oracle/diag/rdbms/orcl/orcl/hm
Default Trace File /u01/app/oracle/diag/.../trace/orcl_ora_11424.trc
Active Problem Count 3
Active Incident Count 8
La vue V$DIAG_INFO répertorie tous les principaux emplacements pour le référentiel ADR :
• ADR Base : Chemin de la base ADR.
• ADR Home : Chemin du répertoire d'origine ADR pour l'instance de base de données en
cours.
Remarque : Il s'agit d'un nom de chemin. Il n'existe pas de variable d'environnement
officielle nommée ADR_HOME.
• Diag Trace : Emplacement du fichier texte d'alertes et des fichiers trace des processus en
arrière-plan/avant-plan.
• Diag Alert : Emplacement d'une version XML du fichier d'alertes.
• Diag Incident : Emplacement pour l'écriture des journaux d'incidents.
• Diag Cdump : Répertoire dans lequel sont écrits les dumps noyau (core dumps) pour le
diagnostic.
• Health Monitor : Emplacement des journaux issus de l'exécution de Health Monitor.
• Default Trace File : Chemin d'accès du fichier trace associé à votre session. Des
fichiers trace SQL sont écrits à cet emplacement.

Interpréter les messages RMAN
Des informations RMAN pour la résolution de problèmes sont

disponibles aux emplacements suivant :
• Sortie de la commande RMAN
• Fichier trace RMAN
• Fichier d'alertes
• Fichier trace du serveur Oracle
• Fichier sbtio.log
La sortie de la commande RMAN contient les actions pertinentes pour le travail RMAN, ainsi que
les messages d'erreur générés par RMAN, le serveur et le fabricant du média. Les messages
d'erreur RMAN sont identifiés par le préfixe RMAN-nnnn. La sortie s'affiche sur le terminal (sortie
standard) mais elle peut être consignée dans un fichier si vous définissez l'option LOG ou la
redirection en shell.
Le fichier trace RMAN contient la sortie DEBUG. Il n'est utilisé que lorsque vous vous servez de
l'option de commande TRACE.
Le fichier d'alertes contient un journal chronologique des erreurs, des paramètres d'initialisation
non définis par défaut et des opérations d'administration. Dans la mesure où il enregistre les
valeurs des enregistrements remplacés du fichier de contrôle, il peut être utile pour la
maintenance RMAN en l'absence de catalogue de restauration.
Le fichier trace Oracle contient la sortie détaillée générée par les processus serveur Oracle. Il est
créé à l'apparition d'un message d'erreur ORA-600 ou ORA-3113 (suivant un message ORA-
7445), chaque fois que RMAN ne peut pas allouer un canal et en cas d'échec du chargement de
la bibliothèque de gestion des supports (MML, Media Management Library).
Le fichier sbtio.log contient des informations propres au fabricant, écrites par le logiciel de gestion
des supports et se trouvant dans USER_DUMP_DEST. Notez que ce journal ne contient pas les
erreurs RMAN, ni celles du serveur Oracle.

Option DEBUG
• L'option DEBUG est utilisée pour :

– afficher le code PL/SQL généré
– déterminer précisément l'emplacement où se produit le
blocage ou l'erreur d'une commande RMAN
• L'option DEBUG est définie à l'invite RMAN ou dans un bloc
run.
• L'option DEBUG génère une quantité très importante
d'informations, de sorte qu'il est nécessaire de rediriger la
sortie vers un fichier trace :
$ rman target / catalog rman/rman debug trace trace.log
L'option DEBUG affiche toutes les instructions SQL exécutées au cours des compilations RMAN,
ainsi que les résultats de ces exécutions. Toute information générée par les packages PL/SQL du
catalogue de restauration s'affiche également. Dans l'exemple suivant, la sortie DEBUG est écrite
pendant la sauvegarde du fichier de données 3, mais pas du fichier de données 4 :
RMAN> run {
debug on;
allocate channel c1 type disk;
backup datafile 3;
debug off;
backup datafile 4; }
N'oubliez pas que la sortie de la commande DEBUG peut être volumineuse. Il est donc essentiel
de disposer de suffisamment d'espace disque pour le fichier trace. La session de sauvegarde
simple suivante, qui ne génère aucune erreur, crée un fichier trace d'environ un demi mégaoctet :
$ rman target / catalog rman/rman debug trace sample.log
RMAN> backup database;
RMAN> host "ls –l sample.log";
-rw-r--r-- 1 user02 dba 576270 Apr 6 10:38 sample.log
host command complete

Interpréter les piles d'erreurs RMAN
• Lisez la pile de bas en haut.
• Recherchez le texte Additional information.
• Le code RMAN-03009 identifie la commande qui a échoué.
RMAN-00571: ===========================================
RMAN-00569: ======= ERROR MESSAGE STACK FOLLOWS =======
RMAN-00571: ===========================================
RMAN-03009: failure of backup command on c1 channel at
09/04/2012 13:18:19
ORA-19506: failed to create sequential file,
name="07d36ecp_1_1", parms=""
ORA-27007: failed to open file
SVR4 Error: 2: No such file or directory
Additional information: 7005
Additional information: 1
ORA-19511: Error from media manager layer,error text:
En raison de la quantité de données enregistrée par RMAN, il peut s'avérer difficile d'identifier les
messages utiles dans la pile d'erreurs RMAN. Tenez compte des conseils et des suggestions ci-
après :
• Dans la mesure où bon nombre des messages de la pile d'erreurs ne sont pas utiles pour la
résolution des problèmes, essayez d'identifier les quelques erreurs les plus importantes.
• Recherchez les lignes avec le texte Additional information suivi d'un nombre entier.
Ces lignes indiquent une erreur du gestionnaire de support. L'entier qui suit fait référence à
un code expliqué dans le texte du message d'erreur.
• Lisez les messages de bas en haut car RMAN les génère dans cet ordre. La pile se termine
souvent par une ou deux erreurs informatives.
• Recherchez le message RMAN-03002 ou RMAN-03009 situé juste après l'en-tête. Le
message RMAN-03009 est le même que RMAN-03002, mais il comprend l'ID de canal. Si le
problème est lié à une commande RMAN, ces messages mentionnent la commande
concernée. Les erreurs de syntaxe génèrent une erreur RMAN-00558.

Data Recovery Advisor
• Détection, analyse et réparation rapides des défaillances

• Réduction des perturbations pour les utilisateurs
• Défaillances empêchant l'exécution et défaillances en
cours d'exécution
• Interfaces utilisateur :
– Interface graphique EM (plusieurs chemins)
– Ligne de commande RMAN
• Configurations de base de données prises en charge :
– Mono-instance
– Pas RAC
– Prise en charge du basculement vers une base de secours
en cas de panne, mais pas de fonctionnalités d'analyse et de
réparation des bases de secours
La fonction Data Recovery Advisor collecte automatiquement les informations sur les problèmes
de données lorsqu'une erreur est détectée. Elle peut, par ailleurs, effectuer une recherche
proactive des défaillances éventuelles. Dans ce mode, elle détecte les défaillances et les analyse
avant qu'un processus de base de données ne soulève le problème de corruption et ne signale
une erreur. (Notez que les réparations sont toujours sous contrôle manuel.)
Les défaillances de données peuvent être très graves. Par exemple, en l'absence des fichiers de
journalisation actuels, vous ne pouvez pas démarrer la base. Toutefois, certaines défaillances
(comme les corruptions de blocs dans les fichiers de données) ont des conséquences moindres
car elles ne mettent pas la base hors service ou n'empêchent pas de démarrer l'instance Oracle.
La fonction de conseil Data Recovery Advisor permet de gérer ces deux cas de figure, à savoir
lorsque la base ne peut pas être démarrée (les fichiers de base de données requis étant
manquants, incohérents ou endommagés) et lorsque des corruptions de fichier sont détectées
lors de l'exécution.

Interfaces utilisateur
La fonction de conseil Data Recovery Advisor est disponible à partir d'Enterprise Manager (EM)
Cloud Control et dans RMAN. En cas de défaillance, vous pouvez y accéder de plusieurs manières.
Les exemples suivants partent tous de la page d'accueil de l'instance de base de données :
• Availability > Backup & Recovery > Perform Recovery > Advise and Recover
• lien Active Incidents > page "Problems" de Support Workbench : onglet Checker Findings >
Launch Recovery Advisor
• Database Instance Health > clic sur le lien approprié (par exemple, ORA 1578 dans la section
Incidents) > Support Workbench, page Problems Detail > Data Recovery Advisor
• Database Instance Health > section Related Links : Support Workbench > onglet Checker
Findings : Launch Recovery Advisor
• Related Link: Advisor Central > onglet Advisors : Data Recovery Advisor
• Related Link: Advisor Central > onglet Checkers : Details > onglet Run Detail : Launch
Recovery Advisor
Vous pouvez également utiliser cette fonction via la ligne de commande RMAN, par exemple :
rman target / nocatalog
rman> list failure all;
Configurations de base de données prises en charge
Dans la version actuelle, Data Recovery Advisor prend en charge les bases de données mono-
instances. Les environnements Oracle Real Application Clusters (RAC) ne sont pas pris en charge.
Data Recovery Advisor ne sait pas utiliser les blocs ou les fichiers transférés depuis une base de
données de secours pour réparer les défaillances d'une base principale. D'autre part, cette fonction
ne peut être utilisée pour diagnostiquer et réparer les défaillances d'une base de secours. En
revanche, elle prend en charge le basculement vers une base de secours en tant qu'option de
réparation (comme indiqué plus haut).

Data Recovery Advisor
Réduction du temps d'arrêt en supprimant toute confusion :
1. Evaluer les défaillances de données. Health Monitor
2. Classer les défaillances par ordre de gravité.

Data
3. Demander un conseil. Recovery
Advisor
4. Choisir une solution et l'exécuter.
5. Effectuer des vérifications proactives. DBA
Dans Oracle Database 11g, le workflow de diagnostic automatique fonctionne comme indiqué ci-
après. Avec Data Recovery Advisor, vous devez simplement lancer la fonction de conseil, puis
exécuter la solution associée.
1. Health Monitor exécute automatiquement les vérifications. Il consigne des échecs et leurs
symptômes en tant que résultats (Findings) dans le référentiel ADR.
2. La fonction de conseil Data Recovery Advisor exprime les résultats sous forme de
défaillances. Elle répertorie les résultats des évaluations de défaillances précédemment
exécutées par degré de gravité (critique ou élevée).
3. Lorsque vous demandez un conseil pour réparer une défaillance, Data Recovery Advisor
détermine des options automatiques et manuelles, vérifie leur faisabilité et vous propose
une solution.
4. Vous pouvez choisir d'exécuter manuellement une réparation ou demander à Data
Recovery Advisor de s'en charger.
5. En plus des vérifications automatiques (essentiellement "réactives") de Health Monitor et de
Data Recovery Advisor, Oracle recommande d'utiliser la commande VALIDATE pour un
contrôle "proactif".

Défaillances de données : Exemples
• Impossibilité d'accéder à des composants,
par exemple :
– Fichiers de données manquants au niveau
du système d'exploitation
– Permissions d'accès non valides
– Tablespace hors ligne, etc.
• Corruptions physiques : Echecs de checksum de bloc ou
valeurs de champ non valides dans un en-tête de bloc
• Corruptions logiques : Dictionnaire incohérent, morceau de
ligne endommagé, entrée d'index non valide ou transaction
corrompue
• Incohérences : Fichier de contrôle plus ancien/récent que les
fichiers de données et les fichiers de journalisation en ligne
• Echecs d'E/S : Dépassement du nombre limite de fichiers
ouverts, canaux inaccessibles, erreur réseau ou d'E/S
Les défaillances de données sont détectées par des vérifications définies dans le cadre des
procédures de diagnostic de l'état de la base de données ou de ses composants. Chaque
vérification peut diagnostiquer une ou plusieurs défaillances et déterminer la réparation
appropriée.
Une vérification peut être réactive ou proactive. Lorsqu'une erreur se produit dans la base, des
vérifications réactives sont exécutées automatiquement. Vous pouvez également lancer des
vérifications proactives, notamment en exécutant la commande VALIDATE DATABASE.
Dans Cloud Control, accédez à la page Perform Recovery si vous détectez que votre base de
données est en état arrêté ou monté.
La fonction de conseil Data Recovery Advisor peut analyser les défaillances et suggérer des
options de réparation, comme illustré dans la diapositive.

Data Recovery Advisor :
Interface de ligne de commande RMAN
Commande RMAN Action

LIST FAILURE Affiche une évaluation de défaillances précédemment
exécutée
ADVISE FAILURE Affiche l'option de réparation recommandée
REPAIR FAILURE Répare et ferme des défaillances (après ADVISE dans

la même session RMAN)
CHANGE FAILURE Modifie ou ferme une ou plusieurs défaillances
Si vous constatez ou suspectez une défaillance de base de données, utilisez la commande LIST
FAILURE pour obtenir des informations à son sujet. Vous pouvez afficher la totalité ou un sous-
ensemble des défaillances et limiter la sortie de différentes manières. Les défaillances sont
identifiées de manière unique par un numéro. Notez que ces numéros ne sont pas consécutifs.
Les écarts n'ont aucune signification.
La commande ADVISE FAILURE affiche une option de réparation recommandée pour les
défaillances indiquées. Elle affiche une synthèse de la défaillance en entrée et ferme
implicitement toutes les défaillances ouvertes qui ont été réparées. Lorsqu'aucune option n'est
utilisée, le comportement par défaut consiste à donner des conseils sur toutes les défaillances de
priorité CRITICAL et HIGH enregistrées dans le référentiel ADR.
La commande REPAIR FAILURE est utilisée après une commande ADVISE FAILURE au sein
de la même session RMAN. Par défaut, elle utilise l'unique recommandation de réparation de la
dernière commande ADVISE FAILURE exécutée dans la session en cours. En l'absence de
recommandation, la commande REPAIR FAILURE lance une commande ADVISE FAILURE
implicite. Une fois la réparation terminée, la commande ferme la défaillance.
La commande CHANGE FAILURE modifie la priorité ou ferme une ou plusieurs défaillances. Vous
pouvez seulement modifier les priorités HIGH et LOW. Les défaillances ouvertes sont fermées
implicitement lorsqu'elles sont réparées. Toutefois, vous pouvez également fermer une
défaillance de façon explicite.

Afficher la liste des défaillances de données
La commande RMAN LIST FAILURE affiche les évaluations
de défaillances exécutées précédemment :
• Les défaillances qui viennent d'être diagnostiquées
sont incluses.
• Les défaillances fermées sont supprimées
(par défaut).
Syntaxe :
LIST FAILURE
[ ALL | CRITICAL | HIGH | LOW | CLOSED |
failnum[,failnum,…] ]
[ EXCLUDE FAILURE failnum[,failnum,…] ]
[ DETAIL ]
La commande RMAN LIST FAILURE affiche la liste des défaillances. Si l'instance cible utilise un
catalogue de restauration, elle peut être en mode STARTED. Sinon, elle doit être en mode
MOUNTED. La commande LIST FAILURE ne lance pas de vérifications pour diagnostiquer de
nouvelles défaillances. Elle affiche les résultats d'évaluations exécutées précédemment.
L'exécution répétée de la commande LIST FAILURE revalide toutes les défaillances existantes.
Si de nouvelles défaillances sont détectées, elles sont affichées. Si un utilisateur résout
manuellement des défaillances ou si des défaillances transitoires disparaissent, Data Recovery
Advisor les supprime de la sortie de la commande LIST FAILURE. Voici une description de la
syntaxe :
• failnum : Numéro de la défaillance pour laquelle il faut afficher des options de réparation.
• ALL : Affichage de toutes les défaillances, quelle que soit leur priorité.
• CRITICAL : Affichage des défaillances de priorité CRITICAL dont le statut est OPEN. Ces
défaillances nécessitent une attention immédiate car elles rendent la base de données
totalement indisponible (il peut s'agir, par exemple, d'un fichier de contrôle manquant).
• HIGH : Affichage des défaillances de priorité HIGH dont le statut est OPEN. Ces défaillances
rendent la base de données partiellement indisponible ou irrécupérable ; elles doivent donc
être réparées rapidement (par exemple, en cas de fichiers de journalisation archivés
manquants).

• LOW : Affichage des défaillances de priorité LOW dont le statut est OPEN. Ces défaillances
peuvent attendre que des défaillances plus prioritaires soient résolues.
• CLOSED : Liste des défaillances fermées uniquement.
• EXCLUDE FAILURE : Permet d'exclure de la liste les numéros de défaillance indiqués.
• DETAIL : Permet d'afficher les défaillances avec tous les détails associés. Par exemple, si
un fichier présente plusieurs corruptions de bloc, l'option DETAIL répertorie chacune d'elles.
Pour plus de détails sur la syntaxe de la commande, reportez-vous au manuel Oracle Database
Backup and Recovery Reference.

Obtenir un conseil de réparation
La commande RMAN ADVISE FAILURE :

• affiche une synthèse des défaillances en entrée
• inclut un avertissement si de nouvelles défaillances sont
apparues dans le référentiel ADR
• affiche une liste de vérifications manuelles
• recommande une seule réparation
• génère un script de réparation (pour une réparation
automatique ou manuelle)
. . .
Repair script:
/u01/app/oracle/diag/rdbms/orcl/orcl/hm/reco_2979
128860.hm
RMAN>
La commande RMAN ADVISE FAILURE affiche une option de réparation recommandée pour les
défaillances indiquées. Elle affiche une synthèse de la défaillance indiquée en entrée. Elle ferme
implicitement toutes les défaillances ouvertes qui ont été réparées.
Lorsqu'aucune option n'est utilisée, le comportement par défaut consiste à donner des conseils
sur toutes les défaillances de priorité CRITICAL et HIGH enregistrées dans le référentiel ADR. Si
une nouvelle défaillance a été enregistrée dans le référentiel ADR depuis la dernière commande
LIST FAILURE, elle affiche un message d'avertissement (WARNING) avant de fournir un conseil
sur les défaillances présentant la priorité CRITICAL ou HIGH.
Deux options générales de réparation peuvent être implémentées : sans ou avec perte de
données.
Lorsque la fonction de conseil Data Recovery Advisor propose une option de réparation
automatisée, elle génère un script qui indique comment RMAN compte réparer le problème. Si
vous ne voulez pas effectuer la réparation automatiquement, vous pouvez utiliser ce script
comme point de départ d'une réparation manuelle. L'emplacement du script au niveau du
système d'exploitation est affiché à la fin du résultat de la commande. Vous pouvez analyser,
personnaliser (si nécessaire) ou exécuter manuellement ce script, par exemple si cela est
recommandé par les informations de la trace d'audit.
Syntaxe
ADVISE FAILURE
[ ALL | CRITICAL | HIGH | LOW | failnum[,failnum,…] ]
[ EXCLUDE FAILURE failnum [,failnum,…] ]

Exécuter les réparations
La commande RMAN REPAIR FAILURE :

• suit la commande ADVISE FAILURE
• répare la défaillance indiquée
• ferme la défaillance réparée
Syntaxe :
REPAIR FAILURE
[USING ADVISE OPTION integer]
[ { {NOPROMPT | PREVIEW}}...]
Cette commande doit être utilisée après une commande ADVISE FAILURE exécutée dans la
même session RMAN. Par défaut (sans option explicite), elle utilise l'unique recommandation de
réparation de la dernière commande ADVISE FAILURE exécutée dans la session en cours. En
l'absence de recommandation, la commande REPAIR FAILURE lance une commande ADVISE
FAILURE implicite.
Avec USING ADVISE OPTION integer, vous indiquez le numéro de l'option de réparation
voulue par son numéro (provenant de la commande ADVISE FAILURE) ; il ne s'agit pas du
numéro de l'erreur.
Par défaut, vous êtes invité à confirmer l'exécution de la commande car des modifications
substantielles peuvent être requises. Au cours de l'exécution de la réparation, la sortie de la
commande indique la phase actuellement déployée.
Une fois la réparation terminée, la commande ferme la défaillance.
Il est impossible d'exécuter plusieurs sessions de réparation simultanées. En revanche,
les sessions REPAIR … PREVIEW simultanées sont autorisées.
• PREVIEW signifie : Ne pas exécuter les réparations, mais afficher le script RMAN généré
précédemment avec l'ensemble des actions de réparation et commentaires.
• NOPROMPT signifie : Ne pas afficher d'invite de confirmation.

Classifier (et fermer) les défaillances
La commande RMAN CHANGE FAILURE est utilisée pour :

• modifier la priorité d'une défaillance (sauf la priorité CRITICAL)
• fermer une ou plusieurs défaillances
Exemple :
RMAN> change failure 5 priority low;

List of Database Failures
=========================
Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- -------
5 HIGH OPEN 20-DEC-06 one or more
datafiles are missing
Do you really want to change the above failures (enter YES or
NO)? yes
changed 1 failures to LOW priority
La commande CHANGE FAILURE permet de modifier la priorité ou de fermer une ou plusieurs

défaillances.
Syntaxe
CHANGE FAILURE
{ ALL | CRITICAL | HIGH | LOW | failnum[,failnum,…] }
[ EXCLUDE FAILURE failnum[,failnum,…] ]
{ PRIORITY {CRITICAL | HIGH | LOW} |
CLOSE } – Change le statut en "closed" (fermé).
[ NOPROMPT ] – Ne pas demander confirmation à l'utilisateur.
La priorité d'une défaillance ne peut être changée que de HIGH en LOW et de LOW en HIGH. La
modification du niveau de priorité CRITICAL génère une erreur. (Par exemple, vous pouvez
modifier la priorité d'une défaillance de HIGH à LOW pour que celle-ci ne s'affiche plus dans la liste
générée par défaut par la commande LIST FAILURE. Ainsi, si une corruption de bloc présente la
priorité HIGH et que le bloc concerné figure dans un tablespace peu utilisé, vous pouvez changer
temporairement la priorité en LOW.)
Les défaillances ouvertes sont fermées implicitement lorsqu'elles sont réparées. Toutefois, vous
pouvez également fermer une défaillance de façon explicite. Cela nécessite une ré-évaluation de
toutes les défaillances ouvertes car certaines peuvent devenir inutiles suite à cette fermeture.
Par défaut, la commande invite l'utilisateur à confirmer la modification demandée.

Vues de la fonction de conseil Data Recovery Advisor
Vues V$ :
• V$IR_FAILURE : Liste de toutes les défaillances, y
compris celles qui ont été fermées (résultat de la
commande LIST FAILURE)
• V$IR_MANUAL_CHECKLIST : Liste des réparations
manuelles conseillées (résultat de la commande ADVISE
FAILURE)
• V$IR_REPAIR : Liste des réparations (résultat de
la commande ADVISE FAILURE)
• V$IR_FAILURE_SET : Correspondance
entre les identifiants des défaillances
et ceux des réparations conseillées
Pour obtenir des détails sur les vues dynamiques utilisées par Data Recovery Advisor, reportez-
vous au manuel Oracle Database Reference.

Quiz
Data Recovery Advisor gère aussi bien les cas où vous ne

pouvez pas démarrer la base de données (car des fichiers de
base de données requis sont manquants, incohérents ou
endommagés) que ceux où des corruptions de fichier sont
repérées lors de l'exécution.
a. Vrai
b. Faux
Réponse : a

Quiz
Après l'exécution de la commande ADVISE FAILURE, la

réparation est effectuée automatiquement. Vous n'avez plus le
contrôle.
a. Vrai
b. Faux
Réponse : b

Quiz
Le référentiel ADR réside dans la base de données. Par

conséquent, pour l'analyse des incidents, il faut qu'une instance
soit montée.
a. Vrai
b. Faux
Réponse : b

Définition de la corruption de bloc
• Chaque fois qu'un bloc fait l'objet d'une lecture ou

d'une écriture, une vérification de cohérence est effectuée.
– Version du bloc
– Adresse du bloc de données dans le cache par rapport à
l'adresse du bloc de données dans la mémoire tampon de
bloc
– Checksum de bloc, si activé
• On distingue deux types de corruption de bloc :
– Corruption physique
– Corruption logique (ou logicielle)
Un bloc de données corrompu (endommagé) est un bloc qui n'est pas dans un format Oracle
reconnu ou dont le contenu n'est pas cohérent en interne. En général, les corruptions sont
provoquées par du matériel défectueux ou par des problèmes du système d'exploitation. La base
de données Oracle distingue deux types de corruption : la "corruption logique" et la "corruption
physique". Une corruption logique suppose une erreur interne Oracle. Les blocs faisant l'objet
d'une corruption logique sont marqués comme endommagés par la base Oracle dès lors qu'une
incohérence est détectée. Dans le cas d'une corruption physique, le bloc a un format incorrect.
Les informations lues à partir du disque n'ont aucun sens.
Comme nous venons de le voir, plusieurs défaillances et corruptions de données peuvent être
réparées avec Data Recovery Advisor. Nous allons maintenant étudier la méthode manuelle.
Vous pouvez réparer une corruption physique de bloc en récupérant le bloc et/ou en supprimant
l'objet de base de données qui le contient. Si une corruption physique est due à du matériel
défectueux, le problème ne sera pas totalement résolu tant que la défaillance matérielle n'aura
pas été corrigée.

Symptômes d'une corruption de bloc :
ORA-01578
L'erreur ORA-01578: "ORACLE data block corrupted
(file # %s, block # %s)" :
• est générée lorsqu'un bloc de données endommagé est
trouvé
• renvoie toujours le numéro de fichier et le numéro de bloc
relatifs
• est renvoyée à la session associée à l'interrogation en
cours lorsque la corruption a été découverte
• apparaît dans le fichier alert.log
En général, l'erreur ORA-01578 est due à un problème matériel. Lorsqu'elle renvoie toujours les
mêmes arguments, il est probable qu'un bloc fait l'objet d'une corruption physique.
Si les arguments changent chaque fois, il peut s'agir d'un problème matériel et vous devez vérifier
la mémoire et l'espace de stockage (page), ainsi que rechercher la présence éventuelle de
contrôleurs défectueux dans le sous-système d'E/S.
Remarque : ORA-01578 renvoie le numéro de fichier relatif, mais l'erreur ORA-01110 associée
affiche le numéro absolu.

Comment traiter une corruption
• Examinez le fichier d'alertes et le fichier journal du système
d'exploitation.
• Utilisez les outils de diagnostic afin de déterminer le type de
corruption. Inclure les objets
dépendants, par exemple
• Déterminez si l'erreur persiste en un index de table
exécutant plusieurs fois les vérifications.
ANALYZE TABLE emp VALIDATE STRUCTURE CASCADE ONLINE;
• Récupérez si nécessaire les données

à partir de l'objet endommagé. Pendant l'exécution du
code DML
• Résolvez les éventuels problèmes matériels :
– Cartes mémoire
– Contrôleurs de disque
– Disques
• Récupérez ou restaurez si nécessaire les données à partir de
l'objet endommagé.
Tentez toujours de déterminer si l'erreur est permanente. Exécutez la commande ANALYZE

plusieurs fois ou, si possible, procédez à un arrêt et à un redémarrage, puis tentez de nouveau
d'effectuer l'opération qui a échoué précédemment. Déterminez s'il existe d'autres corruptions. Si
vous en détectez, cela peut signifier qu'il existe d'autres blocs endommagés.
Les défaillances matérielles doivent être traitées immédiatement. Lorsque vous êtes confronté à
des problèmes matériels, contactez le fabricant et procédez aux vérifications et réparations
nécessaires avant de continuer. Une session complète de diagnostics matériels doit être lancée.
De nombreux types de défaillance matérielle sont possibles :
• Hardware ou firmware d'E/S défectueux
• Problème d'E/S ou de mise en cache du système d'exploitation
• Problèmes de mémoire ou de pagination
• Utilitaires de réparation de disque
Pour plus d'informations, reportez-vous au manuel Oracle Database Administrator’s Guide.

Définir les paramètres pour la détection des corruptions
... Eviter les corruptions de la mémoire et des données
Détecter les corruptions des systèmes de stockage,

des systèmes d'E/S et des disques
...
Détecter les écritures non persistantes dans la base de secours physique
• Cloud Control > Administration > Initialization Parameters

• EM Express > Configuration > Initialization Parameters
Conseil : Effectuez un test préalable car ces paramètres
ont un impact sur les performances.
Paramètres recommandés pour la détection de corruption de bloc :

• DB_BLOCK_CHECKING : Lance la vérification des blocs de base de données. Cela permet
souvent d'éviter la corruption de la mémoire et des données. (Option par défaut : FALSE ;
option recommandée : FULL ou MEDIUM)
• DB_BLOCK_CHECKSUM : Lance le calcul et le stockage d'un checksum dans l'en-tête de
cache de chaque bloc de données lors de son écriture sur le disque. Les checksums sont
utiles pour détecter les corruptions causées par les disques, les systèmes de stockage ou
les systèmes d'E/S sous-jacents. (Option par défaut : TYPICAL ; option recommandée :
FULL)
• DB_LOST_WRITE_PROTECT : Lance la recherche des "écritures perdues". Des pertes
d'écriture de bloc de données se produisent dans une base de secours physique lorsque le
sous-système d'E/S signale la fin de l'écriture d'un bloc qui n'a pas encore été entièrement
écrit dans l'espace de stockage persistant. Bien entendu, l'opération d'écriture a été
effectuée sur la base de données principale. (Option par défaut : NONE ; option
recommandée : TYPICAL)
Remarque : Chacun des paramètres définis pour la détection des corruptions de bloc a un impact
variable sur les performances et doit par conséquent être testé avant d'être utilisé en
environnement de production.

Restauration physique de bloc
La restauration physique de bloc :
• réduit la durée moyenne de récupération (MTTR)
• augmente la disponibilité au cours d'une restauration physique
– Le fichier de données reste en ligne au cours de la récupération.
– Seuls les blocs en cours de récupération sont inaccessibles.
• est appelée à l'aide de la commande RMAN RECOVER...BLOCK
– Elle restaure les blocs à l'aide de journaux Flashback et de
sauvegardes complètes ou incrémentielles de niveau 0.
– La restauration physique est réalisée à l'aide de fichiers de
journalisation.
• La vue V$DATABASE_BLOCK_CORRUPTION
affiche les blocs marqués comme endommagés.
Dans la plupart des cas, la base de données marque un bloc comme faisant l'objet d'une
corruption physique, puis l'écrit sur le disque à la première rencontre de la corruption. Aucune
lecture ultérieure du bloc ne réussira tant que ce dernier n'aura pas été récupéré. Vous ne pouvez
procéder à une récupération que sur des blocs marqués comme endommagés ou signalés lors
d'une vérification de corruption. La restauration physique de bloc (BMR) est réalisée à l'aide de la
commande RECOVER...BLOCK. Par défaut, RMAN recherche dans les journaux Flashback des
copies valides des blocs, puis recherche ces blocs dans des sauvegardes complètes ou de
niveau 0. Lorsque RMAN trouve des copies valides, il les restaure et procède à une restauration
physique sur les blocs. La restauration physique de bloc ne peut utiliser que des fichiers de
journalisation, pas de sauvegardes incrémentielles.
La vue V$DATABASE_BLOCK_CORRUPTION affiche les blocs marqués comme endommagés par
des composants de base de données (commandes RMAN, commande ANALYZE, utilitaire dbv,
interrogations SQL, etc.) Les types de corruption suivants entraînent l'ajout de lignes dans cette
vue :
• Corruption physique : La base de données ne reconnaît pas le bloc ; le checksum n'est
pas valide, le bloc ne contient que des zéros ou l'en-tête du bloc est fracturé. La vérification
de corruption physique est activée par défaut.
• Corruption logique : Le bloc présente un checksum valide, l'en-tête et la fin du bloc
correspondent, mais le contenu est incohérent. La restauration physique de bloc ne peut
pas réparer une corruption logique du bloc. La vérification de corruption logique est
désactivée par défaut. Vous pouvez l'activer en indiquant l'option CHECK LOGICAL dans les
commandes BACKUP, RESTORE, RECOVER et VALIDATE.

Prérequis à la restauration physique de bloc
• La base de données cible doit être en mode ARCHIVELOG.

• Les sauvegardes des fichiers de données contenant
les blocs endommagés doivent être des sauvegardes
complètes ou incrémentielles de niveau 0.
– Pour pouvoir être utilisées, les copies proxy doivent être
restaurées à un emplacement autre que celui par défaut.
• Pour la récupération, RMAN ne peut utiliser que des
fichiers de journalisation archivés.
• Un bloc de données corrompu peut être restauré à partir
des journaux Flashback s'ils sont disponibles.
Les prérequis suivants s'appliquent à la commande RECOVER ... BLOCK :

• La base de données cible doit être exécutée en mode ARCHIVELOG et être ouverte ou
montée avec un fichier de contrôle en cours.
• Les sauvegardes des fichiers de données contenant les blocs endommagés doivent être
des sauvegardes complètes ou incrémentielles de niveau 0, et non des copies proxy (copies
déléguées à un système tiers). S'il existe seulement des sauvegardes de type copie proxy,
vous pouvez les restaurer à un emplacement autre que celui par défaut sur le disque,
auquel cas RMAN les considère comme des copies de fichiers de données et y recherche
les blocs lors de la restauration physique de bloc.
• Pour la récupération, RMAN ne peut utiliser que des fichiers de journalisation archivés
(archived redo logs). Les sauvegardes incrémentielles de niveau 1 ne peuvent donc pas
être prises en compte. En outre, la restauration physique de bloc ne peut pas survivre à un
fichier de journalisation archivé manquant ou inaccessible, bien qu'elle puisse parfois
survivre à des enregistrements de journalisation manquants.
• La fonctionnalité Flashback Database doit être activée sur la base de données cible pour
permettre à RMAN de rechercher dans les journaux Flashback des copies valides des blocs
endommagés. Si la journalisation Flashback est activée et contient des versions plus
anciennes et non endommagées des blocs, RMAN peut les utiliser pour éventuellement
accélérer la récupération.

Récupérer des blocs individuels
La commande RMAN RECOVER...BLOCK :
• identifie les sauvegardes contenant les blocs à récupérer
• lit les sauvegardes et accumule les blocs demandés dans
des tampons en mémoire
• gère la session de restauration physique de bloc en lisant
les fichiers de journalisation archivés à partir de la
sauvegarde si nécessaire
RECOVER DATAFILE 6 BLOCK 3; Récupérer un seul bloc
RECOVER Récupérer plusieurs blocs
DATAFILE 2 BLOCK 43 Dans plusieurs fichiers de données
DATAFILE 2 BLOCK 79
DATAFILE 6 BLOCK 183;
RECOVER CORRUPTION LIST; Récupérer tous les blocs
journalisés dans
V$DATABASE_BLOCK_CORRUPTION
La récupération des blocs requiert l'identification préalable des blocs endommagés. En général,
les corruptions de bloc sont signalées aux emplacements suivants :
• Résultats de la commande LIST FAILURE, VALIDATE ou BACKUP ... VALIDATE
• Vue V$DATABASE_BLOCK_CORRUPTION
• Messages d'erreur dans la sortie standard
• Fichier d'alertes et fichiers trace utilisateur (identifiés dans la vue V$DIAG_INFO)
• Résultats des commandes SQL ANALYZE TABLE et ANALYZE INDEX
• Résultats de l'utilitaire DBVERIFY
Par exemple, vous pouvez découvrir les messages suivants dans un fichier trace utilisateur :
ORA-01578: ORACLE data block corrupted (file # 7, block # 3)
ORA-01110: data file 7: '/oracle/oradata/orcl/tools01.dbf'
ORA-01578: ORACLE data block corrupted (file # 2, block # 235)
ORA-01110: data file 2: '/oracle/oradata/orcl/undotbs01.dbf'
Une fois que les blocs sont identifiés, exécutez la commande RECOVER ... BLOCK à l'invite
RMAN en précisant les numéros de fichier et de bloc concernés.
RECOVER
DATAFILE 7 BLOCK 3
DATAFILE 2 BLOCK 235;

Méthode recommandée : Vérifications proactives
Lancer un contrôle proactif de l'état de la base de données et

de ses composants :
• Health Monitor ou commande RMAN VALIDATE
DATABASE
• Détection des corruptions logiques et physiques
• Consignation des résultats dans le référentiel ADR
Pour les bases de données très volumineuses, vous souhaiterez peut-être exécuter des
vérifications proactives supplémentaires (par exemple, quotidiennement pendant les périodes de
faible activité). Vous pouvez planifier des contrôles périodiques de l'état du système via le
vérificateur Health Monitor ou la commande RMAN VALIDATE. En règle générale, lorsqu'un
contrôle réactif détecte une ou plusieurs défaillances dans un composant de base de données, il
est préférable d'effectuer une vérification plus poussée de ce composant.
La commande RMAN VALIDATE DATABASE permet de lancer des contrôles de l'état de la base
de données et de ses composants. Elle étend la commande VALIDATE BACKUPSET existante.
Tout problème détecté lors de la validation est affiché. Les problèmes déclenchent l'exécution
d'une évaluation des défaillances. Si une défaillance est détectée, elle est consignée dans le
référentiel ADR en tant que résultat. Vous pouvez utiliser la commande LIST FAILURE pour
afficher toutes les défaillances enregistrées dans le référentiel.
La commande VALIDATE prend en charge la validation de blocs de données et de jeux de
sauvegarde individuels. Dans le cas d'une corruption physique, la base de données ne reconnaît
pas du tout le bloc. Dans le cas d'une corruption logique, le contenu du bloc est logiquement
incohérent. Par défaut, la commande VALIDATE ne recherche que les corruptions physiques.
Vous pouvez indiquer l'option CHECK LOGICAL pour rechercher également les corruptions
logiques.
Les corruptions de bloc peuvent être interblocs ou intrablocs. Dans le cas d'une corruption
intrabloc, la corruption se produit dans le bloc lui-même et peut être physique ou logique. Dans le
cas d'une corruption interbloc, la corruption se produit entre des blocs et ne peut être que logique.
La commande VALIDATE ne recherche que les corruptions intrablocs.

Rechercher les corruptions de bloc
• La commande VALIDATE :
– analyse les fichiers désignés et vérifie leur contenu
– vérifie que les fichiers de données existent et se trouvent à
l'emplacement correct
– recherche les blocs de données endommagés
– peut vérifier des jeux de sauvegarde et des blocs de
données spécifiques
– ignore les blocs qui n'ont jamais été utilisés
– affiche les défaillances et les consigne dans le référentiel
ADR
• Précisez l'option CHECK LOGICAL pour rechercher à la fois
les corruptions physiques et logiques.
• Interrogez la vue V$DATABASE_BLOCK_CORRUPTION
pour examiner les résultats.
La commande VALIDATE permet de rechercher manuellement les corruptions physiques et

logiques dans des fichiers de base de données. Vous pouvez également utiliser la commande
BACKUP VALIDATE, mais seule la commande VALIDATE permet de vérifier des jeux de
sauvegarde et des blocs de données spécifiques.
Pour plus de détails concernant la syntaxe, reportez-vous au manuel Oracle Database Backup
and Recovery Reference.

Réparation automatique de blocs : Base principale
• Les blocs endommagés de la base principale sont réparés

automatiquement à l'aide de blocs provenant d'une base
de secours physique.
• L'interrogation en temps réel doit être activée sur la base
Réparation automatique de blocs
Base Base de secours Interrogations

principale physique avec
interrogation
en temps réel
La fonctionnalité de réparation automatique des blocs utilise les blocs d'une base de secours
physique pour effectuer une récupération de blocs sans intervention manuelle. Elle nécessite que
l'interrogation en temps réel soit activée sur la base de secours physique.
Quand une interrogation est exécutée sur une base de secours physique configurée avec
l'interrogation en temps réel et qu'un bloc endommagé est détecté, un bloc valide est extrait de la
base principale.
Quand un bloc endommagé est détecté au cours d'une opération de récupération sur la base de
secours, le processus de récupération extrait un bloc valide de la base principale.
Cette fonctionnalité réduit le délai pendant lequel les données de production ne sont pas
accessibles à cause d'une corruption de bloc en réparant automatiquement cette corruption dès
qu'elle est détectée. Le délai de récupération des blocs est réduit car les blocs utilisés pour la
réparation ne proviennent pas de sauvegardes sur disque ou bande mais sont des blocs valides
et à jour trouvés dans une base de secours physique synchronisée accessible en temps réel.
Remarque : La réparation automatique de bloc s'applique uniquement aux corruptions physiques
(lorsque le checksum n'est pas valide, que le bloc ne contient que des zéros ou que l'en-tête de
bloc est fracturé).
L'interrogation en temps réel fait partie de l'option Oracle Active Data Guard.

Réparation automatique de blocs :
Base de secours physique
• Les blocs endommagés de la base de secours physique
sont réparés automatiquement à l'aide de blocs de la base
principale.
• L'interrogation en temps réel doit être activée sur la base
Réparation automatique de blocs
Base Base de secours Interrogations

principale physique avec
interrogation
en temps réel
La réparation automatique de blocs s'applique également aux corruptions de blocs de la base de

secours physique. Une restauration physique est effectuée à l'aide de blocs extraits de la base
principale. Pour tirer profit de cette fonctionnalité, il faut que l'interrogation en temps réel soit
activée sur la base de secours physique.

Synthèse

• détecter une corruption de la base de données et y remédier
– examiner le référentiel ADR (Automatic Diagnostic Repository)
– utiliser les commandes RMAN de réparation de données pour :
— répertorier les défaillances
— obtenir un conseil de réparation
— réparer les défaillances
– effectuer des vérifications proactives de défaillances
• gérer les corruptions de bloc :
– vérifier l'intégrité des blocs en temps réel
– effectuer une restauration physique de bloc
– rechercher proactivement et traiter les corruptions de blocs

Diagnostiquer une défaillance de base de données

– repérer des défaillances avec Data Recovery Advisor
– réparer des défaillances
• L'exercice 9-2 vous apprend à effectuer et analyser une
récupération d'instance avec ADRCI.
• Dans l'exercice 9-3, vous utiliserez Data Recovery Advisor
pour détecter et réparer une corruption de bloc.
• Le premier exercice crée volontairement une défaillance de base de données en supprimant

un fichier de données dans le système de fichiers. Vous utilisez Data Recovery Advisor pour
repérer cette défaillance et vous la réparez à l'aide d'un script généré par la fonction de
conseil.
• Le deuxième exercice vous initie à l'utilisation d'ADRCI.
• Le troisième exercice traite de la corruption de bloc. Vous utilisez Data Recovery Advisor
pour repérer le problème et vous le réparez à l'aide d'un script généré par cette fonction de
conseil.

Concepts de restauration et de récupération

Objectifs

• comprendre comment utiliser la meilleure technologie
de récupération Oracle Database en fonction de votre
situation
• décrire la récupération d'instance ou la récupération
après panne
• décrire la récupération complète
• décrire la récupération jusqu'à un point dans le temps
• décrire la récupération via RESETLOGS
Vous abordez le deuxième chapitre du module "Récupération" qui en comprend quatre, à savoir :

Comprendre la perte de fichier
• Une perte de fichier peut résulter des situations suivantes :

– Erreur de l'utilisateur
– Erreur d'application
– Défaillance physique
• La perte d'un fichier non critique n'empêche pas la base
de données de continuer à fonctionner.
• Elle peut être résolue de plusieurs manières :
– Création d'un nouveau fichier
– Reconstruction du fichier
– Récupération du fichier perdu ou endommagé
Des fichiers peuvent être perdus ou endommagés pour les raisons suivantes :
• Erreur de l'utilisateur : Un administrateur peut supprimer ou écraser par inadvertance un
fichier important du système d'exploitation.
• Erreur d'application : Une application ou un script peut contenir une erreur logique et, lors
du traitement de fichiers de base de données, provoquer la perte ou l'altération d'un fichier.
• Défaillance physique : Un lecteur ou un contrôleur de disque peut subir une défaillance
totale ou partielle provoquant l'altération (voire la perte totale) de fichiers.
Un fichier non critique est un fichier dont la base de données et la plupart des applications
peuvent se passer. Par exemple, si la base de données perd un fichier de journalisation
multiplexé, d'autres copies du fichier de journalisation peuvent être utilisées pour préserver
le fonctionnement de la base de données.
Bien que la perte d'un fichier non critique n'entraîne pas la panne de la base de données,
elle peut avoir un impact sur le fonctionnement de celle-ci, par exemple :
• La perte d'un tablespace d'index peut ralentir considérablement les applications et les
interrogations, voire rendre l'application inutilisable si les index servaient à appliquer
des contraintes.
• La perte d'un groupe de fichiers de journalisation en ligne, dès lors qu'il ne s'agit pas
du groupe en cours, peut entraîner la suspension des opérations de base de données
jusqu'à la génération de nouveaux fichiers journaux.

Techniques de réparation des données
Pour réagir aux pertes de données potentielles :
• Défaillance physique (fichier de données manquant ou
corrompu) :
– Data Recovery Advisor
– Restauration physique de fichier de données
– Récupération de bloc
• Défaillance logique (erreur d'une application ou
d'un utilisateur) :
– Fonctionnalités Flashback logiques
– Oracle Flashback Database
– Récupération jusqu'à un point dans le temps (PITR) :
— de la base de données (DBPITR)
— de tablespace (TSPITR)
— de table (TPITR)
Récapitulatif de ces techniques de réparation de données :

• La fonction de conseil Data Recovery Advisor peut diagnostiquer les défaillances,
recommander des solutions et appliquer celles-ci automatiquement.
• La restauration physique de fichier de données est une forme de restauration physique qui
permet de restaurer des sauvegardes de fichiers de données et d'appliquer des fichiers de
journalisation archivés (archived redo logs) ou des sauvegardes incrémentielles pour
récupérer les modifications perdues. Vous pouvez ainsi récupérer l'intégralité ou une partie
d'une base de données. La restauration physique de fichiers de données constitue la forme
la plus généraliste de récupération et elle peut s'appliquer aux défaillances physiques
comme logiques.
• La restauration physique de bloc est une forme de restauration physique qui permet de
récupérer des blocs individuels au sein d'un fichier de données (plutôt que le fichier tout
entier).
• Les fonctionnalités Flashback logiques permettent d'afficher ou de rétrograder des objets ou
des transactions de base de données spécifiques jusqu'à un moment du passé. Elles ne
nécessitent pas l'utilisation de RMAN.
• Oracle Flashback Database est un mécanisme de récupération au niveau bloc qui est
similaire à une restauration physique, sauf qu'il est généralement plus rapide et ne
nécessite pas de restaurer une sauvegarde. Vous pouvez renvoyer l'intégralité de votre
base de données à un état antérieur sans restaurer d'anciennes copies des fichiers de
données à partir d'une sauvegarde, à condition toutefois d'avoir activé la journalisation
Flashback à l'avance. Que ce soit pour Flashback Database ou pour les points de
restauration garantis, une zone de récupération rapide doit être configurée pour la
journalisation.

• La récupération jusqu'à un point dans le temps (PITR, point-in-time recovery) est un type
spécial de retour à un moment passé, également appelé récupération incomplète.
- La fonctionnalité DBPITR de RMAN restaure la base de données à partir de
sauvegardes antérieures au point de récupération ciblé, puis utilise des sauvegardes
incrémentielles et des fichiers de journalisation pour réimplémenter les modifications
jusqu'au point voulu.
- La fonctionnalité TSPITR de RMAN récupère un tablespace dans un état antérieur à
celui du reste de la base de données.
- La fonctionnalité TPITR de RMAN récupère une table dans un état antérieur. TSPITR
et TPITR utilisent une base de données auxiliaire.

Restauration et récupération
Restauration :
• de base de données RMAN assure automatiquement :
(tous les fichiers de données) • la sélection des sauvegardes
• de tablespaces • le basculement en cas de défaillance
• l'optimisation de la restauration
• de fichiers de contrôle etc.
• de fichiers de journalisation
archivés
• de fichiers de paramètres
serveur
Fichier de
journalisation
Récupération
Le module "Récupération" couvre deux types d'activités principaux : la restauration et la

récupération.
• La restauration d'un fichier consiste à copier une sauvegarde de ce fichier à la place du
fichier d'origine pour que la base de données puisse l'utiliser. Cela est nécessaire si, par
exemple, un fichier est endommagé en raison d'une défaillance du disque physique sur
lequel il se trouve. En général, ce type d'incident est dû à des problèmes matériels (erreurs
d'écriture sur disque par exemple) ou à une défaillance du contrôleur. Dans ce cas, une
sauvegarde du fichier doit être copiée sur un nouveau disque (ou un disque réparé). Les
types de fichier pouvant être restaurés sont indiqués dans la diapositive.
- RMAN utilise les enregistrements des jeux de sauvegarde ou copies d'image figurant
dans le référentiel RMAN pour choisir les meilleures sauvegardes disponibles. Si deux
sauvegardes ont la même date, RMAN privilégie les copies d'image par rapport aux
jeux de sauvegarde car elles sont plus rapides à restaurer (même constat pour les
sauvegardes sur disque par rapport aux sauvegardes sur bande).
- RMAN utilise automatiquement le basculement en cas de défaillance pour ignorer les
sauvegardes corrompues ou inaccessibles et rechercher des fichiers exploitables.
- Par défaut, RMAN ne restaure pas un fichier de données si celui-ci se trouve à
l'emplacement correct et que son en-tête contient les informations attendues, et ainsi
de suite.
• La récupération du fichier entraîne l'application d'informations de journalisation de façon à
avancer l'état du fichier dans le temps, jusqu'au point de votre choix. Ce point est
généralement aussi proche que possible de l'heure de la défaillance.
Dans le domaine des bases de données, ces deux opérations sont souvent désignées
collectivement par le terme "récupération".

Utiliser les commandes RMAN RESTORE et RECOVER
• La commande RESTORE permet de restaurer des fichiers

de base de données à partir d'une sauvegarde.
• La commande RECOVER récupère les fichiers restaurés
en appliquant les modifications enregistrées dans les
sauvegardes incrémentielles et les fichiers de
journalisation.
RMAN> ALTER TABLESPACE inv_tbs OFFLINE IMMEDIATE;
RMAN> RESTORE TABLESPACE inv_tbs;
RMAN> RECOVER TABLESPACE inv_tbs;
RMAN> ALTER TABLESPACE inv_tbs ONLINE;
• L'assistant de récupération de Cloud Control crée et

exécute un script RMAN pour effectuer la récupération.
La reconstitution de tout ou partie du contenu d'une base de données à partir d'une sauvegarde
implique généralement deux phases : extraction d'une copie du fichier de données à partir d'une
sauvegarde, puis réapplication des changements effectués depuis la sauvegarde à l'aide des
fichiers de journalisation archivés (archived redo logs) et en ligne (online redo logs), afin d'amener
la base de données jusqu'au numéro SCN souhaité (généralement le plus récent).
• RESTORE {DATABASE | TABLESPACE name [,name]... | DATAFILE name
[,name] }...
La commande RESTORE extrait le fichier de données sur disque à partir d'un emplacement
de sauvegarde sur bande, sur disque ou sur tout autre support, puis elle le met à la
disposition du serveur de base de données. RMAN restaure à partir d'une sauvegarde tous
les fichiers de journalisation archivés qui sont nécessaires pour l'opération de récupération.
Si des sauvegardes sont stockées sur un gestionnaire de support, des canaux doivent être
configurés ou alloués pour l'accès aux sauvegardes stockées à cet emplacement.
• RECOVER {DATABASE | TABLESPACE name [,name]... | DATAFILE name
[,name] }...
La commande RECOVER utilise la copie restaurée du fichier de données et lui applique les
modifications enregistrées dans les sauvegardes incrémentielles et les fichiers de
journalisation de la base de données.
Vous pouvez aussi effectuer une récupération complète ou jusqu'à un point dans le temps à l'aide
de l'assistant de récupération Recovery Wizard. A partir de la page d'accueil de la base de
données dans Cloud Control, accédez à Availability > Backup & Recovery > Perform Recovery.
Remarque : La fonction de conseil Data Recovery Advisor offre une méthode automatisée pour
détecter la nécessité d'une récupération et la réaliser.

Echec d'instance
Qui lance le redémarrage ?
Vous ou Oracle Restart ?
Causes typiques Solutions possibles

Panne de courant Redémarrez l'instance à l'aide de la
commande STARTUP. La
récupération suite à l'échec d'une
Défaillance matérielle instance est automatique,
notamment via la réimplémentation
des modifications des fichiers de
Echec d'un processus en arrière- journalisation, puis l'annulation des
plan d'importance critique transactions non validées.
Procédures d'arrêt d'urgence

Recherchez les causes d'échec à
l'aide du fichier d'alertes, des fichiers
trace et de Cloud Control.
Un échec d'instance se produit lorsque l'instance de base de données s'arrête avant que tous les
fichiers de la base soient synchronisés. Il peut être provoqué par une défaillance matérielle ou
logicielle ou par les commandes d'arrêt d'urgence SHUTDOWN ABORT et STARTUP FORCE.
Il est rarement nécessaire que l'administrateur intervienne pour remédier à un échec d'instance si
Oracle Restart est activé et surveille la base de données. Oracle Restart essaie de redémarrer
l'instance dès que l'échec se produit. Si une intervention manuelle est requise, il y a sans doute
un problème plus sérieux qui empêche le redémarrage, par exemple une défaillance de CPU.

Comprendre la récupération d'instance
La récupération automatique d'instance ou la récupération après

panne :
• est provoquée par des tentatives d'ouverture d'une base de
données dont les fichiers n'ont pas été synchronisés lors de
l'arrêt
• utilise les informations stockées dans les groupes de fichiers
de journalisation pour effectuer la synchronisation
• implique deux opérations distinctes :
1. Réimplémentation dans les fichiers de données des
modifications (validées ou non) enregistrées dans les fichiers
de journalisation
2. Annulation des modifications qui ont été implémentées mais
ne sont pas validées
La base de données Oracle se rétablit automatiquement après un échec d'instance. Il suffit pour
cela que l'instance soit démarrée normalement. Si Oracle Restart est activé et configuré pour
surveiller la base de données concernée, ce démarrage se produit automatiquement. L'instance
monte les fichiers de contrôle, puis tente d'ouvrir les fichiers de données. Si elle découvre que les
fichiers de données n'ont pas été synchronisés lors de l'arrêt, elle utilise les informations
contenues dans les groupes de fichiers de journalisation pour réimplémenter les modifications
dans les fichiers de données jusqu'à l'instant de l'arrêt. Une fois la base de données ouverte, les
transactions non validées sont annulées (rollback).

Phases de la récupération d'instance
1. Démarrage de l'instance (fichiers
de données non synchronisés)
Instance
2. Réimplémentation des modifications
(informations de journalisation) SGA
3. Les fichiers contiennent des données validées
et non validées Processus
en arrière-plan
4. Ouverture de la base de données
5. Annulation des modifications
non validées Base de données
6. Les fichiers contiennent SCN :

des données validées SCN : 140 SCN : 143 74-101
SCN:
SCN : 129 SCN : 143 102-143
Annulation
SCN: 99
Fichiers Groupe de
Fichiers de de fichiers de
données contrôle journalisation
Pour qu'une instance puisse ouvrir un fichier de données, le numéro SCN (System Change
Number) contenu dans l'en-tête du fichier doit correspondre au numéro SCN stocké dans les
fichiers de contrôle de la base.
Si les numéros ne correspondent pas, l'instance applique les données des fichiers de
journalisation en ligne, en réexécutant de manière séquentielle les transactions jusqu'à ce que les
fichiers de données soient à jour. Une fois que tous les fichiers de données ont été synchronisés
avec les fichiers de contrôle, la base de données est ouverte et les utilisateurs peuvent s'y
connecter.
Lors de l'application des fichiers de journalisation, toutes les transactions sont implémentées afin
de rétablir la base dans l'état où elle se trouvait au moment de l'échec. Parmi ces transactions,
certaines étaient probablement en cours et n'avaient pas encore été validées (commit). Une fois
la base de données ouverte, ces transactions non validées sont annulées (rollback).
A la fin de la phase d'annulation de la récupération d'instance, les fichiers de données
contiennent uniquement des données validées.

Régler la récupération d'instance
• Au cours d'une récupération d'instance, les transactions

effectuées entre la position du point de reprise et la fin du
fichier de journalisation doivent être appliquées aux
fichiers de données.
• Le réglage consiste à contrôler la différence entre la
position du point de reprise et la fin du fichier de
journalisation.
Position du point Fin du fichier de

de reprise journalisation
Récupération d'instance
Transactions
Les informations relatives à une transaction sont enregistrées dans les groupes de fichiers de
journalisation avant que l'instance renvoie le message de validation commit complete de cette
transaction. Les informations des groupes de fichiers de journalisation garantissent que la
transaction pourra être récupérée en cas d'échec. Les informations de transaction doivent
également être écrites dans le fichier de données. L'écriture dans le fichier de données a
généralement lieu un peu après l'enregistrement des informations dans les groupes de fichiers de
journalisation, car elle est beaucoup plus lente que l'écriture des informations de journalisation.
(L'écriture est aléatoire dans les fichiers de données et séquentielle dans les journaux.)
Toutes les trois secondes, le processus de point de reprise (checkpoint) enregistre dans le fichier
de contrôle des informations concernant la position du point de reprise dans le fichier de
journalisation. Ainsi, la base de données Oracle sait que toutes les entrées de journalisation
enregistrées avant ce point ne sont pas nécessaires pour la récupération. Dans le graphique de la
diapositive, les blocs à rayures roses n'ont pas encore été écrits sur le disque.
Le temps nécessaire à la récupération de l'instance correspond au temps nécessaire pour rétablir
les fichiers de données de leur état au moment du dernier point de reprise jusqu'à l'état
correspondant au dernier numéro SCN enregistré dans le fichier de contrôle. L'administrateur
contrôle cet instant en définissant une durée moyenne de récupération (MTTR) cible (en
secondes), ainsi que la taille des groupes de fichiers de journalisation. Par exemple, pour deux
groupes de fichiers de journalisation, la distance entre la position du point de reprise et la fin du
groupe ne peut pas dépasser 90 % de la taille du plus petit groupe.
La lecture des blocs de données auxquels les informations de journalisation sont appliquées
implique évidemment un délai supplémentaire.

Utiliser MTTR Advisor
• Indiquez la durée souhaitée en secondes.

• La valeur par défaut est 0 (désactivé).
• La valeur maximum est 3 600 secondes (une heure).
SQL> ALTER SYSTEM SET fast_start_mttr_target =

30 SCOPE=BOTH;
Secondes
Le paramètre d'initialisation FAST_START_MTTR_TARGET simplifie la configuration du délai de

récupération après un échec d'instance ou une défaillance système. La fonction de conseil MTTR
Advisor convertit la valeur de FAST_START_MTTR_TARGET en plusieurs paramètres pour
permettre une récupération d'instance dans un délai aussi proche que possible de celui désiré.
Remarque : En affectant explicitement au paramètre FAST_START_MTTR_TARGET la valeur 0,
vous désactivez la fonction de conseil.
Le paramètre FAST_START_MTTR_TARGET doit être défini avec une valeur qui prend en charge
le contrat de niveau de service de votre système. Plus la durée MTTR cible est faible, plus la
surcharge d'E/S est importante en raison de l'écriture de fichiers de données supplémentaires (ce
qui a un impact sur les performances). En revanche, une valeur élevée augmente le temps de
récupération de l'instance.
Navigation : A partir de la page d'accueil de la base de données dans Cloud Control : Availability
> Backup & Recovery > Recovery Settings

Défaillance physique
Causes typiques Solutions possibles

Echec d'un disque 1. Restaurez le fichier affecté à
partir d'une sauvegarde.
2. Indiquez à la base de données
Echec d'un contrôleur de disque
un nouvel emplacement de
fichier (si nécessaire).
Suppression ou corruption d'un 3. Récupérez le fichier en
fichier nécessaire au fonctionnement appliquant les informations de
de la base de données journalisation (si nécessaire).
Oracle Corporation définit une défaillance physique comme une défaillance entraînant la perte ou
la corruption d'un ou de plusieurs fichiers de base de données (fichiers de données, de contrôle
ou de journalisation).
La récupération suite à une défaillance physique nécessite la restauration et la récupération des
fichiers manquants. Pour garantir que la base pourra être récupérée suite à une défaillance
physique, appliquez les méthodes recommandées décrites dans les pages qui suivent.

Comparaison entre récupération complète
et récupération incomplète
Une récupération peut avoir deux portées distinctes :
• Récupération complète : La base de données ou le tablespace retrouve
un état actuel, avec notamment toutes les modifications de données
validées jusqu'au point dans le temps où la récupération a été demandée
• Récupération jusqu'à un point dans le temps (PITR) ou incomplète :
La base de données ou le tablespace retrouve l'état correspondant à
un point spécifique du passé qui est antérieur au moment où l'opération
de récupération a été demandée
Moment de la
Récupération défaillance
complète
PITR
Heure de début
Restauration Transactions manquantes de la tâche de
à partir de cette après récupération incomplète récupération
sauvegarde
Lorsque vous effectuez une récupération complète, vous rétablissez la base de données dans
l'état le plus à jour, en incluant toutes les modifications validées jusqu'au moment présent.
En revanche, une récupération incomplète ramène la base de données ou le tablespace à un état
spécifique du passé. On parle aussi de "récupération jusqu'à un point dans le temps" (PITR,
Point-In-Time Recovery). Certaines transactions sont donc manquantes. Toute modification de
données effectuée entre le moment cible de la récupération et le temps présent est perdue. Ce
type de récupération est préférable dans bon nombre de cas, notamment lorsque des
modifications indésirables ont été apportées à la base de données et doivent être annulées. La
récupération jusqu'à un point du passé constitue un moyen de supprimer ces erreurs.

Processus de récupération complète
Journal
archivé
Journal
archivé
Journal
en ligne Application des
informations
Modifications d'annulation
appliquées
4
2
1 3 5
Fichiers de données Fichiers de données contenant
restaurés des transactions validées Fichiers de données
et non validées récupérés
La procédure qui suit décrit ce qui se produit au cours d'une récupération complète :
1. Les fichiers endommagés ou manquants sont restaurés à partir d'une sauvegarde.
2. Les modifications enregistrées dans les sauvegardes incrémentielles, dans les fichiers de
journalisation archivés et dans les fichiers de journalisation en ligne sont appliquées si
nécessaire. Les modifications des fichiers de journalisation sont appliquées aux fichiers de
données jusqu'au fichier de journalisation en ligne actuel et jusqu'à ce que les transactions
les plus récentes aient été réappliquées. Des blocs d'annulation sont générés tout au long
de cette procédure. Cette étape est appelée réimplémentation des modifications ou
récupération de cache.
3. Les fichiers de données restaurés peuvent à présent contenir des modifications validées
(commit) et des modifications non validées.
4. Les blocs d'annulation sont utilisés pour annuler (rollback) les modifications non validées.
Cette étape est parfois dite de récupération des transactions.
5. Les fichiers de données sont à présent rétablis dans un état cohérent avec les autres
fichiers de données de la base.

Récupération jusqu'à un point dans le temps
Journal
archivé
Journal
X
archivé
Journal
X
en ligne
Ouverture Application des
Application des modifications jusqu'à de la base informations
un point dans le temps de données d'annulation
2
4 5
1 3 6
Fichiers de données Fichiers de données contenant
restaurés remontant des transactions validées Fichiers de données
aussi loin dans le et non validées récupérés jusqu‘à
temps que nécessaire jusqu'à un point donné un point donné
La récupération jusqu'à un point dans le temps, ou récupération incomplète, utilise une

sauvegarde pour produire une version de la base de données qui n'est pas à jour. Autrement dit,
vous n'appliquez pas tous les enregistrements de journalisation générés après la sauvegarde la
plus récente. N'effectuez ce type de récupération qu'en cas d'absolue nécessité. Pour effectuer
une récupération jusqu'à un point dans le temps, vous avez besoin des éléments suivants :
• Une sauvegarde base fermée ou base ouverte valide de tous les fichiers de données,
effectuée avant le point de récupération.
• Tous les fichiers de journalisation archivés entre le moment de la sauvegarde et le point de
récupération choisi.
La procédure à suivre pour effectuer la restauration jusqu'à un point dans le temps est décrite
ci-après :
1. Restaurez les fichiers de données à partir de la sauvegarde. La sauvegarde utilisée doit
être antérieure au point de récupération visé. Vous pouvez soit copier les fichiers à l'aide de
commandes du système d'exploitation, soit utiliser la commande RMAN RESTORE.
2. Utilisez la commande RECOVER. Appliquez les informations de journalisation contenues
dans tous les fichiers journaux archivés nécessaires pour atteindre le point de récupération.

3. Vous obtenez une situation de récupération excessive. Les fichiers de données
contiennent des transactions validées, mais aussi des transactions non validées parce que les
fichiers de journalisation enregistrent les données sans attendre leur validation (commit)
4. Utilisez la commande ALTER DATABASE OPEN. Avant d'appliquer les informations
d'annulation, vous ouvrez la base de données pour offrir une plus grande disponibilité.
5. Appliquez les données d'annulation. Pendant l'application des informations de
journalisation, les informations concernant les fichiers de données d'annulation ont également
été appliquées. Les informations d'annulation peuvent donc être appliquées aux fichiers de
données pour annuler les transactions non validées. C'est l'objet de cette étape.
6. Le processus est terminé. Les fichiers de données ont récupéré l'état dans lequel ils se
trouvaient au moment que vous avez choisi comme point de récupération.
Oracle Flashback Database est l'alternative la plus efficace à la récupération d'une base de données
jusqu'à un point dans le temps (voir le chapitre "Utiliser Flashback Database"). A la différence des
autres fonctionnalités Flashback, elle fonctionne au niveau physique et rétablit le contenu des
fichiers de données actuels à un point donné dans le temps. Le résultat obtenu est équivalent à celui
d'une récupération de la base de données jusqu'à un point dans le temps, OPEN RESETLOGS inclus.
Toutefois, le processus Flashback Database est généralement plus rapide car il ne vous demande
pas de restaurer les fichiers de données et qu'il requiert une application limitée des informations de
journalisation par rapport à une restauration physique.

Récupération avec l'option RESETLOGS
• Problème : Il manque des fichiers de journalisation archivés

pour atteindre le SCN de récupération ciblé.
• Workflow :
1. Restaurez des sauvegardes.
2. Procédez à une récupération aussi loin que le permet la série
intègre de fichiers de journalisation.
3. Ouvrez la base de données en utilisant l'option RESETLOGS.
Une nouvelle incarnation de base de données est créée
automatiquement pour éviter toute confusion lorsque deux
flux d'informations de journalisation distincts présentent les
mêmes numéros SCN mais se produisent à des moments
différents.
Remarque : Les modifications postérieures au dernier fichier
de journalisation archivé que vous appliquez sont perdues.
La récupération jusqu'à un point dans le temps est la seule possibilité si vous devez effectuer une
récupération et que vous constatez qu'il manque un fichier de journalisation archivé contenant
des transactions intervenues entre le moment de la sauvegarde à partir de laquelle vous
effectuez la restauration et le numéro SCN ciblé par la récupération. En l'absence du fichier de
journalisation manquant, vous n'avez aucune trace des mises à jour apportées aux fichiers de
données au cours de cette période. La seule solution consiste à récupérer la base de données à
partir de l'instant correspondant à la sauvegarde restaurée, jusqu'à l'instant le plus avancé pour
lequel vous disposez d'une série ininterrompue de fichiers de journalisation archivés, puis à ouvrir
la base de données avec l'option RESETLOGS. Toutes les modifications effectuées dans le fichier
de journalisation manquant ou postérieurement sont perdues.
Une incarnation de base de données "en cours" est créée lorsque vous ouvrez une base avec
l'option RESETLOGS. L'incarnation dont elle est issue est appelée "incarnation parent". Un numéro
d'incarnation est utilisé pour étiqueter et identifier de manière unique chaque flux d'informations
de journalisation.
Une fois la récupération terminée, vous pouvez reprendre des opérations normales sans utiliser
OPEN RESETLOGS. Toutefois, après une récupération de base de données jusqu'à un point dans
le temps ou une récupération avec un fichier de contrôle de sauvegarde, vous devez ouvrir la
base avec l'option RESETLOGS de manière à créer une nouvelle incarnation. La base de données
requiert une nouvelle incarnation afin d'éviter toute confusion lorsque deux flux de données de
journalisation distincts présentent les mêmes numéros SCN mais interviennent à des moments
différents. Si vous appliquez les informations de journalisation incorrectes à votre base de
données, elle sera corrompue.
L'existence de plusieurs incarnations d'une même base détermine la manière dont RMAN traite
les sauvegardes qui ne figurent pas dans chemin de l'incarnation en cours. En général,
l'incarnation en cours est celle qu'il convient d'utiliser.

Quiz
Quelles technologies Oracle permettent de récupérer les

erreurs logiques de la base de données ?
a. Technologies Flashback
b. LogMiner
c. RMAN TSPITR (récupération de tablespace jusqu'à un
point dans le temps)
Réponses : a, b, c

Quiz
Parmi les opérations suivantes, lesquelles ont lieu au cours

d'une récupération d'instance ?
a. Les fichiers de données sont restaurés à partir de
sauvegardes.
b. Les modifications effectuées par des transactions validées
ou non validées sont appliquées aux fichiers de données
via les fichiers de journalisation.
c. Les effets des transactions non validées sont annulés.
Réponses : b, c

Quiz
Pour effectuer une récupération jusqu'à un point dans le temps,

il faut restaurer tous les fichiers de données à l'aide de
sauvegardes effectuées avant le point de récupération ciblé.
a. Vrai
b. Faux
Réponse : a

Quiz
Oracle Flashback Database est la plus efficace alternative à

une récupération de base de données jusqu'à un point dans le
temps car elle ne nécessite pas que vous restauriez les fichiers
de données et qu'elle requiert une application limitée
d'informations de journalisation par rapport à une restauration
physique.
a. Vrai
b. Faux
Réponse : a

Synthèse

• déterminer la meilleure technologie de récupération
d'Oracle Database en fonction de votre situation de
défaillance
• décrire la récupération d'instance ou récupération après
panne
• décrire la récupération complète
• décrire la récupération jusqu'à un point dans le temps

Déterminer des procédures de récupération
L'exercice 10-1 est une étude de cas. Il montre comment
déterminer la meilleure approche de récupération en fonction
d'un ensemble donné de circonstances.
Dans cet exercice, vous allez étudier les circonstances d'une défaillance et la configuration de la
sauvegarde pour déterminer une stratégie de restauration et de récupération.

Etude de cas 1
Des sauvegardes sont effectuées lors d'un arrêt nocturne, avec une stratégie de
sauvegarde incrémentielle. Une sauvegarde de niveau 1 est appliquée chaque
nuit à la sauvegarde de niveau 0 précédente. La commande ARCHIVE LOG
LIST affiche le résultat suivant :
SQL> archive log list
Database log mode No Archive Mode
Automatic archival Disabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 61
Next log sequence to archive 63
Current log sequence 63
Un disque contenant les fichiers de données du tablespace SYSAUX tombe

en panne.
1. Une récupération complète est-elle possible ? Quelles sont les étapes à
suivre ?
2. Si une récupération complète n'est pas possible, comment procéder pour
récupérer un maximum de données ? Quelles données (transactions) sont
perdues ?

Etude de cas 2
Des sauvegardes base ouverte sont effectuées de nuit, avec une

stratégie de sauvegarde incrémentielle. Une sauvegarde de niveau 1
est appliquée chaque nuit à la sauvegarde de niveau 0 précédente.
La commande ARCHIVE LOG LIST affiche le résultat suivant :
SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 61
Next log sequence to archive 63
Current log sequence 63
Un fichier de données qui fait partie du tablespace de l'application et
contient des données critiques est perdu.
Décrivez la procédure à suivre pour effectuer une récupération
complète.

Etude de cas 3
Les effets d'un traitement batch qui ne s'est pas exécuté

correctement hier soir à 20h ont été supprimés à l'aide d'une
récupération incomplète jusqu'à 18h, après quoi la base a été
ouverte.
Les vérifications effectuées à la suite de la récupération
révèlent que certaines transactions cruciales antérieures
à 19h15 ne figurent pas dans la base de données.
1. Quelles sont des options valides pour récupérer ces
transactions ?
2. Décrivez les conditions requises pour récupérer ces
transactions.

Procéder à une récupération I

Objectifs

• effectuer les opérations de restauration et de récupération
appropriées en fonction de la nature de la défaillance de
votre base de données
• récupérer des fichiers de données à la suite de
défaillances physiques
• procéder à des récupérations complètes et incomplètes
(jusqu'à un point dans le temps)
Vous abordez le troisième chapitre du module "Récupération" qui en comprend quatre, à savoir :

Vérifier que des sauvegardes sont disponibles
Commande RMAN Action
RESTORE PREVIEW RMAN indique les sauvegardes et les fichiers de

journalisation archivés qu'il utilise pour restaurer et
récupérer la base de données jusqu'au point dans le
temps indiqué.
RESTORE VALIDATE RMAN détermine les jeux de sauvegarde, copies des

fichiers de données et fichiers de journalisation
archivés qui ont besoin d'être restaurés, puis les
valide.
RECOVER VALIDATE Signale et valide les sauvegardes que RMAN pourrait

HEADER utiliser pour restaurer les fichiers nécessaires à la
récupération.
Utilisez les commandes suivantes pour vous assurer que toutes les sauvegardes nécessaires
sont disponibles et pour déterminer si vous devez prescrire à RMAN d'utiliser ou d'éviter des
sauvegardes spécifiques :
• RESTORE PREVIEW : Affiche les sauvegardes et les fichiers de journalisation archivés que
RMAN peut utiliser pour restaurer et récupérer la base de données jusqu'au point dans le
temps indiqué. RMAN interroge les métadonnées, mais ne lit pas réellement les fichiers de
sauvegarde. Le résultat de cette commande présente le même format que celui de la
commande LIST BACKUP.
• RESTORE VALIDATE : Indique que RMAN doit décider quels jeux de sauvegarde, copies de
fichiers de données et fichiers de journalisation archivés ont besoin d'être restaurés, puis les
valider. Aucun fichier n'est restauré. Pour les fichiers sur disque et sur bande, RMAN lit tous
les blocs de l'élément de sauvegarde ou de la copie d'image. RMAN valide également les
sauvegardes hors site.
• RECOVER VALIDATE HEADER : Signale et valide les sauvegardes que RMAN peut utiliser
pour restaurer les fichiers nécessaires à la récupération. Lorsque vous exécutez la
commande RECOVER VALIDATE HEADER, RMAN effectue les mêmes opérations que pour
la commande RESTORE PREVIEW. En revanche, en plus de répertorier les fichiers
nécessaires à la restauration et à la récupération, il valide les en-têtes des fichiers de
sauvegarde pour déterminer si les fichiers sur disque ou dans le catalogue de gestion des
supports correspondent à ce qui est indiqué dans les métadonnées de son référentiel.
RMAN vous permet de valider des bases de données Conteneur (CDB) et des bases de données
pluggables (PDB). Ces types de base sont traités dans le cours Oracle Database 12c: Managing
Multitenant Architecture.

Effectuer une restauration en mode
NOARCHIVELOG
Si la base de données est en mode NOARCHIVELOG et qu'un
fichier de données est perdu, procédez de la manière suivante :
2. Restaurez l'intégralité de la base à partir de la sauvegarde,
y compris les fichiers de données et de contrôle.
4. Informez les utilisateurs qu'ils doivent entrer à nouveau
toutes les modifications qu'ils ont effectuées depuis la
dernière sauvegarde.
La perte d'un fichier de données (quel qu'il soit) dans une base de données en mode
NOARCHIVELOG nécessite une restauration complète de la base, y compris des fichiers de
contrôle et de tous les fichiers de données.
Lorsque la base est en mode NOARCHIVELOG, il n'est possible de récupérer que l'état de la plus
récente sauvegarde. Par conséquent, les utilisateurs doivent de nouveau entrer toutes les
modifications qui ont été apportées depuis cette sauvegarde.
Pour effectuer ce type de récupération :
2. Dans la page Maintenance Properties, cliquez sur Perform Recovery.
3. Sélectionnez le type de récupération Whole Database.
Si vous avez une base de données en mode NOARCHIVELOG qui utilise une stratégie de
sauvegarde incrémentielle, RMAN restaure d'abord le niveau 0 le plus récent, puis la récupération
RMAN applique les sauvegardes incrémentielles.

Récupération à l'aide de sauvegardes incrémentielles
en mode NOARCHIVELOG
Les sauvegardes incrémentielles permettent d'effectuer une

récupération limitée d'une base de données en mode
NOARCHIVELOG.
Dans SQL*Plus ou RMAN :
STARTUP FORCE NOMOUNT;

RESTORE CONTROLFILE;
ALTER DATABASE MOUNT;
RESTORE DATABASE;
RECOVER DATABASE NOREDO;
ALTER DATABASE OPEN RESETLOGS;
Vous pouvez effectuer une récupération limitée d'une base de données en mode NOARCHIVELOG
à l'aide des sauvegardes incrémentielles. Ces dernières doivent être cohérentes.
Si vous avez effectué des sauvegardes incrémentielles, RMAN utilise les sauvegardes de
niveau 0 et 1 pour restaurer et récupérer la base.
Vous devez indiquer l'option NOREDO dans la commande RECOVER DATABASE si les fichiers de
journalisation en ligne sont perdus ou si les informations de journalisation ne peuvent pas être
appliquées aux sauvegardes incrémentielles. Si vous ne spécifiez pas l'option NOREDO, RMAN
recherche les fichiers de journalisation en ligne après avoir appliqué les sauvegardes
incrémentielles. Si ces fichiers ne sont pas disponibles, il émet un message d'erreur.
Si les fichiers de journalisation en ligne en cours contiennent toutes les modifications depuis la
dernière sauvegarde incrémentielle, vous pouvez exécuter la commande RECOVER DATABASE
sans l'option NOREDO. Les modifications seront appliquées.
Remarque : Vous devez restaurer le fichier de contrôle uniquement s'il n'est pas à jour.

Effectuer une récupération complète
Perte d'un fichier de données non critique en mode

ARCHIVELOG :
• Si un fichier de données est perdu ou endommagé et que
ce fichier n'appartient pas au tablespace SYSTEM ou UNDO,
vous restaurez et récupérez le fichier manquant pendant
que la base de données est ouverte.
• La récupération peut aller jusqu'au moment de la dernière
validation (commit) et les utilisateurs ne sont pas obligés
d'entrer à nouveau certaines données.
Lorsque la base de données est en mode ARCHIVELOG, la perte d'un fichier de données, quel
qu'il soit tant qu'il n'appartient pas au tablespace SYSTEM ou UNDO, affecte uniquement les objets
figurant dans le fichier manquant. Le reste de la base de données est toujours disponible pour les
utilisateurs.
Pour restaurer et récupérer le fichier de données manquant :
1. Dans Cloud Control, accédez à la page Perform Recovery.
2. Choisissez le type de récupération Datafiles et sélectionnez l'option "Recover to current
time".
3. Ajoutez tous les fichiers de données à récupérer.
4. Déterminez si vous voulez restaurer les fichiers vers l'emplacement par défaut ou (en cas de
disque ou de contrôleur manquant) vers un nouvel emplacement.
5. Lancez le travail RMAN afin de restaurer et de récupérer les fichiers manquants.
Comme la base de données est en mode ARCHIVELOG, la récupération peut aller jusqu'au
moment de la dernière validation (commit) et les utilisateurs n'ont pas besoin d'entrer à nouveau
leurs données les plus récentes.

Effectuer une récupération complète
Perte d'un fichier de données critique en mode ARCHIVELOG :

1. L'instance peut s'arrêter automatiquement, mais pas
toujours. Si nécessaire, utilisez la commande SHUTDOWN
ABORT pour l'arrêter.
2. Montez la base de données.
3. Restaurez et récupérez le fichier de données manquant.
Exécutez cette tâche dans
l'exercice pratique.
Les fichiers de données appartenant au tablespace SYSTEM ou contenant des données UNDO ont
une importance critique pour le système. La perte d'un de ces fichiers nécessite une restauration
de la base de données à partir de l'état MOUNT (à la différence d'autres fichiers de données qui
peuvent être restaurés pendant que la base est ouverte).
Pour procéder à cette récupération :
1. Arrêtez l'instance si ce n'est déjà fait.
3. Dans Cloud Control, accédez à la page Perform Recovery.
4. Choisissez le type de récupération Datafiles et sélectionnez l'option "Recover to current
time".
5. Ajoutez tous les fichiers de données à récupérer.
6. Déterminez si vous voulez restaurer les fichiers vers l'emplacement par défaut ou (en cas de
disque ou de contrôleur manquant) vers un nouvel emplacement.
7. Lancez le travail RMAN afin de restaurer et de récupérer les fichiers manquants.
8. Ouvrez la base de données. Les utilisateurs n'ont pas à entrer de nouveau certaines
données car la récupération va jusqu'au moment de la dernière validation (commit).

Restaurer des groupes de disques ASM
• Utilisez la commande ASMCMD md_restore pour

restaurer des groupes de disques ASM à partir d'un fichier
de sauvegarde de métadonnées.
• En cas de perte d'un groupe de disques ASM, le fichier de
sauvegarde de métadonnées permet de reconstruire ce
groupe et ses métadonnées au lieu de recréer le groupe
manuellement.
• Options de restauration :
– full : Crée un groupe de disques et restaure les
métadonnées
– nodg : Restaure les métadonnées uniquement
– newdg -o : Crée un groupe de disques nommé
différemment du groupe original et restaure les métadonnées
Vous pouvez utiliser la commande ASMCMD md_restore pour reconstruire un groupe

de disques ASM à partir d'un fichier de sauvegarde de métadonnées créé précédemment.
Ce fichier de sauvegarde est obtenu à l'aide de la commande ASMCMD md_backup. Si vous
perdez un groupe de disques ASM pour lequel il n'existe pas de fichier de sauvegarde des
métadonnées, vous devez le re-créer ce groupe manuellement.

Restaurer des groupes de disques ASM : Exemples
• Restaurer tous les groupes de disques du fichier de

métadonnées :
ASMCMD> md_restore /backup/asm_metadata --full
• Restaurer uniquement les métadonnées correspondant

au groupe de disques DATA :
ASMCMD> md_restore /backup/asm_metadata --nodg –G data
• Créer un script SQL pour restaurer le groupe de disques

DATA :
ASMCMD> md_restore /backup/asm_metadata –full
–S asmsql.sql –G data
Les exemples présentés dans la diapositive ci-dessus illustrent plusieurs options de la commande
ASMCMD md_restore.
Le troisième exemple crée un script SQL. Le groupe de disques n'est pas re-créé lorsque l'option
–S est utilisée.
Reportez-vous au manuel Oracle Automatic Storage Management Administrator’s Guide pour
plus d'informations sur la commande md_restore.

Rappels sur la récupération de copies d'image
RMAN peut récupérer des copies d'image à l'aide de
sauvegardes incrémentielles :
• Les copies d'image sont mises à jour avec toutes les
modifications jusqu'au SCN de la sauvegarde
incrémentielle.
• La sauvegarde incrémentielle réduit le temps requis pour
la restauration physique.
• Il n'est pas nécessaire d'effectuer une copie d'image après
la restauration incrémentielle.
RMAN> RECOVER COPY OF
2> DATAFILE {n|'file_name'}
Fichiers de
sauvegarde
incrémentielle
Copie d'image d'un
fichier de données
Vous pouvez utiliser RMAN pour appliquer des sauvegardes incrémentielles à des copies
d'image de fichiers de données. Avec cette méthode de récupération, vous utilisez RMAN pour
récupérer une copie d'un fichier de données, c'est-à-dire que vous réimplémentez (récupérez) les
modifications de la copie d'image jusqu'à un certain point dans le temps, via l'application des
sauvegardes incrémentielles. La copie d'image est mise à jour avec toutes les modifications
jusqu'au numéro SCN au niveau duquel la sauvegarde incrémentielle a été effectuée. RMAN
utilise ensuite le fichier de données actualisé résultant pour effectuer la restauration physique,
comme il utiliserait une copie d'image complète prise au niveau de ce numéro SCN. Cependant,
cela permet d'éviter la surcharge liée à l'exécution quotidienne d'une copie d'image complète de
la base de données. L'application de sauvegardes incrémentielles aux copies d'image de fichiers
de données présente les avantages suivants :
• La restauration physique (à l'aide de fichiers journaux archivés) est plus rapide, car il suffit
d'appliquer uniquement les fichiers journaux qui ont été archivés depuis la dernière
sauvegarde incrémentielle.
• Il est inutile d'effectuer une copie d'image complète après la restauration incrémentielle.
Si le processus de récupération échoue pendant l'application du fichier de sauvegarde
incrémentielle, relancez-le tout simplement. RMAN détermine automatiquement les fichiers de
sauvegarde incrémentielle à appliquer : ceux-ci peuvent être antérieurs à la copie d'image du
fichier de données et s'échelonner jusqu'au moment où vous voulez arrêter le processus de
récupération. S'il existe plusieurs versions d'une copie d'image dans le catalogue RMAN, RMAN
utilise automatiquement la dernière. RMAN signale une erreur s'il n'est pas en mesure de
fusionner un fichier de sauvegarde incrémentielle avec une copie d'image.

Récupérer des copies d'image : Exemple
Si vous exécutez les commandes suivantes quotidiennement :

RMAN> recover copy of database with tag 'daily_inc';
RMAN> backup incremental level 1 for recover of copy
2> with tag 'daily_inc' database;
Le résultat est le suivant :

RECOVER BACKUP
Jour 1 Rien Création de copies

d'image
Jour 2 Rien Création du niveau

d'incrément 1
A partir du Récupération de copies à partir Création du niveau

jour 3 d'une sauvegarde incrémentielle d'incrément 1
Si vous exécutez quotidiennement les commandes illustrées sur la diapositive, vous disposez à
tout moment de copies d'image à jour pour l'ensemble des fichiers de données de la base.
Le tableau indique les conséquences de chaque exécution. Notez que cet algorithme requiert une
configuration initiale ; la stratégie ne se réalise qu'après le jour 3.
• Jour 1 : La commande RECOVER ne fait rien. Il n'existe encore aucune copie d'image
à récupérer. La commande BACKUP crée les copies d'image.
• Jour 2 : La commande RECOVER ne fait toujours rien. Cela est dû à l'absence de
sauvegarde incrémentielle. Comme des copies d'image de référence ont été créées
le jour 1, la commande BACKUP crée la sauvegarde incrémentielle.
• Jour 3 : La commande RECOVER applique les modifications aux copies d'image à partir de
la sauvegarde incrémentielle. La commande BACKUP effectue une autre sauvegarde
incrémentielle qui sera utilisée pour récupérer les copies d'image le jour 4, et ainsi de suite.
Lors de l'implémentation de ce type de stratégie de sauvegarde, il est important d'utiliser
des balises. Celles-ci permettent de relier des sauvegardes incrémentielles particulières aux
copies d'image réalisées. Sans balise, la sauvegarde incrémentielle la plus récente (peut-être
incorrecte) serait utilisée pour récupérer les copies d'image.

Basculement rapide vers des copies d'image
Effectuez une récupération rapide Vous pouvez éventuellement
en procédant comme suit : remettre les fichiers à leur
1. Mettez les fichiers de données emplacement d'origine en
hors ligne. procédant comme suit :
2. Utilisez la commande SWITCH 5. Créez une copie d'image
TO ... COPY pour basculer des fichiers de données à
vers les copies d'image. leur emplacement d'origine.
3. Récupérez les fichiers de 6. Mettez les fichiers de
données. données hors ligne.
4. Mettez les fichiers de données 7. SWITCH TO ... COPY
en ligne. 8. Récupérez les fichiers de
données.
Les fichiers de données ont été
récupérés et sont maintenant utilisables 9. Mettez les fichiers de
à leur nouvel emplacement. données en ligne.
SQL> SWITCH DATAFILE 'filename' TO COPY;
Vous pouvez utiliser des copies d'image de fichiers de données en vue d'une récupération rapide
en procédant comme suit :
1. Mettez les fichiers de données hors ligne.
2. Utilisez la commande SWITCH TO ... COPY pour pointer vers la copie d'image
des fichiers.
3. Récupérez les fichiers de données.
4. Mettez les fichiers de données en ligne.
A ce stade, la base est utilisable et les fichiers de données ont été récupérés. Toutefois, si vous
souhaitez remettre ces derniers à leur emplacement d'origine, procédez comme suit :
5. Créez une copie d'image des fichiers de données à leur emplacement d'origine à l'aide de la
commande BACKUP AS COPY.
6. Mettez les fichiers de données hors ligne.
7. Basculez vers la copie que vous avez effectuée à l'étape 5 à l'aide de la commande SWITCH
TO COPY.
9. Mettez les fichiers de données en ligne.
Cette commande vous permet de récupérer des fichiers de données, des tablespaces, des
fichiers temporaires ou l'intégralité de la base de données. Les fichiers vers lesquels vous
basculez doivent être des copies d'image.

Utiliser la commande SET NEWNAME
pour basculer vers d'autres fichiers
• Utilisez la commande SET NEWNAME dans un bloc RUN pour effectuer
une restauration vers un emplacement autre que celui par défaut.
RUN
{ ALLOCATE CHANNEL dev1 DEVICE TYPE DISK;
ALLOCATE CHANNEL dev2 DEVICE TYPE sbt;
SQL "ALTER TABLESPACE users OFFLINE IMMEDIATE";
SET NEWNAME FOR DATAFILE '/disk1/oradata/prod/users01.dbf'
TO '/disk2/users01.dbf';
RESTORE TABLESPACE users;
SWITCH DATAFILE ALL;
RECOVER TABLESPACE users;
SQL "ALTER TABLESPACE users ONLINE";
}
• Au lieu de noms individuels, indiquez un format de nom par défaut

pour tous les fichiers d'une base ou d'un tablespace spécifique.
• Le nom par défaut est utilisé pour les commandes DUPLICATE,
RESTORE et SWITCH du bloc RUN.
La commande SET NEWNAME ne peut être utilisée qu'à l'intérieur d'un bloc RUN. Elle prépare un
mapping des noms pour les opérations ultérieures. Dans l'exemple de la diapositive, la
commande SET NEWNAME définit l'emplacement d'écriture pour une opération de restauration de
ce fichier de données. L'exécution de la commande RESTORE entraîne la restauration du fichier
de données users01.dbf vers /disk2/users01.dbf. Le fichier de données est écrit à cet
emplacement, mais le fichier de contrôle ne pointe toujours pas vers ce dernier. La commande
SWITCH entraîne la mise à jour du fichier de contrôle avec le nouvel emplacement.
Il est plus efficace d'utiliser la clause SET NEWNAME pour définir le format de nom par défaut pour
tous les fichiers de données d'un tablespace spécifique ou de la base (au lieu de définir chaque
nom individuellement comme dans les versions de base de données antérieures à Oracle
Database 11g Release 2).
L'ordre de priorité associé à la commande SET NEWNAME est le suivant :
1. SET NEWNAME FOR DATAFILE et SET NEWNAME FOR TEMPFILE
2. SET NEWNAME FOR TABLESPACE
3. SET NEWNAME FOR DATABASE

Utiliser des points de restauration
Un point de restauration attribue un nom à un point dans le temps :

• Maintenant :
SQL> CREATE RESTORE POINT before_mods;
• Dans le passé :
SQL> CREATE RESTORE POINT end_q1 AS OF SCN 100;
Chronologie
Vous pouvez attribuer un nom à un point dans le temps ou un numéro SCN particulier.
Cela permet par la suite de le référencer, notamment lors de la réalisation d'opérations
de flashback ou d'une récupération jusqu'à un point dans le temps.
• Le premier exemple de la diapositive crée un point de restauration qui correspond au
moment présent. Ainsi, si vous vous apprêtez à appliquer une mise à jour d'une application
ou de données dans la base, vous savez que vous pourrez revenir à l'état précédant
immédiatement la mise à jour en utilisant le point de restauration BEFORE_MODS.
• Le second exemple de la diapositive crée un point de restauration qui représente un SCN
passé : 100. Ce point de restauration peut être utilisé de la même manière que le précédent.
Normalement, les points de restauration sont gardés dans la base de données pendant au moins
la durée indiquée par le paramètre d'initialisation CONTROL_FILE_RECORD_KEEP_TIME.
Toutefois, lorsque vous créez un point de restauration, vous pouvez utiliser l'option PRESERVE
afin qu'il soit stocké jusqu'à ce que vous le supprimiez de façon explicite.
Les points de restauration sont listés dans la vue V$RESTORE_POINT avec leur nom, leur numéro
SCN, un horodatage et d'autres informations.

Effectuer une récupération jusqu'à
un point dans le temps
Pour effectuer une récupération jusqu'à un point dans le temps
gérée par le serveur, procédez comme suit :
1. Déterminez le point ciblé par la restauration : numéro
SCN, horodatage, point de restauration ou numéro de
séquence de journal.
2. Définissez les variables d'environnement NLS de façon
appropriée.
4. Préparez et exécutez un bloc RUN à l'aide des commandes
SET UNTIL, RESTORE et RECOVER.
5. Ouvrez la base de données en mode
READ ONLY et vérifiez que le point de
récupération est correct.
6. Ouvrez la base de données avec RESETLOGS.
Vous pouvez effectuer une récupération jusqu'à un point dans le temps gérée par le serveur en
procédant comme suit. La base de données doit être exécutée en mode ARCHIVELOG.
1. Déterminez la cible de la restauration. Il peut s'agir d'une date et d'une heure, d'un SCN,
d'un point de restauration ou d'un numéro de séquence de journal. Par exemple, si vous
savez que des transactions incorrectes ont été soumises hier à 15h00, vous pouvez choisir
hier à 14h59 comme point cible de la restauration.
2. Définissez les variables d'environnement NLS (National Language Support) de sorte que les
constantes temporelles que vous fournissez à RMAN soient formatées correctement. Voici
des exemples de paramétrage :
$ export NLS_LANG = american_america.us7ascii
$ export NLS_DATE_FORMAT = "yyyy-mm-dd:hh24:mi:ss"
3. Montez la base de données. Si elle est ouverte, vous devez d'abord l'arrêter, comme dans
l'exemple suivant :
RMAN> shutdown immediate
RMAN> startup mount

4. Créez un bloc RUN et exécutez-le. Les commandes RECOVER et RESTORE doivent figurer dans
le même bloc RUN afin que le paramètre UNTIL s'applique aux deux. Par exemple, si vous
choisissez d'effectuer une récupération jusqu'à une valeur SCN particulière, la commande
RESTORE doit connaître cette valeur pour restaurer les fichiers à partir de sauvegardes
suffisamment anciennes, c'est-à-dire des sauvegardes effectuées avant ce SCN. Voici un
exemple de bloc RUN :
RUN
{
SET UNTIL TIME '2012-08-14:21:59:00';
RESTORE DATABASE;
RECOVER DATABASE;
}
Remarque : Si vous ne voulez pas faire appel aux paramètres NLS, vous pouvez définir la
date et l'heure de manière explicite. Par exemple, dans un format européen :
set until time
"to_date('14.08.2012 21:59:00','dd.mm.yyyy hh24:mi:ss')";
5. Dès que vous ouvrez la base de données pour lecture/écriture, vous validez (commit) la
restauration que vous venez d'effectuer. C'est pourquoi vous devez d'abord l'ouvrir en mode
READ ONLY et examiner quelques données pour vérifier que la récupération a fonctionné selon
vos attentes.
RMAN> SQL 'ALTER DATABASE OPEN READ ONLY';
6. Si les résultats de la récupération vous satisfont, ouvrez la base de données avec l'option
RESETLOGS comme illustré ci-dessous :
RMAN> ALTER DATABASE OPEN RESETLOGS;

Quiz
Lorsque la base de données est en mode ARCHIVELOG,

elle peut rester ouverte pendant que vous récupérez une perte
dans le tablespace SYSTEM.
a. Vrai
b. Faux
Réponse : b

Synthèse

• effectuer les opérations de restauration et de récupération
appropriées en fonction de la nature de la défaillance de
votre base de données
• récupérer des fichiers de données à la suite de
défaillances physiques
• procéder à des récupérations complètes et incomplètes
(jusqu'à un point dans le temps)

Récupération après une défaillance physique
• Dans l'exercice 11-1, vous effectuez une récupération
complète après la perte d'un fichier de données essentiel.
• Dans l'exercice 11-2, vous effectuez une récupération
incomplète, c'est-à-dire jusqu'à un point dans le temps.
Dans le premier exercice, vous allez procéder à une récupération complète de la base de
données après la perte d'un fichier de données essentiel. Dans ce cas, Data Recovery Advisor ne
peut pas être utilisé.
Le second exercice vous place dans un scénario qui nécessite une récupération incomplète.

Procéder à une récupération II

Objectifs

• récupérer la base de données suite à la perte du fichier
de paramètres serveur
• récupérer la base suite à des problèmes de fichier de
contrôle et de fichier de journalisation
• recréer le fichier d'authentification par mot de passe
• récupérer des tablespaces d'index et en lecture seule
• examiner la récupération automatique du fichier
temporaire
• décrire la procédure générale de restauration de la base
de données vers un nouvel hôte
• décrire la récupération après sinistre
Vous abordez le dernier chapitre du module "Récupération" qui en comprenait quatre au total, à
savoir :

Récupération suite à la perte du fichier
La clause FROM MEMORY permet la création du fichier à partir
des valeurs de paramètre actuelles au niveau système.
SQL> CREATE PFILE [= 'pfile_name' ]

FROM { { SPFILE [= 'spfile_name'] } | MEMORY } ;
SQL> CREATE SPFILE [= 'spfile_name' ]

FROM { { PFILE [= 'pfile_name' ] } | MEMORY } ;
Le moyen le plus simple de récupérer un fichier de paramètres serveur est d'utiliser la clause
FROM MEMORY qui crée un fichier de paramètres d'initialisation de type texte (PFILE) ou un fichier
de paramètres serveur (SPFILE) à partir des paramètres définis au niveau système. Dans un
environnement RAC, le fichier créé contient les valeurs de paramètre de chaque instance.
Au démarrage de l'instance, toutes ces valeurs sont enregistrées dans le fichier d'alertes
alert.log. Depuis la version Oracle Database 11g, le dump des paramètres consigné dans
alert.log est écrit avec une syntaxe valide. Ainsi, vous pouvez plus facilement couper-coller
les paramètres dans un fichier distinct, puis utiliser ce dernier en tant que fichier PFILE pour une
nouvelle instance. Le nom du fichier PFILE ou SPFILE est consigné dans le fichier alert.log
au démarrage de l'instance. Par ailleurs, le fichier d'alertes vous avertit en cas d'utilisation d'un
fichier PFILE inconnu côté client.
Pour prendre en charge cette fonctionnalité supplémentaire, vous devez attribuer la valeur
11.0.0.0 ou ultérieure au paramètre d'initialisation COMPATIBLE.

Restaurer le fichier de paramètres serveur à partir
de la sauvegarde automatique du fichier de contrôle
RMAN> STARTUP FORCE NOMOUNT;
RMAN> RESTORE SPFILE FROM AUTOBACKUP;
RMAN> STARTUP FORCE;
Recovery
Manager
(RMAN) Zone de récupération
rapide
Fichier de
paramètres
serveur Base de données
Si vous avez perdu le fichier de paramètres serveur et ne pouvez pas utiliser la clause FROM
MEMORY, vous pouvez le restaurer à partir de la sauvegarde automatique. La procédure est
similaire à la restauration du fichier de contrôle à partir de la sauvegarde automatique. Si la
sauvegarde automatique n'est pas dans la zone de récupération rapide, indiquez le paramètre
DBID de la base. Exécutez la commande RESTORE SPFILE FROM AUTOBACKUP.
Si vous restaurez le fichier SPFILE dans un emplacement autre que celui par défaut, utilisez la
syntaxe suivante :
RESTORE SPFILE TO <file_name> FROM AUTOBACKUP
Si vous restaurez le fichier SPFILE à partir de la zone de récupération rapide, utilisez la syntaxe
suivante :
RMAN> run {
2> restore spfile from autobackup
3> recovery area = '<flash recovery area destination>'
4> db_name = '<db_name>';
5> }

Perte d'un fichier de contrôle
Si un fichier de contrôle est perdu ou endommagé, l'instance se ferme
brutalement en principe.
• Si les fichiers de contrôle sont stockés dans des groupes de
disques ASM, les options de récupération sont les suivantes :
– Procéder à une récupération assistée à l'aide de Cloud Control.
– Placer la base de données en mode NOMOUNT et utiliser une
commande RMAN pour restaurer le fichier de contrôle à partir
d'une copie existante.
RMAN> restore controlfile from

'+DATA/orcl/controlfile/current.260.695209463';
• Si les fichiers de contrôle sont stockés dans le système de fichiers :

– Arrêtez la base de données.
– Copiez le fichier de contrôle existant à la place du fichier perdu.
Ouvrez la base de données une fois le fichier de contrôle restauré.
Les options de récupération disponibles suite à la perte d'un fichier de contrôle sont différentes
selon la configuration de stockage des fichiers de contrôle et selon qu'il existe encore au moins
une copie du fichier de contrôle ou que toutes ont été perdues.
Si vous utilisez un espace de stockage ASM et qu'il reste encore au moins une copie du fichier de
contrôle, vous pouvez effectuer soit une récupération assistée à l'aide de Cloud Control, soit une
récupération manuelle en utilisant RMAN comme suit :
1. Placez la base de données en mode NOMOUNT.
2. Connectez-vous à RMAN et lancez la commande RESTORE CONTROLFILE pour restaurer
le fichier de contrôle à partir d'une copie existante de ce dernier, par exemple :
restore controlfile from
'+DATA/orcl/controlfile/current.260.695209463';
3. Une fois le fichier de contrôle restauré, ouvrez la base de données.
Remarque : Vous pouvez également utiliser la commande ASMCMD cp pour restaurer le fichier
de contrôle.
Si vos fichiers de contrôle sont stockés en tant qu'éléments standard du système de fichiers et
qu'il reste au moins une copie du fichier de contrôle, vous pouvez simplement copier celle-ci à
l'emplacement du fichier perdu pendant que la base est arrêtée. Si la défaillance physique est
due à la perte d'un disque ou d'un contrôleur, copiez l'un des fichiers de contrôle restants vers un
autre emplacement et mettez à jour le fichier de paramètres de l'instance afin qu'il pointe vers ce
nouvel emplacement. Vous pouvez également supprimer du fichier de paramètres d'initialisation
la référence au fichier de contrôle manquant. Souvenez-vous qu'Oracle recommande de disposer
à tout moment d'au moins deux copies du fichier de contrôle.

Récupération suite à la perte de toutes les copies
du fichier de contrôle : Présentation
A jour Sauvegarde
Disponible Restaurer le fichier de contrôle Restaurer le fichier de

de sauvegarde, effectuer une contrôle de sauvegarde,
récupération complète, OPEN effectuer une récupération
RESETLOGS. complète, OPEN
RESETLOGS.
Indisponible Recréer le fichier de contrôle, Restaurer le fichier de

OPEN RESETLOGS. contrôle de sauvegarde,
effectuer une récupération
jusqu'à un point dans le
temps, OPEN RESETLOGS.
Statut des fichiers de Statut des fichiers

journalisation en ligne de données
La perte de l'ensemble des fichiers de contrôle ne devrait jamais se produire. La prévention est
préférable à la récupération. Même si vous avez placé des copies du fichier de contrôle à
différents emplacements, vous pouvez être amené à effectuer une récupération suite à la perte de
l'ensemble de ces copies. Si vous avez perdu toutes les copies du fichier de contrôle en cours et
que vous disposez d'une sauvegarde de ce fichier, la procédure à suivre dépend du statut des
fichiers de journalisation en ligne et des fichiers de données. Si vous n'avez pas de sauvegarde
du fichier de contrôle mais disposez d'un fichier texte créé avec la commande ALTER DATABASE
BACKUP CONTROLFILE TO TRACE, vous pouvez être en mesure d'utiliser ce fichier texte pour
recréer le fichier de contrôle.
Fichiers de journalisation en ligne disponibles
Si, d'une part, les fichiers de journalisation en ligne sont disponibles et contiennent les
informations de journalisation nécessaires à la récupération et que, d'autre part, les fichiers de
données sont à jour, vous pouvez restaurer un fichier de contrôle de sauvegarde, effectuer une
récupération complète, puis ouvrir la base de données avec l'option RESETLOGS. Vous devez
indiquer le nom des fichiers de journalisation en ligne pendant la récupération. Si ces fichiers ne
sont pas à jour, effectuez la même procédure.
Fichiers de journalisation en ligne non disponibles
Si les fichiers de journalisation en ligne ne sont pas disponibles et que les fichiers de données
sont à jour, recréez le fichier de contrôle et ouvrez la base de données avec l'option RESETLOGS.
Si les fichiers de données ne sont pas à jour, restaurez un fichier de contrôle de sauvegarde,
effectuez une récupération jusqu'à un point dans le temps, puis ouvrez la base de données avec
l'option RESETLOGS.

Restaurer le fichier de contrôle à partir
de la sauvegarde automatique
Sans Recovery
catalogue de Manager
restauration : (RMAN) Zone de récupération rapide
Avec vérification croisée implicite des sauvegardes sur disque
Fichier de contrôle
Base de données Sans catalogue de restauration :

RMAN> SET DBID nnn
RMAN> STARTUP NOMOUNT;
RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP;
RMAN> ALTER DATABASE MOUNT; Remonter dans le temps
RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN RESETLOGS; Nouvelle incarnation de
la base de données
Oracle Corporation recommande de configurer le mode AUTOBACKUP du fichier de contrôle pour

être en mesure de restaurer rapidement ce dernier en cas de besoin. Les commandes permettant
de restaurer le fichier de contrôle sont les mêmes, que vous utilisiez ou non une zone de
récupération rapide. Cependant, si vous utilisez une zone de récupération rapide, RMAN procède
implicitement à des vérifications croisées des sauvegardes et des copies d'image répertoriées
dans le fichier de contrôle, et il catalogue les éventuels fichiers de la zone de récupération rapide
qui ne sont pas enregistrés dans le fichier de contrôle restauré, ce qui permet de renforcer l'utilité
de celui-ci pour la restauration du reste de la base de données.
Utilisez les commandes présentées dans la diapositive pour effectuer une récupération suite à la
perte de fichiers de contrôle.
1. Pour commencer, démarrez l'instance en mode NOMOUNT. Elle ne peut pas être montée car
il n'y a pas de fichier de contrôle.
2. Restaurez le fichier de contrôle à partir d'une sauvegarde.
3. Vous pouvez désormais monter la base.
4. Vous devez récupérer la base. En effet, vous disposez d'un fichier de contrôle de
sauvegarde qui contient des informations sur une version antérieure de la base.
5. Une fois la base récupérée, vous pouvez l'ouvrir. Vous devez indiquer l'option RESETLOGS
car le nouveau fichier de contrôle représente une instanciation différente de la base de
données.
Remarque : Les sauvegardes sur bande ne font pas l'objet d'une vérification croisée automatique
après la restauration d'un fichier de contrôle. Après avoir restauré le fichier de contrôle et monté
la base de données, vous devez donc effectuer une vérification croisée des sauvegardes sur
bande.

Restaurer le fichier SPFILE et le fichier de contrôle
Avec un catalogue de restauration : Restauration vers tous les
emplacements répertoriés dans le
• Base de données dans l'état NOMOUNT paramètre CONTROL_FILES.
RMAN> RESTORE CONTROLFILE; Restauration vers un emplacement
RMAN> RESTORE CONTROLFILE... TO <destination> autre que ceux par défaut.
Perte du fichier SPFILE et du fichier de contrôle :

1. Définissez le paramètre DBID ou utilisez le catalogue de
restauration.
2. Restaurez le fichier SPFILE à partir de la sauvegarde
automatique autobackup.
3. Démarrez l'instance avec le fichier SPFILE restauré.
4. Restaurez le fichier de contrôle à partir de la sauvegarde
automatique autobackup.
5. Montez la base de données avec le fichier de contrôle restauré.
6. Restaurez et récupérez la base de données.
7. Ouvrez la base de données en utilisant l'option RESETLOGS.
Si vous disposez d'un catalogue de restauration, vous n'êtes pas obligé de définir le DBID ou
d'utiliser la sauvegarde automatique du fichier de contrôle pour restaurer ce dernier. Vous pouvez
utiliser la commande RESTORE CONTROLFILE sans argument :
RMAN> RESTORE CONTROLFILE;
L'instance doit être dans l'état NOMOUNT lorsque vous effectuez cette opération, et RMAN doit être
connecté au catalogue de restauration. Le fichier de contrôle restauré est écrit dans tous les
emplacements indiqués par le paramètre d'initialisation CONTROL_FILES.
Utilisez la commande RESTORE CONTROLFILE... TO <destination> pour restaurer le fichier de
contrôle vers un emplacement autre que ceux par défaut.
Si vous avez également perdu le fichier SPFILE associé à la base de données et que vous devez
le restaurer à partir de la sauvegarde automatique, la procédure à suivre est similaire à la
restauration du fichier de contrôle à partir de la sauvegarde automatique. Vous devez d'abord
définir le DBID de la base de données, puis utiliser la commande RESTORE SPFILE FROM
AUTOBACKUP.
Une fois que vous avez démarré l'instance avec le fichier de paramètres serveur restauré, RMAN
peut restaurer le fichier de contrôle à partir de la sauvegarde automatique. Après avoir restauré et
monté le fichier de contrôle, vous disposez des informations de sauvegarde nécessaires pour
restaurer et récupérer la base de données.
Après avoir restauré les fichiers de contrôle de la base de données à partir de la sauvegarde,
vous devez procéder à une restauration physique complète puis ouvrir la base avec l'option
RESETLOGS.

Quiz
Quelles actions devez-vous effectuer pour assurer la

récupération suite à la perte d'un fichier de contrôle
(lorsque les fichiers de contrôle sont multiplexés) ?
a. Arrêtez l'instance de base de données.
b. Copiez tous les fichiers de données à partir de
sauvegardes.
c. Copiez le fichier de contrôle à partir d'une sauvegarde.
d. Copiez l'un des fichiers de contrôle à jour à l'emplacement
du fichier perdu :
Réponses : a, d

Récupérer des objets de base de données
NOLOGGING
SQL> CREATE TABLE sales_copy NOLOGGING;
SQL> INSERT /*+ APPEND */ INTO sales_copy
2 SELECT * FROM sales_history;
Les objets créés avec l'attribut
NOLOGGING ne peuvent pas être
récupérés (même si la base est en
mode ARCHIVELOG).
Fichier de
journalisation
Si nécessaire, sauvegardez la table

après l'opération d'insertion à des
fins de récupération.
Si vous le pouvez, tirez parti des avantages offerts par l'attribut NOLOGGING des tables et des
index. Lorsque vous créez une table avec cet attribut, les données écrites dans le flux des
informations de journalisation se limitent à la consignation de la création de l'objet. Les insertions
volumineuses sont ainsi plus rapides.
Dans l'exemple de la diapositive, la table SALES_COPY est créée en tant que table NOLOGGING.
Lorsqu'une insertion est effectuée avec le conseil (hint) APPEND, aucune information de
journalisation n'est donc générée. Il s'ensuit que vous ne pouvez pas récupérer cette
transaction sur la table SALES_HISTORY. Si cela pose problème, il est important de réaliser une
sauvegarde des tables alimentées de cette manière immédiatement après chaque transaction
d'insertion. Vous pourrez alors accéder à la sauvegarde la plus récente de la table.
Si vous effectuez une restauration physique et que des objets NOLOGGING sont impliqués, ceux-
ci seront marqués comme faisant l'objet d'une corruption logique pendant le processus de
récupération. Dans ce cas, supprimez les objets NOLOGGING, puis recréez-les.

Perte d'un fichier de journalisation
Si un membre d'un groupe de fichiers de journalisation est

perdu et que le groupe comporte encore au moins un membre :
• L'instance continue de fonctionner normalement.
• Un message est consigné dans le fichier d'alertes pour
vous informer qu'un membre est introuvable.
• Vous pouvez restaurer le fichier journal manquant en
supprimant le membre perdu et en ajoutant un nouveau
membre.
• Si le groupe auquel appartient le fichier journal manquant
a été archivé, vous pouvez vider le groupe pour recréer le
fichier manquant.
• Réalisez immédiatement une sauvegarde complète de
l'ensemble de la base de données.
La récupération suite à la perte d'un seul membre d'un groupe de fichiers de journalisation ne
devrait pas affecter le fonctionnement de l'instance.
Pour procéder à cette récupération :
1. Déterminez si un fichier de journalisation est manquant en consultant le fichier d'alertes.
2. Restaurez le fichier manquant en commençant par supprimer le fichier de journalisation
membre perdu :
ALTER DATABASE DROP LOGFILE MEMBER ''
Ajoutez alors un membre pour remplacer celui qui a été perdu :
ALTER DATABASE ADD LOGFILE MEMBER '' TO GROUP n
Vous pouvez également utiliser Cloud Control pour supprimer et recréer le membre du
groupe de fichiers de journalisation.
Remarque : Si vous avez opté pour des fichiers de journalisation OMF (Oracle Managed
Files) et utilisez la syntaxe précédente pour ajouter un membre à un groupe de fichiers de
journalisation existant, le nouveau membre n'est pas un fichier OMF. Pour garantir que le
nouveau membre sera un fichier OMF, l'option de récupération la plus simple consiste à
créer un nouveau groupe de fichiers de journalisation, puis à supprimer celui dont un
membre a été perdu.
3. Si la défaillance physique est due à la perte d'une unité de disque ou d'un contrôleur,
renommez le fichier manquant
4. Si le groupe a déjà été archivé, ou si vous êtes en mode NOARCHIVELOG, vous avez la
possibilité de résoudre le problème en vidant le groupe de journalisation pour recréer les
fichiers manquants. Sélectionnez le groupe approprié, puis l'action Clear Logfile. Vous
pouvez également vider manuellement le groupe défectueux à l'aide de la commande
suivante :
ALTER DATABASE CLEAR LOGFILE GROUP #

Remarque : Cloud Control ne vous permet pas de vider un groupe de journalisation qui n'a pas
été archivé ; en effet, il en résulterait une rupture de la chaîne des informations de journalisation.
Si vous devez vider un groupe de fichiers de journalisation qui n'a pas été archivé, effectuez
immédiatement une sauvegarde complète de l'ensemble de la base de données. A défaut, vous
vous exposez à une perte de données si une autre défaillance se produit. Pour vider un groupe de
fichiers de journalisation qui n'a pas été archivé, utilisez la commande suivante : ALTER
DATABASE CLEAR UNARCHIVED LOGFILE GROUP #

Statut d'un groupe de fichiers
de journalisation : Rappel
Le statut d'un groupe de fichiers de journalisation

peut prendre l'une des valeurs suivantes à un
instant donné :
• CURRENT : Le processus LGWR écrit
actuellement les données de journalisation
dans ce groupe.
• ACTIVE : Le groupe n'est plus la destination
d'écriture du processus LGWR, mais il est
encore nécessaire pour la récupération
d'instance.
• INACTIVE : Le groupe n'est plus la
destination d'écriture du processus LGWR et
il n'est plus nécessaire pour la récupération
d'instance.
Pour aborder le thème de la perte de fichiers de journalisation (fichiers redo log), il est important
de comprendre les différents statuts possibles d'un groupe de fichiers de journalisation. Au cours
de l'exécution normale d'une base de données Oracle, les groupes de fichiers de journalisation
peuvent prendre successivement trois états. Ces états sont les suivants, dans l'ordre du cycle :
• CURRENT : Cet état signifie que le processus LGWR écrit actuellement dans ce groupe les
données de journalisation relatives aux transactions qui ont lieu dans la base. Le groupe
conserve cet état jusqu'à ce qu'un changement de groupe de fichiers de journalisation se
produise.
• ACTIVE : Le groupe de fichiers de journalisation contient encore des données de
journalisation requises pour la récupération d'instance. Il conserve ce statut jusqu'à
l'exécution du point de reprise (checkpoint) au cours duquel toutes les modifications
de données indiquées dans le groupe sont écrites dans les fichiers de données.
• INACTIVE : L'exécution du point de reprise a eu lieu, ce qui signifie que le groupe
de fichiers de journalisation n'est plus requis pour la récupération d'instance et peut devenir
le prochain groupe CURRENT.

Récupération suite à la perte d'un groupe
de fichiers de journalisation
Début
Oui Réparer INACTIVE CURRENT

Terminé Statut du
le support ? groupe
Non ACTIVE
Non
Vider le Exécuter Effectuer un Instance
Non changement
fichier Archivé ? point de en panne ?
journal. reprise. de journal.
Sauvegarder
la base de Oui
Oui CKPT
données. Oui
Vider le fichier réussi ?
journal.
Non
Restaurer et effectuer
une récupération incomplète
jusqu'à annulation.
Si vous avez perdu un groupe de fichiers de journalisation entier, toutes les copies des fichiers de
journalisation de ce groupe sont inutilisables ou ont disparu.
Dans le cas le plus simple, le groupe de fichiers de journalisation présente l'état INACTIVE. Cela
signifie qu'il ne fait actuellement l'objet d'aucune écriture et n'est plus nécessaire à la récupération
d'instance. Si le problème est temporaire ou si vous pouvez réparer le support, la base de
données continue à s'exécuter normalement et le groupe est réutilisé lorsque suffisamment
d'événements de changement de fichier de journalisation se produisent. Sinon, si le support ne
peut pas être réparé, vous pouvez vider le fichier journal. Lorsque vous effectuez cette opération,
vous indiquez que le fichier journal peut être réutilisé.
Si le groupe de fichiers de journalisation en question est dans l'état ACTIVE, il reste nécessaire à
la récupération d'instance même s'il ne fait actuellement pas l'objet d'écritures. Si vous ne pouvez
pas créer de point de reprise (checkpoint), le groupe de fichiers de journalisation n'est plus
nécessaire à la récupération d'instance et vous pouvez continuer comme si le groupe présentait
l'état inactif.
Si le groupe de fichiers de journalisation présente l'état CURRENT, il faisait l'objet d'écritures
actives lors de la perte. Dans ce cas, il est même possible que le processus LGWR échoue. Le
cas échéant, l'instance tombe en panne. A ce stade, la seule option qui s'offre à vous consiste à
effectuer une restauration à partir de la sauvegarde, à procéder à une récupération incomplète
jusqu'à annulation (cancel), puis à ouvrir la base de données avec l'option RESETLOGS.

Vider un fichier journal
Début
Oui
ALTER DATABASE CLEAR LOGFILE ... Fichier journal
archivé ?
Non
Nécessaire Oui
pour fichier de
données ?
Non
ALTER DATABASE CLEAR UNARCHIVED LOGFILE ...
ALTER DATABASE CLEAR UNARCHIVED LOGFILE ... UNRECOVERABLE DATAFILE
Pour vider un fichier journal, utilisez la commande suivante :

ALTER DATABASE CLEAR [UNARCHIVED] LOGFILE GROUP <n>
[UNRECOVERABLE DATAFILE]
Lorsque vous effectuez cette opération, vous indiquez que le fichier journal peut être réutilisé. Si
le fichier journal a déjà été archivé, la forme la plus simple de la commande peut être utilisée.
Utilisez l'interrogation suivante pour déterminer quels groupes de fichiers de journalisation ont été
archivés :
SQL> SELECT GROUP#, STATUS, ARCHIVED FROM V$LOG;
Par exemple, la commande suivante vide le groupe de fichiers de journalisation 3, qui a déjà été
archivé :
SQL> ALTER DATABASE CLEAR LOFGILE GROUP 3;
Si le groupe n'a pas encore été archivé, vous devez indiquer le mot-clé UNARCHIVED. Vous
indiquez de cette manière qu'il est possible que des sauvegardes se fondent sur ce fichier de
journalisation pour la récupération, mais que vous avez décidé de renoncer à cette possibilité de
récupération. Il est tout à fait possible que cette solution vous convienne, en particulier si vous
réalisez une autre sauvegarde juste après avoir corrigé le problème sur le groupe de fichiers de
journalisation ; vous n'avez alors plus besoin de ce fichier.
Le fichier de journalisation peut être requis pour récupérer un fichier de données actuellement
hors ligne.

Recréer un fichier d'authentification par mot de passe
SQL> grant sysdba to admin2;

grant sysdba to admin2
*
ERROR at line 1:
ORA-01994: GRANT failed: password file missing or disabled
Pour procéder à une récupération suite à la perte d'un fichier

de mots de passe :
1. Recréez le fichier de mots de passe à l'aide de orapwd.
$ orapwd file=$ORACLE_HOME/dbs/orapworcl password=ora entries=5
2. Ajoutez des utilisateurs au fichier de mots de passe et

affectez les privilèges appropriés à chaque utilisateur.
Faites appel à l'utilitaire orapwd pour créer un fichier de mots de passe. Lorsque vous vous
connectez à l'aide du privilège SYSDBA, vous vous connectez sous le schéma SYS et non sous le
schéma associé à votre nom utilisateur. Pour SYSOPER, vous êtes connecté au schéma PUBLIC.
L'accès à la base de données à l'aide du fichier de mots de passe est fourni par des commandes
GRANT émises par des utilisateurs dotés de privilèges.
En général, le fichier de mots de passe n'est pas inclus dans les sauvegardes car, dans presque
tous les cas, il peut facilement être recréé.
Il est très important, pour la sécurité du système, de protéger le fichier de mots de passe et les
variables d'environnement qui identifient l'emplacement de ce fichier. Tout utilisateur ayant accès
à ces informations pourrait compromettre la sécurité de la connexion.
Ne supprimez ni ne modifiez le fichier de mots de passe dans le cas d'une base de données ou
d'une instance montée avec REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE ou SHARED. Si vous
le faites, vous ne pourrez pas vous reconnecter à distance avec le fichier de mots de passe.
Remarque : Lorsque vous recréez le fichier de mots de passe, vous devez tenir compte du fait
que les mots de passe distinguent les majuscules des minuscules. Par ailleurs, si le fichier de
mots de passe d'origine a été créé avec l'option IGNORECASE=Y, il doit être recréé avec la même
option.

Utiliser un fichier de mots de passe
Pour recréer le fichier de mots de passe, procédez comme suit :
1. Créez le fichier de mots de passe à l'aide de l'utilitaire de gestion des mots de passe orapwd.
orapwd file=filename password=password entries=max_users
Où :
- filename est le nom du fichier de mots de passe (obligatoire).
- password est le mot de passe pour SYS (facultatif). Vous êtes invité à indiquer le mot de
passe si vous n'incluez pas l'argument password.
- max_users est le nombre maximal d'utilisateurs distincts autorisés à se connecter en tant
que SYSDBA ou SYSOPER. Si vous dépassez ce nombre, vous devez créer un nouveau
fichier de mots de passe. Il est plus sûr d'utiliser un nombre élevé. Notez l'absence
d'espaces autour du signe égal (=).
Exemple : orapwd file=$ORACLE_HOME/dbs/orapwU15 password=admin entries=5
Les autres options (à partir de la version 12.1) sont :
- ASM : Défini avec la valeur y, crée un fichier de mots de passe Oracle ASM. L'option par
défaut n crée un fichier de mots de passe de base de données.
- FORMAT : Défini avec la valeur (par défaut) 12, crée le fichier de mots de passe dans le
format de la version 12c. Ce format prend en charge les privilèges système SYSBACKUP,
SYSDG et SYSKM. Si cet argument est défini avec la valeur legacy, le fichier de mots de
passe est dans le format hérité, c'est-à-dire le format antérieur à Oracle Database 12c. La
valeur legacy n'est pas autorisée si l'argument SYSBACKUP ou SYSDG est précisé.
- SYSBACKUP : La valeur y crée une entrée SYSBACKUP dans le fichier de mots de passe.
Vous êtes invité à fournir le mot de passe. Ce dernier est stocké dans le fichier de mots de
passe créé.
- SYSDG : La valeur y crée une entrée SYSDG dans le fichier de mots de passe. Vous êtes
invité à fournir le mot de passe. Ce dernier est stocké dans le fichier de mots de passe
créé.
- SYSKM : La valeur y crée une entrée SYSKM dans le fichier de mots de passe. Vous êtes
invité à fournir le mot de passe. Ce dernier est stocké dans le fichier de mots de passe
créé.
- DELETE : La valeur y supprime le fichier de mots de passe indiqué. La valeur par défaut n
autorise la création du fichier de mots de passe.
- FORCE : La valeur y autorise le remplacement d'un fichier de mots de passe existant.
Pour obtenir la liste complète des options disponibles, reportez-vous au manuel Oracle
Database Administrator’s Guide.
2. Connectez-vous à la base de données en utilisant le fichier de mots de passe créé à l'étape 1 et
octroyez les privilèges nécessaires.
SQL> CONNECT sys/admin AS SYSDBA
SQL> grant sysdba to admin2;
Emplacement du fichier de mots de passe
UNIX : 0$ORACLE_HOME/dbs
Windows : %ORACLE_HOME%\database
Gérer le fichier de mots de passe
Supprimez le fichier de mots de passe existant à l'aide de commandes du système d'exploitation, puis
créez-en un nouveau à l'aide de l'utilitaire de gestion des mots de passe.

Récupération suite à la perte d'un tablespace d'index
• Il est possible de récupérer un tablespace contenant

uniquement des index sans réaliser d'opération RECOVER.
• En cas de perte d'un fichier de données appartenant à un
tablespace d'index, il peut s'avérer plus simple de recréer
le tablespace et les index.
• Utilisez les options suivantes pour réduire le temps
de régénération de l'index :
– PARALLEL
– NOLOGGING
SQL> CREATE INDEX rname_idx

2 ON hr.regions (region_name)
3 PARALLEL 4;
Les index sont des objets calculés dans le sens où ils ne fournissent aucune donnée d'origine. Il
s'agit simplement d'une représentation différente de données qui existent déjà. Ainsi, dans la
plupart des cas, il est facile de les recréer. Si vous disposez d'un tablespace contenant
uniquement des index, la récupération suite à la perte d'un fichier de données appartenant à ce
tablespace peut être simplifiée.
En cas de perte d'un fichier de données de ce type, vous pouvez procéder comme suit :
1. Supprimez le fichier de données.
2. Supprimez le tablespace.
3. Recréez le tablespace d'index.
4. Recréez les index qui figuraient dans le tablespace.
Lors de la création ou de la recréation d'un index, vous pouvez utiliser les mots-clés suivants afin
de réduire le temps nécessaire à l'opération :
• PARALLEL : Permet à plusieurs processus d'oeuvrer simultanément pour créer un index.
L'option par défaut est NOPARALLEL.
• NOLOGGING : Avec ce mot-clé, la création de l'index est plus rapide car la quantité d'entrées
de journalisation générées pendant le processus de création est réduite au minimum.
Si vous devez recréer des index, utilisez le package DBMS_METADATA pour extraire les
métadonnées du dictionnaire de données.

Récupérer un tablespace en lecture seule
Des éléments particuliers sont à prendre en considération pour

la sauvegarde et la récupération gérées par l'utilisateur dans
le cas d'un tablespace en lecture seule :
• Il est inutile de placer le tablespace en mode sauvegarde
pour faire une copie de ses fichiers de données.
• Il est inutile de mettre le tablespace ou le fichier de
données hors ligne avant d'en faire une copie.
Les tablespaces en lecture seule ne faisant l'objet d'aucune écriture, des éléments particuliers
sont à prendre en considération afin d'optimiser leur processus de récupération. Il est inutile de
placer un tablespace en lecture seule en mode sauvegarde ou de le mettre hors ligne avant de le
copier vers l'emplacement de sauvegarde. Il suffit de le copier.
Lorsque vous restaurez un tablespace en lecture seule, mettez-le hors ligne, restaurez les fichiers
de données lui appartenant, puis remettez-le en ligne.
Prenons l'exemple suivant, où un tablespace en lecture seule est placé en lecture/écriture :
1. Effectuez une sauvegarde du tablespace en lecture seule.
2. Placez le tablespace en lecture/écriture.
3. Récupérez le tablespace.
La sauvegarde que vous avez réalisée à l'étape 1 peut encore être utilisée pour récupérer ce
tablespace ; toutefois, depuis la réalisation de cette sauvegarde, le tablespace a été placé en
lecture/écriture et a peut-être fait l'objet d'écritures. Dans ce cas, il doit faire l'objet d'une
récupération.

Récupération automatique d'un fichier Tempfile
Les instructions SQL dont l'exécution nécessite un espace
temporaire peuvent échouer si l'un des fichiers temporaires est
manquant.
SQL> select * from big_table order by
1,2,3,4,5,6,7,8,9,10,11,12,13;
select * from big_table order by
1,2,3,4,5,6,7,8,9,10,11,12,13
*
ERROR at line 1:
ORA-01565: error in identifying file
'/u01/app/oracle/oradata/orcl/temp01.dbf'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Heureusement :
• Les fichiers temporaires sont recréés automatiquement
au démarrage.
• Possibilité de recréer manuellement les fichiers.
Si un fichier temporaire (tempfile) appartenant au tablespace TEMP est perdu ou endommagé,

les extents qu'il contient ne sont plus disponibles. Ce problème peut se traduire par l'apparition
d'erreurs lors de l'exécution d'instructions SQL nécessitant un espace temporaire à des fins de tri.
L'instruction SQL présentée dans la diapositive doit trier une longue liste de colonnes et nécessite
donc un espace temporaire. Lorsque cette instruction est exécutée, elle rencontre une erreur à
cause de l'absence de ce fichier.
L'instance de base de données Oracle peut démarrer avec un fichier temporaire manquant. Si un
fichier temporaire est manquant lors du démarrage de la base, il est créé automatiquement et la
base de données s'ouvre normalement. Dans ce cas, un message du type illustré ci-après
apparaît dans le fichier d'alertes pendant le démarrage :
Re-creating tempfile /u01/app/oracle/oradata/orcl/temp01.dbf
Dans le cas peu probable où vous pensez qu'une recréation manuelle est préférable, utilisez les
commandes suivantes :
SQL> ALTER TABLESPACE temp ADD TEMPFILE
'/u01/app/oracle/oradata/orcl/temp02.dbf' SIZE 20M;
SQL> ALTER TABLESPACE temp DROP TEMPFILE
'/u01/app/oracle/oradata/orcl/temp01.dbf';

Restaurer et récupérer la base de données
sur un nouvel hôte
Utilisez cette procédure pour :
• effectuer des tests de restauration
• déplacer une base de données de production vers
un nouvel hôte
Sauvegardes RMAN>
paramètres paramètres
serveur serveur
Utilisez la procédure décrite dans les pages suivantes pour effectuer des tests de restauration.
Vous pouvez également l'utiliser pour déplacer une base de données de production vers un
nouvel hôte.
L'identificateur (DBID) de la base de données test qui est restaurée est identique à celui de la
base de données cible. Si vous utilisez un catalogue de restauration et que vous vous connectez
à la base de données test et à la base de données du catalogue de restauration, ce dernier est
mis à jour avec les informations sur la base de données test. Cette opération peut avoir un impact
sur la capacité de RMAN à restaurer et récupérer la base de données cible.
Si votre intention est de créer une copie de la base de données cible en vue d'une utilisation sur
un nouvel hôte, vous devez créer une base dupliquée à l'aide de la commande RMAN
DUPLICATE. En effet, la base dupliquée se voit attribuer un nouveau DBID qui permet son
enregistrement dans le même catalogue de restauration que la base cible d'origine. Reportez-
vous au chapitre intitulé "Dupliquer une base de données" pour plus d'informations sur la
commande DUPLICATE.

Préparer la restauration de la base de données
sur un nouvel hôte
Pour préparer la restauration d'une base de données, procédez
comme suit :
1. Enregistrez l'identificateur (DBID) de la base de données
source.
2. Copiez sur le nouvel hôte le fichier de paramètres
d'initialisation de la base de données source.
3. Assurez-vous que les sauvegardes source, y compris
la sauvegarde automatique du fichier de contrôle,
sont accessibles sur l'hôte de restauration.
Effectuez les étapes mentionnées dans la diapositive pour préparer la restauration de la base de
données sur un nouvel hôte.
Remarque : Si vous effectuez un test de restauration, ne vous connectez pas au catalogue de
restauration lors de la restauration des fichiers de données. En effet, si vous vous y connectez,
RMAN enregistre des informations sur les fichiers de données restaurés dans le catalogue et
considère la base restaurée comme la base cible en cours. Par ailleurs, si le fichier de contrôle
n'est pas suffisamment volumineux pour contenir l'ensemble des données du référentiel RMAN
relatives aux sauvegardes à restaurer et que vous devez utiliser un catalogue de restauration,
exportez le catalogue, puis importez-le dans un autre schéma ou une autre base. Utilisez le
catalogue de restauration copié pour effectuer le test de restauration.

Restaurer la base de données sur un nouvel hôte
Pour restaurer la base de données, effectuez les opérations

suivantes sur l'hôte de restauration :
1. Configurez la variable d'environnement ORACLE_SID.
2. Démarrez RMAN et connectez-vous à l'instance cible en
mode NOCATALOG.
3. Définissez l'identificateur de la base de données (DBID).
4. Démarrez l'instance en mode NOMOUNT.
5. Restaurez le fichier de paramètres serveur à partir des
jeux de sauvegarde.
6. Arrêtez l'instance.
7. Editez le fichier de paramètres d'initialisation restauré.
8. Démarrez l'instance en mode NOMOUNT.
Pour restaurer la base de données, effectuez sur l'hôte de restauration les étapes mentionnées dans
cette page et dans la page suivante.
1. Configurez la variable d'environnemen ORACLE_SID comme indiqué dans l'exemple suivant :
$ setenv ORACLE_SID orcl
2. Démarrez RMAN et connectez-vous à l'instance cible. Ne vous connectez pas au catalogue de
restauration, comme indiqué dans l'exemple suivant :
$ rman TARGET /
3. Définissez l'identificateur de la base de données (DBID). Vous pouvez trouver le DBID de la
base source en interrogeant la colonne DBID de la vue V$DATABASE.
RMAN> SET DBID 1090770270;
4. Démarrez l'instance en mode NOMOUNT :
RMAN> STARTUP NOMOUNT
Vous recevez un message d'erreur similaire à celui qui suit car le fichier de paramètres serveur
(SPFILE) n'a pas été restauré. RMAN utilise un fichier de paramètres "fictif" pour démarrer
l'instance.
startup failed: ORA-01078: failure in processing system parameters

5. Restaurez le fichier de paramètres serveur à partir des jeux de sauvegarde, puis arrêtez
l'instance comme illustré dans l'exemple ci-dessous :
RESTORE SPFILE TO PFILE '?/oradata/test/initorcl.ora' FROM AUTOBACKUP;
6. Arrêtez l'instance :
SHUTDOWN IMMEDIATE;
7. Editez le fichier de paramètres d'initialisation restauré pour modifier les paramètres
spécifiques à l'emplacement, par exemple ceux qui terminent par _DEST, afin de refléter la
nouvelle structure de répertoires.
8. Démarrez l'instance en mode NOMOUNT à l'aide du fichier de paramètres d'initialisation édité.
RMAN> STARTUP NOMOUNT
> PFILE='?/oradata/test/initorcl.ora';

Restaurer la base de données sur un nouvel hôte
9. Créez un bloc RUN pour :

– restaurer le fichier de contrôle
– monter la base de données
10. Créez le script de récupération RMAN pour restaurer
et récupérer la base de données.
11. Exécutez le script RMAN.
12. Ouvrez la base de données en utilisant l'option
RESETLOGS.
9. Créez un bloc RUN pour restaurer le fichier de contrôle à partir d'une sauvegarde
automatique et montez la base de données, comme indiqué dans l'exemple suivant :
RUN
{
RESTORE CONTROLFILE FROM AUTOBACKUP;
ALTER DATABASE MOUNT;
}
10. Interrogez la vue V$DATAFILE sur le nouvel hôte pour déterminer les noms de fichier de
base de données enregistrés dans le fichier de contrôle. Créez le script de récupération
RMAN pour restaurer et récupérer la base de données, en effectuant les opérations
appropriées :
a. A l'aide de la commande SET NEWNAME, indiquez le chemin du nouvel hôte pour
chacun des fichiers de données qui est restauré sur une destination différente de l'hôte
d'origine.
b. Utilisez la commande SQL ALTER DATABASE RENAME FILE pour indiquer le chemin
des fichiers de journalisation en ligne.
c. Incluez la commande SET UNTIL pour limiter la récupération à la fin des fichiers de
journalisation archivés.
d. Incluez la commande SWITCH afin que le fichier de contrôle reconnaisse les nouveaux
chemins comme des noms corrects de fichiers de données.

Voici un exemple de script de récupération :
RUN
{
SET NEWNAME FOR DATAFILE 1 TO '?/oradata/test/system01.dbf';
SET NEWNAME FOR DATAFILE 2 TO '?/oradata/test/undotbs01.dbf';
SET NEWNAME FOR DATAFILE 3 TO '?/oradata/test/sysaux.dbf';
SET NEWNAME FOR DATAFILE 4 TO '?/oradata/test/users01.dbf';
SET NEWNAME FOR DATAFILE 5 TO '?/oradata/test/example01.dbf';
SQL "ALTER DATABASE RENAME FILE ''/u01/app/oracle/oradata/orcl/redo01.log''
TO ''?/oradata/test/redo01.log'' ";
SET UNTIL SCN 4545727;
RESTORE DATABASE;
SWITCH DATAFILE ALL;
RECOVER DATABASE;
}
11. Exécutez le script de récupération.
12. Ouvrez la base de données avec l'option RESETLOGS :
RMAN> ALTER DATABASE OPEN RESETLOGS;
Une fois le test terminé, vous pouvez arrêter l'instance de base de données de test et supprimer la
base de test, ainsi que l'ensemble de ses fichiers.

Effectuer une récupération après sinistre
• Un sinistre entraîne la perte de l'intégralité de la base de

données cible, de la base de données du catalogue de
restauration, de tous les fichiers de contrôle en cours, de
tous les fichiers de journalisation en ligne et de tous les
fichiers de paramètres.
• La récupération après sinistre inclut la restauration et la
récupération de la base de données cible.
• Il faut au minimum disposer des sauvegardes suivantes :
– Sauvegardes des fichiers de données
– Fichiers de journalisation archivés correspondants
– Au moins une sauvegarde automatique du fichier de contrôle
Une récupération après sinistre inclut la restauration et la récupération de la base de données

cible après la perte de l'intégralité de cette dernière, de l'ensemble des fichiers de contrôle en
cours, des fichiers de journalisation en ligne et des fichiers de paramètres, ainsi que de la base
de données du catalogue de restauration (s'il existe un catalogue).
Pour effectuer une récupération après sinistre, il faut au minimum disposer des sauvegardes
suivantes :
• Sauvegardes des fichiers de données
• Fichiers de journalisation archivés (archived redo logs) correspondants générés après la
sauvegarde
• Au moins une sauvegarde automatique du fichier de contrôle
Remarque : Pour savoir comment Oracle Data Guard peut fournir une protection complète contre
les sinistres, reportez-vous au manuel Oracle Data Guard Concepts and Administration.

Effectuer une récupération après sinistre
Procédure de base :
1. Restaurez une sauvegarde automatique du fichier
de paramètres serveur (SPFILE).
2. Démarrez l'instance de la base de données cible.
3. Restaurez le fichier de contrôle à partir de la sauvegarde
automatique.
5. Restaurez les fichiers de données.
7. Ouvrez la base de données en utilisant l'option
RESETLOGS.
La procédure de base pour effectuer une récupération après sinistre est décrite dans la
diapositive ci-dessus. Après avoir monté la base de données, suivez la procédure permettant
d'effectuer la récupération à l'aide d'un fichier de contrôle de sauvegarde.

Restaurer des sauvegardes cryptées
• Avant de lancer la restauration, configurez la session
RMAN de façon à pouvoir décrypter les sauvegardes.
• Pour restaurer un jeu comprenant des sauvegardes créées
avec des mots de passe différents, indiquez tous les mots
de passe nécessaires dans la commande SET
DECRYPTION.
SET DECRYPTION IDENTIFIED BY '<password_1>'
{, '<password_2>',…,'<password_n>' }
Notes
• Si vous perdez le mot de passe d'une sauvegarde cryptée
en mode Mot de passe, vous ne pouvez pas restaurer
cette sauvegarde.
• Si vous perdez le fichier contenant la clé d'une sauvegarde
cryptée en mode Transparent, vous ne pouvez pas
restaurer cette sauvegarde.
Utilisez la commande SET DECRYPTION pour indiquer le(s) mot(s) de passe de décryptage à
utiliser lors de la lecture de sauvegardes ayant fait l'objet d'un cryptage en mode double ou d'un
cryptage avec mot de passe. Lorsque RMAN lit un élément de sauvegarde crypté, il essaie
chaque mot de passe figurant dans la liste jusqu'à ce qu'il trouve celui qui lui permet de décrypter
l'élément. Une erreur est générée si aucune des clés indiquées n'est correcte.
Si vous perdez le mot de passe d'une sauvegarde cryptée en mode Mot de passe, vous ne
pouvez pas restaurer cette sauvegarde.
Etant donné que l'infrastructure Oracle de gestion des clés archive toutes les clés maître
précédentes dans le fichier de clés d'accès (ou portefeuille de cryptage), la modification ou la
réinitialisation de la clé maître de la base de données en cours n'affecte pas la capacité de
restauration des sauvegardes cryptées effectuées à l'aide d'une ancienne clé maître. Vous
pouvez recréer la clé maître de la base de données à tout moment. Mais RMAN pourra toujours
restaurer toutes les sauvegardes cryptées créées par cette base.
Si vous perdez le fichier contenant la clé d'une sauvegarde cryptée en mode Transparent, vous
ne pouvez plus restaurer cette sauvegarde. Comme le fichier de clés d'accès contient toutes les
clés de cryptage des sauvegardes antérieures, vous pouvez en restaurer une sauvegarde pour
récupérer les sauvegardes qui ont été cryptées antérieurement. En revanche, les sauvegardes
cryptées après la sauvegarde du fichier de clés d'accès sont inaccessibles.
Méthode recommandée : Sauvegardez fréquemment le fichier de clés d'accès.

Quiz
Parmi les emplacements suivants, lesquels peuvent être

utilisés pour obtenir un bloc pendant une restauration physique
de blocs ?
a. Journaux Flashback
b. Sauvegardes complètes
c. Sauvegardes incrémentielles de niveau 0
d. Sauvegardes incrémentielles de niveau 1
Réponses : a, b, c

Synthèse

• récupérer la base de données suite à la perte du fichier
• récupérer la base suite à des problèmes de fichier de
contrôle et de fichier de journalisation
• recréer le fichier d'authentification par mot de passe
• récupérer des tablespaces d'index et en lecture seule
• examiner la récupération automatique du fichier
temporaire
• décrire la procédure générale de restauration de la base
de données vers un nouvel hôte
• décrire la récupération après sinistre

Procéder à des récupérations
• Dans l'exercice 12-1, vous restaurez un fichier de
paramètres perdu.
• Dans l'exercice 12-2, vous restaurez un seul fichier
de contrôle.
• Dans l'exercice 12-3, vous restaurez toutes les copies
du fichier de contrôle.
• Dans l'exercice 12-4, vous restaurez le fichier de mots de
passe de la base de données.
• L'exercice 12-5 vous fait découvrir la récupération
automatique qui a lieu en cas de fichier temporaire
manquant.
Ces exercices vous permettent d'apprendre à restaurer une base de données après la perte de
différents fichiers. Vous pouvez les exécuter dans l'ordre de votre choix ; toutefois, une fois que
vous en avez commencé un, vous devez le mener à bien.

Utiliser le cryptage RMAN
– préparer la base de données en vue du cryptage
– créer une sauvegarde cryptée en mode transparent
• Dans l'exercice 12-7, vous procéderez à la récupération
d'un fichier de données perdu en utilisant une sauvegarde
cryptée.
• Dans l'exercice 12-8, vous restaurez un portefeuille de
cryptage perdu.
Remarque : Si vous perdez le portefeuille de cryptage et n'en
avez conservé aucune sauvegarde, vous devrez récupérer la
base de données jusqu'à un point dans le temps antérieur à
l'utilisation du portefeuille.
• Dans le premier exercice, vous créez une sauvegarde cryptée qui est protégée contre la
violation des données en cas de perte du support de la sauvegarde. En l'occurrence, vous
utiliserez le mode de cryptage transparent qui s'appuie sur un portefeuille de cryptage. Si le
portefeuille de cryptage est perdu, la sauvegarde n'est pas récupérable. Pour alléger les
conséquences de ce type de perte, ou pour permettre la récupération de la sauvegarde sur
une machine différente, vous pouvez utiliser un cryptage basé sur un mot de passe au lieu
d'un cryptage transparent. Vous pouvez aussi cumuler les deux modes pour garantir que la
sauvegarde pourra être récupérée soit par le mot de passe, soit par le portefeuille de
cryptage.
• Dans le deuxième exercice, vous récupérez un fichier de données perdu à l'aide d'une
sauvegarde cryptée.
• Dans le troisième exercice, vous récupérez un portefeuille de cryptage perdu.

D78850FR20 sg1

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

D78850FR20 sg1

Transféré par

Droits d'auteur :

Formats disponibles

Oracle Database 12c: Backup

and Recovery Workshop

Manuel du stagiaire – Volume 1

Learn more from Oracle University at oracle.com/education/

Maria Billings Avertissement

3 Configuration en vue de la récupération

4 Utiliser le catalogue de restauration RMAN

5 Stratégies de sauvegarde et terminologie associée

6 Réaliser des sauvegardes

7 Améliorer des sauvegardes

8 Utiliser les sauvegardes RMAN cryptées

9 Diagnostiquer les défaillances

10 Concepts de restauration et de récupération

11 Procéder à une récupération I

12 Procéder à une récupération II

13 RMAN et Oracle Secure Backup

14 Utiliser les technologies Flashback

18 Dupliquer une base de données

19 Dépanner et régler RMAN

B Utiliser Enterprise Manager Cloud Control

Copyright © 2015, Oracle et/ou ses affiliés. Tous droits réservés.

A la fin de ce chapitre, vous pourrez :

Copyright © 2015, Oracle et/ou ses affiliés. Tous droits réservés.

Oracle Database 12c: Backup and Recovery Workshop 1 - 2

• Oracle Database 12c: Administration Workshop

Copyright © 2015, Oracle et/ou ses affiliés. Tous droits réservés.

Oracle Database 12c: Backup and Recovery Workshop 1 - 3

1 Module I : Introduction et configuration 3 11. Effectuer une récupération : Partie 1

2 Module II : Sauvegarde 4 15. Flashback Database

Copyright © 2015, Oracle et/ou ses affiliés. Tous droits réservés.

Oracle Database 12c: Backup and Recovery Workshop 1 - 4

Copyright © 2015, Oracle et/ou ses affiliés. Tous droits réservés.

Oracle Database 12c: Backup and Recovery Workshop 1 - 5

Copyright © 2015, Oracle et/ou ses affiliés. Tous droits réservés.

Oracle Database 12c: Backup and Recovery Workshop 1 - 6

Copyright © 2015, Oracle et/ou ses affiliés. Tous droits réservés.

Oracle Database 12c: Backup and Recovery Workshop 1 - 7

Oracle Database 12c: Backup and Recovery Workshop 1 - 8

• Evaluez les protections à mettre en oeuvre.

Copyright © 2015, Oracle et/ou ses affiliés. Tous droits réservés.

Oracle Database 12c: Backup and Recovery Workshop 1 - 9

Les pannes peuvent généralement être réparties en plusieurs

Copyright © 2015, Oracle et/ou ses affiliés. Tous droits réservés.

Oracle Database 12c: Backup and Recovery Workshop 1 - 10

• Composants inaccessibles : Fichiers de données

Copyright © 2015, Oracle et/ou ses affiliés. Tous droits réservés.

Oracle Database 12c: Backup and Recovery Workshop 1 - 11

Protection des données Minutes/Heures Technologies

Analyse de la récupération Réduire les délais Data Recovery Advisor

Objectif d'une Objectif de temps de Solution Oracle

Copyright © 2015, Oracle et/ou ses affiliés. Tous droits réservés.

Oracle Database 12c: Backup and Recovery Workshop 1 - 12

Oracle Enterprise Manager Cloud Control 12c (Cloud Control)

Copyright © 2015, Oracle et/ou ses affiliés. Tous droits réservés.

Oracle Database 12c: Backup and Recovery Workshop 1 - 13

Oracle Recovery Manager

Module OSB pour le cloud Stockage

• Sauvegarde et récupération Oracle pour l'ensemble de

Copyright © 2015, Oracle et/ou ses affiliés. Tous droits réservés.

Oracle Database 12c: Backup and Recovery Workshop 1 - 14

Copyright © 2015, Oracle et/ou ses affiliés. Tous droits réservés.

Oracle Database 12c: Backup and Recovery Workshop 1 - 15

Copyright © 2015, Oracle et/ou ses affiliés. Tous droits réservés.