D78850FR20 sg2

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

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

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

Objectifs
A la fin de ce chapitre, vous pourrez :
• identifier les composants d'Oracle Secure Backup
• décrire l'intégration entre RMAN et OSB
• configurer les sauvegardes RMAN sur bande et leur
restauration
• effectuer une sauvegarde RMAN sur bande
• effectuer une récupération de la base de données à partir
d'une bande
• gérer les sauvegardes sur bande
Remarque : Oracle Secure Backup et Oracle Database présentent des

numéros de version différents. OSB 10.4 est la version correcte pour
Oracle Database 12c. Pour obtenir toutes les informations à jour,
consultez le site OTN.
Il est à noter que les versions d'Oracle Secure Backup (OSB) ne suivent pas la même
numérotation que celles de la base de données. Ainsi, OSB 10.4 est la version correcte pour
Oracle Database 12c.
• La page d'accueil des produits est accessible via le site Oracle Technology Network (OTN) :
http://www.oracle.com/technetwork/products/secure-backup/overview/index.html.
• Vous pouvez télécharger de la documentation sur les produits à partir de ce site :
http://www.oracle.com/technetwork/products/secure-backup/documentation/index.html.
Oracle Database 12c : Backup and Recovery Workshop 13 - 2

Oracle Secure Backup : Présentation
Composants ou rôles d'hôte :
Serveur • Serveur d'administration
d'administration
– Gère les paramètres de
Catalogue OSB
configuration et le catalogue
de l'historique des
R sauvegardes
E
S Serveur • Serveur de média
E de média
A – Transfère les données vers
U ou depuis les périphériques
Périphérique
de stockage connectés
Client
• Client
Domaine
– Contient les données à
d'administration sauvegarder, par exemple :
Données à
sauvegarder
— Base de données Oracle
— Système de fichiers
Un domaine d'administration est un groupe d'ordinateurs de votre réseau que vous gérez comme
une unité globale pour exécuter des opérations de sauvegarde et de restauration. Il comprend un
serveur d'administration, un ou plusieurs clients, et un ou plusieurs serveurs de média.
• Le serveur d'administration est un ordinateur du domaine d'administration qui inclut une
installation complète du logiciel Oracle Secure Backup. Cet hôte gère les fichiers
du catalogue de sauvegarde ainsi que d'autres fichiers contenant des paramètres de
configuration et des données d'administration. Le serveur d'administration exécute le
planificateur, lequel lance et surveille les travaux exécutés dans le domaine d'administration.
Un seul serveur d'administration est nécessaire pour chaque domaine d'administration d'un
site. Vous configurez un serveur d'administration lors de l'installation d'Oracle Secure
Backup sur l'hôte.
• Un serveur de média est un ordinateur auquel sont connectés un ou plusieurs
périphériques de stockage secondaires, par exemple une librairie de sauvegarde.
Il échange des données avec les périphériques de stockage qui lui sont connectés.
Au cours de l'installation, vous pouvez configurer plusieurs périphériques de stockage
secondaires sur les serveurs de média.
• Un client est un ordinateur dont les données accessibles en local sont sauvegardées par
Oracle Secure Backup. Ces données peuvent être des bases de données ou des systèmes
de fichiers Oracle.

Options d'interface avec Oracle Secure Backup
Outil Web
EM
Oracle
RMAN Secure obtool
SBT
Backup
Opérations de base Opérations de système

de données de fichiers
La diapositive ci-dessus décrit quatre façons différentes d'accéder à Oracle Secure Backup en
fonction de ce que vous voulez faire :
• Enterprise Manager fournit une interface graphique pour les opérations de
sauvegarde/restauration sur bande via l'intégration avec RMAN. EM comprend un lien vers
l'outil Web d'Oracle Secure Backup pour les opérations de sauvegarde et de restauration
basées sur des systèmes de fichiers.
• Utilisez RMAN pour sauvegarder vos bases de données directement sur bande. RMAN est
accessible au moyen du client RMAN en mode ligne de commande et via l'interface
graphique Enterprise Manager. RMAN communique avec Oracle Secure Backup via
l'interface SBT (System Backup to Tape).
• L'outil Web est une application à interface graphique pour les tâches relatives à OSB.
Il vous permet de configurer des domaines d'administration, de gérer des opérations,
de parcourir le catalogue de sauvegarde, de sauvegarder et restaurer des données. Cette
interface graphique interactive fournit l'accès à l'utilitaire obtool. Vous devez l'utiliser pour
sauvegarder des données au niveau système de fichiers.
• L'utilitaire obtool fournit une interface en mode ligne de commande vers Oracle Secure
Backup.

Gérer les données à protéger
Base de données Données du système de

Oracle fichiers
Définir les données à Jeux de sauvegarde RMAN Jeux de données définis

sauvegarder par l'utilisateur : basés sur
des hôtes, des fichiers ou
des répertoires
Options de sauvegarde Utilisation des niveaux Plusieurs niveaux de

RMAN de sauvegarde sauvegarde : complète,
complète et incrémentielle incrémentielle ou hors site
Fréquence des Sauvegardes récurrentes Sauvegardes récurrentes

sauvegardes ou à la demande ou à la demande
Oracle Secure Backup et RMAN vous permettent de gérer facilement l'infrastructure

de sauvegarde des données des systèmes de fichiers et des bases de données Oracle.
D'un point de vue conceptuel, la définition des données à sauvegarder est similaire pour les
systèmes de fichiers et pour les bases de données. Dans les deux cas, vous devez définir les
éléments à inclure dans la sauvegarde.
• Pour la base de données, vous utilisez les jeux de sauvegarde RMAN.
• Lors de la sauvegarde de données de système de fichiers, OSB utilise la définition de "jeu
de données" qui décrit les données réelles du système de fichiers à sauvegarder. Pour
définir le jeu de données destiné à Oracle Secure Backup, vous pouvez faire appel à l'outil
Web ou à l'utilitaire obtool.
Une fois que vous avez défini les données à sauvegarder, vous devez déterminer le type de
sauvegarde qui répond le mieux à vos besoins en matière de sauvegarde et de restauration. Pour
les bases de données Oracle, RMAN propose des sauvegardes complètes et des sauvegardes
incrémentielles qui sont stockées sur bande par Oracle Secure Backup.
Pour les systèmes de fichiers, OSB offre plusieurs niveaux comprenant la sauvegarde complète,
les sauvegardes incrémentielles multiples et la sauvegarde hors site. La sauvegarde hors site est
une sauvegarde complète qui est exécutée indépendamment de toute stratégie de sauvegarde
incrémentielle.

Utilisez RMAN ou EM pour programmer vos sauvegardes de base de données ; utilisez Oracle
Secure Backup pour programmer vos sauvegardes de système de fichiers.
Une fois que vous avez défini les données à sauvegarder, choisi le type de sauvegarde et planifié
les opérations, Oracle Secure Backup peut implémenter vos plannings de sauvegarde
automatiquement. Vous intervenez seulement en cas de problèmes matériels ou de besoins en
supports.

Eléments de sauvegarde et images de sauvegarde
Utilisez RMAN pour gérer les éléments de sauvegarde RMAN.
Jeu de sauvegarde RMAN
Fichiers de Elément de Elément de

base de sauvegarde
sauvegarde …
données
Oracle RMAN RMAN
Image de Image de
sauvegarde sauvegarde
Images OSB
La sauvegarde d'une base de données Oracle créée par RMAN produit un jeu de sauvegarde
(une structure logique propre à RMAN) contenant au moins un élément de sauvegarde (fichier
physique propre à RMAN incluant les données sauvegardées).
Oracle Secure Backup (OSB) sauvegarde et gère dans son propre catalogue les métadonnées de
sauvegarde relatives aux différents éléments de sauvegarde RMAN écrits sur bande. Vous
pouvez consulter les éléments de sauvegarde à l'aide de l'outil en mode ligne de commande
obtool ou de l'interface Web d'Oracle Secure Backup.
Remarque : La meilleure solution est de mettre à jour les éléments de sauvegarde à l'aide
de RMAN, en évitant toute mise à jour manuelle via Oracle Secure Backup.
Lorsque vous gérez les éléments de sauvegarde stockés sur bande avec les utilitaires d'Oracle
Secure Backup plutôt qu'avec RMAN, le catalogue OSB et le référentiel RMAN peuvent être
désynchronisés. Le cas échéant, utilisez la commande RMAN CROSSCHECK avant de prendre
d'autres mesures correctives.

RMAN et Oracle Secure Backup Présentation
OS RMAN OSB
Librairie de sauvegarde
BACKUP
Fichier de
AS COPY Copie Image de Famille de supports
données 1 d'image sauvegarde
Jeu de volumes
BACKUP AS
BACKUPSET Volume Volume Volume
Fichier de Elément de Section Section Section
données 2 sauvegarde d'image de d'image de d'image de
sauvegarde sauvegarde sauvegarde
(filesperset 3)
Image de
sauvegarde
Volume Volume Volume

Fichier de
données 3 Elément de Section Section Section
sauvegarde d'image de d'image de d'image de
sauvegarde sauvegarde sauvegarde
Image de
sauvegarde
Fichier de
données 4
Jeu de
sauvegarde
Famille de supports
Fichier du
...
Image de
système sauvegarde
de fichiers
La diapositive ci-dessus présente une vue générale des composants RMAN et OSB. La partie
gauche illustre la relation entre les fichiers de données au niveau du système d'exploitation et les
copies d'image et éléments de sauvegarde RMAN, ainsi que les liens de ces derniers avec les
images de sauvegarde OSB. Les fichiers d'un système de fichiers n'ont pas d'équivalents RMAN
et sont donc reliés directement aux images de sauvegarde OSB.
La partie droite de la diapositive montre comment les images de sauvegarde OSB sont stockées
en tant que sections de volume dans des jeux de volumes appartenant chacun à une famille de
supports au sein d'une librairie de sauvegarde.

RMAN et Oracle Secure Backup :
Flux de processus élémentaire
EM
5 4
RMAN 1
2 Serveur
d'administration
3
Données en cours
Client OSB : de sauvegarde Serveur de
Serveur de bases média
de données
1. RMAN lance une sauvegarde et transmet à OSB le sélecteur de stockage des sauvegardes
de base de données. Si RMAN est démarré à partir de l'interface EM (Enterprise Manager),
vous devez configurer le serveur d'administration dans EM (configuration effectuée une fois
pour toutes).
2. Oracle Secure Backup crée le travail de sauvegarde. En principe, il utilise l'espace de noms
de système d'exploitation qui est associé à l'utilisateur OSB de la session en cours.
3. Oracle Secure Backup exécute le travail (il transfère les données du client au média).
4. Oracle Secure Backup met à jour son propre catalogue.
5. RMAN met à jour son référentiel.
Ce flux de processus et ses aspects les plus intéressants sont décrits en détail dans les pages
qui suivent.

Quiz
Dans une configuration qui inclut Oracle Secure Backup (OSB),

la meilleure méthode pour gérer les éléments de sauvegarde
Oracle (éléments de base de données) sur bande consiste à
utiliser :
a. OSB
b. RMAN
c. OSB ou RMAN
d. RMAN ou SQL
Réponse : b

Commencer à utiliser Oracle Secure Backup
Tâches d'installation :
• Installez le logiciel Oracle Secure Backup.
• Définissez des rôles d'hôte pour le serveur d'administration,
le(s) serveur(s) de média et les clients (partie intégrante de
l'installation).
• Déterminez vos exigences de sécurité et effectuez la
configuration appropriée. Par exemple, configurez la
préautorisation pour les interactions entre RMAN et OSB.
• Définissez un sélecteur de stockage des sauvegardes de base
de données, avec au moins un nom ou un ID de base de
données, un nom d'hôte unique et un type de contenu.
• Déterminez et définissez les stratégies de conservation
suivantes :
– Conservation RMAN en fonction du contenu
– Conservation OSB de système de fichiers en fonction du temps
La diapositive ci-dessus présente un aperçu des tâches de configuration initiale qui seront
décrites plus en détail dans les pages suivantes. Les tâches indiquées sont exécutées par
un utilisateur doté de privilèges élevés.
Vous devez déterminer les rôles d'hôte avant de commencer une installation. En effet,
la procédure d'installation OSB permet de configurer des rôles d'hôte initiaux.

Exécuter les tâches d'installation
1. Connectez-vous en tant qu'utilisateur root.

2. Créez un répertoire d'origine <OSB_Home> pour Oracle
Secure Backup.
3. Accédez au répertoire <OSB_Home>.
4. Exécutez le programme d'installation à partir de votre
répertoire<OSB_Home> et répondez aux invites.
[stage] $ su - root
Password: oracle [[** not displayed **]]
[stage]# mkdir -p /usr/local/oracle/backup
[stage]# cd /usr/local/oracle/backup
[backup]# /stage/osb_installmedia/setup
Il est recommandé d'installer le logiciel Oracle Secure Backup dans le répertoire

/usr/local/oracle/backup. Dans ce chapitre, ce répertoire est appelé OSB_Home.
Remarque : Il n'existe pas de variable d'environnement OSB_Home par défaut pour faire
référence à ce répertoire, alors qu'il existe une variable ORACLE_HOME pour les installations
d'Oracle Database.
Après avoir créé votre répertoire OSB_Home, basculez vers ce répertoire et exécutez le
programme d'installation à partir de votre zone intermédiaire, à savoir le répertoire
/stage/osb_installmedia dans cet exemple.

Vérifier votre installation
Quelques exemples :
• Afficher les processus Oracle Secure Backup dans Linux :
$ ps -e | grep ob
• Utiliser des commandes obtool pour afficher les

utilisateurs Oracle Secure Backup et la famille de supports
par défaut :
$ obtool
ob> lsuser
ob> lsmf --long
Le processus d'installation crée des objets par défaut. La diapositive présente quelques manières
de vérifier votre installation à l'aide de commandes obtool :
ob> lsuser
admin admin
oracle oracle
ob> lsmf --long
OSB-CATALOG-MF:
Write window: 7 days
Keep volume set: 14 days
Appendable: yes
Volume ID used: unique to this media family
Comment: OSB catalog backup media family
RMAN-DEFAULT:
Keep volume set: content manages reuse
Appendable: yes
Volume ID used: unique to this media family
Comment: Default RMAN backup media family
ob> logout

Sécuriser les données et l'accès
au domaine de sauvegarde
• Contrôle d'accès de niveau utilisateur
– Affectation des utilisateurs à des ensembles de privilèges appelés
classes
– Identité d'utilisateur cohérente, qui établit la correspondance entre
les privilèges du système d'exploitation et l'utilisateur Oracle Secure
Backup : on parle d'accès préautorisé
• Authentification d'hôte
– Authentification serveur bidirectionnelle
• Cryptage
– Cryptage Oracle Secure Backup pour les données en cours
de transfert et sur bande
– Pour les sauvegardes de la base de données :
cryptage RMAN ou OSB au choix
– Pour les sauvegardes au niveau système
de fichiers : cryptage OSB
• Pour accéder au logiciel Oracle Secure Backup, vous devez entrer un nom utilisateur et un
mot de passe, ou utiliser une préautorisation. Chaque utilisateur d'Oracle Secure Backup
est affecté à une classe qui définit les actions qu'il est autorisé à exécuter.
• Tous les hôtes du domaine d'administration utilisent des certificats SSL et X.509 pour
vérifier et authentifier l'identité des utilisateurs. Les données sensibles sont cryptées avant
d'être transmises sur le réseau. Le serveur Web exige un certificat X.509 signé et des clés
publiques et privées associées pour établir une connexion SSL avec un navigateur client. Le
certificat X.509 destiné au serveur Web est auto-signé par le script d'installation lorsque
vous installez OSB sur le serveur d'administration.
Remarque : Actuellement, le protocole NDMP (Network Data Management Protocol)
n'inclut pas de mécanisme permettant la négociation d'une connexion SSL avec des
serveurs de fichiers NDMP.
• Pour les sauvegardes de base de données, vous avez le choix entre le cryptage RMAN et le
cryptage OSB. Pour les sauvegardes de système de fichiers, utilisez le cryptage OSB.
Choix possibles pour le cryptage de la base de données :
- Cryptage de sauvegarde RMAN : les données sont cryptées au sein de la base.
- Cryptage OSB : les données sont cryptées après que RMAN les a transmises à OSB
via l'interface SBT.

Préautorisation
Script RMAN :
run { …
allocate channel oem_sbt_backup1 type 'SBT_TAPE' format '%U';
…}
Les utilisateurs préautorisés n'ont pas besoin de

se connecter explicitement.
Oracle Secure Backup effectue les vérifications

suivantes :
• Préautorisation RMAN
• Correspondance d'identité du système d'exploitation
et de la base de données
• Classe comprenant les droits de sauvegarde et/ou
restauration
Vous pouvez accorder aux utilisateurs Oracle Secure Backup une préautorisation d'accès à la
ligne de commande obtool (cmdline), à rman ou aux deux.
La préautorisation pour les sauvegardes au niveau système de fichiers sert principalement
à éviter la procédure de connexion à Oracle Secure Backup lors de l'exécution de scripts
personnalisés. A défaut de préautorisation cmdline, le script échouerait car l'accès à Oracle
Secure Backup n'est accordé qu'à l'issue d'une procédure de connexion de l'utilisateur.
La préautorisation RMAN est requise pour sauvegarder ou restaurer la base de données Oracle.
Ces sauvegardes de base de données peuvent être exécutées à partir de RMAN ou d'Enterprise
Manager. Quand il reçoit une communication en provenance de RMAN (via sbt), Oracle Secure
Backup vérifie que l'utilisateur OSB répond aux critères suivants :
1. Préautorisation RMAN sur l'hôte.
2. Correspondance avec l'identité utilisateur du système d'exploitation de l'instance Oracle
associée à la base de données (par exemple, oracle).
3. Affectation à une classe OSB comprenant les droits de sauvegarder et/ou restaurer la base
de données :
- access Oracle backups (défini sur owner, class, ou all)
- perform Oracle backups and restores
Si ces trois critères ne sont pas remplis, Oracle Secure Backup n'exécute pas les demandes de
sauvegarde ou de restauration RMAN.

Définir la conservation des sauvegardes RMAN
• Appliquer une stratégie de conservation avec les
sauvegardes sur disque et sur bande
• Définir une stratégie de conservation RMAN avec RECOVERY
WINDOW
• Utiliser la commande RMAN DELETE OBSOLETE :
– Supprimer les fichiers obsolètes du disque
– Signaler à Oracle Secure Backup les éléments de sauvegarde
qui ne sont plus utiles
• Définir des familles de supports gérées en fonction du
contenu pour RMAN et Oracle Secure Backup
(recommandation)
Fichier2 Fichier1 Maintenant
Fenêtre de récupération RMAN

Conservation pendant sept jours
Lorsque vous définissez des périodes de conservation dans RMAN, une combinaison de
sauvegardes sur disque et sur bande est utilisée pour répondre à vos besoins en matière de
récupération. Si vous utilisez Oracle Secure Backup et la zone de récupération rapide, la stratégie
de conservation RMAN recommandée est la définition par l'utilisateur de l'option RECOVERY
WINDOW. Cela signifie que vous définissez la période pendant laquelle la récupération jusqu'à un
point dans le temps doit être possible. Lorsque vous définissez la fenêtre de récupération, tenez
compte également des points suivants :
• La durée de conservation requise dépend des besoins en matière de récupération.
• La zone de récupération rapide doit être dimensionnée en fonction de la capacité de
récupération souhaitée à partir du disque.
• Des sauvegardes sur disque et sur bande doivent être programmées (fréquence et portée).
Si le plan de récupération prévoit un certain nombre d'heures par jour pour la restauration à partir
du disque, la zone de récupération rapide doit être suffisamment spacieuse pour pouvoir contenir
les fichiers nécessaires à la récupération pour la période considérée. La durée pendant laquelle
les sauvegardes restent dans la zone de récupération rapide est déterminée par la quantité
d'espace disque disponible et non par un paramètre temporel spécifique.
Exemple de commande obtool permettant de créer une famille de supports pour les
sauvegardes RMAN :
ob> mkmf --vidunique --writewindow forever content-man-family

Gestion des supports : Stratégies d'expiration en
vue du recyclage automatique des bandes
OSB
Recyclage des volumes gérés en fonction du temps Prêt pour réutilisation :
Lendemain de
Fenêtre d'écriture Durée de conservation l'expiration du volume
Mises à jour Mises à jour

autorisées interdites
Création du jeu Fermeture du jeu
de volumes de volumes
Sauvegardes au niveau Librairie de sauvegarde
système de fichiers,
ne concerne pas RMAN Famille de supports
Jeu de volumes
Volume Volume Volume
Fichier du sys- Section Section Section
tème de fichiers Image de d'image de d'image de d'image de
sauvegarde sauvegarde sauvegarde sauvegarde
Système OSB
d'exploitation
Oracle Secure Backup automatise le recyclage des bandes en réutilisant celles-ci une fois que
les sauvegardes ou les volumes ont expiré, selon la méthode de recyclage définie par l'utilisateur.
Stratégies d'expiration basées sur le temps : Le moment de l'expiration est défini au niveau du
volume pour les familles de supports gérées en fonction du temps. Lorsqu'un volume arrive à
expiration, son contenu peut être écrasé. Chaque volume d'un jeu a une date d'expiration
déterminée comme suit :
• La fenêtre d'écriture définie par l'utilisateur détermine la durée pendant laquelle la bande
peut être remplie après le premier événement d'écriture (facultatif).
• La durée de conservation définie par l'utilisateur détermine le temps pendant lequel le
volume doit être conservé après la fin de la fenêtre d'écriture ou, si aucune fenêtre d'écriture
n'a été définie, après le premier événement d'écriture sur bande. Si aucune fenêtre
d'écriture n'a été définie, le volume accepte des insertions jusqu'à ce qu'il soit plein.
• L'expiration intervient au terme de la durée de la fenêtre d'écriture augmentée de la durée
de conservation.
En résumé, les volumes gérés en fonction du temps pour les sauvegardes de système de fichiers
ont une période d'expiration définie par l'utilisateur qui ne dépend pas de leur contenu. (Cette
stratégie ne concerne pas RMAN.)

Sélecteur de stockage
des sauvegardes de base de données
• RMAN transmet à OSB le nom de la base de données,
le type de contenu et le numéro de copie.
• OSB détermine le sélecteur correspondant.
• Le sélecteur indique la famille de périphériques et de
supports (ainsi que les restrictions éventuelles).
RMAN OSB
Nom de BdD (* = toutes) Hôte (* = tous)
ID de BdD Sélecteur de Famille de supports
stockage des
Nombre de copies sauvegardes Périphériques restreints
de base de
Contenu : archivelog, données Temps d'attente des ressources
full, incremental, Cryptage
autobackup
Les sélecteurs de stockage de sauvegarde de base de données sont destinés aux opérations de
sauvegarde et de restauration des bases Oracle. Ils sont gérés en tant que type d'objet sur le
serveur d'administration.
Lorsque RMAN effectue une sauvegarde de base de données Oracle vers des périphériques et
des supports gérés par Oracle Secure Backup, il transmet à Oracle Secure Backup le nom de la
base, le type du contenu et le nombre de copies. A partir de ces informations, OSB détermine le
sélecteur de stockage de sauvegarde approprié. Le sélecteur indique à Oracle Secure Backup
(s'il y a lieu) les périphériques auxquels restreindre la sauvegarde et la famille de supports à
utiliser.
Les sélecteurs de stockage de sauvegarde permettent d'indiquer les ressources devant être
utilisées par les sauvegardes SBT. Un objet de type sélecteur de stockage de sauvegarde de
base de données contient les informations mentionnées dans la diapositive.
• Un astérisque (*) comme nom ou ID de base de données indique que le sélecteur de
stockage s'applique à toutes les bases de données.
• Un astérisque (*) en tant qu'hôte indique que le sélecteur s'applique aux bases résidant sur
tous les hôtes disponibles.

Définir les paramètres de gestion
des supports dans RMAN
Utiliser le paramètre ENV de l'option parms :
• OB_MEDIA_FAMILY[_n] pour les supports à utiliser
• OB_DEVICE[_n] pour les unités de bande
• OB_RESOURCE_WAIT_TIME pour la disponibilité
des ressources
• OB_ENCRYPTION pour le cryptage OSB
• OB_RESTORE_DEVICE pour l'opération de restauration
• OB_IGNORE_NUMA pour l'accès NUMA
run {
allocate channel c1 device type sbt parms
'ENV=(OB_MEDIA_FAMILY=my_mf)';
backup database include current controlfile;
backup archivelog all not backed up;
}
Si vous utilisez des sélecteurs de stockage de base de données OSB, il n'est pas nécessaire de
définir des paramètres de gestion des supports dans RMAN. Certaines circonstances peuvent
toutefois exiger d'outrepasser ces sélecteurs en définissant explicitement des paramètres RMAN.
Vous pouvez préciser des paramètres de gestion des supports de différentes manières :
• Variables d'environnement définies à l'aide du paramètre ENV de l'option PARMS dans
la commande CONFIGURE ou ALLOCATE CHANNEL
• Commande RMAN SEND
Vous pouvez utiliser les paramètres OSB répertoriés dans la diapositive dans les travaux
de sauvegarde et de restauration RMAN.
Le paramètre OB_IGNORE_NUMA (nouveauté dans OSB 10.4) régit la prise en charge de l'accès
NUMA (Non-Uniform Memory Access). Sa valeur par défaut est 1 (NUMA activé).

Récapitulatif de la configuration OSB pour RMAN
Configurer Oracle Secure Backup pour RMAN :

1. Accès RMAN à l'interface SBT d'OSB
2. Préautorisation
3. Familles de supports pour les sauvegardes RMAN
(avec expiration des volumes et ID de volume unique)
4. Sélecteur de stockage des sauvegardes de base de
données
5. Paramètres de gestion des supports dans RMAN
(facultatifs)
1. Configurez l'accès RMAN à l'interface SBT d'Oracle Secure Backup. Si vous utilisez
Enterprise Manager Database Control, cette étape consiste à enregistrer le serveur
d'administration auprès d'Enterprise Manager. (Il suffit d'indiquer le répertoire d'origine
d'Oracle Secure Backup. RMAN localise automatiquement la librairie SBT.)
2. Créez un utilisateur OSB préautorisé.
3. Oracle Corporation recommande de créer explicitement des familles de supports pour les
sauvegardes RMAN. Lorsque vous créez une famille de supports, vous indiquez un ID de
volume unique et une stratégie d'expiration qui détermine à quel moment un volume de
cette famille peut être recyclé.
Si vous ne créez pas de familles de supports dédiées, Oracle Secure Backup utilise
une famille de supports par défaut (solution suffisante dans le cadre de ce cours).
4. Créez un sélecteur de stockage des sauvegardes de base de données dans Enterprise
Manager ou à l'aide de l'utilitaire obtool.
5. Si vous utilisez des sélecteurs de stockage de base de données Oracle Secure Backup, il
n'est pas indispensable de définir les paramètres de gestion des supports dans RMAN.
Une fois que vous avez configuré RMAN pour utiliser l'interface SBT d'Oracle Secure Backup, les
procédures à accomplir pour effectuer les opérations de sauvegarde et de restauration RMAN sur
bande sont identiques à celles utilisées pour les opérations sur disque.

Sauvegarder la zone de récupération rapide sur bande
• Une seule commande RMAN :

RMAN> BACKUP DEVICE TYPE SBT RECOVERY AREA;
• Avantages de la zone de récupération rapide sur bande :
– Exécution de sauvegardes sur bande optimisées
– Première restauration à partir de la zone de récupération
rapide pour des performances maximales, puis utilisation
de la bande (si nécessaire)
– Réduction des E/S de base de données (groupe de disques
distinct)
Pour sauvegarder la zone de récupération rapide sur bande à l'aide d'Oracle Secure Backup,
lancez la commande RMAN : BACKUP DEVICE TYPE SBT RECOVERY AREA. Cette méthode
de sauvegarde de disque à bande (au lieu d'exécuter une sauvegarde distincte de la base de
production sur bande) présente plusieurs avantages :
• Réalisation de sauvegardes optimisées de la zone de récupération rapide qui permettent
d'économiser les bandes. Elimination des sauvegardes inutiles de fichiers se trouvant déjà
sur bande.
• Utilisation par RMAN d'une logique de restauration plus performante : d'abord à partir du
disque, puis d'une bande si nécessaire. Sinon, RMAN utilise la sauvegarde la plus récente,
indépendamment du support de stockage.
• Réduction des E/S (ce qui est important dans le cas d'une base de production) car la zone
de récupération rapide utilise un groupe de disques distinct.

Travaux Oracle Secure Backup
Journal :
Evénements importants
Travail
Sauvegarde
Restauration
ID Transcription :
Type Détails du travail
Récapitulatifs de
travaux : Fichiers
texte pour les
opérations au
niveau du système
de fichiers
Un travail est créé pour chaque opération de sauvegarde ou de restauration. Chaque travail est
associé à un ID unique, un journal et une transcription (illustrés dans le graphique ci-dessus).
• Le journal d'un travail décrit les principaux événements :
- Création du travail
- Répartition du travail
- Temps d'exécution
• La transcription décrit les détails d'un travail :
- Elle est créée au moment de la répartition
- Elle est mise à jour au fur et à mesure de la progression du travail
- Elle signale les besoins tels que la nécessité d'une intervention de l'opérateur
Il existe deux types de travail :
• Travaux sur ensembles de données (dataset jobs) pour les sauvegardes et les restaurations
des systèmes de fichiers
• Travaux de sauvegarde (backup jobs) Oracle pour les sauvegardes et les restaurations des
bases de données
Les récapitulatifs de travaux sont des fichiers texte produits par Oracle Secure Backup qui
décrivent l'état de travaux sélectionnés de sauvegarde et de restauration de système de fichiers.
Les rapports récapitulatifs de travaux peuvent être générés régulièrement puis envoyés par email
aux utilisateurs.

Afficher les fichiers de journalisation
et les transcriptions
Gestionnaire de support Oracle Secure Backup

(Oracle ou tiers) (répertoire <OSB_Home>)
DIAGNOSTIC_DEST=<ADR base> admin/log/scheduler/log

- <ADR home>
- /trace/sbtio.log
Si une erreur survient au cours d'une session SBT, Oracle Secure Backup essaie d'envoyer sa
description au serveur d'administration afin qu'elle soit enregistrée dans la transcription du travail.
RMAN enregistre l'erreur dans le fichier trace sbtio.log, sauf si l'utilisateur a configuré un
fichier différent. Le paramètre d'initialisation DIAGNOSTIC_DEST indique l'emplacement de la
base ADR (Automatic Diagnostic Repository), c'est-à-dire du répertoire qui contient un ou
plusieurs répertoires d'origine ADR. Par défaut, le fichier sbtio.log se trouve dans le sous-
répertoire trace.
La description d'une erreur SBT contient les informations suivantes :
• Emplacement (fonction) où l'erreur s'est produite (par exemple, sbtbackup)
• Opération qui était en cours d'exécution (par exemple, "creating a backup piece")
• Description succincte du problème (par exemple, "unable to contact admin server")
• Description succincte de la solution que l'utilisateur peut appliquer (s'il y a lieu)
• Nom d'un fichier trace ou d'un fichier de débogage contenant des informations
complémentaires sur le problème (s'il y a lieu)
Vous pouvez obtenir d'autres informations de trace à l'aide de l'option TRACE de la commande
ALLOCATE CHANNEL. Par exemple : ALLOCATE CHANNEL c1 TYPE sbt TRACE 5 …
La fourchette des niveaux de trace va de 0 (erreurs uniquement) à 6 (informations détaillées de
débogage).

Commandes obtool courantes
Catégorie Commande obtool
Hôtes lshost -l
Périphériques lsdev
Sélecteurs de stockage lsssel
Informations utilisateur id, lsuser, lsclass
Travaux et plannings lsjob (-a | -c | -p)

lsbw (fenêtres de sauvegarde)
lssched
Sauvegardes lsds (informations sur les ensembles de données)

lspiece (éléments de sauvegarde RMAN)
lsbackup (sauvegardes de système de fichiers)
lssection (sections d'image de sauvegarde)
Familles de supports lsmf --long
Volumes lsvol --all ou lsvol --library <libname>
La diapositive ci-dessus répertorie quelques-unes des commandes obtool courantes que vous
pouvez utiliser pour interroger les données d'administration et de catalogue d'Oracle Secure
Backup. D'autres options permettent de préciser les informations à extraire, par exemple la liste
de tous les volumes d'une famille de supports ou la liste des travaux terminés.
Pour plus d'informations sur ces options, reportez-vous au manuel Oracle Secure Backup
Reference.
Ces commandes peuvent vous aider à résoudre les problèmes liés à l'installation et à la
configuration d'OSB. Par exemple, la commande lshost affiche les rôles actuels d'un hôte. Si
vous souhaitez ajouter un périphérique à votre domaine OSB, l'hôte doit avoir le rôle
mediaserver, lequel n'est pas installé par défaut.

Quiz
Quels paramètres RMAN transmet-il à OSB via un sélecteur de

stockage de base de données ?
a. Nom ou ID de base de données
b. Numéro de copie
c. Nom unique de l'hôte
d. Type de contenu
Réponses : a, b, d

Quiz
Quels types de contenu peuvent être associés à un sélecteur

de stockage ?
a. Journal archivé
b. Tablespace
c. Fichier de données
d. Sauvegarde automatique
e. Sauvegarde incrémentielle
Réponses : a, d, e

Quiz
Quelle est la stratégie de conservation recommandée pour

les sauvegardes RMAN réalisées avec OSB ?
a. Fenêtre de récupération RMAN
b. Gestion par OSB de la durée de conservation
Réponse : a

Quiz
Où RMAN peut-il consigner les erreurs en provenance d'OSB

transmises sur l'interface SBT ?
a. Dans $ORACLE_HOME/trace/sbtio.log par défaut
b. Dans /usr/local/oracle/sbtio.log par défaut
c. Dans un autre emplacement défini par le DBA
d. Dans $ORACLE_HOME/rdbms/log/sbtio.log par
défaut
Réponses : c, d

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

• identifier les composants d'Oracle Secure Backup
• décrire l'intégration entre RMAN et OSB
• configurer les sauvegardes RMAN sur bande et leur
restauration
• effectuer une sauvegarde RMAN sur bande
• effectuer une récupération de la base de données à partir
d'une bande
• gérer les sauvegardes sur bande

Présentation des exercices :
Effectuer des sauvegardes et des restaurations
RMAN basées sur un support de bande
Dans ces exercices, vous allez :
• Effectuer une sauvegarde RMAN sur bande
• Restaurer un fichier de données à partir d'une sauvegarde
sur bande

Utiliser les technologies Flashback

Objectifs

• utiliser les technologies Flashback à titre de prévention
et de protection contre divers types d'erreur
• configurer votre base de données pour l'utilisation des
technologies Flashback
• effectuer des opérations Flashback
• faire la distinction entre validité temporelle et historique

Technologies Flashback :
Détection et correction d'erreurs
• Flashback simplifie énormément la récupération des erreurs,
en vous permettant de :
– consulter les données telles qu'elles étaient à un moment passé
– "défaire" les modifications de données indésirables
– réduire le temps de correction des erreurs
• Flashback est facile à utiliser et inclut des commandes simples
qui n'impliquent pas de procédures complexes.
Récupération
Flashback traditionnelle
80
Temps de récupération
60
40
20
0
Les technologies Flashback d'Oracle Database constituent un ensemble de solutions de

récupération de données qui permettent de corriger des erreurs humaines en annulant leurs
effets de manière sélective et efficace. Elles prennent en charge des récupérations à tous
niveaux : ligne, transaction, table ou base de données entière.

Rappels : Transactions et informations d'annulation
Données
d'origine dans
le cache de
tampons
Données d'annulation "anciennes"

dans le tablespace d'annulation
Opérations DML
Lorsqu'une transaction commence, un segment d'annulation lui est affecté. Pendant la durée de
vie de la transaction, lorsque des données sont modifiées, les "anciennes" valeurs d'origine sont
copiées dans ce segment. Pour voir les affectations de segments d'annulation aux transactions,
consultez la vue V$TRANSACTION.
Les segments d'annulation sont des segments spécialisés créés automatiquement par l'instance
pour la prise en charge des transactions. Comme n'importe quel segment, ils sont constitués
d'extents (ensembles de blocs contigus), eux-mêmes composés de blocs de données. Les
segments d'annulation changent de taille en fonction des besoins, agissant comme un tampon de
stockage circulaire pour les transactions qui leur sont affectées.
Lorsqu'une transaction a rempli tous les blocs de son extent de segment d'annulation en cours,
un autre bloc lui est affecté dans le même extent. S'il ne reste plus de blocs libres, elle obtient un
bloc provenant de l'extent suivant du segment. Une fois tous les extents consommés, la
transaction revient au premier extent ou demande à ce qu'un nouvel extent soit alloué au
segment d'annulation.
La partie gauche du graphique de la diapositive représente une table dans laquelle sont stockées
des données d'origine provenant d'une opération DML. Ces données sont conservées dans le
cache de tampons (si elles ne sont pas retirées de la mémoire sur la base de la liste LRU) puis
écrites dans le tablespace d'annulation (représenté par une forme circulaire dans la partie droite).
Remarque : Les opérations DML en parallèle peuvent forcer une transaction à utiliser plusieurs
segments d'annulation. Pour plus d'informations sur l'exécution de code DML en parallèle,
reportez-vous au manuel Oracle Database VLDB and Partitioning Guide.

Technologie Flashback
Utilisations de la technologie Flashback :
• Afficher des données dans un état antérieur
• Dérouler la chronologie des données d'avant
en arrière et inversement
• Aider les utilisateurs à analyser les erreurs
et à y remédier
Pour l'analyse des erreurs :
Oracle Flashback Query
Oracle Flashback Version Query
Oracle Flashback Transaction Query Pour la récupération des erreurs :
Oracle Flashback Transaction Backout
Oracle Flashback Table
Oracle Flashback Drop
Oracle Flashback Database
La technologie Flashback d'Oracle est un groupe de fonctionnalités permettant de consulter les

états antérieurs des données (et de dérouler leur chronologie dans les deux sens) sans qu'il soit
nécessaire d'effectuer une restauration de la base à partir d'une copie de sauvegarde. Grâce à
cette technologie, vous pouvez aider les utilisateurs à analyser leurs erreurs et à y remédier.
• Flashback Query : Afficher les données validées dans la base à un point donné du passé.
La commande SELECT assortie de la clause AS OF permet de désigner un moment dans le
passé, à l'aide d'un horodatage ou d'un numéro SCN (System Change Number).
• Flashback Version Query : Afficher les données d'historique validées correspondant à un
intervalle de temps spécifique. Utilisez la clause VERSIONS BETWEEN de la commande
SELECT (pour des raisons de performances avec les index existants).
• Flashback Transaction Query : Afficher les modifications effectuées au niveau des
transactions.
• Flashback Transaction Backout : Annuler (rollback) une transaction spécifique et les
transactions dépendantes.
• Flashback Table : Restituer dans une ou plusieurs tables le contenu correspondant à un
point dans le passé, sans affecter les autres objets de la base.
• Flashback Drop : Annuler les effets d'une suppression de table en rappelant cette table et
les objets dépendants (index et déclencheurs) dans la base de données à partir de la
corbeille.
• Flashback Database : Rétablir l'état de la base de données correspondant à un moment du
passé ou à un numéro SCN.

Technologie Flashback
Niveau Exemples de scénario Technologie Dépend de Affecte les

objet Flashback données
Base de Vidage d'une table ; modifications Database Journaux Flashback Oui
données non souhaitées sur plusieurs tables
Table Suppression d'une table Drop Corbeille Oui
Mise à jour avec une clause WHERE Table Données d'annulation Oui
incorrecte
Comparaison de données actuelles Query Données d'annulation Non

avec des données du passé
Comparaison des versions Version Query Données d'annulation Non

d'une ligne
Transaction Recherche et annulation Transaction Données d'annulation / Oui

de transactions suspectes Query de journalisation
provenant de journaux
archivés
Table et Audit, conformité, rapports Data Archive Tablespace Non

transaction historiques, gestion du cycle de vie (Temporal)
Vous pouvez utiliser la technologie Flashback lorsqu'une corruption logique se produit dans une
base Oracle et que vous avez besoin de récupérer rapidement les données. Comme dans le cas
des erreurs humaines, il est difficile d'identifier les objets et les lignes affectés par une transaction
incorrecte. Avec la technologie Flashback, il est possible de déterminer de quelle façon les
erreurs ont été introduites dans la base de données, puis de réparer les dommages. Vous pouvez
afficher les transactions qui ont contribué à des modifications de ligne spécifiques, afficher toutes
les versions d'une ligne spécifique sur une période donnée ou simplement afficher des données
telles qu'elles apparaissaient à un point spécifique dans le temps. Le tableau de la diapositive
présente des utilisations standard de la technologie Flashback. L'opération Flashback Database
s'appuie sur les journaux Flashback. Flashback Drop utilise la corbeille. Toutes les autres
fonctionnalités utilisent les données d'annulation.
Les fonctionnalités Flashback ne modifient pas toutes la base de données. Certaines servent
simplement à interroger d'autres versions des données. Vous pouvez faire appel à ces dernières
pour analyser un problème et pour vous aider lors de la récupération :
• Déterminer le type d'opération flashback à utiliser pour corriger le problème.
• Utiliser le résultat de l'interrogation dans une commande INSERT, UPDATE ou DELETE
permettant de réparer les données erronées.

Préparer la base de données pour un flashback
• Accordez des privilèges FLASHBACK.

• Paramètres pertinents pour l'annulation :
– UNDO_TABLESPACE='UNDOTBS1'
– UNDO_MANAGEMENT='AUTO'
– UNDO_RETENTION=900
– Garantir la conservation des informations d'annulation
Pour activer les fonctionnalités Flashback pour une application, vous devez :
• Octroyer des privilèges Flashback aux utilisateurs, rôles ou applications qui ont besoin
d'utiliser ces fonctionnalités.
• Avoir un tablespace d'annulation disposant d'un espace suffisant pour conserver les
données requises par les opérations Flashback. Plus la fréquence de mise à jour des
données par les utilisateurs est élevée, plus l'espace requis est important.
Pour un tablespace d'annulation automatiquement extensible (option par défaut), la base Oracle
conserve les données d'annulation de manière à pouvoir répondre au minimum aux besoins de
conservation de l'interrogation dont l'exécution est la plus longue et au seuil de conservation des
informations d'annulation défini par le paramètre UNDO_RETENTION. Vous pouvez interroger la
vue V$UNDOSTAT.TUNED_UNDORETENTION pour déterminer la durée pendant laquelle les
données d'annulation sont conservées au niveau du tablespace d'annulation actuel. La définition
du paramètre UNDO_RETENTION ne garantit pas qu'il n'y aura aucun écrasement de données
d'annulation non parvenues à expiration. Le comportement par défaut consiste à écraser les
informations d'annulation de transactions validées même si elles n'ont pas encore expiré plutôt
que de laisser une transaction active échouer à cause d'un manque d'espace. En cas de conflit,
les transactions sont prioritaires sur les interrogations. Ce comportement peut toutefois être
modifié via la garantie de la période de conservation.

Garantir la période de conservation
des informations d'annulation
Conservation garantie :
15 minutes
Données Une transaction qui génère trop

Les instructions SELECT qui
stockées dans d'informations d'annulation par rapport
s'exécutent en 15 minutes ou moins
sont honorées par défaut. le tablespace à l'espace disponible échoue.
d'annulation
SQL> ALTER TABLESPACE undotbs1 RETENTION GUARANTEE;
Avec une durée de conservation garantie, les paramètres de conservation des informations
d'annulation sont appliqués même s'ils entraînent l'échec de transactions. (En cas de conflit, les
interrogations sont prioritaires sur les transactions, comme le montre le schéma de la diapositive
ci-dessus.)
Indiquez la clause RETENTION GUARANTEE au niveau du tablespace d'annulation pour garantir
que les données d'annulation non expirées ne seront pas supprimées. En configurant la garantie
de conservation, vous devez comprendre que les opérations en cours qui ont besoin d'espace
d'annulation dans les segments du tablespace concerné risquent d'échouer. RETENTION
GUARANTEE est un attribut de tablespace et non un paramètre d'initialisation. La diapositive ci-
dessus en présente un exemple. Pour rétablir le comportement par défaut :
SQL> ALTER TABLESPACE undotbs1 RETENTION NOGUARANTEE;
Si vous devez satisfaire à des besoins de conservation de longue durée, créez un historique.

Quiz
Parmi les technologies Flasback suivantes, lesquelles utilisent

des données d'annulation ?
a. Flashback Database
b. Flashback Drop
c. Flashback Table
d. Flashback Query
e. Flashback Version Query
f. Flashback Transaction Query
Réponses : c, d, e, f

Flashback
¾ - Query
Utiliser la technologie Flashback - Version
- Table
pour interroger les données - Transaction
- Drop
• Flashback Query - Data Archive
– Interroger toutes les données à un point dans le temps spécifique.

• Flashback Version Query
– Voir toutes les versions d'une ligne entre
deux points dans le temps.
– Voir les transactions qui ont modifié la ligne.
• Flashback Transaction Query
– Voir toutes les modifications effectuées par une transaction.
11:00 11:10
La technologie Flashback permet d'interroger des versions antérieures des objets de schéma et
des données historiques, et d'effectuer une analyse des modifications. D'un point de vue logique,
chaque transaction génère une nouvelle version de la base de données. Avec la technologie
Flashback, vous pouvez accéder à ces versions pour rechercher une erreur et son origine :
• Flashback Query : Interroger toutes les données telles qu'elles se présentaient à un point
dans le temps spécifique.
• Flashback Version Query : Consulter toutes les versions d'une ligne entre deux points
dans le temps, ainsi que les transactions qui ont modifié cette ligne.
• Flashback Transaction Query : Consulter toutes les modifications effectuées par une
transaction et, si nécessaire, annuler les effets d'une transaction à l'aide de commandes
SQL "undo".

Flashback Query
Permet d'interroger toutes les données correspondant à

un point dans le temps ou un numéro SCN spécifique.
Mises à jour
indésirables
T1 T2
SELECT employee_id, salary FROM employees

AS OF TIMESTAMP <T1>
WHERE employee_id = 200
La fonctionnalité Flashback Query permet d'interroger un état antérieur de la base de données.

La clause AS OF de l'instruction SELECT permet d'indiquer le moment qui vous intéresse. Cette
méthode est pratique pour analyser une divergence de données.
Remarque : TIMESTAMP et SCN sont les options acceptées par la clause AS OF.

Flashback
- Query
Flashback Version Query ¾ - Version
- Table
La clause VERSIONS : - Transaction
- Drop
• Extrait toutes les versions des lignes entre - Data Archive
deux points dans le temps ou deux numéros SCN
• Extrait uniquement les données validées
• Ne peut pas être utilisée pour interroger des tables
externes, des tables temporaires, des tables fixes ou
des vues
• Peut être utilisée pour créer des vues
• Ne peut pas englober de commandes DDL
• Filtre les opérations de récupération d'espace dans
les segments
SELECT versions_xid, salary FROM employees
VERSIONS BETWEEN TIMESTAMP <t1> and <t2>
WHERE employee_id = 200;
La fonctionnalité Flashback Version Query permet d'utiliser la clause VERSIONS pour extraire
toutes les versions des lignes entre deux points dans le temps ou deux numéros SCN. Les lignes
renvoyées représentent un historique des modifications effectuées par différentes transactions.
Flashback Version Query extrait uniquement les données validées (commit) dans la base. Les
versions non validées des lignes au sein d'une transaction ne sont pas affichées. Les lignes
renvoyées incluent également les versions supprimées puis réinsérées des lignes.
Utilisez cet historique pour auditer les lignes d'une table et obtenir des informations sur les
transactions qui les ont affectées. L'identificateur de transaction renvoyé (pseudo-colonne
VERSIONS_XID) peut ensuite servir à effectuer une extraction de transactions à l'aide de
LogMiner ou à lancer une opération Flashback Transaction Query.
• La clause VERSIONS ne peut pas être utilisée pour interroger des tables externes, des
tables temporaires, des tables fixes ou des vues. En revanche, vous pouvez l'utiliser pour
créer une vue.
• La clause VERSIONS d'une instruction SELECT ne peut pas produire les versions des lignes
modifiées par des instructions DDL (Data Definition Language) qui changent la structure des
tables correspondantes. Cela signifie que l'interrogation cesse de produire des lignes
lorsqu'elle atteint un point dans le passé correspondant à la modification de la structure de
la table.
• Certaines opérations de maintenance, par exemple une récupération d'espace dans les
segments, sont susceptibles de déplacer des lignes au sein des blocs. Dans ce cas,
l'interrogation exclut les versions fantômes de ce type car les données de la ligne restent
inchangées.

Flashback
- Query
Flashback Table : Présentation - Version
¾ - Table
- Transaction
- Drop
• Flashback Table récupère des tables jusqu'à - Data Archive
un point spécifique dans le temps.
• Il s'agit d'une opération "sur place".
• La base de données reste en ligne.
Instructions DML Tables ayant fait

erronées Utilisateur l'objet d'un
flashback
Flashback Table permet de récupérer des tables à un moment spécifique de leur évolution sans
avoir à effectuer les opérations traditionnelles de récupération jusqu'à un point dans le temps.
Une opération Flashback Table est réalisée sur place, pendant que la base de données est en
ligne, en annulant (rollback) uniquement les modifications apportées aux tables indiquées ainsi
qu'à leurs objets dépendants.
Une instruction Flashback Table est exécutée en tant que transaction unique. Si elle ne réussit
pas pour toutes les tables, l'intégralité de la transaction est annulée.
Remarque : Vous pouvez utiliser Flashback Version Query et Flashback Transaction Query pour
déterminer l'instant de flashback approprié.

Flashback Table
• Récupérer une ou plusieurs tables (et les objets associés)
à un point spécifique dans le temps sans restaurer de
sauvegarde
• Utiliser les données du tablespace d'annulation
• Prérequis :
– Privilège FLASHBACK ANY TABLE ou privilège objet
FLASHBACK sur la table concernée
– Privilèges SELECT, INSERT, DELETE et ALTER sur la table
– Déplacement de lignes activé
• Interfaces : Cloud Control et SQL*Plus
FLASHBACK TABLE hr.departments TO TIMESTAMP

TO_TIMESTAMP('2013-01-25 21:00:00',
'YYYY-MM-DD HH24:MI:SS');
Flashback Table vous permet de récupérer une ou plusieurs tables jusqu'à un point dans le
temps spécifique sans avoir à restaurer de sauvegarde. Lorsque vous utilisez cette fonctionnalité,
les données des tables sont restaurées avec les objets associés (index, contraintes,
déclencheurs (triggers), etc.). Les données utilisées pour répondre à une demande Flashback
Table sont extraites du tablespace d'annulation. Vous pouvez utiliser Flashback Version Query et
Flashback Transaction Query pour déterminer l'instant de flashback approprié.
Flashback Table permet aux utilisateurs d'effectuer facilement et rapidement une récupération
suite à des modifications accidentelles, sans l'intervention d'un administrateur de base de
données. Vous devez octroyer le privilège système FLASHBACK TABLE ou FLASHBACK ANY
TABLE à tout utilisateur qui emploie la fonctionnalité Flashback Table. Vous devez également lui
octroyer les privilèges objet SELECT, INSERT, DELETE et ALTER.
Vous pouvez utiliser Enterprise Manager ou SQL*Plus pour effectuer un flashback sur une table.
L'assistant vous guide tout au long du processus.
Pour pouvoir effectuer un flashback sur une table, vous devez activer le déplacement de lignes
(row movement) dans cette table. Le serveur Oracle peut alors déplacer une ligne dans la table.
Utilisez Enterprise Manager ou la commande ALTER TABLE pour activer le déplacement de
lignes.

Flashback Table : Points à prendre en compte
• La commande FLASHBACK TABLE est exécutée en tant

que transaction unique. Elle acquiert des verrous DML
de type Exclusive.
• Les statistiques ne font pas partie du flashback.
• Les index en cours et les objets dépendants sont
conservés.
• Les opérations Flashback Table :
– ne peuvent pas être exécutées sur des tables système
– ne peuvent pas concerner des opérations DDL
– génèrent des données d'annulation (undo) et de
journalisation (redo)
• L'instruction FLASHBACK TABLE est exécutée dans son ensemble dans le cadre d'une
transaction unique. Le flashback est effectué pour toutes les tables indiquées, ou pour
aucune.
• L'instruction Flashback Table acquiert des verrous DML (Data Manipulation Language) de
type Exclusive sur toutes les tables indiquées, pour la période nécessaire à l'opération.
• Les statistiques relatives aux objets concernés ne font pas partie du flashback.
• Tous les index existants sont conservés. Les index supprimés ne sont pas recréés. Les
vues matérialisées sur validation (commit) dépendantes sont également conservées
automatiquement.
• Les tables indiquées dans l'instruction FLASHBACK TABLE font l'objet d'un flashback, à
condition qu'aucune des contraintes définies sur ces tables ne soit enfreinte. Si des
contraintes sont enfreintes pendant l'exécution du flashback, l'opération est abandonnée et
les tables sont laissées dans l'état où elles se trouvaient avant l'appel de l'instruction
FLASHBACK TABLE.
• Vous ne pouvez pas appliquer une opération Flashback Table jusqu'à un point dans le
temps antérieur au point d'exécution d'une opération DDL (Data Definition Language) qui a
altéré la structure d'une table ou qui a permis de récupérer de l'espace dans une table
impliquée dans l'opération Flashback. Cette restriction ne s'applique pas aux instructions
DDL qui modifient uniquement les attributs de stockage des tables.
• L'opération Flashback Table ne peut pas être exécutée sur des tables système, des tables
distantes ou des tables fixes.

Flashback
- Query
Flashback Transaction Query - Version
- Table
¾ - Transaction
- Drop
- Data Archive
DBA
FLASHBACK_TRANSACTION_QUERY
Flashback Version Query
Flashback Transaction Backout
Code DML
erroné Code SQL
d'annulation
Flashback Transaction Query est un outil de diagnostic que vous pouvez utiliser pour consulter
les modifications apportées à la base de données au niveau transaction. Il permet de
diagnostiquer les problèmes dans la base de données et d'effectuer des analyses et des audits
sur les transactions (comme illustré dans le graphique ci-dessus).
Vous pouvez utiliser la vue FLASHBACK_TRANSACTION_QUERY pour déterminer toutes les
instructions SQL à utiliser pour annuler les modifications apportées par une transaction spécifique
ou sur une période donnée.
Cette fonctionnalité est utilisée en liaison avec la fonctionnalité Flashback Version Query avec
l'aide de l'assistant Perform Recovery Wizard.

Flashback Transaction Query :
Points à prendre en compte
• Les commandes DDL sont vues comme des mises à jour
du dictionnaire.
• Une opération Flashback Transaction Query sur une
transaction portant une commande DDL affiche les
modifications apportées au dictionnaire de données.
• Les objets supprimés apparaissent en tant que numéros
d'objet.
• Les utilisateurs supprimés apparaissent en tant qu'ID
utilisateur.
Dans la base de données, les opérations DDL sont simplement une série d'opérations de gestion
de l'espace et de modifications du dictionnaire de données. Une opération Flashback Transaction
Query sur une transaction portant une commande DDL affiche les modifications apportées au
dictionnaire de données.
Lorsque Flashback Transaction Query implique des tables qui ont été supprimées de la base de
données, les noms de ces tables n'apparaissent pas. Ils sont remplacés par des numéros d'objet.
Si l'utilisateur qui a exécuté une transaction est supprimé, l'opération Flashback Transaction
Query sur cette transaction affiche uniquement l'ID de l'utilisateur correspondant. Le nom de
l'utilisateur n'apparaît pas.
Remarque : Lorsque les données d'annulation sont en nombre insuffisant pour une transaction
spécifique, une ligne contenant la valeur UNKNOWN dans la colonne OPERATION de
FLASHBACK_TRANSACTION_QUERY est renvoyée.

Flashback Transaction Backout
• Utilisez cette fonctionnalité pour annuler les effets d'une

transaction et des transactions dépendantes.
• Oracle Database détermine les dépendances entre
transactions et crée une transaction de compensation qui
défait les modifications non souhaitées.
• La journalisation supplémentaire doit être activée.
• Les privilèges SELECT, FLASHBACK et DML doivent être
accordés sur toutes les tables concernées.
Avec Flashback Transaction, vous pouvez annuler les effets d'une transaction ainsi que des
transactions qui en dépendent. Oracle Database détermine les dépendances entre transactions
et, de fait, crée une transaction de compensation qui défait les modifications non souhaitées. La
base de données est "rembobinée", comme si la transaction (et toutes celles qui pourraient en
dépendre) n'avait jamais eu lieu.
Vous pouvez utiliser la fonctionnalité Flashback Transaction à partir d'Enterprise Manager ou par
le biais de packages PL/SQL.
Pour procéder à un flashback ou une annulation (back-out) de transaction (c'est-à-dire pour créer
une transaction de compensation), vous devez disposer de privilèges SELECT, FLASHBACK et
DML sur toutes les tables concernées.

Exécuter un flashback de transaction
• Utilisez Enterprise Manager ou la procédure
DBMS_FLASHBACK. TRANSACTION_BACKOUT.
• Si l'appel PL/SQL se termine avec succès, cela signifie
que la transaction n'a pas de dépendances et qu'une seule
transaction a été annulée.
• Une fois que l'option d'annulation est sélectionnée,
le rapport concernant les dépendances est généré dans
les vues DBA_FLASHBACK_TXN_STATE et
DBA_FLASHBACK_TXN_REPORT.
• Examinez ce rapport qui indique toutes les transactions
annulées.
• Validez (commit) les modifications pour les rendre
permanentes. Ou :
• Annulez (rollback) la procédure pour supprimer
les modifications.
L'assistant Flashback Transaction Wizard d'Enterprise Manager appelle la procédure

DBMS_FLASHBACK.TRANSACTION_BACKOUT avec l'option NOCASCADE.
Conseils d'utilisation
• L'annulation de transactions n'est pas prise en charge en cas de conflits entre instructions
DDL.
• L'annulation de transactions hérite de la prise en charge des types de données de
LogMiner.
• Lorsque vous identifiez la nécessité d'une annulation de transaction, lancez l'opération dès
que possible afin d'améliorer les performances. Des fichiers de journalisation (redo logs)
volumineux et des vitesses d'exécution des transactions élevées ralentissent les opérations
d'annulation.
• Fournissez un nom de transaction pour l'opération d'annulation afin de faciliter un audit
ultérieur. A défaut, un nom sera généré automatiquement.
La vue DBA_FLASHBACK_TXN_STATE indique si une transaction est actuellement active dans le
système ou effectivement annulée. Cette table est mise à jour par les transactions de
compensation. Chaque transaction de compensation peut correspondre à plusieurs lignes,
chacune fournissant la relation de dépendance entre les transactions affectées.
La vue DBA_FLASHBACK_TXN_REPORT fournit des informations détaillées sur toutes les
transactions de compensation qui ont été validées dans la base de données. Chaque ligne de
cette vue est associée à une (et une seule) transaction de compensation.

Recommandation : Flashback basé sur
les informations d'annulation :
Flashback Query, Flashback Table
• La fonction de conseil Undo Advisor d'Enterprise Manager
fournit des recommandations concernant les options de
taille disponibles pour la conservation des informations
d'annulation.
• Informations d'annulation de taille fixe : La conservation
des informations d'annulation est réglée automatiquement
pour garantir la meilleure conservation possible en fonction
de la taille du tablespace et de la charge système en
cours.
• Restrictions DDL : Impossible d'interroger un moment du
passé en cas de modification structurelle de table(s).
Certaines commandes DDL qui modifient la structure d'une table invalident les données
d'annulation concernant cette table. Il s'agit notamment des commandes qui suppriment et
modifient des colonnes, déplacent des tables, suppriment des partitions ou vident des tables ou
des partitions. Il n'est pas possible d'extraire des données antérieures à l'exécution de ces
commandes DDL. Toute tentative à cet effet génère une erreur ORA-1466. Cette restriction ne
s'applique pas aux opérations DDL qui modifient les attributs de stockage d'une table, notamment
PCTFREE, INITRANS et MAXTRANS.

Flashback
- Query
Flashback Drop et la corbeille - Version
- Table
- Transaction
¾ - Drop
- Data Archive
1 RECYCLEBIN=ON
2 3
DROP TABLE employees; FLASHBACK TABLE
employees
TO BEFORE DROP;
Par erreur
A l'aide de la commande FLASHBACK TABLE, vous pouvez annuler les effets d'une instruction
DROP TABLE sans avoir recours à une récupération jusqu'à un point dans le temps (comme le
montre le graphique ci-dessus).
1. Le paramètre d'initialisation RECYCLEBIN permet de contrôler si la fonction Flashback Drop
est activée (ON) ou désactivée (OFF). Lorsqu'il est défini sur OFF, les tables supprimées ne
sont pas placées dans la corbeille.
2. Si ce paramètre a la valeur (par défaut) ON, les tables supprimées vont dans la corbeille.
3. Les tables supprimées peuvent être récupérées à l'aide de la commande FLASHBACK
TABLE …TO BEFORE DROP.

Corbeille
BIN$zbjrBdpw==$0 EMPLOYEES
BIN$zbjra9wy==$0 EMPLOYEES_PK
Corbeille
DBA_FREE_SPACE
EMPLOYEES BIN$zbjrBdpw==$0
3
EMPLOYEES_PK BIN$zbjra9wy==$0
Les objets :
– sont renommés
– ne sont pas
1 déplacés
2 DROP TABLE employees;
Si la corbeille n'est pas activée et que vous supprimez une table, l'espace correspondant peut
être utilisé immédiatement par d'autres objets. En revanche, si vous supprimez une table alors
que la corbeille est activée, l'espace associé à la table et aux objets dépendants n'est pas
immédiatement récupérable, même s'il apparaît dans DBA_FREE_SPACE. Les objets supprimés
sont référencés dans la corbeille et appartiennent toujours à leur propriétaire. L'espace utilisé par
les objets de la corbeille n'est jamais récupéré automatiquement, sauf en cas de manque
d'espace. Cela vous permet de récupérer les objets de la corbeille pendant un laps de temps le
plus long possible.
Lorsqu'une table supprimée est "déplacée" vers la corbeille, elle est renommée à l'aide d'un nom
généré par le système, de même que les objets et contraintes associés. Le modèle de nom utilisé
est BIN$unique_id$version, où unique_id est un identificateur unique de niveau global
(GUID) de 26 caractères pour cet objet (rendant ainsi le nom de la corbeille unique sur l'ensemble
des bases de données) et version est un numéro de version attribué par la base.
La corbeille proprement dite est une table du dictionnaire de données qui gère les relations entre
les noms d'origine des objets supprimés et les noms générés par le système pour ces derniers.
Vous pouvez interroger la corbeille à l'aide de la vue DBA_RECYCLEBIN. Le diagramme de la
diapositive illustre ce comportement :
1. Vous avez créé une table nommée EMPLOYEES dans votre tablespace.
2. Vous supprimez la table EMPLOYEES.
3. Les extents (ensembles de blocs contigus) qui étaient occupés par la table EMPLOYEES sont
libérés.
4. La table EMPLOYEES est renommée et son nouveau nom est enregistré dans la corbeille.

Ignorer la corbeille
DROP TABLE <table_name> [PURGE] ;
DROP TABLESPACE <ts_name>

[INCLUDING CONTENTS] ;
DROP USER <user_name> [CASCADE] ;
Désactiver l'utilisation de la corbeille :

ALTER SYSTEM SET RECYCLEBIN=OFF SCOPE=SPFILE;
• Vous pouvez exécuter la commande DROP TABLE PURGE pour supprimer définitivement de
la base de données une table et ses objets dépendants. Lorsque vous utilisez cette
commande, les objets correspondants ne sont pas envoyés dans la corbeille.
• Lorsque vous exécutez la commande DROP TABLESPACE ... INCLUDING CONTENTS, les
objets du tablespace supprimé ne sont pas placés dans la corbeille. En outre, les objets de
la corbeille qui appartiennent à ce tablespace sont purgés. Si vous exécutez la même
commande sans la clause INCLUDING CONTENTS, il faut que le tablespace soit vide pour
que l'exécution réussisse. Cependant, la corbeille peut contenir des objets appartenant au
tablespace. Dans ce cas, ces objets sont purgés.
• Lorsque vous exécutez la commande DROP USER ... CASCADE, l'utilisateur et tous les
objets dont il est propriétaire sont supprimés de façon permanente de la base de données.
Tous les objets de la corbeille appartenant à l'utilisateur supprimé sont purgés.
Pour des raisons de sécurité, vous pouvez décider de ne pas autoriser l'accès à la corbeille (par
exemple, l'objet en cours est crypté mais l'objet supprimé est en texte clair et risque de dévoiler
des données sensibles). Connecté en tant que SYSDBA, vous pouvez effectuer les opérations
suivantes :
• Afficher le statut de la corbeille : SHOW PARAMETER RECYCLEBIN
• Désactiver l'utilisation de la corbeille : ALTER SYSTEM SET RECYCLEBIN=OFF
SCOPE=SPFILE; Vous devez redémarrer la base de données après avoir exécuté cette
commande.

Flashback
- Query
Utiliser Flashback Data Archive - Version
- Table
- Transaction
Suivi automatisé de l'historique des modifications - Drop
de la base : ¾ - Data Archive
• Activation au niveau table, avec la durée de conservation
de votre choix.
• Les modifications ultérieures sont stockées de manière
transparente et sécurisée.
• Les données pour lesquelles la durée de conservation est
dépassée sont supprimées automatiquement.
• Utiliser les technologies Flashback pour interroger les données
historiques.
SELECT … AS OF TIMESTAMP…
SELECT … VERSIONS BETWEEN TIMESTAMP and TIMESTAMP…
Cas d'utilisation des requêtes

Flashback : Rapports d'audit,
mises à jour Table historique Historique interrogations de conformité, d'historique,
de la gestion du cycle de vie
base
Flashback Data Archive constitue un mécanisme de suivi des modifications apportées aux bases
de production qui est à la fois sûr, efficace, facile d'emploi et transparent pour les applications.
Cette technologie permet de surveiller et stocker automatiquement les données dans les tables
activées pour FDA. Les interrogations Flashback obtiennent ainsi un accès de niveau SQL aux
versions des objets de base de données sans recevoir d'erreur Snapshot Too Old.
Une archive FDA permet le suivi et le stockage de toutes les modifications transactionnelles
apportées à une table "surveillée" pendant toute sa durée de vie. Il n'est plus nécessaire
d'intégrer cette fonctionnalité à l'application. Vous pouvez utiliser Flashback Data Archive pour
créer des rapports de conformité ou d'audit, analyser des données ou alimenter des systèmes
d'aide à la décision.

Créer un historique et activer l'archivage
1. Créez un nouveau tablespace pour le stockage des
données historiques.
2. Créez une archive FDA, affectez-la au tablespace et
indiquez sa durée de conservation. (Cette tâche nécessite
le privilège système FLASHBACK ARCHIVE ADMINISTER.)
CREATE FLASHBACK ARCHIVE fda1 TABLESPACE fda_tbs1
OPTIMIZE DATA QUOTA 10M RETENTION 1 YEAR;
Optimisation FDA autre que par défaut avec compression et suppression des doublons
3. Modifiez les tables de base pour activer leur archivage

et affectez une archive Flashback. (Cette tâche nécessite
le privilège objet FLASHBACK ARCHIVE.)
ALTER TABLE HR.EMPLOYEES FLASHBACK ARCHIVE fda1;
Historique
Table de base
Une archive FDA (Flashback Data Archive) est composée d'au moins un tablespace. Vous
pouvez disposer de plusieurs archives FDA. Celles-ci sont configurées avec une durée de
conservation. En fonction des durées de conservation exigées, il est recommandé de créer
différentes archives : par exemple, une pour tous les enregistrements qui doivent être conservés
pendant deux ans et une autre pour tous les enregistrements qui doivent être conservés pendant
cinq ans. Le serveur de base de données purge automatiquement toutes les informations
historiques dès le lendemain du jour où la période de conservation expire.
1. Créez un tablespace pour votre archive FDA. La taille dépend de la table de base et de
l'activité DML et DDL attendue.
2. Créez une archive FDA avec une durée de conservation (par défaut, avec duplication et
sans compression). Les données archivées seront conservées pendant cette durée. Cette
tâche nécessite le privilège système FLASHBACK ARCHIVE ADMINISTER. Si vous avez
besoin de définir plusieurs durées de conservation, créez plusieurs archives. La clause
OPTIMIZE DATA crée l'archive FDA avec compression des données et suppression des
doublons.
3. Activez l'archivage Flashback pour l'ensemble d'une table (puis désactivez-le). Cette tâche
requiert le privilège objet FLASHBACK ARCHIVE. Même quand l'archivage Flashback est
activé sur une table, certaines instructions DDL ne sont pas autorisées sur cette table.
L'archivage Flashback est désactivé par défaut pour toutes les tables.

Fonctionnement de Flashback Data Archive
Données historiques :
• Les lignes sont capturées de manière asynchrone par des
processus en arrière-plan à intervalles réguliers définis
automatiquement (par défaut, toutes les cinq minutes)
• Purge automatique conformément à la stratégie de
conservation
DML
• Stockage par défaut non optimisé

Données d'origine
• Avec la clause OPTIMIZE DATA :
dans le cache de
annulation Données compression et .élimination
.. des
tampons d'annulation
doublons
DML
Processus en
arrière-plan fbda help Esclaves fbda (selon les besoins)
données historiques
• Partitions créées
automatiquement, sur des critères
de temps et de volume
• Les partitions non liées sont
EMPLOYEES FDA1 ignorées par les interrogations
Les données historiques sont capturées à partir des données d'annulation (et du cache de
tampons) par le processus en arrière-plan fdba selon des intervalles réguliers définis
automatiquement. L'intervalle par défaut est de cinq minutes. Une ligne mise à jour de la table de
base est stockée dans son intégralité, quel que soit le nombre de colonnes modifiées.
• La clause OPTIMIZE DATA active automatiquement la compression des tables et des
objets LOB et la suppression des doublons LOB, avec des options variées : Compression
avancée de table au niveau ligne, compression et déduplication intelligentes SecureFiles,
compression ILM aux niveaux segment et ligne. La gestion de cycle de vie (ILM, Information
Lifecycle Management) est activée pour permettre aux nouvelles données d'être archivées
sans compression, puis compressées en arrière-plan au bout d'un certain temps.
Remarque : Si la table de base utilise la compression de colonne hybride, elle ne peut pas
être activée pour l'archivage FDA.
• Les tables d'historique FDA déjà compressées et débarrassées des doublons qui
proviennent de versions inférieures à 12.1 ne sont pas modifiées. Elles continuent d'être
stockées sous forme compressée et sans duplication de données.
• Pour cesser d'optimiser les tables d'historique FDA, exécutez l'instruction suivante :
SQL> ALTER FLASHBACK ARCHIVE fla1 NO OPTIMIZE DATA;
• Chaque partition Flashback Data Archive (FDA) dispose d'au moins 1 jour et 1 Mo, avec un
partitionnement sur ENDSCN. Les interrogations Flashback sur les archives ignorent les
partitions non liées.
• Le processus fbda peut appeler jusqu'à dix processus esclaves d'archivage Flashback.
• Si ces processus sont trop occupés, l'archivage peut être effectué en ligne, mais cela affecte
notablement les temps de réponse.

Collecter le contexte utilisateur dans un historique
• Niveaux de collecte : NONE (par défaut), TYPICAL, ALL
– Définis avec
DBMS_FLASHBACK_ARCHIVE.SET_CONTEXT_LEVEL
– Le niveau TYPICAL collecte l'ID utilisateur de la base de
données, l'ID utilisateur global, l'identifiant du client, le nom
du service, le nom du module et le nom de l'hôte
• Obtenu via GET_SYS_CONTEXT (USERENV)
SQL> EXEC DBMS_FLASHBACK_ARCHIVE.SET_CONTEXT_LEVEL('TYPICAL')
PL/SQL procedure successfully completed
SQL> SELECT DBMS_FLASHBACK_ARCHIVE.GET_SYS_CONTEXT

2 (VERSIONS_XID, 'USERENV','SESSION_USER'),
3 VERSIONS_XID,VERSIONS_STARTTIME,VERSIONS_ENDTIME,
4 employee_id, salary
5 FROM hr.employees VERSIONS BETWEEN SCN MINVALUE
6 AND MAXVALUE ;
• Le contexte utilisateur d'une transaction exécutée sur une table avec historique peut être
collecté et extrait. Les paramètres de l'espace de noms USERENV décrivent la session en
cours. Le contexte utilisateur est obtenu à l'aide de
DBMS_FLASHBACK_ARCHIVE.GET_SYS_CONTEXT.
• Sa collecte est contrôlée par un paramètre (défini par
DBMS_FLASHBACK_ARCHIVE.SET_CONTEXT_LEVEL) qui admet les valeurs NONE,
TYPICAL et ALL. Par défaut, aucun contexte utilisateur n'est collecté.
Dans le cas TYPICAL, les informations collectées sont notamment l'ID utilisateur de la base
de données, l'ID utilisateur global, l'identifiant de client, le nom du service, le nom du module
ou le nom d'hôte.
• Les lignes de ces tables sont purgées lorsque la date de validation est antérieure à la plus
ancienne des dates de conservation des archives Flashback.
• Chaque ligne du contexte utilisateur peut être lue uniquement par le DBA ou par le
propriétaire de la transaction.

Evolution transparente de schéma
• Opérations DDL prises en charge :
– Ajouter, supprimer, renommer et modifier une colonne
– Supprimer et vider une partition
– Renommer et vider une table
Flashback Version Query
1 2 3
1
Ajouter une
une colonne
2
Supprimer
colonne
3
temps
• Les interrogations Flashback s'appliquent aux

modifications DDL précédentes.
• Les autres instructions DDL ne sont pas prises en
charge automatiquement.
Les commandes DDL (Data Definition Language) les plus courantes peuvent être utilisées avec
les archives FDA (Flashback Data Archive). Lorsqu'un schéma évolue (de l'une des façons
indiquées dans la diapositive), la technologie d'historique (Temporal History) garde
automatiquement une trace des modifications. Flashback Query renvoie les lignes appropriées
avec le schéma correspondant (comme indiqué dans le diagramme).

Evolution complète de schéma
Dissociez ou associez des procédures dans le package
DBMS_FLASHBACK_ARCHIVE :
• Désactivez Flashback Archive sur des tables spécifiques
et autorisez des opérations DDL plus complexes
(mises à niveau, fragmentation de tables, etc.).
• Assurez l'intégrité du schéma pendant l'association.
(La table de base et la table d'historique doivent appartenir
au même schéma.)
Remarque : Utilisez cette fonction avec précaution, en sachant
que l'archive n'est plus garantie immuable puisque l'historique
a pu être modifié au moment de la dissociation.
1 2
Table
dissocier Modifier le schéma de
Table base
d'histo-
rique associer Modifier le schéma Table
d'histo-
4 3 rique
Toutes les modifications DDL qui ne sont pas prises en charge automatiquement peuvent être
exécutées via le package DBMS_FLASHBACK_ARCHIVE.
Remarque : Utilisez cette fonction avec précaution, en sachant que l'archive ne peut plus être
garantie comme immuable puisque l'historique a pu être modifié au moment de la dissociation.
Un message est consigné dans le catalogue système lorsque la dissociation se produit.
Le diagramme de la diapositive illustre le workflow suivant :
1. Si vous disposez du privilège FLASHBACK ARCHIVE ADMINISTER, vous pouvez dissocier
l'archive de la table de base à l'aide de la procédure DISASSOCIATE_FBA.
2. Apportez les modifications nécessaires à la table de base.
3. Apportez les modifications nécessaires à l'archive correspondante.
4. Associez ensuite la table à l'archive au sein du même schéma, à l'aide de la procédure
RESASSOCIATE_FBA. La fonctionnalité d'historique vérifie que les schémas sont identiques
après l'association.
Les tables d'historique ne sont pas transportables. Certaines instructions DDL provoquent une
erreur ORA-55610 lorsqu'elles sont appliquées à une table activée pour FDA, par exemple :
• ALTER TABLE …avec la clause UPGRADE TABLE
• instruction ALTER TABLE qui déplace ou échange une opération sur une partition ou sous-
partition
• instruction DROP TABLE

Flashback
- Query
Validité temporelle et historique - Version
- Table
- Transaction
Différencier les lignes actives - Drop
des lignes inactives : ¾ - Data Archive
• Validité temporelle : Date ID Date

Poste
de valeur effective, gérée employé d'embauche
par l'utilisateur, dans la 100 Clerk 22-Apr-11
même table
200 Developer 12-Dec-11
• Historique : Chronologie
des transactions gérée 400 Salesman 22-Mar-12
par le système dans un
tablespace distinct
Archive FDA
Table Requête
Insertion de Historique Interrogations
base Flashback
23-Mar-12
Les applications annotent souvent la validité d'un fait enregistré dans une table avec des dates ou
des horodatages adaptés aux besoins métier sous-jacents (par exemple, la date d'embauche d'un
employé dans des applications de ressources humaines ou la date effective des garanties dans le
secteur des assurances). Cet attribut temporel de validité est généralement contrôlé par
l'utilisateur qui définit la dimension de période de validité lors de la création des tables.
Les dates et horodatages de validité temporelle diffèrent de ceux mentionnés au moment où le
fait a été enregistré dans la base de données. Les dates et horodatages de l'enregistrement des
faits dans la base de données sont des attributs de l'historique (également appelé Flashback
Data Archive - FDA) ; ils sont gérés par le système.
Dans l'exemple de la diapositive, l'employé 400 a été embauché le 22 mars, mais la ligne
correspondante n'a été entrée que le 23 mars dans la table HR.EMP. 22-MAR-12 est la date de
valeur dans l'historique, tandis que 23-MAR-12 est la date d'opération dans l'historique.
Avec l'application implicite du filtre sur la dimension Période de validité, une interrogation peut
obtenir les lignes qui sont actuellement valides ou qui seront valides à l'avenir. L'interrogation
peut masquer les lignes dont les faits ne sont actuellement pas valides.
Les interrogations bi-temporelles peuvent utiliser à la fois la date de validité et la date de
transaction.

Utiliser la clause PERIOD FOR
• Conserver des données actives et inactives dans la même table.
• Définir une dimension de période de validité lors de la création
de la table.
– Définir explicitement les deux colonnes date/heure.
– Ou : Laisser le système créer ces colonnes automatiquement.
SQL> CREATE TABLE emp
2 ( empno number, salary number, deptid number,
3 name VARCHAR2(100),
4 user_time_start DATE, user_time_end DATE,
5 PERIOD FOR user_time (user_time_start,user_time_end));
• Insérer des lignes en nommant explicitement
les colonnes de période de validité.
SQL> CREATE TABLE emp2
2 ( empno number, salary number, deptid number,
3 name VARCHAR2(100),
3 PERIOD FOR user_time);
Une dimension de date de valeur (représentée par la nouvelle clause PERIOD FOR) se compose
de deux colonnes de date/heure qui peuvent être indiquées dans la définition de table (premier
exemple ci-dessus) ou qui sont créées automatiquement (second exemple ci-dessus).
Pour masquer les colonnes correspondant à la dimension de période de validité, il suffit d'indiquer
une clause PERIOD FOR sans mentionner les colonnes de date/heure. Oracle crée deux
colonnes masquées et utilise le nom de la dimension Période de validité comme préfixe de leurs
noms. Le nom de la dimension Période de validité est utilisé pour supprimer cette dimension au
besoin. Dans le deuxième exemple, vous avez défini le nom user_time pour cette dimension et
ce nom est utilisé comme préfixe pour les deux colonnes de date/heure créées
automatiquement : USER_TIME_START et USER_TIME_END.
Pour insérer des lignes dans une table dotée d'une dimension de période de validité, vous
nommez les deux colonnes de date/heure correspondantes de la manière suivante :
SQL> INSERT INTO emp2 (empno, salary, deptid, name, user_time_start,
user_time_end) VALUES (1,1000,20, 'John', SYSDATE, NULL);
SQL> select EMPNO, user_time_start, user_time_end from emp2;
EMPNO USER_TIME_START USER_TIME_END
---------- ----------------------------------- ------------------
1 17-AUG-12 09.58.03.000000 AM +00:00

Filtrage sur les colonnes avec une dimension
Période de validité : Exemple 1
Appliquer un filtre sur les colonnes de période de validité pour n'accéder qu'aux données actives :
JEAN
SCOTT
ADAM
KIM
01-JAN-90 01-JAN-94 31-DEC-10

01-JAN-91 30-JUN-94 31-DEC-11
01-JAN-92 31-DEC-12
01-JAN-93 31-DEC-13
JIM
MARIA
TOM
SQL> select * from hr.emp as of PERIOD FOR user_time

2 to_date('01-DEC-1992', 'dd-mon-yyyy') ;
Comment filtrer les données sur les colonnes de période de validité ? Exécutez l'instruction
SELECT avec la clause PERIOD FOR ou utilisez la procédure DBMS_FLASHBACK_ARCHIVE.
• Il existe un ensemble de données "valide" en fonction des horodatages de début et de fin de
la dimension Période de validité et en fonction de l'horodatage de l'interrogation (clause
AS OF ou aucun attribut).
• D'autre part, il existe un autre ensemble de lignes où l'horodatage de l'interrogation n'est
pas inclus dans la période de validité.
Ces deux ensembles de lignes résident dans la même table. En limitant la visibilité des données
aux lignes valides, vous pouvez contrôler la portée des interrogations et des instructions DML.
Jusqu'à présent, vous pouviez effectuer des interrogations avec la clause AS OF et des
interrogations de versions pour la période de transaction uniquement. Vous pouvez désormais
faire la même chose pour la période de validité.
Pour chaque nouvel employé que vous avez inséré dans la table, vous avez inclus une date
d'embauche et des dates de début et de fin de validité. Ces dates indiquent si une ligne est active
ou inactive. Elles sont entrées par l'application et correspondent à des dates valides. Le moment
où les lignes ont été insérées et validées dans la table correspond à la date de transaction.
Vous pouvez filtrer les employés actifs en utilisant la nouvelle clause PERIOD FOR.
L'interrogation présentée dans la diapositive affiche tous les employés actifs qui étaient valides à
la date explicite '01-DEC-1992', c'est-à-dire pour lesquels cette date est comprise dans la
période de validité située entre USER_TIME_START et USER_TIME_END.

Filtrage sur les colonnes avec une dimension
Période de validité : Exemple 2
Utiliser des interrogations de versions pour la dimension Période de validité :
JEAN
SCOTT
ADAM
KIM
01-JAN-90 01-JAN-94 31-DEC-10

01-JAN-91 30-JUN-94 31-DEC-11
01-JAN-92 31-DEC-12
01-JAN-93 31-DEC-13
JIM
MARIA
TOM
SQL> SELECT * FROM hr.emp VERSIONS PERIOD FOR user_time

2 BETWEEN to_date('31-DEC-2011','DD-MON-YYYY')
3 AND to_date('31-DEC-2012','DD-MON-YYYY');
Vous pouvez filtrer les employés actifs en utilisant la clause VERSIONS PERIOD FOR
BETWEEN :
select * from hr.emp VERSIONS PERIOD FOR user_time
BETWEEN to_date('31-DEC-2011', 'dd-mon-yyyy')
AND to_date('31-DEC-2012', 'dd-mon-yyyy') ;
Cette interrogation extrait tous les employés pour lesquels la date VALID_TIME_START est
antérieure ou égale à '31-DEC-2011' et la date VALID_TIME_END est égale ou ultérieure à
'31-DEC-2012'.
Les interrogations qui combinent les dimensions de période de validité et de période de
transaction sont dites "bitemporelles".
Cet exemple affiche les lignes correspondant à la date de transaction spécifiée et qui sont valides
actuellement.
select * from hr.emp
as of period for user_time to_date('31-DEC-1992', 'dd-mon-yyyy')
as of timestamp to_date ('30-mar-2012','dd-mon-yyyy');

Utiliser DBMS_FLASHBACK_ARCHIVE
• Le contrôle de la visibilité s'applique aux interrogations et aux
instructions DML.
• La visibilité totale s'applique au code DDL.
• Définition de la visibilité avec DBMS_FLASHBACK_ARCHIVE :
– Définir la visibilité des données valides à un moment donné :
DBMS_FLASHBACK_ARCHIVE.ENABLE_AT_VALID_TIME('ASOF',
(to_timestamp('29-SEP-10 05.44.01 PM'))
– Définir la visibilité des données valides actuellement au sein
de la période de validité au niveau session :
DBMS_FLASHBACK_ARCHIVE.ENABLE_AT_VALID_TIME('CURRENT')
– Définir la visibilité des données au niveau de la table entière :
DBMS_FLASHBACK_ARCHIVE.ENABLE_AT_VALID_TIME('ALL')
Les utilisateurs peuvent modifier la visibilité des données au sein d'une session à l'aide du
nouveau package DBMS_FLASHBACK_ARCHIVE. Le contrôle de la visibilité s'applique à toutes les
instructions SQL SELECT et au code DML (Data Manipulation Language).
Pour les instructions DDL (Data Definition Language), les données visibles sont par défaut toutes
les données de la table. Par exemple, les opérations CTAS (create table as select), de
redéfinition en ligne et ALTER TABLE MOVE ont une visibilité totale sur les données de la table.
Les colonnes masquées sont également visibles pour les opérations DDL, ce qui assure leur
préservation (et celle de leurs données).
Le premier exemple de la diapositive définit la visibilité de la période de validité à la date '29-
SEP-2010' et affiche uniquement les lignes englobant cette date de validité.
Le deuxième exemple limite la visibilité aux données qui sont actuellement valides au sein de la
période au niveau de la session.
Le troisième exemple définit une visibilité qui s'étend à la table entière. C'est la visibilité de table
temporelle par défaut.

Quiz
Pour utiliser la dimension d'historique, vous devez activer

l'archivage Flasback pour :
a. La base de données entière
b. Un tablespace spécifique
c. Une table spécifique
Réponse : c

Quiz
Choisissez l'affirmation correcte à propos de la fonctionnalité

de validité temporelle.
a. La validité temporelle et l'historique ne peuvent pas être
utilisés dans la même interrogation.
b. Le contrôle de visibilité de la validité temporelle peut être
défini au niveau session.
c. Les colonnes de validité temporelle sont mises à jour
automatiquement par Oracle.
Réponse : b

Synthèse

• utiliser les technologies Flashback à titre de prévention et
de protection contre divers types d'erreur
• configurer votre base de données pour l'utilisation des
technologies Flashback
• effectuer des opérations Flashback
• faire la distinction entre validité temporelle et historique

Utiliser les technologies Flashback
Dans ces exercices, vous allez effectuer les tâches suivantes :
1. Préparer la base en vue d'utiliser les technologies
Flashback
– Configurer la conservation des données d'annulation
– Vérifier la valeur du paramètre RECYCLEBIN
2. Restaurer une table supprimée
3. Utiliser Flashback Table pour annuler les effets d'une
transaction
4. Collecter le contexte utilisateur dans des tables
d'historique (facultatif)
Pour compléter votre formation, vous pouvez consulter les vidéos relatives à Flashback qui sont
disponibles sur YouTube et OLL.

Flashback Database

Objectifs

• décrire l'architecture Flashback Database
• configurer votre base de données pour la prise en charge
de Flashback Database
• utiliser Flashback Database

Flashback Database : Protection permanente
des données
• Stratégie de récupération rapide jusqu'à
un point dans le temps
• Evite de restaurer une sauvegarde de la
base entière
• Assure une protection permanente des
Ecriture sur disque données de la base
• Solution optimisée : journalisation des blocs
Nouvelle Ancienne
avant modification
version version
de bloc de bloc • Restaure uniquement les blocs modifiés
• Réapplique les journaux pour récupérer la
base jusqu'au moment voulu
• Assure une récupération rapide qui s'estime
en minutes et non en heures
Fichiers de Journal • Restaure la base en une seule commande :
données Flashback
FLASHBACK DATABASE TO '2:05 PM'
Flashback Database est une fonctionnalité unique de récupération jusqu'à un point dans le temps
qui permet de "rembobiner" rapidement une base de données pour la ramener à un état antérieur.
Elle restaure la base plus rapidement que les méthodes classique de restauration et récupération
parce que seuls les blocs de données impactés sont traités.
Flashback Database utilise des journaux qui enregistrent les anciennes versions des blocs. Le
diagramme de la diapositive montre le processus qui écrit l'ancienne version du bloc dans le
journal et la nouvelle version dans le fichier de données lorsque des opérations d'écriture sur
disque sont lancées et que la fonctionnalité Flashback Database est activée. Lorsque la
commande FLASHBACK DATABASE est émise, seuls les blocs modifiés sont extraits des journaux
Flashback. Ces blocs sont ensuite récupérés à l'aide des journaux archivés appropriés pour
atteindre le point dans le temps qui convient.

Flashback Database
L'opération Flashback Database :

• fonctionne comme un bouton de rembobinage de la base
de données
• peut être utilisée en cas de corruptions logiques
des données par des utilisateurs
Un utilisateur La base de "Appuyez sur le bouton La base de

génère des données est de rembobinage" données est
erreurs. endommagée. (FLASHBACK DATABASE). "rembobinée".
Avec Flashback Database, vous pouvez rapidement rétablir la base de données dans un état
correspondant à un point dans le passé en annulant toutes les modifications effectuées après ce
point. Cette opération est rapide car elle ne nécessite pas la restauration de sauvegardes. Vous
pouvez utiliser cette fonctionnalité pour annuler des modifications ayant entraîné des corruptions
logiques des données.
Lorsque vous effectuez une opération Flashback Database, le serveur Oracle Database utilise
des images passées des blocs pour "défaire" les modifications récentes. Au cours du
fonctionnement normal de la base de données, le serveur de base de données Oracle consigne
occasionnellement ces images de bloc dans des journaux Flashback. Ces derniers sont écrits de
façon séquentielle et ne sont pas archivés. Le serveur Oracle Database crée, supprime et
redimensionne automatiquement les journaux Flashback dans la zone de récupération rapide.
Vous n'avez à utiliser les journaux Flashback que pour surveiller les performances et déterminer
l'espace disque à leur allouer dans la zone de récupération rapide.
Le temps nécessaire au "rembobinage" de la base de données à l'aide de Flashback Database
est proportionnel à la longueur de la période à remonter et à l'activité de la base pendant cette
période. Il faudrait bien plus longtemps pour restaurer et récupérer l'ensemble de la base. Les
images "avant" figurant dans les journaux Flashback sont utilisées uniquement pour restaurer un
état passé de la base de données, tandis que la récupération avant (forward recovery) permet
d'amener la base jusqu'à un état cohérent correspondant à un point du passé.

Architecture de Flashback Database
Pas toutes SGA

les modifi- Tampon de
Mémoire cations ! journalisation
tampon Cache de tampons
flashback Toutes les LGWR
modifications
Enregistrement
périodique des
images "avant"
des blocs.
Journaux Fichiers
RVWR de journa-
Flashback Restauration physique
lisation
avec réimplémentation
Annulation des de modifications.
1 modifications à l'aide 2
des images "avant".
… …
Lorsque vous activez la fonctionnalité Flashback Database, le processus en arrière-plan RVWR

(Flashback Writer) est démarré. Ce processus écrit de manière séquentielle les données
Flashback Database de la mémoire tampon Flashback vers les journaux Flashback Database.
Ceux-ci sont réutilisés de façon circulaire. Par la suite, lorsqu'une commande FLASHBACK
DATABASE est exécutée, les journaux Flashback sont utilisés pour restaurer les images "avant"
des blocs. Les données de journalisation sont ensuite utilisées pour réimplémenter les
modifications jusqu'au point dans le temps souhaité.
La surcharge liée à l'activation de Flashback Database dépend du dosage lecture/écriture dans la
charge globale de la base de données. Les simples interrogations n'impliquant aucune activité de
journalisation Flasback, la surcharge liée à l'activation de Flashback Database est proportionnelle
à l'activité d'écriture dans la base.

Configurer Flashback Database
1. Configurez la zone 2. Définissez la durée de 3. Activez Flashback

de récupération rapide. conservation ciblée. Database.
SQL> ALTER SYSTEM SET

2 DB_FLASHBACK_RETENTION_TARGET=2880 SCOPE=BOTH;
SQL> ALTER DATABASE FLASHBACK ON;
Pour configurer Flashback Database, procédez comme suit :

1. Configurez la zone de récupération rapide.
2. Définissez la durée de conservation voulue pour les données de journalisation Flashback à
l'aide du paramètre d'initialisation DB_FLASHBACK_RETENTION_TARGET. Ce paramètre
indique (en minutes) jusqu'à quel point dans le passé vous aimeriez "rembobiner" la base
de données. L'exemple de la diapositive indique 2 880 minutes, ce qui représente deux
jours. Ce paramètre définit une durée ciblée. Il ne la garantit pas. La période de flashback
effective dépend de la quantité de données Flashback conservées dans la zone de
récupération rapide.
3. Activez la fonctionnalité Flashback Database à l'aide de la commande suivante :
ALTER DATABASE FLASHBACK ON;
La commande permettant d'activer Flashback Database ne peut être exécutée que si la
base est configurée pour l'archivage. Vous pouvez activer Flashback Database pendant que
la base de données est ouverte.
Pour savoir si Flashback Database est activé, utilisez l'interrogation suivante :
SELECT flashback_on FROM v$database;
Pour désactiver Flashback Database, exécutez la commande ALTER DATABASE FLASHBACK
OFF. Tous les journaux Flashback Database existants sont alors automatiquement supprimés.

Flashback Database : Exemples
• Pour effectuer un flashback, montez la base de données
(en mode exclusif).
RMAN> FLASHBACK DATABASE TO TIME =
2> "TO_DATE('2009-05-27 16:00:00',
3> 'YYYY-MM-DD HH24:MI:SS')";
RMAN> FLASHBACK DATABASE TO SCN=23565;
RMAN> FLASHBACK DATABASE
2> TO SEQUENCE=223 THREAD=1;
SQL> FLASHBACK DATABASE
2 TO TIMESTAMP(SYSDATE-1/24);
SQL> FLASHBACK DATABASE TO SCN 53943;
SQL> FLASHBACK DATABASE TO RESTORE POINT b4_load;
• Pour vérifier les modifications, ouvrez la base en lecture seule.
• Pour finaliser l'opération, ouvrez la base en lecture/écriture
avec l'option RESETLOGS.
Vous pouvez utiliser la commande RMAN FLASHBACK DATABASE pour exécuter l'opération
Flashback Database. Les options SEQUENCE et THREAD permettent de préciser un numéro
séquentiel et un thread de fichier de journalisation en tant que limite inférieure. RMAN sélectionne
uniquement les fichiers qui peuvent être utilisés pour effectuer le flashback jusqu'au numéro de
séquence indiqué (ce dernier étant exclu).
Vous pouvez également utiliser la commande SQL FLASHBACK DATABASE pour ramener la base
de données jusqu'à un instant ou un numéro SCN du passé. Si vous utilisez la clause TO SCN,
vous devez indiquer un numéro. Si vous utilisez TO TIMESTAMP, vous devez indiquer un
horodatage. Il est également possible d'indiquer le nom d'un point de restauration.
La vue V$SESSION_LONGOPS permet de surveiller la progression des opérations Flashback
Database.
Remarque : La base de données doit être montée en mode exclusif pour la commande
FLASHBACK DATABASE. Elle doit être ouverte en lecture seule pour l'examen des modifications. A
l'issue de l'opération, la base doit être ouverte en lecture/écriture avec l'option RESETLOGS.

Flashback Database :
Eléments à prendre en compte
• Une fois l'opération Flashback Database terminée,
ouvrez la base de données :
– en mode lecture seule pour vérifier que le point dans le
temps ou le SCN indiqué a été utilisé
– avec l'option RESETLOGS pour autoriser les opérations DML
• Vous ne pouvez pas utiliser Flashback Database dans
les cas suivants :
– Le fichier de contrôle a été restauré ou recréé.
– Un tablespace a été supprimé.
– La taille d'un fichier de données a été réduite.
• Utilisez la clause TO BEFORE RESETLOGS pour remonter
avant la dernière opération RESETLOGS.
Lorsque vous ne pouvez pas utiliser la fonctionnalité Flashback Database, vous devez utiliser une
opération de récupération incomplète afin de rétablir la base de données dans un état antérieur.
Une fois l'opération Flashback Database terminée, vous pouvez ouvrir la base de données en
mode lecture seule afin de vous assurer que le point dans le temps ou le SCN indiqué a été
utilisé. Si ce n'est pas le cas, vous pouvez procéder à un nouveau flashback de la base ou
effectuer une récupération afin de réimplémenter les modifications requises.
Vous ne pouvez pas utiliser Flashback Database pour récupérer un fichier de données qui a été
supprimé pendant la période de flashback. Le fichier supprimé est ajouté au fichier de contrôle et
marqué comme étant hors ligne (offline), mais il n'est pas pris en compte dans le flashback.
Flashback Database ne peut pas ramener un fichier de données jusqu'à un point dans le temps
postérieur à sa création et antérieur à une opération de redimensionnement. Si un fichier a été
redimensionné pendant la période sur laquelle vous voulez procéder au flashback de la base,
vous devez mettre ce fichier hors ligne avant de lancer l'opération Flashback Database. Cette
restriction s'applique aux fichiers ayant fait l'objet d'une récupération d'espace, pas aux fichiers
qui ont été étendus. Vous pouvez utiliser Flashback Database avec les fichiers de données
configurés pour l'extension automatique. Un flashback peut remonter juste avant la dernière
opération RESETLOGS si vous indiquez la clause TO BEFORE RESETLOGS dans la commande
FLASHBACK DATABASE.
Remarque : La période cible de conservation des données Flashback ne garantit pas la
disponibilité de ces données au moment voulu. Si de l'espace est nécessaire pour des fichiers
requis dans la zone de récupération rapide, les journaux Flashback peuvent être supprimés
automatiquement.

Surveiller les informations Flashback Database
Pour déterminer si les données Flashback peuvent être
conservées pendant la durée demandée :
• Affichez le quota d'espace disque de la zone de récupération
rapide :
SQL> SELECT estimated_flashback_size,
2 flashback_size
3 FROM V$FLASHBACK_DATABASE_LOG;
• Déterminez la fenêtre de flashback en cours :
SQL> SELECT oldest_flashback_scn,
2 oldest_flashback_time
3 FROM V$FLASHBACK_DATABASE_LOG;
• Surveillez la journalisation dans les journaux Flashback
Database :
SQL> SELECT *
2 FROM V$FLASHBACK_DATABASE_STAT;
Il est important de surveiller l'utilisation de l'espace de la zone de récupération rapide pour savoir
si le délai de conservation ciblé est respecté. Pour cela, consultez la vue
V$FLASHBACK_DATABASE_LOG :
• ESTIMATED_FLASHBACK_SIZE utilise les données Flashback journalisées précédemment
pour évaluer l'espace disque requis dans la zone de récupération rapide pour que les
journaux Flashback puissent être conservés pendant la durée demandée. Cette estimation
est basée sur la charge globale observée pendant la plus courte des deux périodes
suivantes : période écoulée depuis le démarrage de l'instance ou période la plus récente
égale à la durée de conservation cible.
• FLASHBACK_SIZE indique (en octets) la taille actuelle des données Flashback.
• OLDEST_FLASHBACK_SCN et OLDEST_FLASHBACK_TIME indiquent approximativement le
SCN et le point dans le temps les plus éloignés jusqu'où la base peut être ramenée par
flashback. La colonne CURRENT_SCN de la vue V$DATABASE indique le SCN actuel de la
base.
Utilisez la vue V$FLASHBACK_DATABASE_STAT pour surveiller la surcharge liée à la
consignation des données Flashback dans les journaux Flashback Database. Cette vue contient
24 heures d'informations, chaque ligne représentant un intervalle d'une heure. Vous pouvez
l'utiliser pour repérer les changements dans le débit de génération des données Flashback.

SQL> SELECT begin_time, end_time, flashback_data, db_data,
2 redo_data, estimated_flashback_size AS EST_FB_SZE
3 FROM V$FLASHBACK_DATABASE_STAT;
BEGIN_TIM END_TIME FLASHBACK_DATA DB_DATA REDO_DATA EST_FB_SZE

--------- --------- -------------- ---------- ---------- ----------
12-FEB-09 12-FEB-09 16384 0 24576 0
12-FEB-09 12-FEB-09 6594560 7471104 1533440 815923200
12-FEB-09 12-FEB-09 17235968 12361728 5150920 839467008
12-FEB-09 12-FEB-09 311648256 37249024 10272768 855195648
A partir de ces informations, vous pouvez être amené à ajuster le délai de conservation ou la taille
de la zone de récupération rapide.
FLASHBACK_DATA et REDO_DATA représentent respectivement le nombre d'octets de données
Flashback et le nombre d'octets de données de journalisation qui ont été écrits au cours de
l'intervalle. DB_DATA indique le nombre d'octets de blocs de données ayant fait l'objet de lectures et
d'écritures. Cette vue contient également une estimation de l'espace de flashback requis pour
l'intervalle.
Vous pouvez interroger V$RECOVERY_FILE_DEST pour afficher des informations relatives à la zone
de récupération rapide. Cette vue comprend les colonnes suivantes :
• NAME : Nom de la zone de récupération rapide, incluant la chaîne de localisation
• SPACE_LIMIT : Limite d'espace disque indiquée par le paramètre
DB_RECOVERY_FILE_DEST_SIZE
• SPACE_USED : Espace utilisé par les fichiers de la zone de récupération rapide (en octets)
• SPACE_RECLAIMABLE : Quantité d'espace qui peut être récupérée en supprimant les fichiers
obsolètes, les fichiers redondants et les fichiers de faible priorité via l'algorithme de gestion de
l'espace
• NUMBER_OF_FILES : Nombre de fichiers
SQL> SELECT name, space_limit AS quota,

2 space_used AS used,
3 space_reclaimable AS reclaimable,
4 number_of_files AS files
5 FROM v$recovery_file_dest;
NAME QUOTA USED RECLAIMABLE FILES

------------------------ ---------- ---------- ----------- -----
/u01/flash_recovery_area 5368707120 2507809104 203386880 226

Points de restauration garantis
Un point de restauration garanti vous assure de pouvoir exécuter

une commande FLASHBACK DATABASE jusqu'à ce numéro SCN
à tout moment.
SQL> CREATE RESTORE POINT before_upgrade

2 GUARANTEE FLASHBACK DATABASE;
A l'instar des points de restauration normaux, les points de restauration garantis peuvent être
utilisés en tant qu'alias de SCN dans le cadre d'opérations de récupération. La principale
différence réside dans le fait que les points de restauration garantis sont conservés sans limite de
date dans le fichier de contrôle et doivent être supprimés de façon explicite. Toutefois, ils
fournissent également une fonctionnalité spécifique liée à l'utilisation de la fonctionnalité
Flashback Database.
Lorsque vous créez un point de restauration garanti au niveau d'un SCN spécifique, vous êtes
certain de pouvoir exécuter une opération Flashback Database pour rétablir votre base dans l'état
correspondant à ce SCN, même si la journalisation Flashback n'est pas activée. Si la
journalisation Flashback est activée, la création d'un point de restauration garanti impose la
conservation des journaux Flashback qui sont nécessaires pour effectuer une opération
Flashback Database jusqu'à n'importe quel point dans le temps postérieur à la création du point
de restauration garanti le plus ancien.
Vous pouvez utiliser un point de restauration garanti pour ramener la base de données entière à
un état antérieur correct remontant à plusieurs jours ou à plusieurs semaines dès lors que
l'espace disque disponible dans la zone de récupération rapide est suffisant pour le stockage des
journaux requis. Comme les points de restauration normaux, les points de restauration garantis
peuvent être utilisés pour indiquer le point dans le temps des opérations RECOVER DATABASE.
Remarque : Les limitations qui s'appliquent à Flashback Database s'appliquent également aux
points de restauration garantis. Par exemple, la récupération d'espace dans un fichier de données
ou la suppression d'un tablespace peut empêcher le flashback des fichiers de données affectés
jusqu'au point de restauration garanti.

Flashback Database et points de restauration garantis
L'utilisation de points de restauration garantis nécessite que

la base de données respecte les prérequis suivants :
• La valeur du paramètre d'initialisation COMPATIBLE doit
être supérieure ou égale à 10.2.
• La base de données doit être en mode ARCHIVELOG.
• FLASHBACK DATABASE requiert l'utilisation de fichiers
de journalisation archivés à compter de l'heure du point
de restauration.
• Une zone de récupération rapide doit être configurée.
Pour prendre en charge l'utilisation de points de restauration garantis, la base de données doit
satisfaire aux prérequis suivants :
• La valeur du paramètre d'initialisation COMPATIBLE doit être supérieure ou égale à 10.2.
• La base de données doit être exécutée en mode ARCHIVELOG.
• Pour le rembobinage de la base de données jusqu'à un point de restauration garanti, la
commande FLASHBACK DATABASE a besoin de fichiers de journalisation archivés
(archived redo logs) à compter de l'heure du point de restauration.
• Une zone de récupération rapide doit être configurée car c'est là que le serveur Oracle
Database stocke les journaux requis.
• Si la fonctionnalité Flashback Database n'est pas activée, la base de données doit être
montée, mais non ouverte, lors de la création du premier point de restauration garanti (ou si
tous ceux créés précédemment ont été supprimés).
La journalisation pour la fonctionnalité Flashback Database et les points de restauration garantis
implique la capture d'images des blocs de fichiers de données avant application des
modifications. La commande FLASHBACK DATABASE peut utiliser ces images pour rétablir l'état
antérieur des fichiers de données. Les principales différences entre la journalisation flashback
classique et la journalisation pour les points de restauration garantis portent sur le moment où les
blocs sont consignés et sur le fait que les journaux peuvent ou non être supprimés pour répondre
à un manque d'espace dans la zone de récupération rapide. Ces différences affectent l'utilisation
de l'espace pour les journaux, ainsi que les performances de la base de données.

Si vous activez la fonctionnalité Flashback Database et que vous définissez un ou plusieurs points
de restauration garantis, la base de données procède à une journalisation flashback classique. Dans
ce cas, la zone de récupération conserve les journaux Flashback requis pour un flashback vers
n'importe quel point arbitraire entre le présent et le point de restauration garanti le plus ancien
actuellement défini. Les journaux Flashback ne sont pas supprimés en cas de manque d'espace s'ils
sont nécessaires à la garantie.

Recommandations concernant Flashback Database
• Réglez la zone de récupération rapide.

– Utilisez ASM, configurez suffisamment de disques, et ainsi de suite.
• Utilisez une base de secours physique pour tester la journalisation
Flashback.
• Utilisez V$FLASHBACK_DATABASE_LOG pour dimensionner l'espace
des journaux, après avoir exécuté une charge globale qui dure plus
longtemps que la période de conservation des informations
Flashback.
• Créez un point de restauration garanti sans activer la journalisation
Flashback.
– Cela permet d'économiser l'espace disque pour les charges globales
où les mêmes blocs sont mis à jour de manière répétitive.
– Supprimez le point de restauration garanti pour récupérer
immédiatement l'espace.
Pour obtenir de bonnes performances avec Flashback Database dans les bases de données de
production volumineuses, Oracle émet les recommandations suivantes :
• Utilisez un système de fichiers rapide pour la zone de récupération rapide, de préférence
sans mise en mémoire cache des fichiers du système d'exploitation. Les fichiers qui sont
stockés dans la zone de récupération rapide, y compris les journaux Flashback, sont
généralement volumineux. La mise en mémoire cache des fichiers du système d'exploitation
est en principe inefficace. Par ailleurs, elle risque d'augmenter la surcharge de la CPU en
raison des opérations de lecture et d'écriture impliquant ces fichiers. Utilisez un système de
fichiers de type ASM.
• Configurez suffisamment de disques pour le système de fichiers hébergeant la zone de
récupération rapide. Il peut être nécessaire de recourir à plusieurs disques pour fournir le
débit dont le serveur de base de données Oracle a besoin pour écrire efficacement les
journaux Flashback.
• Si le système de stockage utilisé pour héberger la zone de récupération rapide n'est pas
doté d'une mémoire RAM non volatile, essayez de configurer le système de fichiers au-
dessus des volumes de stockage en mode stripe, avec une taille de stripe relativement
petite (par exemple, 128 ko). Cela permet de répartir chaque écriture vers les journaux
Flashback entre plusieurs disques et donc d'améliorer les performances.
• Définissez le paramètre d'initialisation LOG_BUFFER avec une valeur égale ou supérieure à
8 Mo. Cela permet au serveur de base de données Oracle d'allouer une quantité de
mémoire maximale (en général 16 Mo) pour l'écriture dans les journaux Flashback.

Vous devez définir une durée de conservation des données Flashback au moins égale à 60 minutes.
Le serveur de base de données Oracle écrit un marqueur de métadonnées dans les journaux
Flashback environ toutes les 30 minutes. Si la durée de conservation des données est inférieure à
60 minutes, un marqueur nécessaire risque d'être supprimé en cas de contraintes d'espace dans le
journal Flashback.
Un point de restauration est un nom défini par l'utilisateur qui est associé à un point dans le temps
de la base de données. Il est utilisé avec Flashback Database, Flashback Table et RMAN. Un point
de restauration garanti (GRP, guaranteed restore point) est un type spécial de point de restauration
qui garantit la conservation des journaux Flashback jusqu'à l'utilisation ou la suppression du point de
restauration. Lorsque la journalisation Flashback est activée, les journaux Flashback sont en général
créés proportionnellement aux fichiers de journalisation archivés générés au cours de la même
période de conservation. Lorsque la journalisation Fashback est désactivée et qu'un GRP est créé,
chaque bloc modifié est journalisé une seule fois pour mettre à jour le GRP. Avec la journalisation
Flashback, l'enregistrement des blocs se fait en continu. Afin d'économiser de l'espace, vous pouvez
créer un GRP pour la récupération rapide d'un ensemble spécifique de transactions, par exemple un
travail en mode batch, puis supprimer ce GRP pour récupérer l'espace.

Quiz
Si vous voulez utiliser Flashback Database, vous devez activer

cette fonctionnalité pour :
a. La base de données entière
b. Un tablespace spécifique
c. Une table spécifique
Réponse : a

Quiz
Les points de restauration garantis ne sont pas éliminés

automatiquement du fichier de contrôle et doivent être
supprimés de façon explicite.
a. Vrai
b. Faux
Réponse : a

Synthèse

• décrire l'architecture Flashback Database
• configurer votre base de données pour la prise en charge
de Flashback Database
• utiliser Flashback Database

Flashback Database
Dans ces exercices, vous allez :
1. configurer votre base de données pour Flashback
Database
2. utiliser Flashback Database
Pour compléter votre formation, vous pouvez consulter les vidéos relatives à Flashback
qui sont disponibles sur YouTube et OLL.

Transport de données

Objectifs

• transporter des tablespaces entre bases de données
à l'aide de copies d'image ou de jeux de sauvegarde
• transporter des bases de données à l'aide de fichiers
de données ou de jeux de sauvegarde

Transport de données entre plates-formes
Transport de bases de données, de fichiers de données et

de tablespaces entre plates-formes :
• Transport inter-plateformes (avec formats endian
différents)
• Utilisation de copies d'image et de jeux de sauvegarde
• Utilisation de sauvegardes avec tablespace incohérent
Avantages :
• Réduction des temps d'indisponibilité dus aux migrations
• Choix de la compression et de la sauvegarde multisection
• Pas de catalogage dans le fichier de contrôle et donc pas
d'utilisation pour les opérations de restauration standard
RMAN permet de transporter des bases de données, des fichiers de données et des tablespaces
entre plates-formes. Il peut s'agir notamment de transférer des tablespaces entre des plates-
formes associées à différents formats endian (ordre des octets). Vous pouvez convertir une base
de données sur l'hôte de destination ou l'hôte d'origine. Pour les plates-formes présentant le
même format endian, aucune conversion n'est requise.
• Le transport de données entre plates-formes peut utiliser des copies d'image ou des jeux de
sauvegarde.
• Vous pouvez également créer des sauvegardes inter-plateformes avec tablespace
incohérent à l'aide de copies d'image et de jeux de sauvegarde. Une sauvegarde est dite
"avec tablespace incohérent" lorsqu'elle est créée alors que le tablespace n'est pas en
lecture seule.
Lorsque vous utilisez des jeux de sauvegarde, vous pouvez choisir des options de compression
et de sauvegarde multisection qui réduisent le temps de transport.
Remarque : RMAN ne catalogue pas les jeux de sauvegarde créés pour le transport inter-
plateformes dans le fichier de contrôle. Cela garantit qu'ils ne seront pas utilisés pour des
opérations classiques de restauration.

Transport de données avec temps d'arrêt minimal
Mode d'ouverture de la base et format endian requis :
• Transport de base de données : ouverture en lecture seule,
format endian identique
• Transport de tablespace : ouverture en lecture/écriture,
format endian différent
Exemple :
1. Créez une sauvegarde incrémentielle de niveau 0 de la base
de données et appliquez-la sur la destination.
2. Créez des sauvegardes incrémentielles et appliquez-les sur
la destination. Les sauvegardes doivent être de moins en moins volumineuses.
3. Répétez la création et l'application de sauvegardes

incrémentielles.
4. Effectuez la dernière sauvegarde incrémentielle en mode
READ ONLY, appliquez-la, puis ouvrez les deux bases de
données (cohérentes entre elles).
Lorsque vous développez une stratégie de transport de base de données, vous devez tenir
compte du format endian des plates-formes et du mode d'ouverture de la base.
• Un transport au niveau base de données nécessite le même format endian sur la source et
la destination et le mode d'ouverture READ ONLY de la base source (ce qui n'est pas
souhaitable pour une base que les utilisateurs ont besoin de mettre à jour fréquemment).
• Les tablespaces et les jeux de sauvegarde peuvent être transportés entre des plates-formes
présentant différents formats endian et en laissant la base de données source en ligne (en
mode READ WRITE).
La diapositive ci-dessus décrit un workflow qui tient compte de ces exigences. Il est d'intérêt
stratégique de réduire au minimum le temps d'indisponibilité de la base de données en effectuant
la majeure partie du travail lorsque celle-ci est ouverte en mode READ WRITE. Ce n'est qu'à
l'étape finale (sauvegarde incrémentielle de petite envergure) que la base de données est en
mode READ ONLY car cela permet d'ouvrir les deux bases dans un état parfaitement cohérent.
Remarque : La note My Oracle Support numéro 1389592.1 fournit des informations sur la
manière d'implémenter ce scénario pour les bases de données Oracle de version 11.2.

Transporter un tablespace avec des copies d'image
Source Placer les tablespaces en lecture seule.
Utiliser Data Pump pour extraire les métadonnées.
La cible
utilise-t-elle le même Non
format endian ?
Convertir les fichiers
de données avec RMAN.
Oui
Fournir les fichiers de données et le fichier dump à la cible.
Utiliser Data Pump pour importer les métadonnées.
Cible Placer les tablespaces en lecture/écriture.
Pour transporter un tablespace d'une plate-forme source vers une plate-forme cible, il faut d'abord
convertir les fichiers de données du tablespace dans un format compréhensible par la base cible.
Les structures de disque Oracle Database ont généralement un format commun, mais il est
possible que les plates-formes source et cible utilisent des formats endian (ordre des octets selon
leur poids) différents. Lorsque vous passez à une plate-forme présentant un format endian
différent, vous pouvez utiliser la commande CONVERT de l'utilitaire RMAN pour convertir l'ordre
des octets. Cette opération peut être effectuée sur la plate-forme source ou sur la plate-forme
cible. Pour les plates-formes présentant le même format endian, aucune conversion n'est requise.
Le schéma de la diapositive ci-dessus décrit les étapes possibles pour transporter un tablespace
d'une plate-forme source vers une plate-forme cible. Il est aussi possible d'effectuer la conversion
après avoir fourni les fichiers à la plate-forme cible. Les deux dernières étapes doivent être
exécutées sur la plate-forme cible.
Pour l'essentiel, la procédure est la même qu'avec les versions antérieures du serveur de base de
données Oracle, excepté lorsque les deux plates-formes utilisent des formats endian différents. Il
est supposé que les deux plates-formes sont compatibles avec la fonctionnalité de tablespace
transportable.

Déterminer le format endian d'une plate-forme
• Les tablespaces transportables entre plates-formes :
– simplifient le déplacement des données entre un data
warehouse et des datamarts
– permettent la migration d'une base de données d'une plate-
forme vers une autre
– même jeu de caractères sur les plates-formes source et cible
• Afficher la liste des plates-formes prises en charge et de
leurs formats endian :
SQL> SELECT * FROM V$TRANSPORTABLE_PLATFORM;
• Déterminer le format endian des plates-formes source et

cible :
SELECT tp.endian_format
FROM v$transportable_platform tp, v$database sp
WHERE tp.platform_name = sp.platform_name;
A l'aide de tablespaces transportables, des fichiers de données Oracle (contenant des données
de table, des index et quasiment tout objet de base de données Oracle) peuvent être directement
transportés d'une base vers une autre. Les tablespaces transportables permettent également de
transporter des métadonnées.
Vous pouvez utiliser la fonctionnalité de tablespace transportable pour déplacer des données
entre différentes plates-formes (avec le même jeu de caractères). Cela permet de simplifier la
distribution des données entre un environnement de data warehouse et des datamarts, lesquels
s'exécutent souvent sur des plates-formes plus restreintes. Cela permet également de migrer une
base de données d'une plate-forme vers une autre, via la reconstruction du dictionnaire et le
transport des tablespaces utilisateur.
Le déplacement de données à l'aide de tablespaces transportables est bien plus rapide que la
réalisation d'un export/import ou d'un déchargement/chargement des mêmes données. En effet,
les fichiers contenant l'ensemble des données réelles sont juste copiés vers l'emplacement de
destination et vous utilisez Data Pump pour transférer uniquement les métadonnées des objets
de tablespace vers la nouvelle base.
Pour pouvoir transporter des fichiers de données d'une plate-forme vers une autre, vous devez
vous assurer que le système source et le système cible s'exécutent sur l'une des plates-formes
prises en charge. Interrogez la vue V$TRANSPORTABLE_PLATFORM pour savoir si le format
endian (ordre des octets) est le même sur les deux plates-formes. La vue V$DATABASE comporte
deux colonnes permettant de déterminer le nom et l'identificateur de votre plate-forme.

Utiliser la commande RMAN CONVERT
RMAN :
• convertit les tablespaces, les fichiers de données ou
les bases au format d'une plate-forme de destination
• ne modifie pas les fichiers d'entrée
• écrit les fichiers convertis vers la destination
• peut effectuer la conversion sur la plate-forme d'origine
ou de destination
• suppose que vous lancez le transfert des données
rman target sys@orcl

RMAN> ALTER TABLESPACE bartbs READ ONLY;
RMAN> CONVERT TABLESPACE bartbs

TO PLATFORM 'Solaris Operating System (x86-64)'
FORMAT '/tmp/transport/%U';
Vous utilisez la commande RMAN CONVERT pour convertir un tablespace, un fichier de données
ou une base au format d'une plate-forme de destination afin de préparer le transport entre
différentes plates-formes :
• CONVERT DATAFILE
• CONVERT TABLESPACE
• CONVERT DATABASE
Les fichiers d'entrée ne sont pas modifiés par la commande CONVERT car la conversion n'est pas
effectuée "sur place". RMAN écrit les fichiers convertis vers la destination indiquée.
Lorsque vous utilisez la commande RMAN CONVERT, vous pouvez effectuer la conversion des
données sur la plate-forme source après l'export Data Pump ou sur la plate-forme cible avant
l'import Data Pump. Dans les deux cas, vous devez transférer les fichiers de données du système
source vers le système cible.
Restrictions : La commande CONVERT ne traite pas les types de données utilisateur qui
nécessitent des conversions de format endian. Pour transporter entre différentes bases des objets
qui sont construits sur des types sous-jacents stockant les données dans un format spécifique à
la plate-forme, recourez aux utilitaires d'import et d'export Data Pump.
Pour plus d'informations sur les prérequis, l'utilisation, les restrictions et la syntaxe à prendre en
considération, reportez-vous aux manuels Oracle Database Backup and Recovery Reference et
Oracle Database Administrator’s Guide.

Quiz
Sélectionnez les affirmations qui sont vraies :

a. La commande RMAN CONVERT effectue une conversion
"sur place", de sorte que les fichiers d'entrée sont modifiés
avant leur transport vers la desination.
b. Les tablespaces en lecture/écriture doivent être en lecture
seule au moment de la conversion de format endian.
c. Vous pouvez transporter des bases de données dans un
environnement de data warehouse.
Réponses : b, c

Transporter des données avec des jeux de sauvegarde
1 • COMPATIBLE=12.0 (ou valeur supérieure)
• Mode READ ONLY pour la création d'une sauvegarde de base de données
Prérequis inter-plateformes
• Base de données en mode READ WRITE pour la création d'une sauvegarde de
tablespace inter-plateformes
Base de données source Conversion de

FOR TRANSPORT format endian
Métadonnées
Métadonnées 5
2
Données de
Destination ? sauvegarde
4
Transport de
TO PLATFORM données
3
Données de
sauvegarde Base de destination
Conversion de
format endian
Le schéma de la diapositive ci-dessus représente le transport de données avec des jeux

de sauvegarde.
1. Avant de créer un jeu de sauvegarde qui peut être utilisé pour le transfert de données entre
plates-formes, vérifiez que les conditions suivantes sont remplies :
- Le paramètre COMPATIBLE doit avoir une valeur égale ou supérieure à 12.0.
- Pour le transport d'une base de données entière, il faut que la base source soit
ouverte en lecture seule. En effet, les tablespaces SYS et SYSAUX prennent part au
transport.
- Lorsque vous utilisez la clause DATAPUMP, la base doit être ouverte en lecture/écriture
pour que Data Pump puisse accéder aux métadonnées.
2. La conversion de format endian (si elle est nécessaire) peut être effectuée à deux
emplacements. La clause FOR TRANSPORT indique que le jeu de sauvegarde peut être
transporté vers n'importe quelle base de destination. Si la base de destination utilise un
format endian différent de celui de la base source, la conversion est effectuée sur la base de
destination. La clause TO PLATFORM indique que la conversion s'effectue sur la base
source. La clause DATAPUMP indique qu'un fichier dump d'export doit être créé pour les
tablespaces. Dans ce cas, la base de données doit être ouverte en lecture/écriture. L'export
peut avoir lieu après la dernière sauvegarde incrémentielle.
3. Un tablespace indique les métadonnées et les données de sauvegarde de la base de
données source.
4. La flèche grise représente le transport des données.
5. Les données de sauvegarde, les métadonnées et un tablespace sont transférés vers
la base de destination.

Etapes de la procédure : 1
1. Vérifiez que les conditions requises sont remplies.
Métadonnées
2. Démarrez une session RMAN dans la base
de données source. Base de
3. Recherchez le nom exact de la plate-forme données
source
de destination.
4. Placez le tablespace en mode de lecture seule.
RMAN> ALTER TABLESPACE test READ ONLY;
5. Exécutez une sauvegarde transportable entre plates-formes et
un export Data Pump.
– Conversion sur l'hôte de destination
RMAN> BACKUP FOR TRANSPORT FORMAT '/bkp/test.bck'
DATAPUMP FORMAT '/bkp/test.dmp' TABLESPACE test;
– Conversion sur l'hôte source
RMAN> BACKUP TO PLATFORM 'HP Tru64 UNIX'
FORMAT '/bkp/test.bck'
DATAPUMP FORMAT '/bkp/test.dmp' TABLESPACE test;
1. Vérifiez les prérequis : La base de données source doit être ouverte en mode de
lecture/écriture.
2. Démarrez une session RMAN et connectez-vous à l'instance cible.
3. Pour transporter des tablespaces entre plates-formes, obtenez le nom exact de la plate-
forme de destination.
4. Placez le tablespace en mode de lecture seule.
5. Sauvegardez le tablespace source en utilisant la commande BACKUP avec la clause TO
PLATFORM ou FOR TRANSPORT pour indiquer le lieu de la conversion. Utilisez la clause
DATAPUMP pour signaler la nécessité d'un fichier dump d'export des métadonnées du
tablespace.
Remarque : La clause ALLOW INCONSISTENT de la commande BACKUP permet de sauvegarder
des tablespaces qui ne sont pas en mode de lecture seule. Même si la sauvegarde est créée,
vous ne pouvez pas ajouter ces tablespaces directement dans la base de données cible parce
qu'ils ne sont pas cohérents. Il vous faudra créer ultérieurement une sauvegarde incrémentielle
de ces tablespaces lorsqu'ils seront en lecture seule. Cette sauvegarde incrémentielle doit
contenir la clause DATAPUMP qui crée un fichier dump d'export des métadonnées des
tablespaces.

Etapes de la procédure : 2
Métadonnées
6. Déplacez les jeux de sauvegarde et le fichier
dump d'export Data Pump vers l'hôte de destination. Base de
données de
7. Connectez-vous à l'hôte de destination en tant que destination
TARGET.
8. Restaurez la sauvegarde transportable inter-plateformes et
le fichier d'export Data Pump.
RMAN> RESTORE FOREIGN TABLESPACE test
FORMAT '/oracle/test.dbf'
FROM BACKUPSET '/bkp/test.bck'
DUMP FILE FROM BACKUPSET '/bkp/test.dmp' ;
6. Déconnectez-vous de la base de données source et déplacez les jeux de sauvegarde et le

fichier dump d'export Data Pump vers l'hôte de destination. Vous pouvez pour cela faire
appel aux utilitaires du système d'exploitation.
7. Connectez-vous à l'hôte de destination (vers lequel le tablespace est transporté) en tant que
TARGET. Assurez-vous que la base de destination est ouverte en mode de lecture/écriture.
8. Utilisez la commande RESTORE dans la base de destination comme illustré dans la
diapositive. La clause FOREIGN TABLESPACE pointe vers le fichier de données source HP.
La clause FORMAT indique l'emplacement de destination. La clause DUMP FILE FROM
BACKUPSET restaure les métadonnées requises à partir du fichier dump.
Autre exemple :
1. Créez des sauvegardes incrémentielles inter-plateformes autorisant les tablespaces
incohérents à l'aide de la clause ALLOW INCONSISTENT :
BACKUP INCREMENTAL FROM SCN=2720649 FOR TRANSPORT
ALLOW INCONSISTENT FORMAT '/home/u_inc1.bkp' TABLESPACE
users;
2. Restaurez la sauvegarde créée précédemment à l'aide de la commande RESTORE
FOREIGN TABLESPACE.
3. Procédez à la récupération des copies restaurées des fichiers de données à l'aide de
sauvegardes incrémentielles inter-plateformes. Utilisez pour cela la commande RECOVER
FOREIGN DATAFILECOPY.

Transport de base de données :
Utilisation de fichiers de données
• Généralisation de la fonctionnalité de tablespace transportable.
• Il est facile de distribuer des données depuis un environnement de
data warehouse vers des datamarts, car ces derniers se trouvent
habituellement sur des plates-formes plus restreintes.
• Une base de données peut être migrée d'une plate-forme à une
autre très rapidement.
Plate-forme X Même format endian Plate-forme Y
Transfert des fichiers

de base de données
Base de données existante Nouvelle base de données
Grâce à la fonctionnalité de tablespace transportable, le déplacement de données entre des

plates-formes différentes est beaucoup plus rapide. Toutefois, il est toujours nécessaire de
décharger les métadonnées car le tablespace SYSTEM ne peut pas être transporté.
La fonctionnalité de transport de base de données fournit une méthode rapide et simple pour
transporter une base entre différentes plates-formes utilisant le même format endian. Cependant,
l'alignement des disques de la plate-forme source peut être différent de celui de la plate-forme
cible. Par exemple, les plates-formes HP-UX et Solaris utilisent toutes les deux le format big
endian (octet de poids fort au début), mais l'alignement des disques est de huit sur HP-UX et de
quatre sur Solaris.
Pour transporter des bases de données d'une plate-forme à une autre, vous devez vous assurer
que le système source et le système cible sont exécutés sur l'une des plates-formes répertoriées
dans la vue V$TRANSPORTABLE_PLATFORM et que les deux systèmes utilisent le même format
endian.
Par exemple, vous pouvez transporter une base de données exécutée sur Linux IA (32 bits) vers
l'une des plates-formes Windows.
Dans le cadre du transport de tablespace, une base de données cible est déjà disponible pour
l'ajout des données. En revanche, la fonctionnalité de transport de base de données crée une
nouvelle base sur la plate-forme cible. La base créée contient les mêmes données que la base
source. Elle possède également les mêmes propriétés que la base source, à l'exception du nom
de base de données, du nom d'instance et de l'emplacement des fichiers.
Remarque : Le transport d'une base de données est plus rapide qu'un déplacement de données
à l'aide de Data Pump.

Procédure de transport de base de données
Base de données ouverte en mode READ ONLY

avec paramètre COMPATIBLE=10.0.0
Lecture Lecture Transfert Lecture Lecture

seule CONVERT seule seule seule
DATABASE de fichiers
TO PLATFORM
Système source Système cible

OU
Lecture Transfert Lecture Lecture Lecture

CONVERT
DATABASE seule seule seule seule
de fichiers
ON TARGET
Pour pouvoir transporter une base de données, vous devez l'ouvrir en mode READ ONLY. Utilisez
ensuite RMAN pour convertir les fichiers de données requis de la base.
Lorsque vous effectuez la conversion sur la plate-forme source, la commande RMAN CONVERT
DATABASE génère un script qui contient la commande CREATE CONTROLFILE RESETLOGS
correcte utilisée sur le système cible pour créer la nouvelle base de données. La commande
CONVERT DATABASE convertit ensuite tous les fichiers de données identifiés pour qu'ils puissent
être utilisés sur le système cible. Vous transférez alors vers la plate-forme cible les fichiers de
données convertis et le script généré. En exécutant le script sur la plate-forme cible, vous créez
une copie de la base de données.
Pour la conversion sur la plate-forme cible, la commande CONVERT DATABASE (qui est exécutée
sur le système source) génère uniquement deux scripts qui permettent au système cible de
convertir les fichiers de données et de recréer les fichiers de contrôle pour la nouvelle base. Vous
transférez les fichiers de données identifiés et les deux scripts vers la plate-forme cible. Le
premier script utilise la commande RMAN CONVERT DATAFILE pour effectuer la conversion. Le
second script exécute la commande SQL CREATE CONTROLFILE RESETLOGS avec les fichiers
de données convertis pour créer la nouvelle base de données.
Remarque : La base de données source doit être exécutée avec un paramètre d'initialisation
COMPATIBLE de valeur 10.0.0 ou supérieure. Tous les tablespaces identifiés doivent être
passés en mode READ WRITE au moins une fois depuis la définition du paramètre COMPATIBLE
avec la valeur 10.0.0 (ou supérieure).

Transport de base de données : Conversion
RMAN génère un script de RMAN vous invite à
transport pour recréer ces fichiers. redéfinir ces éléments :
Fichiers
temporaires Fichiers BFILE
Répertoires
SYSTEM SYSTEM Tables exernes
Fichier de mots
SYSAUX SYSAUX de passe
Fichiers Fichiers
TBS d'annulation TBS d'annulation de de contrôle Fichiers de
journa- sauvegarde
TBS1 TBS1 lisation
… …
SPFILE PFILE
TBSn TBSn
RMAN convertit les fichiers de données Fichiers trace

(il reformate les informations d'annulation). RMAN crée un fichier PFILE.
Le schéma présenté dans la diapositive ci-dessus montre comment les différentes parties d'une
base de données sont transportées vers la plate-forme cible ou recréées sur cette plate-forme.
Les informations de journalisation et d'annulation de la base de données source sont supprimées.
Les segments d'annulation contiennent des vecteurs de modification qui ne peuvent actuellement
pas être convertis. C'est pourquoi vous devez arrêter proprement l'instance avant d'ouvrir la base
de données en lecture seule.
Pour garantir que les enregistrements d'annulation sont inaccessibles (pour lecture cohérente ou
flashback) après le transport de la base vers sa plate-forme cible, les en-têtes de ces segments
sont convertis, de sorte que toute tentative d'accès aux enregistrements d'annulation génère une
erreur "ORA-01555 Snapshot too old".

Transport d'une base de données : Exemple 1
Source
$ sqlplus / as sysdba
2 DBMS_TDB.CHECK_DB('Microsoft
SQL> startup mount; Windows IA (32 bits)')
1 SQL> alter database open read only;
SQL> host rman target=/
RMAN> CONVERT DATABASE TRANSPORT SCRIPT 'crdb.sql'
3
NEW DATABASE 'newdb' TO PLATFORM 'Microsoft
Windows IA (32-bit)' FORMAT '/tmp/%U';
4 Transférer les fichiers de données, le fichier PFILE et crdb.sql
5 SQL> @crdb.sql
Cible
Pour transporter une base de données exécutée sous Linux IA (32 bits) vers une plate-forme
Windows et nommer la nouvelle base newdb, procédez comme suit si la conversion des fichiers
de données est effectuée sur la plate-forme source :
1. Ouvrez la base de données source en lecture seule.
2. Exécutez la fonction PL/SQL :
DBMS_TDB.CHECK_DB('Microsoft Windows IA (32 bits)').
Cette procédure vérifie si la base de données peut être transportée vers la plate-forme cible.
3. Exécutez la commande RMAN suivante :
convert database transport script 'crdb.sql' new database 'newdb'
to platform 'Microsoft Windows IA (32 bits)' format '/tmp/%U';
RMAN génère les fichiers de données et un fichier PFILE pour la nouvelle base de
données, ainsi qu'un script appelé crdb.sql dans le répertoire /tmp. Ce script crée une
base de données nommée newdb.
4. Transférez tous les fichiers de données, le fichier PFILE et le script sur la plate-forme cible.
5. Exécutez crdb.sql pour créer la base de données sur la plate-forme cible.

Transport d'une base de données : Exemple 2
$ sqlplus / as sysdba DBMS_TDB.CHECK_DB('Microsoft

SQL> startup mount;
2 Windows IA (32 bits)')
1
SQL> alter database open read only;
SQL> host rman target=/
3 RMAN> CONVERT DATABASE ON TARGET PLATFORM CONVERT
SCRIPT 'cnvt.sql' TRANSPORT SCRIPT 'crdb.sql' NEW
DATABASE 'newdb' FORMAT '/tmp/%U';
4 Transférer les fichiers de données, le fichier PFILE, cnvt.sql et crdb.sql
5 SQL> host rman target=/
RMAN> @cnvt.sql
6 RMAN> exit;
SQL> @crdb.sql
Procédez comme suit si la conversion des fichiers de données est effectuée sur la plate-forme
cible :
1. Ouvrez la base de données source en lecture seule.
2. Exécutez la fonction PL/SQL suivante :
DBMS_TDB.CHECK_DB('Microsoft Windows IA (32 bits)')
Cette procédure vérifie si la base de données peut être transportée vers la plate-forme cible.
3. Exécutez la commande RMAN suivante :
convert database on target platform convert script 'cnvt.sql'
transport script 'crdb.sql' new database 'newdb' format '/tmp/%U';
RMAN génère les fichiers de données et un fichier PFILE pour la nouvelle base de
données, ainsi qu'un script appelé cnvt.sql pour convertir les fichiers de données sur la
plate-forme cible et un script appelé crdb.sql pour créer la nouvelle base newdb sur la
plate-forme cible. Il est inutile d'indiquer le nom de la plate-forme cible car la commande
insère le nom de la plate-forme source dans le script cnvt.sql. Ce script contient la
commande RMAN suivante :
convert datafile <list of data files> from platform 'Linux IA (32-
bit)';
4. Transférez tous les fichiers de données, le fichier PFILE et les scripts vers la plate-forme
cible.
5. Exécutez le script cnvt.sql dans RMAN pour convertir les fichiers de données sur
la plate-forme cible.
6. Exécutez crdb.sql pour créer une base de données sur la plate-forme cible.

Transport d'une base de données : Considérations
• Créez le fichier de mots de passe sur la plate-forme cible.

• Transportez les types BFILE utilisés dans la base de données
source.
• Le fichier PFILE généré et le script de transport utilisent OMF.
• Utilisez DBNEWID pour modifier le DBID.
Les fichiers de journalisation (redo logs), les fichiers de contrôle et les fichiers temporaires ne
sont pas transportés. Ils sont recréés pour la nouvelle base de données, sur la plate-forme cible.
Par conséquent, la nouvelle base de la plate-forme cible doit être ouverte avec l'option
RESETLOGS.
Si un fichier de mots de passe est utilisé, il n'est pas transporté et vous devez le créer sur la
plate-forme cible. En effet, les types de nom de fichier autorisés pour le fichier de mots de passe
sont propres au système d'exploitation. Le résultat de la commande CONVERT DATABASE
répertorie tous les noms utilisateur et leurs privilèges système. Il conseille de recréer le fichier de
mots de passe et d'ajouter des entrées pour ces utilisateurs sur la plate-forme cible.
La commande CONVERT DATABASE permet de répertorier tous les objets répertoire et tous les
objets qui utilisent des types de données BFILE ou des tables externes dans la base source.
Vous pouvez être amené à mettre à jour ces objets avec les nouveaux noms de répertoire et de
fichier. Si des types BFILEs sont utilisés dans la base de données, vous devez les transporter.
Le fichier PFILE généré et le script de transport utilisent Oracle Managed Files (OMF) pour les
fichiers de base de données. Si vous ne souhaitez pas utiliser OMF, vous devez modifier le fichier
PFILE et le script de transport.
La base de données transportée a le même DBID que la base source. Vous pouvez faire appel à
l'utilitaire DBNEWID pour le modifier. Dans le script de transport et dans le résultat de la
commande CONVERT DATABASE, vous êtes invité à vous servir de l'utilitaire DBNEWID pour
modifier l'ID de la base de données.

Transport d'une base de données
avec des jeux de sauvegarde : 1 Métadonnées
1. Vérifiez que les conditions suivantes sont remplies :
Base de
– COMPATIBLE est égal ou supérieur à 12.0 données
– OPEN_MODE : lecture seule source
2. Démarrez une session RMAN pour vous connecter à la base de

données source.
RMAN> CONNECT TARGET sys/p@orcl
3. Recherchez le nom exact de la plate-forme de destination dans
V$TRANSPORTABLE_PLATFORM.
4. Sauvegardez la base de données source :
RMAN> BACKUP TO PLATFORM='HP Tru64 UNIX'
FORMAT '/bkp_dir/trans_U%' DATABASE;
Ou :
RMAN> BACKUP FOR TRANSPORT FORMAT '/bkp_dir/trans_U%'
DATABASE;
1. Vérifiez les prérequis (la base de données source doit être ouverte en lecture seule si vous
la transportez en totalité).
2. Démarrez une session RMAN et connectez-vous à l'instance cible.
3. Pour transporter la base d'une plate-forme à une autre, vous aurez besoin du nom exact de
la plate-forme de destination :
SELECT PLATFORM_ID, PLATFORM_NAME, ENDIAN_FORMAT
FROM V$TRANSPORTABLE_PLATFORM
WHERE UPPER(PLATFORM_NAME) LIKE '%LINUX%';
4. Sauvegardez la base de données source en utilisant la commande BACKUP avec l'option TO
PLATFORM ou FOR TRANSPORT. La clause FORMAT indique le répertoire de l'hôte source où
se trouvent les jeux de sauvegarde qui contiennent les données nécessaires au transport de
la base entre plates-formes.
Dans le premier exemple de la diapositive, la conversion a lieu sur l'hôte source et les
fichiers stockés dans le répertoire /bk sont déjà convertis pour la plate-forme UNIX HP
Tru64.
Dans le second exemple, la conversion s'effectue sur l'hôte de destination, pendant
l'exécution de la commande de restauration, et les fichiers situés dans le répertoire /bk sur
l'hôte source ne sont pas encore convertis.

Transport d'une base de données
avec des jeux de sauvegarde : 2 Métadonnées
5. Déconnectez-vous de la base de données source. Base de

données de
6. Déplacez les jeux de sauvegarde et le fichier dump destination
d'export Data Pump vers l'hôte de destination.
7. Connectez-vous à l'hôte de destination en tant que
TARGET.
RMAN> CONNECT TARGET sys/p@orcl2
8. Restaurez l'ensemble du jeu de sauvegarde à l'aide de la
commande RESTORE.
RMAN> RESTORE FOREIGN DATABASE TO NEW
FROM BACKUPSET '/bkp_dir/trans_U%';
5. Déconnectez-vous de la base de données source.

6. Déplacez les jeux de sauvegarde créés par la commande BACKUP et le fichier dump
d'export Data Pump vers l'hôte de destination. Vous pouvez recourir aux utilitaires du
système d'exploitation pour déplacer les jeux de sauvegarde de l'hôte source à l'hôte de
destination.
7. Connectez-vous à l'hôte de destination (vers lequel la base de données est transportée) en
tant que TARGET. Assurez-vous que la base de destination n'est pas montée.
8. Utilisez la commande RESTORE pour restaurer les données dans la base de destination.
RESTORE FOREIGN DATABASE TO NEW
FROM BACKUPSET '/bkp_dir/U%';
où FOREIGN DATABASE désigne les fichiers de données source et NEW indique que les
fichiers restaurés doivent utiliser de nouveaux noms définis par OMF dans la base de
destination. Le jeu de sauvegarde U% est stocké dans le répertoire /bkp_dir de l'hôte de
destination.

Transporter des tablespaces incohérents
Modification du workflow précédent :

• Créez des sauvegardes incrémentielles inter-plateformes
autorisant les tablespaces incohérents à l'aide de la clause
ALLOW INCONSISTENT.
• Restaurez la sauvegarde créée précédemment à l'aide de
la commande RESTORE FOREIGN TABLESPACE.
• Procédez à la récupération des copies de fichiers de
données restaurées à l'aide de sauvegardes
incrémentielles inter-plateformes. Utilisez pour cela la
commande RECOVER FOREIGN DATAFILECOPY.
Pour utiliser des tablespaces incohérents dans un workflow tel que celui décrit dans les pages
précédentes :
• Créez une sauvegarde incrémentielle autorisant les tablespaces incohérent à l'aide de la
clause ALLOW INCONSISTENT :
BACKUP INCREMENTAL FROM SCN=2720649 FOR TRANSPORT
ALLOW INCONSISTENT FORMAT '/u01/backup/inc1.bkp' TABLESPACE
users;
• Restaurez la sauvegarde inter-plateformes incohérente à l'aide de la commande RESTORE
FOREIGN TABLESPACE.
• Procédez à la récupération des fichiers de données restaurés à l'aide de sauvegardes
incrémentielles inter-plateformes en utilisant la commande RECOVER FOREIGN
DATAFILECOPY.
Remarque : La clause ALLOW INCONSISTENT permet de sauvegarder des tablespaces qui ne
sont pas en mode de lecture seule. Même si la sauvegarde est créée, vous ne pouvez pas ajouter
ces tablespaces directement dans la base de données cible parce qu'ils ne sont pas cohérents. Il
vous faudra créer ultérieurement une sauvegarde incrémentielle de ces tablespaces lorsqu'ils
seront en lecture seule. Cette sauvegarde incrémentielle doit contenir la clause DATAPUMP qui
crée un fichier dump d'export des métadonnées des tablespaces.

Quiz
Identifiez les affirmations correctes à propos du transport

de bases de données.
a. Le système source et le système cible doivent tous les
deux s'appuyer sur une plate-forme répertoriée dans
la vue V$TRANSPORTABLE_PLATFORM.
b. La source et la cible peuvent utiliser des formats endian
différents.
c. La base de données source doit être en lecture seule.
d. Les fichiers de journalisation, les fichiers de contrôle et
les fichiers temporaires ne sont pas transportés.
Réponses : a, c, d

Quiz
Lorsque vous transportez des données entre plates-formes

dans Oracle Database 12c, vous pouvez utiliser des copies
d'image uniquement, pas des jeux de sauvegarde.
• Vrai
• Faux
Réponse : b

Synthèse

• transporter des tablespaces entre bases de données
à l'aide de copies d'image ou de jeux de sauvegarde
• transporter des bases de données à l'aide de fichiers
de données ou de jeux de sauvegarde

Présentation de l'exercice
Dans l'exercice 16-1, vous allez transporter un tablespace

à l'aide de jeux de sauvegarde.
Cet exercice montre comment effectuer un transport de tablespace entre plates-formes (bien que
l'environnement des exercices comprenne un seul hôte et une seule plate-forme).
Les démonstrations du produit illustrent le transfert entre plates-formes.

Effectuer une récupération
jusqu'à un point dans le temps

Objectifs
• décrire la récupération jusqu'à un point dans le temps
(PITR) d'une table, d'un tablespace et d'une base de
données
• identifier les circonstances dans lesquelles cette solution
est appropriée et les cas où elle ne peut pas être utilisée
• décrire les opérations qui ont lieu lorsque vous effectuez
une récupération jusqu'à un point dans le temps
• déterminer le point cible correct pour une récupération
• effectuer une récupération automatisée de tablespace
• effectuer une récupération de table à partir de
sauvegardes

Récupération jusqu'à un point dans le temps
Avantages :
• Récupération rapide d'un ou de plusieurs objets dans
un état antérieur
• Aucun impact sur les autres objets
Portée :
• Récupération de table (TPITR)
• Récupération de tablespace (TSPITR)
• Récupération de base de données (DBPITR)
L'un des avantages de la récupération jusqu'à un point dans le temps (PITR, Point-In-Time
Recovery) est qu'elle permet de récupérer un ou plusieurs objets (des tablespaces, par exemple)
dans un état antérieur sans affecter l'état des autres objets de la base de données.
A partir de la version Oracle Database 12c, elle offre trois niveaux différents (portées) :
• Récupération de table (TPITR), pour récupérer une ou plusieurs tables ou partitions de table
jusqu'à un point antérieur
• Récupération de tablespace (TSPITR), pour récupérer un ou plusieurs tablespaces jusqu'à
un point antérieur
• Récupération de base de données (DBPITR), pour migrer une base de données vers une
autre plate-forme : vous créez une nouvelle base sur la plate-forme de destination, puis
procédez au transport de tous les tablespaces utilisateur, à l'exclusion du tablespace
SYSTEM

Quand utiliser une opération TSPITR ?
Une récupération de tablespace jusqu'à un point dans le temps

permet de réaliser les objectifs suivants :
• Récupérer des données perdues suite à l'exécution d'une
instruction TRUNCATE TABLE erronée
• Remédier à une corruption logique de table
• Annuler les effets d'un traitement batch ou d'instructions
DML qui n'ont affecté qu'une partie de la base de données
• Récupérer un schéma logique jusqu'à un point différent de
celui du reste de la base physique
• Récupérer un tablespace supprimé
• Elle peut être exécutée de manière répétitive jusqu'à
plusieurs points dans le temps avant la mise en ligne du
tablespace sans nécessiter de catalogue de restauration
La fonctionnalité de récupération de tablespace jusqu'à un point dans le temps (TSPITR) de

RMAN permet d'accomplir les tâches suivantes :
• Récupérer des données perdues suite à l'exécution d'une instruction TRUNCATE TABLE
erronée
• Remédier à la corruption logique d'une table
• Annuler les effets d'un traitement en mode batch incorrect ou d'une autre instruction DML
(Data Manipulation Language) ayant affecté seulement un sous-ensemble de la base de
données
• Récupérer un schéma logique jusqu'à un point dans le temps autre que celui des autres
parties de la base de données physique
A partir de la version Oracle Database 11g Release 2, TSPITR utilise les fonctionnalités de
tablespace transportable et Data Pump. C'est grâce à cette technologie que TSPITR peut
récupérer un tablespace supprimé. En outre, l'opération peut être exécutée de manière répétée
jusqu'à différents points dans le temps sans nécessiter de catalogue de restauration.

Terminologie liée à la récupération PITR
• Point cible : Point dans le temps ou numéro SCN jusqu'où

l'objet va être récupéré
• Ensemble (ou jeu) de récupération : Pour des tablespaces,
fichiers de données à récupérer
• Ensemble (ou jeu) auxiliaire : Fichiers de données requis
qui ne sont pas inclus dans l'ensemble de récupération.
Il s'agit généralement des éléments suivants :
– Tablespace SYSTEM
– Tablespaces de segments d'annulation de type undo
– Tablespace temporaire
• Destination auxiliaire : Emplacement dans lequel les
fichiers doivent être stockés sur le disque
La terminologie suivante est utilisée pour traiter de la récupération jusqu'à un point dans le temps
(PITR) :
• Point cible : Point dans le temps ou numéro SCN (System Change Number) jusqu'auquel
l'objet va être récupéré.
• Ensemble (ou jeu) de récupération : Dans le cas d'une opération TSPITR, par exemple, il
s'agit des fichiers de données composant les tablespaces à récupérer.
• Ensemble (ou jeu) auxiliaire : Fichiers de données requis (pour les métadonnées et les
dépendances) qui ne figurent pas dans l'ensemble de récupération. Cet ensemble inclut
généralement les éléments suivants :
- Copie du tablespace SYSTEM
- Fichiers de données contenant des segments d'annulation de type undo issus
de l'instance cible
- Dans certains cas, un tablespace temporaire, utilisé lors de l'exportation d'objets de
base de données à partir de l'instance auxiliaire
• Destination auxiliaire : Emplacement sur disque qui peut être utilisé pour stocker n'importe
quel fichier de données de l'ensemble auxiliaire, fichier de contrôle ou journal en ligne de
l'instance auxiliaire pendant l'exécution de l'opération PITR. Les fichiers stockés dans la
destination auxiliaire peuvent être supprimés une fois l'opération PITR terminée.

Récupération de tablespace jusqu'à un point dans
le temps (TSPITR) : Architecture
RMAN 1
6
Fichier de
Instance auxiliaire
contrôle 3
Sauvegardes
4 Restauration
de fichiers
Restauration
de données 5
2
Récupération
Fichiers de
journalisation Tablespace récupéré
Base cible archivés
Le diagramme de la diapositive illustre les entités impliquées dans l'opération TSPITR :

• Base de données cible : Elle contient le tablespace à récupérer.
• Fichier de contrôle : Il fournit des informations de sauvegarde à RMAN.
• Jeux de sauvegarde : Ils sont issus de la base cible et servent à reconstruire le tablespace.
• Fichiers de journalisation archivés : Ils sont issus de la base cible et servent à
reconstruire le tablespace.
• Instance auxiliaire : Il s'agit de l'instance de base de données Oracle utilisée lors de
l'opération TSPITR pour exécuter la récupération.
RMAN effectue les étapes suivantes :
1. Il crée l'instance auxiliaire, la démarre et s'y connecte.
2. Il met hors ligne les tablespaces devant être récupérés.
3. Il restaure dans l'instance auxiliaire un fichier de contrôle de sauvegarde correspondant à un
point dans le temps antérieur au point cible de la récupération.
4. Il restaure vers l'instance auxiliaire les fichiers de données de l'ensemble de récupération et
de l'ensemble auxiliaire.
5. Il récupère les fichiers de données restaurés jusqu'au point indiqué.
6. Il ouvre la base de données auxiliaire avec l'option RESETLOGS.

Récupération de tablespace jusqu'à un point
dans le temps (TSPITR) : Architecture
RMAN
9
Import de métadonnées
Fichier de 10
contrôle
Fichier
Instance d'export
Tablespace auxiliaire
Base cible récupéré
8 7
Export de
Pointage sur le tablespace récupéré métadonnées
Procédure accomplie par RMAN (suite) :

7. RMAN exporte vers la base cible les métadonnées du dictionnaire concernant les objets qui
figurent dans les tablespaces récupérés.
8. Il arrête l'instance auxiliaire. (Il exécute des commandes SWITCH sur la base de données
cible de sorte que le fichier de contrôle de cette dernière pointe vers les fichiers de données
de l'ensemble de récupération qui ont été récupérés sur l'instance auxiliaire.)
9. Il importe les métadonnées du dictionnaire de l'instance auxiliaire vers l'instance cible.
10. Il supprime tous les fichiers de l'ensemble auxiliaire.

Préparation d'une opération PITR
Pour préparer une opération PITR, procédez comme suit :

• Déterminez le point cible approprié.
• Déterminez les éléments requis dans l'ensemble de
récupération.
• Identifiez et (si nécessaire) préservez les objets qui seront
perdus après l'opération PITR.
Avant d'effectuer une récupération jusqu'à un point dans le temps (PITR, Point-In-Time
Recovery), il convient de définir le point cible de cette récupération. Vous devez déterminer si
vous avez besoin de tablespaces supplémentaires dans l'ensemble de récupération. Vous devez
également identifier les objets qui seront perdus suite à l'opération PITR et, s'il y a lieu, faire le
nécessaire pour conserver ces objets.
Toutes ces étapes sont décrites en détail dans la suite du chapitre.

Déterminer le point cible approprié
• Une fois que vous avez effectué une opération TSPITR et

mis le tablespace en ligne, vous ne pouvez plus utiliser
une sauvegarde correspondant à un moment antérieur
(sauf si vous utilisez un catalogue de restauration).
• Utilisez les méthodes suivantes pour déterminer le point
cible approprié :
– Flashback Query
– Flashback Transaction Query
– Flashback Version Query
• Une alternative simple à la fonction TSPITR est le
flashback de données (lorsqu'il est possible).
Pour une récupération de tablespace jusqu'à un point dans le temps (TSPITR), il est très
important de choisir le point cible ou le SCN approprié. En effet, une fois que vous avez réalisé
une opération TSPITR et mis un tablespace en ligne, vous ne pouvez plus utiliser de sauvegarde
antérieure. En pratique, cela signifie que vous ne pouvez pas effectuer une deuxième tentative
d'opération TSPITR si vous choisissez un point cible incorrect la première fois, sauf si vous
utilisez un catalogue de restauration. Dans ce cas, vous pouvez effectuer des opérations TSPITR
répétées avec différents points cible.
Si vous n'utilisez pas de catalogue de restauration, le fichier de contrôle en cours ne contient
aucun enregistrement d'une incarnation antérieure du tablespace récupéré. Une récupération qui
s'appuie sur un fichier de contrôle impliquant ce tablespace ne peut pas utiliser une sauvegarde
effectuée avant la mise en ligne du tablespace. Toutefois, vous pouvez effectuer une récupération
incomplète de l'ensemble de la base jusqu'à n'importe quel moment antérieur ou égal à la mise
en ligne du tablespace si vous êtes en mesure de restaurer un fichier de contrôle de sauvegarde
antérieur à ce moment.
Vous pouvez utiliser Oracle Flashback Query, Oracle Flashback Transaction Query et Oracle
Flashback Version Query pour identifier les modifications apportées à la base et pour vous aider
à déterminer le point cible approprié pour l'opération TSPITR.
Remarque : Si vous disposez de données d'annulation (undo), il est généralement plus simple de
recourir aux outils Flashback pour annuler une modification non souhaitée.

Déterminer les tablespaces à inclure dans
l'ensemble de récupération
• Si des objets figurant dans le tablespace que vous
récupérez sont en relation avec des objets d'autres
tablespaces, vous pouvez :
– ajouter à l'ensemble de récupération le tablespace contenant
les objets liés
– suspendre la relation pendant la durée de l'opération TSPITR
– supprimer la relation
• Utilisez la procédure DBMS_TTS.TRANSPORT_SET_CHECK
pour déterminer si les tablespaces de l'ensemble de
récupération sont autonomes.
DBMS_TTS.TRANSPORT_SET_CHECK ('USERS,EXAMPLE');
SELECT * FROM TRANSPORT_SET_VIOLATIONS;
Pour identifier les relations entre objets qui dépassent les frontières de l'ensemble de
récupération, utilisez la procédure DBMS_TTS.TRANSPORT_SET_CHECK et interrogez la vue
TRANSPORT_SET_VIOLATIONS.
Remarque : La fonctionnalité TSPITR de RMAN exécute automatiquement la procédure
DBMS_TTS.TRANSPORT_SET_CHECK pour les tablespaces de l'ensemble de récupération et
vérifie que l'interrogation de la vue TRANSPORT_SET_VIOLATIONS ne renvoie aucune ligne. Si
des lignes sont renvoyées, RMAN arrête le traitement TSPITR et toute violation d'autonomie des
tablespaces doit être résolue pour poursuivre l'opération de récupération. Vous pouvez exécuter
cette procédure et cette interrogation comme indiqué dans la diapositive par mesure de
précaution.

Identifier les objets qui seront perdus
• Les objets qui avaient été créés dans le tablespace après

le point cible de la récupération sont perdus.
• Pour déterminer quels objets seront perdus après
l'opération TSPITR, interrogez la vue
TS_PITR_OBJECTS_TO_BE_DROPPED.
• Utilisez un export avant TSPITR et un import après
TSPTIR pour conserver et recréer les objets perdus.
Interrogez la vue TS_PITR_OBJECTS_TO_BE_DROPPED pour déterminer si des objets seront

perdus suite à l'exécution d'une récupération de tablespace jusqu'à un point dans le temps
(TSPITR).
Par exemple, vous effectuez une opération TSPITR pour les tablespaces USERS et EXAMPLE,
jusqu'au point cible du 3 avril 2006 à 8h30. Exécutez l'interrogation suivante pour savoir si des
objets seront perdus après l'opération :
SELECT OWNER, NAME, TABLESPACE_NAME,
TO_CHAR(CREATION_TIME, 'YYYY-MM-DD:HH24:MI:SS')
FROM TS_PITR_OBJECTS_TO_BE_DROPPED
WHERE TABLESPACE_NAME IN ('USERS','EXAMPLE')
AND CREATION_TIME >
TO_DATE('2006-APR-03:08:30:00','YY-MON-DD:HH24:MI:SS')
ORDER BY TABLESPACE_NAME, CREATION_TIME;

Récupération PITR de tablespace (TSPITR)
avec RMAN
• Opération TSPITR entièrement automatisée :
– Indiquez la destination auxiliaire.
– RMAN gère tous les aspects de l'opération TSPITR.
– Il s'agit de la méthode recommandée.
• Opération TSPITR personnalisée avec instance auxiliaire
automatique :
– Elle repose sur une opération TSPITR entièrement automatisée.
– Personnalisez l'emplacement des fichiers.
– Indiquez les paramètres d'initialisation.
– Indiquez la configuration des canaux.
• Opération TSPITR utilisant votre propre instance auxiliaire :
– Configurez et gérez l'instance auxiliaire.
Différents types de récupération de tablespace jusqu'à un point dans le temps (TSPITR) sont à
votre disposition :
• Opération TSPITR entièrement automatisée : Vous indiquez la destination auxiliaire,
après quoi RMAN gère tous les aspects de l'opération. Il s'agit de la méthode la plus simple.
Il est recommandé de l'utiliser, sauf si vous souhaitez contrôler davantage l'emplacement
des fichiers de l'ensemble de récupération après l'opération TSPITR ou l'emplacement de
l'ensemble auxiliaire pendant l'opération, ou encore si vous voulez contrôler la configuration
des canaux ou un autre aspect de l'instance auxiliaire.
• Opération TSPITR personnalisée avec instance auxiliaire automatique : Cette
opération repose sur une opération TSPITR entièrement automatisée, utilisant
éventuellement une destination auxiliaire. Vous pouvez personnaliser un ou plusieurs
aspects du comportement, par exemple l'emplacement des fichiers de l'ensemble de
récupération ou de l'ensemble auxiliaire. Vous pouvez indiquer des paramètres
d'initialisation ou des configurations de canaux pour l'instance auxiliaire créée et gérée par
RMAN.
• Opération TSPITR utilisant votre propre instance auxiliaire : Vous configurez, démarrez,
arrêtez et nettoyez l'instance auxiliaire utilisée pour l'opération TSPITR. En outre, vous
pouvez gérer le processus TSPITR grâce à certaines des méthodes disponibles dans
l'opération TSPITR personnalisée avec une instance auxiliaire automatique.

Opération TSPITR entièrement automatisée
1. Configurez les canaux requis pour l'opération TSPITR

dans l'instance cible.
2. Indiquez la destination auxiliaire à l'aide de l'option
AUXILIARY DESTINATION.
RMAN> CONNECT TARGET
RMAN> RECOVER TABLESPACE users, example
> UNTIL TIME '2007-06-29:08:00:00'
> AUXILIARY DESTINATION
> '/u01/app/oracle/oradata/aux';
3. Sauvegardez les tablespaces récupérés et mettez-les
en ligne.
En plus des préparatifs décrits précédemment dans ce chapitre, vous devez effectuer les
opérations suivantes lorsque vous effectuez une récupération de tablespace jusqu'à un point
dans le temps (TSPITR) entièrement automatisée :
• Configurer les canaux requis pour l'opération TSPITR dans l'instance cible
• Indiquer la destination que RMAN doit utiliser pour l'ensemble auxiliaire de fichiers de
données et les autres fichiers de l'instance auxiliaire
Une fois l'opération TSPITR terminée, sauvegardez les tablespaces récupérés et mettez-les en
ligne (online). Vous ne pouvez alors plus utiliser les sauvegardes des tablespaces impliqués dans
l'opération TSPITR qui ont été effectuées avant cette opération.
Remarque : Ce format de date et d'heure suppose que NLS_DATE_FORMAT ait la valeur 'yyyy-
mm-dd:hh24:mi:ss' et que NLS_LANG ait la valeur AMERICAN_AMERICA.WE8MSWIN1252.

Améliorer les performances d'une opération TSPITR
RUN
{
SET NEWNAME FOR DATAFILE
'$ORACLE_BASE/oradata/orcl/users01.dbf'
TO '/u01/backup/users01.dbf';
RECOVER TABLESPACE users UNTIL SEQUENCE 1300 THREAD 1;

}
• CONFIGURE AUXNAME indique un emplacement persistant

de rechange pour une copie d'image de fichier de données
appartenant à l'ensemble auxiliaire
• SET NEWNAME indique un emplacement de rechange
valable pendant la durée d'exécution d'une commande
RUN
Vous pouvez améliorer les performances de la récupération TSPITR en ordonnant à RMAN

d'utiliser des copies d'images existantes de l'ensemble de récupération et des fichiers de données
de l'ensemble auxiliaire. Cette technique permet à RMAN d'ignorer la restauration des fichiers de
données à partir d'une sauvegarde.
La commande CONFIGURE AUXNAME définit un emplacement alternatif persistant pour les copies
d'image des fichiers de données de l'ensemble auxiliaire. La commande SET NEWNAME définit
quant à elle un emplacement alternatif valable pendant la durée d'une commande RUN.

Effectuer une opération RMAN TSPITR avec une
instance auxiliaire gérée par RMAN
• Renommez ou déplacez les fichiers de données de votre

ensemble de récupération.
• Indiquez un emplacement différent de la destination
auxiliaire pour certains ou l'ensemble des fichiers de
données de l'ensemble auxiliaire.
• Créez des sauvegardes sous forme de copies d'image
pour vos fichiers de données avant l'opération TSPITR.
• Utilisez une configuration de canaux différente pour
l'instance auxiliaire.
• Indiquez des paramètres d'initialisation différents pour
l'instance auxiliaire gérée par RMAN.
Pour personnaliser une récupération de tablespace jusqu'à un point dans le temps (TSPITR),
vous pouvez utiliser une instance auxiliaire gérée par RMAN et effectuer les modifications
suivantes :
• Renommez les fichiers de données de l'ensemble de récupération à l'aide de SET NEWNAME
afin qu'ils ne soient pas restaurés et récupérés à leur emplacement d'origine.
• Contrôlez l'emplacement des fichiers de données de l'ensemble auxiliaire. Pour ce faire,
attribuez des noms nouveaux aux différents fichiers avec la commande SET NEWNAME et
utilisez DB_FILE_NAME_CONVERT pour fournir des règles de conversion des noms de
fichier de données de la base cible en noms de fichier de données de la base auxiliaire.
• Utilisez des copies d'image existantes pour les fichiers de données de l'ensemble de
récupération et de l'ensemble auxiliaire sur disque au lieu de restaurer ces fichiers à partir
d'une sauvegarde ; les performances de l'opération RMAN TSPITR seront ainsi accrues.
Remarque : Pour plus d'informations, reportez-vous au manuel Oracle Database Backup and
Recovery User’s Guide.

Effectuer une opération TSPITR RMAN à l'aide
de votre propre instance auxiliaire
• Cette méthode n'est pas recommandée mais elle est prise
en charge.
• Procédez comme suit :
1. Créez un fichier de mots de passe Oracle pour l'instance
auxiliaire.
2. Créez un fichier de paramètres d'initialisation pour
3. Vérifiez la connexion Oracle Net à l'instance auxiliaire.
4. Démarrez l'instance auxiliaire en mode NOMOUNT.
5. Connectez le client RMAN à l'instance cible et à l'instance
auxiliaire.
6. Exécutez la commande RECOVER TABLESPACE.
Oracle recommande d'autoriser RMAN à gérer la création et la destruction de l'instance auxiliaire

utilisée lors de la récupération de tablespace jusqu'à un point dans le temps (TSPITR). Toutefois,
vous pouvez créer et utiliser votre propre instance auxiliaire.
Pour créer une instance Oracle pouvant être utilisée en tant qu'instance auxiliaire, procédez
comme suit :
1. Créez un fichier de mots de passe Oracle pour l'instance auxiliaire à l'aide de l'utilitaire
orapwd.
2. Créez un fichier de paramètres d'initialisation au format texte pour l'instance auxiliaire.
3. Vérifiez la connexion Oracle Net à l'instance auxiliaire à l'aide d'un nom de service réseau
valide.
Pour effectuer l'opération TSPITR, procédez comme suit :
5. Connectez le client RMAN à l'instance cible et à l'instance auxiliaire.
6. Exécutez la commande RECOVER TABLESPACE.
Vous trouverez un exemple détaillé dans le manuel Oracle Database Backup and Recovery
User’s Guide.

Résoudre les problèmes liés à l'opération TSPITR
• Conflits de noms de fichier : Assurez-vous de l'absence

de conflits au niveau des noms lors de l'utilisation des
commandes SET NEWNAME, CONFIGURE AUXNAME et
DB_FILE_NAME_CONVERT.
• RMAN ne parvient pas à identifier les tablespaces
contenant des segments d'annulation (undo) : Utilisez
la clause UNDO TABLESPACE.
• Redémarrage d'une instance auxiliaire manuelle après
l'échec de TSPITR : Arrêtez l'instance et redémarrez-la
en mode NOMOUNT.
Conflits de noms de fichier : Si l'utilisation de SET NEWNAME, CONFIGURE AUXNAME et

DB_FILE_NAME_CONVERT entraîne l'attribution de noms identiques à plusieurs fichiers de
l'ensemble auxiliaire ou de l'ensemble de récupération, vous recevez un message d'erreur lors de
l'opération TSPITR. Pour résoudre ce problème, affectez des valeurs différentes à ces
paramètres afin d'éliminer les noms en double.
RMAN ne peut pas identifier les tablespaces contenant des segments d'annulation de type undo :
Lors de l'opération TSPITR, RMAN a besoin d'informations sur les tablespaces qui contenaient
des segments d'annulation au niveau du point cible de la récupération. Ces informations sont
généralement disponibles dans le catalogue de restauration, si celui-ci est utilisé. En l'absence de
catalogue de restauration, ou si les informations requises sont introuvables, RMAN poursuit
l'opération en partant de l'hypothèse que les tablespaces contenant des segments d'annulation à
l'instant cible sont les mêmes que les tablespaces qui en contiennent à l'instant présent. Si cette
supposition est incorrecte, l'opération TSPITR échoue et une erreur est signalée. Pour éviter cela,
indiquez dans la clause UNDO TABLESPACE la liste des tablespaces contenant des segments
d'annulation à l'instant cible.
Redémarrage d'une instance auxiliaire manuelle après l'échec de TSPITR : Si l'opération
TSPITR échoue alors que vous gérez votre propre instance auxiliaire, vous devez arrêter celle-ci,
résoudre le problème, puis redémarrer l'instance auxiliaire en mode NOMOUNT.

Quiz
Identifiez les cas où il est recommandé d'utiliser l'opération

TSPITR pour récupérer des tablespaces.
a. Pour récupérer un tablespace supprimé
b. Pour récupérer une table jusqu'à un point différent de celui
du reste de la base physique
c. Pour récupérer un schéma logique jusqu'à un point
différent de celui du reste de la base physique
d. Lorsque vous avez besoin d'effectuer des récupérations
répétées jusqu'à plusieurs points dans le temps antérieurs
à la mise en ligne du tablespace sans utiliser de catalogue
de restauration.
Réponses : a, c, d

Récupérer des tables à partir de sauvegardes
Quand récupérer des tables et des partitions de table à partir

des sauvegardes RMAN :
• Petit nombre de tables (pas d'opération TSPITR)
• Tables n'appartenant pas à un tablespace autonome
(pas d'opération TSPITR)
• Tables purgées (pas d'opération Flashback Drop)
• Récupération au-delà des informations d'annulation
disponibles (pas d'opération Flashback Table)
• Après une modification structurelle par une instruction DDL
(pas d'opération Flashback Table)
Dans Oracle Database 12c et les versions supérieures, RMAN vous permet de récupérer une ou
plusieurs tables ou partitions de table jusqu'à un point spécifique dans le temps sans affecter les
autres objets de la base de données. La récupération de tables et de partitions isolées peut être
utile dans les cas suivants :
• Vous devez récupérer un très petit nombre de tables telles qu'elles étaient à un instant
donné. Une opération TSPITR ne serait pas très efficace dans cette situation car elle
amènerait tous les objets du tablespace jusqu'au point indiqué.
• Vous devez récupérer un tablespace qui n'est pas autonome tel qu'il était à un instant
donné. L'opération TSPITR ne peut être utilisée que sur un tablespace autonome.
• Vous devez récupérer des tables qui ont été endommagées ou supprimées par l'option
PURGE, de sorte que vous ne pouvez pas faire appel à la fonctionnalité Flashback Drop.
• Vous avez activé la journalisation pour une opération Flashback Table, mais le moment ou
SCN cible du flashback est situé au-delà des informations d'annulation (undo) disponibles.
• Vous souhaitez récupérer des données qui ont été perdues après une opération DDL (Data
Definition Language) qui a modifié la structure des tables. Vous ne pouvez pas recourir à
Flashback Table pour "rembobiner" une table jusqu'à un point antérieur à une modification
structurelle (vidage d'une table, par exemple).

Récupération de tables : Résumé en images
Nom ?
1 Temps ? 2 3
Import ?
Prérequis vérifiés
4
COMPATIBLE=12.0
(ou valeur supérieure)
Mode ARCHIVELOG
Mode d'ouverture READ WRITE
Base de données Données de Instance auxiliaire
cible sauvegarde
6
5
Fichier
dump
1. RMAN utilise les sauvegardes créées précédemment pour récupérer des tables et des
partitions de table jusqu'à un point spécifique dans le temps. Les conditions requises sont
satisfaites et vous fournissez les informations d'entrée suivantes dans la commande
RECOVER :
- Noms des tables ou partitions à récupérer
- Point dans le temps jusqu'où vous voulez récupérer ces tables ou partitions
- Nécessité éventuelle d'importer les tables ou partitions récupérées dans la base de
données cible
RMAN utilise ces informations pour automatiser le processus de récupération des
-
éléments indiqués
2. RMAN détermine la sauvegarde à utiliser en fonction de vos indications.
3. RMAN crée une instance auxiliaire.
4. RMAN récupère dans l'instance auxiliaire les tables ou partitions voulues, jusqu'au point
voulu dans le temps.
5. RMAN crée un fichier dump d'export Data Pump qui contient les objets récupérés.
6. RMAN importe les objets récupérés dans la base de données cible.
Il est possible de personnaliser ce processus comme expliqué dans les diapositives qui suivent.

Prérequis et restrictions
Pour récupérer des tables et des partitions de table à partir de

sauvegardes RMAN, il est nécessaire que la base de données
cible soit :
• ouverte en lecture/écriture
• en mode ARCHIVELOG
• configurée avec le paramètre COMPATIBLE égal ou
supérieur à 12.0
La récupération n'est pas possible pour les tables ou partitions
appartenant :
• au schéma SYS
• aux tablespaces SYSTEM et SYSAUX
• à des bases de données de secours
La diapositive ci-dessus énumère les conditions requises et les restrictions qui s'appliquent à la
récupération de tables à partir de sauvegardes.
L'objectif d'une récupération de table est bien sûr que la table existe dans l'état où elle était à un
point antérieur dans le temps. Il peut en résulter des problèmes de cohérence.

Indiquer le point de récupération
Indiquez jusqu'à quel point vous souhaitez récupérer une table

ou des partitions en précisant :
• UNTIL SCN integer : un numéro SCN
• UNTIL TIME 'date_string' : un horodatage,
dans le format de date et d'heure :
– défini par les variables d'environnement NLS_LANG et
NLS_DATE_FORMAT ou
– défini par des constantes de date, par exemple SYSDATE – 5
• UNTIL SEQUENCE integer (THREAD integer) :
un numéro séquentiel de journal et un numéro de thread
• RMAN récupère les tables ou les partitions de table dans l'état où elles se trouvaient au
moment défini par le numéro SCN (System Change Number). Le SCN est une limite
supérieure non inclusive.
• RMAN récupère les tables ou les partitions de table telles qu'elles étaient à la date et à
l'heure indiquées. Utilisez le format de date défini dans les variables d'environnement
NLS_LANG et NLS_DATE_FORMAT. Vous pouvez également utiliser des constantes de date
telles que SYSDATE. (SYSDATE – 5 veut dire 5 jours avant la date système.)
• RMAN récupère les tables ou les partitions de table dans l'état où elles se trouvaient au
moment défini par le numéro de séquence de journal et le numéro de thread. RMAN ne
sélectionne que les fichiers qu'il peut utiliser pour restaurer ou récupérer les données
jusqu'au numéro de séquence indiqué, ce numéro n'étant pas inclus.

Etapes d'une récupération de table : 1/2
1. Effectuez les tâches de planification et lancez une session
RMAN avec la commande CONNECT TARGET.
2. Entrez la commande RECOVER TABLE.
3. RMAN détermine la sauvegarde à utiliser en fonction de
vos indications.
4. RMAN crée une instance auxiliaire en utilisant la clause
AUXILIARY DESTINATION si elle est définie.
5. RMAN récupère dans l'instance auxiliaire les tables ou
partitions voulues, jusqu'au point voulu dans le temps.
6. RMAN crée un fichier dump d'export Data Pump contenant
les objets récupérés en utilisant le nom de fichier DUMP
FILE=name et l'emplacement DATAPUMP
DESTINATION=<OS path>.
Remarque : Si un fichier portant le nom indiqué par DUMP FILE existe
déjà à l'emplacement où le fichier dump doit être créé, l'export échoue.
1. Après avoir vérifié que les conditions requises sont remplies, démarrez une session RMAN
et connectez-vous à l'instance cible.
2. Entrez la commande RECOVER TABLE avec les clauses nécessaires.
3. RMAN détermine quelle sauvegarde contient les données à récupérer en fonction du point
de récupération que vous avez indiqué.
4. RMAN crée une instance auxiliaire. Vous pouvez éventuellement préciser l'emplacement
des fichiers de l'instance auxiliaire à l'aide de la clause AUXILIARY DESTINATION ou SET
NEWNAME de la commande RECOVER. La clause recommandée est AUXILIARY
DESTINATION. En effet, si vous utilisez SET NEWNAME et oubliez un seul nom de fichier de
données, la récupération n'aura pas lieu.
5. RMAN récupère dans l'instance auxiliaire les tables ou les partitions de table indiquées
jusqu'au point dans le temps que vous avez défini.
6. RMAN crée un fichier dump d'export Data Pump qui contient les objets récupérés. Vous
pouvez éventuellement préciser le nom du fichier dump d'export (à l'aide de la clause DUMP
FILE et d'un nom par défaut propre au système d'exploitation) à utiliser pour stocker les
métadonnées issues de la base source. Vous pouvez également indiquer l'emplacement où
ce fichier est créé à l'aide de la clause DATAPUMP DESTINATION. Il s'agit généralement du
chemin du répertoire du système d'exploitation qui stocke le fichier dump. En l'absence de
cette indication, le fichier dump est créé à l'emplacement défini par AUXILIARY
DESTINATION. Si cette dernière clause n'est pas définie, le fichier dump est créé dans un
emplacement par défaut propre au système d'exploitation.

Etapes d'une récupération de table : 2/2
7. RMAN importe les objets récupérés dans la base de

données cible, sauf si vous avez précisé la clause
NOTABLEIMPORT.
8. RMAN renomme éventuellement les tables ou partitions de
table récupérées en utilisant les clauses REMAP TABLE et
REMAP TABLESPACE. (Les objets existants ne sont pas
modifiés.)
Remarque : Si vous remappez une table, les objets
dépendants sont exclus de l'import. Vous devez recréer
les index et les contraintes.
7. Par défaut, RMAN importe dans la base de données cible les objets récupérés qui sont
stockés dans le fichier dump d'export. Vous pouvez toutefois choisir de ne pas importer ces
objets en utilisant la clause NOTABLEIMPORT de la commande RESTORE.
Si telle est votre décision, RMAN récupère les tables ou les partitions de table jusqu'au point
défini, puis crée le fichier dump d'export mais ne l'importe pas dans la base cible. Dans ce
cas, vous devez procéder manuellement à cet import au moment voulu à l'aide de l'utilitaire
Data Pump.
8. RMAN offre la possibilité de renommer les tables ou partitions récupérées dans la base de
données cible au moyen de l'option REMAP TABLE.
- Si une table existe déjà et que l'option REMAP n'est pas précisée, la récupération de
cette table génère une erreur.
- Si l'option REMAP est incluse, les index et les contraintes ne sont pas importés. Vous
devez créer manuellement les objets dépendants.
Pour importer les objets récupérés dans un tablespace différent de celui où ces objets
résidaient à l'origine, utilisez la clause REMAP TABLESPACE de la commande RECOVER.
Seules les tables ou partitions qui ont été récupérées sont remappées ; les objets existants
ne sont pas affectés.

Quiz
Lorsque vous effectuez une récupération de tables à partir de

jeux de sauvegarde dans Oracle Database 12c (ou une version
supérieure), RMAN crée, utilise et supprime automatiquement
une instance de base de données auxiliaire.
a. Vrai
b. Faux
Réponse : a

Synthèse
• décrire la récupération jusqu'à un point dans le temps
(PITR) d'une table, d'un tablespace et d'une base de
données
• identifier les circonstances dans lesquelles cette solution
est appropriée et les cas où elle ne peut pas être utilisée
• décrire les opérations qui ont lieu lorsque vous effectuez
une opération PITR
• déterminer le point cible correct pour une opération PITR
• effectuer une opération PITR de tablespace (TSPITR)
automatisée
• effectuer une récupération de table à partir de
sauvegardes

Présentation de l'exercice
Dans l'exercice 17-1, vous allez récupérer une table à partir

de sauvegardes.
Cet exercice met en oeuvre une fonctionnalité introduite par Oracle Database 12c, à savoir la
récupération d'une table à partir d'une sauvegarde à l'aide d'une instance auxiliaire gérée
automatiquement par RMAN.
Vous avez la possibilité de consulter des vidéos à ce sujet sur OLL et YouTube.

Dupliquer une base de données

Objectifs

• énumérer les motifs de création d'une base de données
dupliquée
• choisir une technique de duplication
• dupliquer une base de données à l'aide de RMAN
• utiliser une sauvegarde RMAN pour dupliquer une base
de données
• dupliquer une base de données à partir d'une instance en
cours d'exécution

Utiliser une base de données dupliquée
• Utilisations d'une base de données dupliquée :

– Tester des procédures de sauvegarde et de récupération
– Récupérer des objets en créant un export et en important
ces objets dans la base de production
• Création d'une base de données dupliquée :
– A l'aide de la commande RMAN DUPLICATE
– Sur le même hôte ou sur un hôte distinct
– Avec un contenu identique ou un sous-ensemble de
la source
– Via des canaux auxiliaires pour la duplication à partir
de sauvegardes
Une base de données dupliquée est une copie de la base de données cible. Avec la clause FOR
STANDBY, l'identificateur unique de la base (DBID) est conservé ; si cette clause n'est pas
indiquée, un nouveau DBID est créé. Vous pouvez exploiter la base dupliquée indépendamment
de la base cible pour effectuer les tâches suivantes :
• Tester les procédures de sauvegarde et de récupération.
• Récupérer des objets qui ont été supprimés par inadvertance de la base cible, en créant un
export contenant ces objets dans la base de données dupliquée puis en important les objets
dans la base de production. Néanmoins, vous constaterez probablement qu'il existe des
solutions plus simples et plus rapides pour récupérer des objets, notamment Flashback
Query, Flashback Drop, Flashback Table et la récupération de table à partir d'une
sauvegarde.
Pour créer une base de données dupliquée, vous pouvez utiliser la commande RMAN
DUPLICATE.
• La base dupliquée peut avoir le même contenu que la base source ou seulement un sous-
ensemble. Les deux bases peuvent résider sur le même hôte ou sur des hôtes distincts.
• La plus grande partie du travail de duplication est effectuée par les canaux auxiliaires. Pour
la duplication à partir de sauvegardes, ces canaux correspondent à une session serveur sur
l'instance auxiliaire de l'hôte cible.
• Dans le cas d'une duplication de base active, les canaux cible sont chargés de pousser les
copies des fichiers de données vers l'instance auxiliaire (si les canaux cible sont alloués en
plus grand nombre que les canaux auxiliaires).

Choisir la technique de duplication
Choix de la technique à utiliser pour dupliquer une base,
toujours avec une connexion à l'instance auxiliaire :
Processus de "poussée" basé

sur des copies d'image
A partir d'une
Processus de "traction" basé
base active sur des jeux de sauvegarde (à
Avec connexion partir de la version 12)
A partir de à la cible Avec connexion à un
sauvegardes
catalogue de restauration
Sans connexion
à la cible
Sans connexion à un
catalogue de restauration
Via la ligne de commande RMAN

ou Enterprise Manager Cloud Control
Vous pouvez dupliquer une base de données source vers une base cible située sur le même
ordinateur ou sur une autre machine. L'instance de base de données associée à la base
dupliquée est appelée instance auxiliaire. Toutes les techniques de duplication nécessitent une
connexion à cette instance. Le diagramme de la diapositive présente les techniques de
duplication suivantes :
• A partir d'une base de données active, avec une connexion à l'instance cible et à l'instance
auxiliaire :
- A partir de la version Oracle Database 12c, un processus de "traction" (restauration)
basé sur des jeux de sauvegarde.
- Avant la version Oracle Database 12c, un processus de "poussée" basé sur des
copies d'image.
• A partir d'une sauvegarde, avec une connexion à l'instance cible et à l'instance auxiliaire.
• A partir d'une sauvegarde, avec une connexion à l'instance auxiliaire mais pas à l'instance
cible, et avec une connexion au catalogue de restauration.
• A partir d'une sauvegarde, avec une connexion à l'instance auxiliaire mais pas à l'instance
cible ni au catalogue de restauration.
Vous pouvez dupliquer des bases de données à l'aide de la ligne de commande RMAN ou de
Cloud Control.

Dupliquer une base de données active par "poussée"
• Méthode basée sur des copies d'image
• Via Enterprise Manager ou la ligne de commande RMAN
• Avec un réseau (utiliser la clause FROM ACTIVE
DATABASE)
• Avec un fichier SPFILE personnalisé
Instance Instance • Fichiers de données
source auxiliaire • Fichiers de contrôle
• SPFILE
Données de • Copies des journaux
sauvegarde archivés
Connexion à
Connexion l'instance
Base de à la cible auxiliaire Base de
données données
source dupliquée
Hôte source Hôte de

Client RMAN destination
Vous pouvez demander à la base de données source d'envoyer un "clone" d'elle-même

directement à l'instance auxiliaire en utilisant Enterprise Manager ou la clause FROM ACTIVE
DATABASE de la commande RMAN DUPLICATE.
Vous n'avez pas besoin des sauvegardes existantes pour cette opération. Les copies d'image en
ligne sont créées par la base source et transmises directement via Oracle Net (elles ne sont pas
écrites sur disque) lorsque la clause FROM ACTIVE DATABASE de la commande RMAN
DUPLICATE est utilisée. La base de données source peut être ouverte ou montée.
RMAN se connecte en tant que TARGET à l'instance de base de données source et en tant que
AUXILIARY à l'instance auxiliaire (voir l'illustration ci-dessus).
Les fichiers requis (fichiers de données, fichiers de contrôle, fichier SPFILE et copies des
journaux archivés) sont copiés de l'instance source vers une instance auxiliaire par le biais d'une
connexion réseau. RMAN utilise ensuite un "script en mémoire" (qui existe uniquement en
mémoire) pour effectuer la récupération et ouvrir la base de données.
Cette méthode de duplication de base active, dite "par poussée", était la seule disponible dans
Oracle Database 11g.

Méthodes de duplication "par poussée“
et "par traction"
• La méthode par poussée s'appuie sur des copies d'image.
• La méthode par traction s'appuie sur des jeux de sauvegarde.
– RMAN utilise la méthode par traction lorsqu'il trouve les
éléments suivants :
— USING BACKUPSET
— SECTION SIZE
Les données sont cryptées dans la base de
— Cryptage données source, avant leur transmission.
— Compression
– La méthode par traction nécessite des connexions aux instances
cible et auxiliaire.
RMAN> SET ENCRYPTION …;
RMAN> DUPLICATE TARGET DATABASE TO orcl2
FROM ACTIVE DATABASE
[USING BACKUPSET]
[SECTION SIZE …]
[USING COMPRESSED BACKUPSET] …;
Le processus de "traction" (ou restauration) fonctionne de la manière suivante : Tout d'abord, une
connexion est établie avec la base de données source. L'instance auxiliaire extrait ensuite les
fichiers de base de données requis à partir de la base source sous la forme de jeux de
sauvegarde. Une opération de restauration est effectuée à partir de l'instance auxiliaire. Par
conséquent, moins de ressources sont utilisées dans la base source. Les deux connexions TNS
sont requises sur les instances cible et auxiliaire.
En fonction des clauses de la commande DUPLICATE, RMAN détermine dynamiquement quel
processus utiliser (poussée ou traction). Cela garantit que les scripts personnalisés existants
continuent de fonctionner.
• Lorsque vous indiquez la clause USING BACKUPSET, RMAN utilise la méthode par traction.
• Lorsque vous indiquez SET ENCRYPTION avant la commande DUPLICATE, RMAN utilise
automatiquement la méthode par traction et crée des jeux de sauvegarde. Les sauvegardes
envoyées vers la base de destination sont cryptées.
• La clause SECTION SIZE divise les fichiers de données en sous-sections qui sont
restaurées en parallèle sur plusieurs canaux dans la base auxiliaire. Pour une meilleure
exploitation du parallélisme, allouez davantage de canaux AUXILIARY.
• Avec la clause USING COMPRESSED BACKUPSET, les fichiers sont transférés en tant que
jeux de sauvegarde compressés. RMAN utilise la compression des blocs inutilisés lors de la
création des sauvegardes, ce qui réduit la taille de ces dernières et optimise leur transport
sur le réseau.

avec une connexion à la cible
• Connectez-vous à la cible (base de données source).
• Connectez-vous à l'instance auxiliaire.
• Vous pouvez aussi vous connecter au catalogue de
restauration (ou utiliser le fichier de contrôle de la cible).
Instance Instance
source auxiliaire
Sauvegardes
RMAN
Connexion
Connexion à l'instance
Base de à la cible auxiliaire Base de
données données
source dupliquée
Hôte source Hôte de

destination
Client RMAN
Lorsque vous dupliquez une base de données avec une connexion à la base de données cible,
RMAN peut obtenir les métadonnées relatives aux sauvegardes à partir du fichier de contrôle de
la base de données cible ou à partir du catalogue de restauration.
Le diagramme de la diapositive illustre la duplication à partir de sauvegardes avec une connexion
à la cible. RMAN se connecte à l'instance de base de données source et à l'instance auxiliaire.
RMAN peut aussi se connecter à la base de données du catalogue de restauration (non
représentée dans le graphique). L'hôte de destination doit avoir accès aux sauvegardes RMAN
qui sont nécessaires pour créer la base dupliquée.

Dupliquer une base de données à l'aide du
catalogue de restauration sans connexion à la cible
• Connectez-vous au catalogue de restauration pour obtenir
les métadonnées relatives aux sauvegardes.
• Connectez-vous à l'instance auxiliaire, qui doit avoir accès
aux sauvegardes RMAN.
Instance du Instance
catalogue Sauvegardes auxiliaire
RMAN
Connexion
à l'instance
Connexion auxiliaire
Base de données au catalogue Base de
du catalogue données
de restauration dupliquée
Hôte du Hôte de
catalogue de destination
restauration Client RMAN
Lorsque vous dupliquez une base de données sans connexion à celle-ci mais avec une
connexion au catalogue de restauration, RMAN utilise ce dernier pour obtenir les métadonnées
relatives aux sauvegardes.
Le diagramme de la diapositive illustre la duplication à partir de sauvegardes sans connexion à la
cible. RMAN se connecte à l'instance de base de données du catalogue de restauration et à
l'instance auxiliaire. L'hôte de destination doit avoir accès aux sauvegardes RMAN qui sont
nécessaires pour créer la base dupliquée.

Dupliquer une base de données sans catalogue
de restauration ni connexion à la cible
Connectez-vous à l'instance auxiliaire, laquelle doit avoir accès
à un emplacement sur disque BACKUP LOCATION
Instance
auxiliaire
Emplacement
des sauvegardes
Base de
données
dupliquée
Connexion
à l'instance
auxiliaire Hôte de
destination
Client RMAN
Lorsque vous dupliquez une base de données sans connexion à celle-ci et sans connexion au
catalogue de restauration, RMAN utilise l'emplacement BACKUP LOCATION où sont stockées les
sauvegardes et les copies nécessaires.
Le diagramme de la diapositive illustre la duplication à partir de sauvegardes sans connexion à la
cible ni au catalogue de restauration. L'hôte de destination doit disposer d'un emplacement sur
disque contenant toutes les sauvegardes ou copies nécessaires à la duplication.

Créer une base de données dupliquée
à partir de sauvegardes
1. Créez un fichier de mots de passe Oracle pour l'instance
auxiliaire.
2. Etablissez une connexion Oracle Net avec l'instance
auxiliaire.
3. Créez un fichier de paramètres d'initialisation pour l'instance
auxiliaire.
5. Montez ou ouvrez la base de données cible.
6. Assurez-vous que les sauvegardes et les fichiers de
journalisation archivés sont disponibles.
7. Allouez des canaux auxiliaires si nécessaire.
8. Exécutez la commande DUPLICATE.
Il est important de bien comprendre les étapes élémentaires décrites ci-après ainsi que le
processus RMAN de duplication de base de données.
Si vous utilisez l'interface Enterprise Manager, la plupart de ces étapes sont réalisées par les
assistants. En revanche, si vous créez la base dupliquée à partir de la ligne de commande, vous
devez effectuer les différentes opérations manuellement. Vous pouvez utiliser l'interface EM
comme outil de modélisation et créer votre propre processus de duplication de base de données
à partir du journal généré.
Les principales étapes permettant de créer une base de données dupliquée sont présentées sur
la diapositive. Certaines de ces étapes sont décrites plus en détail dans la suite du chapitre.

Créer un fichier de paramètres d'initialisation
pour l'instance auxiliaire
Définissez les paramètres suivants :
• DB_NAME (requis)
– Si la base de données dupliquée figure dans le même
répertoire Oracle Home que la base cible, elle doit porter un
nom différent.
– Utilisez la même valeur dans la commande DUPLICATE.
• CONTROL_FILES (requis uniquement en l'absence de
l'option SET NEWNAME et d'OMF)
Vous devez créer un fichier de paramètres d'initialisation au format texte pour l'instance auxiliaire.
Ce fichier doit résider sur le même hôte que le client RMAN utilisé pour exécuter la commande
DUPLICATE.
Notez les indications ci-après pour définir chaque paramètre :
• DB_NAME : Si la base dupliquée réside dans le même répertoire Oracle Home que la base
cible, vous devez attribuer à DB_NAME un nom différent de celui de la base cible. Si les deux
bases figurent dans des répertoires d'origine Oracle Home différents, vous devez vérifier
que le nom de la base dupliquée n'est pas identique à un autre nom existant dans le même
répertoire. Veillez à utiliser le nom de base de données affecté à ce paramètre lorsque vous
exécutez la commande DUPLICATE.
• CONTROL_FILES : Ce paramètre est requis lorsque vous n'utilisez pas l'option SET
NEWNAME et Oracle Managed Files (OMF).
Remarque : Vérifiez tous les paramètres d'initialisation qui indiquent des chemins d'accès.
Assurez-vous que les chemins indiqués sont accessibles sur l'hôte de la base de données
dupliquée.

Indiquer de nouveaux noms pour la destination
Techniques disponibles :
• Commande SET NEWNAME
• commande CONFIGURE AUXNAME (en phase d'abandon
pour les fichiers de données des ensembles de
récupération)
• Paramètre DB_FILE_NAME_CONVERT avec la commande
DUPLICATE
Vous pouvez utiliser les techniques suivantes pour indiquer de nouveaux noms pour les fichiers
de données :
• Incluez la commande SET NEWNAME FOR DATAFILE à l'intérieur d'un bloc RUN pour indiquer
les nouveaux noms des fichiers de données.
• Utilisez la commande CONFIGURE AUXNAME.
CONFIGURE AUXNAME est une alternative à SET NEWNAME. La différence entre les deux est
que la configuration définie par la première est réutilisée par les commandes DUPLICATE
ultérieures. A l'opposé, vous devez exécuter SET NEWNAME chaque fois que vous utilisez
DUPLICATE.
Remarque : SET NEWNAME remplace CONFIGURE AUXNAME pour les fichiers
de données des ensembles de récupération.
• Indiquez le paramètre DB_FILE_NAME_CONVERT avec la commande DUPLICATE.

Utiliser les clauses SET NEWNAME
• Les clauses SET NEWNAME permettent d'indiquer un format

de nom par défaut pour tous les fichiers d'une base de
données ou d'un tablespace nommé.
• Le nom par défaut est utilisé pour les commandes
DUPLICATE, RESTORE et SWITCH du bloc RUN.
• Vous pouvez ainsi définir les noms de fichier en une seule
commande au lieu de les indiquer individuellement.
SET NEWNAME FOR DATABASE
TO {NEW|'formatSpec'};
Vous pouvez utiliser SET NEWNAME pour définir le format de nom par défaut de tous les fichiers de données
d'un tablespace nommé et tous les fichiers de données de la base.
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
Exemple :
RUN
{
SET NEWNAME FOR DATABASE TO '/u01/app/oracle/oradata/dupldb/%b';
DUPLICATE TARGET DATABASE TO dupldb
LOGFILE
GROUP 1 ('/u01/app/oracle/oradata/dupldb/redo01a.log',
'/u01/app/oracle/oradata/dupldb/redo01b.log') SIZE 50M REUSE,
'/u01/app/oracle/oradata/dupldb/redo02b.log') SIZE 50M REUSE,
'/u01/app/oracle/oradata/dupldb/redo03b.log') SIZE 50M REUSE;
}

Variables de substitution pour SET NEWNAME
Elément Description
de
syntaxe
%b Définit le nom de fichier sans le chemin d'accès
%f Définit le numéro absolu du fichier de données pour lequel le nouveau

nom est généré
%I Définit l'ID de base de données
%N Définit le nom de tablespace
%U Définit un nom de fichier généré par le système au format suivant :

data-D-%d_id-%I_TS-%N_FNO-%f
Lorsque vous exécutez SET NEWNAME FOR DATABASE ou SET NEWNAME FOR TABLESPACE, vous
devez indiquer des variables de substitution dans la clause TO <filename> pour éviter les
collisions de noms. Indiquez au moins une des variables de substitution suivantes : %b, %f et %U.
%I et %N sont des variables facultatives.

Définir des paramètres pour les noms de fichier
Vous pouvez indiquer les paramètres suivants pour contrôler

explicitement les noms des fichiers de la base de données
auxiliaire :
• CONTROL_FILES
• DB_FILE_NAME_CONVERT
• LOG_FILE_NAME_CONVERT
CONTROL_FILES='/u01/app/oracle/oradata/aux/control01.ctl',
'/u01/app/oracle/oradata/aux/control02.ctl',
'/u01/app/oracle/oradata/aux/control03.ctl'
DB_FILE_NAME_CONVERT='/u01/app/oracle/oradata/orcl',
'/u01/app/oracle/oradata/aux'
LOG_FILE_NAME_CONVERT='/u01/app/oracle/oradata/orcl',
'/u01/app/oracle/oradata/aux'
RMAN génère des noms pour les fichiers de base de données requis lorsque vous exécutez la
commande DUPLICATE. Vous pouvez contrôler les noms des fichiers en définissant les
paramètres suivants dans le fichier de paramètres d'initialisation de l'instance auxiliaire :
• CONTROL_FILES : Ce paramètre permet d'indiquer les noms des fichiers de contrôle. Si
vous ne définissez pas les noms via ce paramètre, le serveur Oracle crée un fichier de
contrôle OMF (Oracle Managed File) dans une destination par défaut. Pour obtenir des
informations plus précises, reportez-vous à la description de la commande SQL CREATE
CONTROLFILE dans le manuel de référence SQL.
• DB_FILE_NAME_CONVERT : Ce paramètre permet d'indiquer le nom des fichiers de
données pour la base auxiliaire. Il présente le format DB_FILE_NAME_CONVERT =
'string1', 'string2', où string1 est le modèle de nom de fichier dans la base cible
et string2 est le modèle pour la base auxiliaire. Vous pouvez également indiquer le
paramètre DB_FILE_NAME_CONVERT en tant qu'option de la commande DUPLICATE
DATABASE.
• LOG_FILE_NAME_CONVERT : Ce paramètre permet d'indiquer les noms des fichiers de
journalisation (fichiers redo log) pour la base de données auxiliaire. Il présente le format
LOG_FILE_NAME_CONVERT = 'string1', 'string2', oùstring1 est le modèle de
nom de fichier dans la base cible et string2 est le modèle pour la base auxiliaire. Vous
pouvez aussi utiliser la clause LOGFILE de la commande DUPLICATE DATABASE pour
indiquer les noms des fichiers de journalisation.

Au lieu d'utiliser les paramètres d'initialisation pour définir les noms des fichiers, vous pouvez
recourir aux méthodes suivantes pour renommer les fichiers de journalisation :
• Utilisez la clause LOGFILE de la commande DUPLICATE.
• Définissez les paramètres d'initialisation OMF (Oracle Managed Files) suivants :
DB_CREATE_FILE_DEST, DB_CREATE_ONLINE_DEST_n ou DB_RECOVERY_FILE_DEST.

Démarrer l'instance en mode NOMOUNT
• Démarrez l'instance auxiliaire en mode NOMOUNT.

• RMAN peut créer un fichier SPFILE.
SQL> startup nomount pfile='$HOME/auxinstance/initAUX.ora'
ORACLE instance started.
Total System Global Area 285212672 bytes

Fixed Size 1218992 bytes
Variable Size 92276304 bytes
Database Buffers 188743680 bytes
Redo Buffers 2973696 bytes
SQL> create spfile Inutile dans les exercices du cours

2 from pfile='$HOME/auxinstance/initAUX.ora';
File created.
Après avoir créé le fichier de paramètres d'initialisation au format texte, appelez SQL*Plus pour
démarrer l'instance auxiliaire en mode NOMOUNT.
RMAN crée un fichier de paramètres serveur (SPFILE) par défaut pour l'instance auxiliaire si les
conditions suivantes sont remplies :
• La duplication n'implique pas de base de données de secours.
• Les fichiers de paramètres serveur ne sont pas dupliqués.
• L'instance auxiliaire n'est pas démarrée avec un fichier de paramètres serveur.
Si ces conditions ne sont pas remplies, créez un fichier de paramètres serveur à partir du fichier
de paramètres d'initialisation. Vous pouvez exécuter CREATE SPFILE avant ou après le
démarrage de l'instance.

Vérifier la disponibilité des sauvegardes et des
fichiers de journalisation archivés
• Des sauvegardes de tous les fichiers de données de
la base cible doivent être accessibles sur l'hôte de
duplication.
• Il est possible d'utiliser une combinaison de sauvegardes
complètes et de sauvegardes incrémentielles.
• Les fichiers de journalisation archivés nécessaires pour
récupérer la base dupliquée doivent être accessibles sur
l'hôte de la base dupliquée.
• Les fichiers de journalisation archivés peuvent être :
– des sauvegardes dans un gestionnaire de support
– des copies d'image
– les fichiers de journalisation archivés eux-mêmes
Les sauvegardes nécessaires à la restauration des fichiers de données doivent être accessibles
sur l'hôte de duplication. Il n'est pas nécessaire de disposer d'une sauvegarde de l'ensemble de
la base cible. Pendant le processus de duplication, RMAN peut, en effet, utiliser une combinaison
de sauvegardes complètes et de sauvegardes incrémentielles pour les différents fichiers de
données.
Les fichiers de journalisation archivés (archived redo logs) nécessaires pour récupérer la base
dupliquée jusqu'au point dans le temps souhaité doivent également être accessibles. Ces fichiers
peuvent être des sauvegardes, des copies d'image ou les fichiers de journalisation archivés eux-
mêmes. Les sauvegardes ou les copies peuvent être transférées vers le disque local du noeud de
la base dupliquée ou montées sur un réseau via NFS (Network File System), par exemple.

Allouer des canaux auxiliaires
• Les canaux auxiliaires définissent une connexion entre
RMAN et une instance de base de données auxiliaire.
• Si aucun canal automatique n'est configuré, allouez des
canaux auxiliaires :
– Démarrez RMAN avec une connexion à la base de données
cible, à l'instance auxiliaire et au catalogue de restauration,
le cas échéant.
– Allouez au moins un canal auxiliaire dans le bloc RUN.
$ rman target sys/oracle_4U@trgt auxiliary

sys/oracle_4U@auxdb
RMAN> RUN
{ALLOCATE AUXILIARY CHANNEL aux1 DEVICE TYPE DISK;
ALLOCATE AUXILIARY CHANNEL aux2 DEVICE TYPE DISK;
…
DUPLICATE TARGET DATABASE to auxdb; . . .
En l'absence de canaux automatiques configurés, allouez manuellement au moins un canal

auxiliaire avant d'exécuter la commande DUPLICATE. La commande ALLOCATE AUXILIARY
CHANNEL doit figurer dans le même bloc RUN que la commande DUPLICATE.
Le type de canal indiqué dans la commande ALLOCATE AUXILIARY CHANNEL doit correspondre
au support sur lequel figurent les sauvegardes de la base cible.
• Si les sauvegardes résident sur un disque, vous pouvez allouer plusieurs canaux afin de
réduire la durée du processus de duplication.
• Pour les sauvegardes sur bande, vous pouvez indiquer le nombre de canaux correspondant
au nombre de périphériques disponibles.
L'instance auxiliaire doit être démarrée avec l'option NOMOUNT et la base cible doit être montée ou
ouverte.

Comprendre l'opération de duplication RMAN
Lorsque vous exécutez la commande DUPLICATE, RMAN effectue les
opérations suivantes :
1A. Il crée un fichier de paramètres serveur pour l'instance auxiliaire
(pour la duplication à partir d'une base active ou de sauvegardes
avec connexion à la cible), ou
1B. Il effectue une restauration à partir de sauvegardes (pour la
duplication à partir d'une base de secours ou à partir de sauvegardes
sans connexion à la cible).
2. Il monte la sauvegarde du fichier de contrôle.
3. Pour la duplication basée sur des sauvegardes : Il sélectionne les
sauvegardes à utiliser pour restaurer les fichiers de données sur
4. Il restaure les fichiers de données cible vers la base de données
dupliquée.
5. Il effectue une récupération incomplète à l'aide de toutes les
sauvegardes incrémentielles et de tous les fichiers de journalisation
archivés disponibles.
Lorsque vous exécutez la commande DUPLICATE, RMAN effectue les opérations indiquées dans
la diapositive.
1A. RMAN crée un fichier de paramètres serveur (SPFILE) par défaut pour l'instance auxiliaire
si les conditions suivantes sont remplies :
- La duplication n'implique pas de base de données de secours.
- Les fichiers de paramètres serveur ne sont pas dupliqués.
- L'instance auxiliaire n'est pas démarrée avec un fichier de paramètres serveur.
1B. RMAN effectue une restauration des sauvegardes : toujours pour la base de secours et pour
la duplication à partir de sauvegardes sans connexion à la cible.
2. RMAN monte la sauvegarde de fichier de contrôle restaurée ou copiée à partir de la base de
données active.
3. Pour la duplication basée sur des sauvegardes : RMAN sélectionne dans son référentiel les
sauvegardes à utiliser pour restaurer les fichiers de données sur l'instance auxiliaire.
4. RMAN restaure les fichiers de données à dupliquer et les copie.
5. RMAN effectue une récupération des fichiers de données à l'aide des sauvegarde
incrémentielles et des fichiers de journalisation archivés, jusqu'à un point dans le temps.
Cette récupération est nécessaire, même si aucun point dans le temps n'est défini
explicitement. En effet, les fichiers de journalisation en ligne de la base source ne sont pas
sauvegardés et ne peuvent pas être appliqués à la base de données dupliquée. Le point de
récupération extrême de la base dupliquée correspond au fichier de journalisation archivé le
plus récent de la base source.

Comprendre l'opération de duplication RMAN
Lorsque vous exécutez la commande DUPLICATE,

RMAN effectue les opérations suivantes :
6. Il arrête et redémarre l'instance auxiliaire en mode NOMOUNT.
7. Il crée un nouveau fichier de contrôle qui définit et stocke
le nouveau DBID dans les fichiers de données.
8. Il ouvre la base dupliquée avec l'option RESETLOGS.
9. Il crée les fichiers de journalisation en ligne pour la base
dupliquée.
Remarque : En cas de ré-exécution, le processus de duplication
essaie de reprendre à partir du point de défaillance.
6. RMAN arrête l'instance et la redémarre en mode NOMOUNT.

7. Il crée un nouveau fichier de contrôle qui définit et stocke le nouvel identificateur unique de
base de données DBID dans les fichiers de données de la base dupliquée.
8. Il ouvre la base de données dupliquée avec l'option RESETLOGS.
9. Il crée les fichiers de journalisation en ligne pour la base dupliquée.
Remarque : Si la commande DUPLICATE DATABASE échoue, vous pouvez l'exécuter à
nouveau ; le processus de duplication essaiera de reprendre à partir du point de défaillance.

Indiquer des options pour la commande DUPLICATE
Vous pouvez indiquer les options suivantes avec la commande

DUPLICATE :
Option Objectif
SKIP READONLY Exclure les tablespaces en lecture seule
SKIP TABLESPACE Exclure les tablespaces nommés
TABLESPACE Inclure les tablespaces nommés
NOFILENAMECHECK Empêcher la vérification des noms de fichier
OPEN RESTRICTED Activer automatiquement RESTRICTED SESSION
NOOPEN Laisser la base dupliquée en mode MOUNT
Vous pouvez indiquer des options supplémentaires lorsque vous exécutez la commande
DUPLICATE.
• SKIP READONLY : Permet d'exclure les fichiers de données appartenant aux tablespaces en
lecture seule.
• SKIP TABLESPACE : Permet d'exclure certains tablespaces de la base cible. Vous ne
pouvez pas exclure le tablespace SYSTEM ni les tablespaces contenant des segments
d'annulation (de type undo ou rollback).
• TABLESPACE : Permet d'inclure certains tablespaces de la base cible.
• NOFILENAMECHECK : Permet d'empêcher RMAN de vérifier si des fichiers de données de la
base cible portent le même nom que des fichiers de données de la base dupliquée. Vous
devez indiquer cette option lorsque les fichiers de journalisation et les fichiers de la base
cible et de la base dupliquée utilisent les mêmes noms. En règle générale, cette option est
utilisée lorsque la base dupliquée est créée sur un hôte qui utilise la même configuration de
disque, la même structure de répertoires et les mêmes noms de fichier que l'hôte de la base
cible. Si vous ne précisez pas NOFILENAMECHECK dans cette situation, RMAN renvoie une
erreur.
• OPEN RESTRICTED : Permet d'activer automatiquement RESTRICTED SESSION à
l'ouverture de la base.
• NOOPEN : Permet de terminer l'opération en laissant la base dupliquée en mode MOUNT.
Utilisez cette option avant de :
- changer le suivi des modifications de bloc
- configurer des sauvegardes incrémentielles rapides ou des paramètres de flashback de
base de données
- déplacer la base de données (par exemple, vers ASM)
- mettre à niveau une base de données

Utiliser d'autres options de la commande
DUPLICATE
Option Objectif
NOREDO Signaler à RMAN que l'application des fichiers de

journalisation doit être supprimée lors de la récupération.
Cette option doit être utilisée avec une commande
DUPLICATE "sans cible" lorsque la base cible est en
mode NOARCHIVELOG au moment de la sauvegarde.
Elle peut également être utilisée pour déclarer
explicitement qu'aucun fichier de journalisation archivé ne
doit être appliqué.
UNDO TABLESPACE Cette option doit être précisée lorsque la base cible n'est
pas ouverte et qu'il n'existe aucune connexion au
catalogue de restauration pour que RMAN ne vérifie pas
la présence d'objets détenus par SYS dans le tablespace.
Les options suivantes de la commande DUPLICATE sont des nouveautés de la version Oracle
Database 11g Release 2 :
• NOREDO : L'option NOREDO est utilisée pour signaler à RMAN que les fichiers de
journalisation ne doivent pas être appliqués lors de la phase de récupération de l'opération
de duplication. Elle doit être précisée lorsque la base de données était en mode
NOARCHIVELOG au moment de la sauvegarde ou lorsque les fichiers de journalisation
archivés sont indisponibles lors de l'opération de duplication. Cette option est appropriée si
une base de données dont le mode actuel est ARCHIVELOG est dupliquée jusqu'à un point
dans le temps où elle était en mode NOARCHIVELOG.
Si vous planifiez une opération DUPLICATE "sans cible" et que la base de données est en
mode NOARCHIVELOG, vous devez utiliser l'option NOREDO pour informer RMAN du mode
de la base. En l'absence de connexion à la base de données cible, RMAN ne peut pas
déterminer le mode.
• UNDO TABLESPACE : RMAN vérifie qu'aucun objet appartenant à l'utilisateur SYS ne figure
dans un des tablespaces dupliqués lors d'une duplication partielle de la base. Les
tablespaces SYSTEM, SYSAUX et les tablespaces de segments d'annulation (de type undo)
sont exclus de cette vérification. Cependant, si la base de données cible n'est pas ouverte
et qu'aucun catalogue de restauration n'est utilisé lors de la duplication, RMAN ne peut pas
obtenir les noms des tablespaces d'annulation. Vous devez donc utiliser l'option UNDO
TABLESPACE pour fournir ces noms.

Variables de substitution pour SET NEWNAME
Elément de Description
syntaxe
%b Définit le nom de fichier sans le chemin de répertoire *NOUVEAU*
%f Définit le numéro absolu du fichier de données pour lequel le nouveau

nom est généré
%I Définit l'ID de base de données
%N Définit le nom du tablespace
%U Définit un nom de fichier généré par le système au format suivant :

data-D-%d_id-%I_TS-%N_FNO-%f
RUN
{ SET NEWNAME FOR DATAFILE 1 TO '/oradata1/system01.dbf';
SET NEWNAME FOR DATAFILE 2 TO '/oradata2/sysaux01.dbf';
SET NEWNAME FOR DATAFILE 3 TO '/oradata3/undotbs01.dbf';
SET NEWNAME FOR DATAFILE 4 TO '/oradata4/users01.dbf';
SET NEWNAME FOR TABLESPACE example TO '/oradata5/%b';
DUPLICATE TARGET DATABASE TO dupldb; }
Pour éviter les conflits de noms lors de la restauration vers un autre emplacement, utilisez les
variables de substitution de la commande SET NEWNAME. Indiquez au moins une des variables
de substitution suivantes : %b, %f et %U. %I et %N sont des variables facultatives.
L'exemple utilise la commande SET NEWNAME FOR TABLESPACE pour définir les noms par défaut
avec une variable de substitution, ainsi que des clauses SET NEWNAME explicites.

Quiz
Sélectionnez les affirmations qui sont vraies concernant

la duplication de base de données.
a. La duplication d'une base de données peut s'effectuer
avec ou sans connexion à l'instance auxiliaire.
b. La duplication d'une base de données peut s'effectuer
avec ou sans connexion au catalogue de restauration.
c. La duplication d'une base de données peut s'effectuer
avec ou sans connexion à la cible.
d. La duplication d'une base de données nécessite de
disposer de sauvegardes RMAN.
e. Vous devez toujours recréer les fichiers de contrôle
manuellement sur l'instance auxiliaire.
Réponses : b, c

Synthèse

• énumérer les motifs de création d'une base de données
dupliquée
• choisir une technique de duplication
• dupliquer une base de données à l'aide de RMAN
• utiliser une sauvegarde RMAN pour dupliquer une base
de données
• dupliquer une base de données à partir d'une instance en
cours d'exécution

Présentation de l'exercice :
L'exercice 18-1 consiste à dupliquer une base de données.
orcl rcat
Exemple de
schéma
Système de
fichiers
DUPLICATE TARGET DATABASE TO dbtest

FROM ACTIVE DATABASE
dbtest SPFILE PARAMETER_VALUE_CONVERT
'/u01/app/oracle/oradata/orcl',
Exemple de '/u01/app/oracle/oradata/dbtest',
schéma
'/u01/app/oracle/fast_recovery_area',
'/u01/app/oracle/dbtest_fra', 'ORCL','DBTEST'
SET
Oracle
Net
DB_RECOVERY_FILE_DEST_SIZE='10g‘;.
Dans cet exercice, vous allez cloner une base de données et recourir à des utilitaires pour
configurer une base dupliquée totalement opérationnelle.

Dépanner et régler RMAN

Objectifs

• interpréter les messages générés par RMAN
• appliquer les principes de réglage recommandés
• diagnostiquer les problèmes de performances de RMAN

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

disponibles dans :
• 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 de RMAN en l'absence de catalogue de restauration. Dans Cloud Control, naviguez
ainsi à partir de la page d'accueil de la base de données : Oracle Database > Logs > Alert Logs
Content > Switch to Text Alert Log Contents. Entrez éventuellement des critères de recherche.
Cliquez sur Go pour afficher le contenu du fichier d'alertes.
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). Ce fichier se trouve
dans USER_DUMP_DEST.
Le fichier sbtio.log contient des informations propres au fabricant, écrites par le logiciel de
gestion des supports et stocké dans USER_DUMP_DEST. Notez que ce journal ne contient pas les
erreurs RMAN, ni celles du serveur Oracle.

Utiliser l'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érant une quantité très importante
d'informations, redirigez 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/2001 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ù nombre des messages de la pile d'erreurs ne sont pas utiles pour la
résolution des problèmes, essayez d'identifier les rares erreurs importantes.
• Recherchez les lignes comportant le texte Additional information suivi d'un nombre
entier. Ces lignes indiquent une erreur du gestionnaire de support. L'entier indiqué 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.

Traiter une commande RMAN
Au cours de la phase de compilation, RMAN effectue les étapes

suivantes :
Ces lettres sont reprises
• Identification des fichiers dans les pages suivantes.
• Constitution d'une procédure de travail composée d'instructions
Au cours de la phase d'exécution, RMAN effectue les étapes suivantes :
• Envoi de chaque étape de la procédure de travail à un canal
disponible
– Connexion OCI distincte à la base cible
– Processus en arrière-plan Oracle chargés du déplacement des
données
— Lecture de données : E/S sur disque ou bande
— Traitement de données : copie de tampon, validation, cryptage et
compression
— Ecriture de données : E/S sur disque ou bande
• Surveillance de l'exécution
I) Au cours de la phase de compilation, RMAN identifie les fichiers qui vont intervenir dans la
commande en interrogeant le référentiel de sauvegarde (lequel peut être le catalogue de
restauration ou le fichier de contrôle de la base cible).
P) A l'aide de ces informations, RMAN construit les étapes d'une procédure. Chaque étape est
constituée d'un jeu d'instructions qui sont envoyées par le client RMAN à l'instance cible en
vue d'exécuter des opérations de déplacement de données spécifiques concernant un ou
plusieurs fichiers.
C) Au cours de la phase d'exécution, RMAN envoie chaque étape de la procédure à un canal
disponible.
S) RMAN surveille les canaux qui traitent le travail en parallèle. Au terme de chaque étape,
RMAN envoie l'étape suivante à ce canal. Lorsque toutes les étapes de la procédure ont été
accomplies, l'exécution de la commande est terminée.
• Chaque canal RMAN contient une connexion OCI distincte à la base de données cible.
Chaque canal représente donc aussi un processus en arrière-plan Oracle qui effectue les
tâches de déplacement de données demandées par le client RMAN.
• Le client RMAN n'exécute pas d'opérations d'E/S. Ces tâches relèvent des processus
Oracle chargés des opérations suivantes :
L) Lecture (Un canal lit les données sur disque ou bande et les place dans des tampons
d'entrée d'E/S.)
T) Traitement de données à l'aide des ressources CPU (Un canal copie les blocs depuis
les tampons d'entrée vers les tampons de sortie et leur applique un traitement
supplémentaire : validation, cryptage et/ou compression.)
E) Ecriture (Un canal écrit les blocs provenant des tampons de sortie sur le support de
stockage, à savoir un disque ou une bande.)

Résolution des problèmes avec RMAN
Fichiers
Copies
de données
d'image
Fichier de Catalogue de Eléments de
contrôle restauration
sauvegarde
VALIDATE Données de
RMAN sauvegarde
Sauvegarde sur disque
Sauvegarde
dans le RMAN Sauvegarde
canal SBT avec un
gestionnaire de
Fichiers de
journalisation sbttest support tiers
archivés
Gestion des supports
Base cible (Exemple : Oracle Secure Backup)
Sauvegarde sur bande
Sur certaines plates-formes, Oracle fournit un outil de diagnostic nommé sbttest. Cet utilitaire
effectue un test simple du logiciel de gestion des supports en agissant comme le serveur de base
de données Oracle et en essayant de communiquer avec le gestionnaire de supports.
Utilisez sbttest pour effectuer un test rapide du gestionnaire de supports.
$ORACLE_HOME/bin/sbttest backup_file_name
Lorsque vous entrez sbttest sans le paramètre obligatoire backup_file_name,
la documentation en ligne s'affiche.
Si sbttest renvoie la valeur 0, cela veut dire que le test s'est déroulé sans erreur. Autrement dit,
le gestionnaire de supports est installé correctement et peut accepter un flux de données, puis
renvoyer les mêmes données lorsqu'elles lui sont demandées. Si sbttest renvoie une valeur
différente de zéro, cela indique que le gestionnaire de supports n'est pas installé ou qu'il n'est pas
correctement configuré.

Détecter un problème
• Déterminez les performances de chaque composant

du système.
• Analysez les étapes de lecture et de traitement à l'aide
de la commande BACKUP VALIDATE.
• Analysez les étapes de lecture et de traitement à l'aide
de la commande RESTORE VALIDATE.
Toute procédure de réglage commence par une étape d'analyse. Avez-vous vraiment un
problème qui peut être résolu par un réglage des opérations RMAN ? Pour le savoir, procédez
comme suit :
• Déterminez les performances de chaque composant de votre système. Par exemple, si vous
prenez la vitesse d'une unité de bande, vous allez comparer le débit de données réel d'une
sauvegarde à la vitesse maximum déclarée dans la documentation de cette unité.
• En ce qui concerne les sauvegardes, analysez les étapes de lecture et de traitement à l'aide
de la commande BACKUP VALIDATE. RMAN va effectuer toutes les étapes de la
sauvegarde jusqu'au moment d'écrire les données dans le périphérique de sortie ; les
données seront alors supprimées et rien ne sera écrit. Notez que l'opération VALIDATE
assure la compression si cette option est demandée dans la commande de sauvegarde,
mais pas le cryptage. Si la compression a été incluse dans la commande de sauvegarde,
l'opération BACKUP VALIDATE doit être exécutée d'abord sans compression pour mesurer
la vitesse à laquelle RMAN lit les fichiers d'entrée, puis ré-exécutée avec compression pour
constater les effets de la compression elle-même.
• Dans une opération RESTORE VALIDATE, RMAN effectue toutes les étapes d'une
restauration jusqu'au moment où il est sur le point d'écrire les données restaurées sur le
disque ; ces données sont alors supprimées et rien n'est écrit. Cette méthode est souvent
utilisée pour valider l'intégrité des supports de sauvegarde, mais elle permet également de
diagnostiquer des problèmes de performances dans les opérations de lecture et de
traitement d'une commande RESTORE. RESTORE VALIDATE assure à la fois le décryptage
et la décompression si la sauvegarde a été créée avec ces options.

Identifier les goulets d'étranglement
affectant les performances
1. Interrogez la colonne EFFECTIVE_BYTES_PER_SECOND
de la vue V$BACKUP_ASYNC_IO ou V$BACKUP_SYNC_IO
à la ligne AGGREGATE.
2. Si la valeur de EFFECTIVE_BYTES_PER_SECOND est
inférieure au débit du support de stockage, exécutez
la commande BACKUP VALIDATE pour obtenir des
informations complémentaires.
1. La commande BACKUP VALIDATE peut vous aider à déterminer si le goulet d'étranglement

se situe dans la phase de lecture ou d'écriture. Commencez par interroger la colonne
EFFECTIVE_BYTES_PER_SECOND de la vue V$BACKUP_ASYNC_IO ou
V$BACKUP_SYNC_IO.
2. Si la valeur contenue dans EFFECTIVE_BYTES_PER_SECOND est inférieure au débit
escompté de votre support de stockage, exécutez la commande BACKUP VALIDATE.
BACKUP VALIDATE effectue les mêmes opérations de lecture sur disque qu'une sauvegarde
mais n'exécute aucune E/S vers un périphérique de sortie. Ainsi, en comparant la durée de
vos opérations de sauvegarde à la durée d'exécution de la commande BACKUP VALIDATE,
vous pouvez déterminer si le goulet d'étranglement est dû aux lectures ou aux écritures.

Identifier les goulets d'étranglement affectant
les performances : Phase de lecture
• Si la durée d'exécution de BACKUP VALIDATE est
équivalente à la durée de la sauvegarde réelle, il est
probable que le problème se situe au niveau de la phase
de lecture.
• Appliquez les recommandations appropriées concernant
l'utilisation du multiplexage et des tampons.
• Examinez les fichiers qui occasionnent des "lenteurs" :
recherchez le fichier de données présentant le rapport
LONG_WAITS/IO_COUNT le plus élevé.
– Si vous utilisez ASM, ajoutez des disques et/ou vérifiez
l'équilibrage des disques existants.
– Déplacez le fichier problématique vers un nouveau disque
ou multiplexez-le avec un autre fichier "lent".
Si la durée d'exécution de la commande BACKUP VALIDATE correspond approximativement à la

durée de la sauvegarde réelle, il est fort probable que le goulet d'étranglement se situe au niveau
de la phase de lecture.
Dans ce cas, vous pouvez améliorer les performances de la sauvegarde en réglant le niveau de
multiplexage.
Remarque : Pour plus d'informations sur les réglages utilisant des paramètres de mémoire
tampon, reportez-vous à la note My Oracle Support numéro 1072545.1.

Diagnostiquer un problème intervenant
en phase d'écriture
Pour analyser un processus d'écriture sur disque :
• Créez un fichier de données sur disque et chronométrez
l'opération.
• Appelez la fonction DBMS_BACKUP_RESTORE.SETPARMS
pour interroger le pilote d'écriture.
Pour analyser un processus d'écriture sur disque, qu'il s'agisse d'une opération de sauvegarde ou
de restauration, créez un tablespace contenant un fichier de données sur le disque et notez la
durée de l'opération. Si les mêmes problèmes de performances se produisent, cela veut dire que
vous devez régler les performances Oracle générales vers le périphérique concerné plutôt que
les paramètres propres à RMAN.
Si cette technique ne convient pas, il est possible de recourir à un pilote d'E/S en écriture. Vous
accédez au pilote d'écriture en appelant la fonction DBMS_BACKUP_RESTORE.SETPARMS avec
les paramètres suivants :
• p0 => 6
• p1 => taille de tampon en octets (indiquez NULL ou 0 pour utiliser la valeur par défaut)
• p2 => nombre de tampons (indiquez NULL ou 0 pour utiliser la valeur par défaut)
• p3 => nombre de blocs à écrire
• p4 => taille des blocs en octets (à indiquer obligatoirement, 8192 est un choix pertinent)
• p5 => nom du fichier à écrire
• p6 => 1
Le pilote d'E/S en écriture est également utile lorsque vous réglez la sortie de canaux de disque
en exécutant des commandes avec des tailles et des nombres de tampons variables.

Identifier les goulets d'étranglement affectant les
performances : Phase d'écriture ou de copie
• Si le temps d'exécution de BACKUP VALIDATE est inférieur à la
durée de la sauvegarde réelle, le problème se situe probablement
au niveau de la copie ou de l'écriture sur le périphérique de
stockage.
• Appliquez les recommandations en matière de compression et de
cryptage des sauvegardes :
– Vérifiez que les performances d'une sauvegarde sans compression
évoluent normalement lorsque vous ajoutez des canaux.
– Utilisez le niveau de compression LOW ou MEDIUM.
– Utilisez l'algorithme de cryptage AES128.
• En cas de sauvegarde sur bande, vérifiez les paramètres MML :
– Taille de tampon TCP/IP
– Taille de tampon client/serveur pour la gestion des supports
– Délai d'expiration client/socket
– Matériel du serveur de média, connectivité vers les supports bande
– Activez la compression sur bande (mais pas la compression RMAN)
Si la durée d'exécution de la commande BACKUP VALIDATE est très inférieure à la durée de la

sauvegarde réelle, il est fort probable que le goulet d'étranglement se situe au niveau de l'écriture
sur le périphérique de sortie.
Si vous utilisez la compression, choisissez le niveau LOW ou MEDIUM.
Utilisez l'algorithme de cryptage AES128 en raison de sa moindre consommation en ressources
CPU.

Utiliser des vues dynamiques pour diagnostiquer
les performances de RMAN
Utilisez les vues suivantes pour déterminer où les opérations
de sauvegarde et de restauration RMAN rencontrent des
problèmes de performances :
Vue Utilisation
V$SESSION_LONGOPS Surveiller la progression des sauvegardes et

restaurations
V$BACKUP_SYNC_IO Identifier les goulets d'étranglement

Déterminer si la bande fonctionne en continu lorsque
les E/S sont synchrones
Afficher la progression détaillée des travaux de
sauvegarde
V$BACKUP_ASYNC_IO Identifier les goulets d'étranglement

Déterminer le débit d'E/S asynchrones
Si vous constatez des problèmes de lenteur d'exécution dans les travaux de sauvegarde et de
restauration, vous pouvez commencer votre analyse à l'aide des vues indiquées dans la
diapositive ci-dessus. La suite du chapitre fournit des informations plus détaillées sur ces vues.

Surveiller la progression des travaux RMAN
Interrogez la vue V$SESSION_LONGOPS pour surveiller la

progression des opérations de sauvegarde et de restauration.
SQL> SELECT SID,SERIAL#,CONTEXT,SOFAR,TOTALWORK,

2 ROUND(SOFAR/TOTALWORK*100,2) "%_COMPLETE"
3 FROM V$SESSION_LONGOPS
4 WHERE OPNAME LIKE 'RMAN%'
5 AND OPNAME NOT LIKE '%aggregate%'
6 AND TOTALWORK != 0
7 AND SOFAR <> TOTALWORK;
SID SERIAL# CONTEXT SOFAR TOTALWORK %_COMPLETE

--- ------- ------- ------- --------- ----------
13 75 1 9470 15360 61.65
12 81 1 15871 28160 56.36
Surveillez la progression des opérations de sauvegarde, de copie et de restauration en

interrogeant la vue V$SESSION_LONGOPS. RMAN utilise les lignes de détail et les lignes
agrégées de cette vue. Les lignes de détail décrivent les fichiers traités au cours d'une étape de
travail spécifique. Les lignes agrégées décrivent les fichiers qui sont traités dans toutes les étapes
d'une commande RMAN. Une étape de travail correspond à la création ou la restauration d'un jeu
de sauvegarde ou d'une copie de fichier de données. Les lignes de détail sont mises à jour avec
chaque mémoire tampon (buffer) faisant l'objet d'une lecture ou d'une écriture lors de la
sauvegarde, de sorte que la granularité des mises à jour est fine. Les lignes agrégées sont mises
à jour à la fin de chaque étape d'un travail ; le niveau de détail est donc plus grossier.
Remarque : Affectez au paramètre STATISTICS_LEVEL la valeur TYPICAL (valeur par défaut)
ou ALL pour alimenter la vue V$SESSION_LONGOPS.
Les colonnes de la vue V$SESSION_LONGOPS qui sont pertinentes pour RMAN sont décrites ci-
après :
• OPNAME : Description textuelle de la ligne. Les lignes de détail indiquent notamment s'il
s'agit d'une copie RMAN de fichier(s) de données, d'une sauvegarde complète RMAN de
fichier(s) de données ou d'une restauration complète RMAN de fichier(s) de données.
• CONTEXT : Pour les lignes de sortie de sauvegarde, cette colonne contient la valeur 2. Pour
toutes les autres lignes à l'exception des copies proxy (qui n'entraînent pas la mise à jour de
cette colonne), la valeur est 1.

SOFAR :
• Pour les copies d'image, il s'agit du nombre de blocs qui ont été lus.
• Pour les lignes d'entrée de sauvegarde, il s'agit du nombre de blocs qui ont été lus à partir des
fichiers en cours de sauvegarde.
• Pour les lignes de sortie de sauvegarde, il s'agit du nombre de blocs qui ont été écrits dans
l'élément de sauvegarde.
• Pour les opérations de restauration, il s'agit du nombre de blocs qui ont été traités vers les
fichiers en cours de restauration dans l'étape de travail considérée.
• Pour les copies proxy, il s'agit du nombre de fichiers qui ont été copiés.
TOTALWORK :
• Pour les copies d'image, il s'agit du nombre total de blocs du fichier.
• Pour les lignes d'entrée de sauvegarde, il s'agit du nombre total de blocs à lire à partir de tous
les fichiers traités dans l'étape de travail considérée.
• Pour les lignes de sortie de sauvegarde, la valeur est 0 parce que RMAN ne sait pas combien
de blocs il va devoir écrire dans chaque élément de sauvegarde.
• Pour les opérations de restauration, il s'agit du nombre total de blocs (tous fichiers confondus)
restaurés dans cette étape du travail.
• Pour les copies proxy, il s'agit du nombre total de fichiers à copier dans cette étape du travail.

Identifier les goulets d'étranglement en matière
de sauvegarde et de restauration
• Vous pouvez utiliser les vues suivantes pour déterminer
la source des goulets d'étranglement et pour afficher la
progression des travaux de sauvegarde :
– V$BACKUP_SYNC_IO
– V$BACKUP_ASYNC_IO
• Ces vues comprennent les lignes suivantes, pour une
sauvegarde comme pour une restauration :
– Une ligne pour chaque fichier de données
– Une ligne agrégée pour plusieurs fichiers de données
– Une ligne pour chaque élément de sauvegarde
La vitesse de sauvegarde maximale est limitée par le matériel disponible. Il n'est pas possible de
sauvegarder plus rapidement que ne le permet la bande passante cumulée de la bande. La seule
exception est le cas où les fichiers de données comportent de nombreux blocs vides qui n'ont pas
besoin d'être sauvegardés.
Le composant du système de sauvegarde qui constitue un goulet d'étranglement dépend de la
vitesse du disque, du lecteur de bande et des autres composants de transport tels que le réseau.
Par exemple, si le goulet d'étranglement se situe au niveau du lecteur de bande mais que la
transmission est continue, il n'est pas possible d'accélérer la sauvegarde.

Goulets d'étranglement liés aux E/S asynchrones
• Utilisez la vue V$BACKUP_ASYNC_IO pour surveiller les

E/S asynchrones.
• Le fichier qui présente le rapport LONG_WAITS /
IO_COUNT le plus élevé constitue probablement le goulet
d'étranglement.
– IO_COUNT est le nombre d'E/S réalisées sur le fichier
– LONG_WAITS est le nombre de fois où le processus de
sauvegarde/restauration a ordonné au système d'exploitation
d'attendre la fin d'une opération d'E/S
• Pour éviter les goulets d'étranglement, les temps d'attente
doivent être nuls.
– SHORT_WAIT_TIME_TOTAL
– LONG_WAIT_TIME_TOTAL
Vous pouvez utiliser la vue V$BACKUP_ASYNC_IO pour surveiller les E/S asynchrones.
La colonne LONG_WAITS affiche le nombre de fois où le processus de sauvegarde ou de
restauration a ordonné au système d'exploitation d'attendre la fin d'une opération d'E/S.
La colonne SHORT_WAITS indique le nombre de fois où le processus de sauvegarde/restauration
a demandé au système d'exploitation d'être informé de la fin d'une E/S en mode non bloquant.
Sur certaines plates-formes, l'implémentation d'E/S asynchrones peut conduire le processus
appelant à attendre la fin de l'E/S pendant une interrogation d'E/S en mode non bloquant.
Le moyen le plus simple pour identifier un goulet d'étranglement consiste à interroger la vue
V$BACKUP_ASYNC_IO afin de connaître le fichier de données présentant le rapport LONG_WAITS
sur IO_COUNT le plus élevé.

Goulets d'étranglement au niveau des E/S synchrones
• Les E/S synchrones sont considérées comme un goulet

d'étranglement.
• Interrogez la colonne DISCRETE_BYTES_PER_SECOND
de la vue V$BACKUP_SYNC_IO pour connaître le débit
des E/S.
– Comparez cette valeur au débit maximum du périphérique.
– Si elle est inférieure au débit indiqué pour le périphérique,
il existe une possibilité de réglage.
Lorsque vous utilisez des E/S synchrones, il est facile de déterminer le temps nécessaire aux
travaux de sauvegarde car les périphériques effectuent une seule opération d'E/S à la fois. Les
E/S Oracle utilisent un mécanisme d'interrogation plutôt qu'un mécanisme d'interruption pour
déterminer à quel moment chaque demande d'E/S se termine. Dans la mesure où le processus
de sauvegarde ou de restauration n'est pas immédiatement informé de l'exécution des E/S par le
système d'exploitation, vous ne pouvez pas déterminer la durée de chaque opération d'E/S.
Utilisez la vue V$BACKUP_SYNC_IO pour identifier l'origine des goulets d'étranglement de
sauvegarde ou de restauration et pour évaluer la progression des travaux de sauvegarde. Cette
vue contient des lignes lorsque les E/S sont synchronisées avec le processus (ou le thread, sur
certaines plates-formes) qui effectue la sauvegarde.

Régler les performances des sauvegardes RMAN
Pour régler les performances de RMAN en matière de

sauvegarde :
1. Supprimez le paramétrage RATE des canaux configurés
et des canaux alloués.
2. Si vous utilisez des E/S disque synchrones, définissez
le paramètre DBWR_IO_SLAVES.
3. Définissez le paramètre d'initialisation LARGE_POOL_SIZE.
4. Réglez les phases de lecture, d'écriture et de copie de
RMAN.
1. Supprimez le paramétrage RATE des canaux configurés et des canaux alloués. Ce

paramètre sert à définir le nombre maximum d'octets (par défaut), de kilo-octets (K), de
mégaoctets (M) ou de gigaoctets (G) que RMAN peut lire par seconde sur le canal. Il limite
le nombre d'octets lus pour que RMAN n'utilise pas une quantité excessive de bande
passante de disque, ce qui nuirait aux performances. Si la sauvegarde n'est pas effectuée
en continu sur bande, vérifiez que le paramètre RATE n'est pas défini dans la commande
ALLOCATE CHANNEL ou CONFIGURE CHANNEL.
2. Si vous utilisez des E/S disque synchrones, définissez le paramètre DBWR_IO_SLAVES. Si
votre disque ne prend pas en charge les E/S asynchrones, essayez d'affecter au paramètre
d'initialisation DBWR_IO_SLAVES une valeur différente de zéro. Toute valeur non nulle de de
DBWR_IO_SLAVES entraîne l'utilisation d'un nombre fixe (quatre) d'esclaves d'E/S disque
pour la sauvegarde et la restauration, ce qui revient à simuler des E/S asynchrones.
Lorsque des esclaves d'E/S sont utilisés, ils obtiennent les tampons correspondants en
mémoire SGA. Si la zone de mémoire LARGE POOL est configurée, elle est utilisée. Sinon,
c'est la zone de mémoire partagée qui est utilisée.
Remarque : Si vous définissez le paramètre DBWR_IO_SLAVES, des processus esclaves
seront utilisés également pour l'écriture dans la base de données. Vous risquez de devoir
augmenter la valeur du paramètre d'initialisation PROCESSES.
3. En cas d'échec de l'allocation de mémoire partagée, définissez le paramètre d'initialisation
LARGE_POOL_SIZE comme indiqué sur la page suivante.
4. Réglez les phases de lecture, d'écriture et de copie de RMAN.

Exécution en parallèle de jeux de sauvegarde
Pour optimiser les performances, allouez plusieurs canaux et

affectez les fichiers à des canaux spécifiques.
Fichier de Fichier de Fichier de

données 1 données 4 données 5 Canal
MML Elément de sauvegarde 1


Vous pouvez configurer des sauvegardes en parallèle en attribuant à l'option PARALLELISM de la

commande CONFIGURE une valeur supérieure à 1 ou en allouant manuellement plusieurs
canaux. RMAN s'exécute alors en parallèle et écrit plusieurs jeux de sauvegarde en parallèle. Les
sessions serveur distribuent le travail de sauvegarde des fichiers désignés.
Exemple
RMAN> RUN {
2> ALLOCATE CHANNEL c1 DEVICE TYPE sbt;
5> BACKUP
6> INCREMENTAL LEVEL = 0
7> (DATAFILE 1,4,5 CHANNEL c1)
8> (DATAFILE 2,3,9 CHANNEL c2)
9> (DATAFILE 6,7,8 CHANNEL c3);
10> SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT';
11> }

Lors de la sauvegarde de fichiers de données, vous pouvez désigner les fichiers à sauvegarder
en indiquant leur chemin ou leur numéro. Par exemple, les deux commandes suivantes effectuent
la même opération :
BACKUP DEVICE TYPE sbt DATAFILE '/home/oracle/system01.dbf';
BACKUP DEVICE TYPE sbt DATAFILE 1;
Lorsque vous créez plusieurs jeux de sauvegarde et que vous allouez plusieurs canaux, RMAN
s'exécute automatiquement en parallèle et écrit plusieurs jeux de sauvegarde en parallèle. Les
sessions serveur allouées partagent le travail de sauvegarde des fichiers de données, des fichiers
de contrôle et des fichiers de journalisation archivés désignés. Notez que vous ne pouvez pas
répartir (stripe) un même jeu de sauvegarde sur plusieurs canaux.
L'exécution en parallèle des jeux de sauvegarde nécessite les opérations suivantes :
• Affecter à l'option PARALLELISM une valeur supérieure à 1 ou allouez plusieurs canaux.
• Indiquer un grand nombre de fichiers à sauvegarder.
Exemple
• Il y a neuf fichiers à sauvegarder (fichiers de données 1 à 9).
• Affectez les fichiers de données à des jeux de sauvegarde de telle sorte que tous les jeux
contiennent approximativement le même nombre de blocs de données (pour des raisons
d'efficacité).
- Les fichiers de données 1, 4 et 5 sont affectés au jeu de sauvegarde 1.
Remarque : Vous pouvez également utiliser le paramètre FILESPERSET pour limiter le nombre
de fichiers de données inclus dans un jeu de sauvegarde.

Définir le paramètre LARGE_POOL_SIZE
• Si le paramètre LARGE_POOL_SIZE n'est pas défini,
le serveur Oracle tente d'obtenir de la mémoire à partir
de la zone de mémoire partagée.
• Si la valeur du paramètre LARGE_POOL_SIZE n'est pas
suffisante, le serveur n'alloue pas de mémoire tampon
à partir de la zone de mémoire partagée.
• Si le serveur ne peut pas obtenir suffisamment de
mémoire, il alloue des tampons à partir de la mémoire
des processus locaux.
• Le serveur Oracle écrit un message dans le fichier
d'alertes pour signaler que des E/S synchrones sont
utilisées pour la sauvegarde en cours.
ksfqxcre: failure to allocate shared memory means sync
I/O will be used whenever async I/O to file not
supported natively
Les demandes d'allocation de mémoire contiguë à partir de la zone de mémoire partagée sont
faibles, avec une taille généralement inférieure à 5 kilo-octets (K). Il peut arriver qu'une demande
plus volumineuse échoue ou nécessite des opérations importantes de gestion interne en vue de
libérer la mémoire contiguë requise. La zone de mémoire LARGE POOL est parfois capable de
répondre à ces besoins. Cette zone de mémoire ne possède pas de liste LRU (Least Recently
Used), de sorte que le serveur Oracle n'essaie pas d'en éliminer les parties obsolètes.
Pour configurer la zone de mémoire LARGE POOL, utilisez le paramètre d'initialisation
LARGE_POOL_SIZE. Interrogez la vue V$SGASTAT.POOL pour savoir dans quelle zone de
mémoire (LARGE POOL ou SGA) réside la mémoire d'un objet. La valeur suggérée pour
LARGE_POOL_SIZE est calculée comme suit :
#_of_allocated_channels * (16 MB + (4*size_of_tape_buffer ))
Pour les sauvegardes sur disque, la mémoire tampon de bande est forcément de 0. Vous devez
donc affecter au paramètre LARGE_POOL_SIZE la valeur 16 Mo. Pour les sauvegardes sur
bande, la taille d'une mémoire tampon de bande est définie par le paramètre de canal RMAN
BLKSIZE, dont la valeur par défaut est de 256 ko. Supposons que vous procédiez à une
sauvegarde sur deux lecteurs de bande. Si la taille de tampon de bande est de 256 ko, affectez
au paramètre LARGE_POOL_SIZE la valeur 34 MB. Si vous portez la valeur de BLKSIZE
à 512 KB, augmentez celle de LARGE_POOL_SIZE jusqu'à 36 MB.
Remarque : La zone de mémoire LARGE POOL est uniquement utilisée pour les mémoires
tampons de disque lorsque DBWR_IO_SLAVES > 0 et pour les mémoires tampons de bande
lorsque BACKUP_TAPE_IO_SLAVES = TRUE. Si vous utilisez ASMM (Automatic Shared Memory
Management), la taille de la zone de mémoire LARGE POOL est automatiquement ajustée en
fonction de la charge globale du système.

Multiplexage RMAN
• Niveau de multiplexage : nombre maximum

de fichiers lus par un canal à un moment
donné de la sauvegarde
– Min (MAXOPENFILES, FILESPERSET)
– La valeur par défaut de MAXOPENFILES est 8.
– La valeur par défaut de FILESPERSET est 64.
• MAXOPENFILES détermine le nombre et
la taille des tampons d'entrée.
– Tous les tampons sont alloués à partir de la
mémoire PGA, sauf si des processus esclaves
d'E/S (disque ou bande) sont activés.
RMAN utilise deux types de mémoire tampon pour les E/S : les mémoires tampons de disque et
les mémoires tampons de bande. Le multiplexage RMAN détermine la façon dont RMAN alloue
les mémoires tampons de disque. Il définit le nombre de fichiers d'une sauvegarde qui sont lus
simultanément puis écrits dans un même élément de sauvegarde.
Le degré de multiplexage dépend du paramètre FILESPERSET de la commande BACKUP, mais
aussi du paramètre MAXOPENFILES de la commande CONFIGURE CHANNEL ou ALLOCATE
CHANNEL.
Remarque : Le multiplexage RMAN est défini au niveau canal. Pour les systèmes ASM et RAID1,
affectez à MAXOPENFILES la valeur 1 ou 2.

Multiplexage RMAN
• Pour les lectures :
Niveau de multiplexage Règle d'allocation
Niveau <= 4 Des tampons de 1 Mo sont alloués de telle sorte que la taille
totale de mémoire tampon pour tous les fichiers d'entrée soit
de 16 Mo.
4 < Niveau <= 8 512 kilo-octets sont alloués de telle sorte que la taille totale de
mémoire tampon pour tous les fichiers soit inférieure à 16 Mo.
Niveau > 8 RMAN alloue quatre tampons sur disque de 128 ko chacun
par canal, de telle sorte que la taille totale de la mémoire
tampon soit de 512 ko par canal pour chaque fichier.
• Pour les écritures, chaque canal reçoit quatre tampons

de résultats de 1 Mo chacun.
Supposons que vous sauvegardiez deux fichiers de données avec un seul canal. Vous affectez à
FILESPERSET la valeur 3 et à MAXOPENFILES la valeur 8. Dans ce cas, le nombre de fichiers de
chaque jeu de sauvegarde est 2 (la plus petite valeur entre FILESPERSET et le nombre de
fichiers lus par chaque canal) et le niveau de multiplexage est 2 (la plus petite valeur entre
MAXOPENFILES et le nombre de fichiers dans chaque jeu de sauvegarde). Lorsque RMAN
procède à une sauvegarde à partir du disque, il utilise l'algorithme décrit dans le tableau présenté
dans la diapositive.
Pour les écritures, chaque canal alloue quatre tampons de sortie de 1 Mo chacun.
Ces mémoires tampon sont allouées à partir de la mémoire PGA, sauf si DBWR_IO_SLAVES a
une valeur différente de zéro.
Remarque : Pour optimiser les performances des opérations de restauration, n'affectez pas au
paramètre FILESPERSET une valeur supérieure à 8.

Performances de restauration et de récupération :
Recommandations
• Réduisez le nombre de fichiers de journalisation archivés
à appliquer en utilisant des sauvegardes incrémentielles.
• Utilisez la restauration physique de bloc pour remédier
à des corruptions de bloc isolées.
• Conservez un nombre approprié de journaux archivés
sur disque.
• Augmentez l'utilisation de la mémoire tampon RMAN.
• Réglez la base de données en fonction des E/S,
des performances des processus d'écriture DBWR et
de l'utilisation des ressources CPU.
La diapositive ci-dessus présente des recommandations visant à améliorer les performances des
opérations de restauration et de récupération.

Quiz
Sélectionnez les propositions correctes concernant

le multiplexage RMAN.
a. Le multiplexage RMAN définit le nombre de fichiers d'une
sauvegarde qui sont lus simultanément puis écrits dans
un même élément de sauvegarde.
b. Le degré de multiplexage dépend du paramètre
FILESPERSET de la commande BACKUP, mais aussi du
paramètre MAXOPENFILES de la commande CONFIGURE
CHANNEL ou ALLOCATE CHANNEL.
c. Le multiplexage RMAN n'est pas défini au niveau canal.
Réponse : a, b

Synthèse

• diagnostiquer les problèmes de performances de RMAN
• appliquer les principes de réglage recommandés

Aucun exercice
Préparation 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
Ce chapitre ne comprend pas d'exercice, mais le formateur va vous expliquer comment préparer
l'atelier.

Présentation de l'atelier

Objectifs
Cet atelier vous apprend à effectuer les tâches suivantes :

• Configurer votre base de données pour répondre à
des besoins métier définis
• Réaliser les sauvegardes requises en fonction de ces
besoins
• Procéder à la récupération de votre base de données à
la suite de différents scénarios de défaillance
Pour vous aider dans ces tâches, utilisez le support de cours, les vidéos conseillées, vos notes
personnelles et les documents suivants :
• Oracle Database Backup and Recovery User’s Guide
• Oracle Database Backup and Recovery Reference

Structure et démarche de l'atelier
• Structure interactive basée sur le travail de groupe
• Scénarios de défaillance variés
• Sessions intensives de diagnostic et de résolution
de problèmes
– Utilisation d'outils et de vues permettant de déterminer l'état
de la base de données et d'obtenir des informations utiles
pour la résolution des problèmes
– Examen des fichiers journaux et des fichiers trace
• Solutions fournies sous forme de plan général d'action
Travail de groupe, structure interactive

L'atelier est organisé de façon à permettre aux participants de travailler en groupe pour effectuer
des opérations de sauvegarde, de restauration et de récupération de la base de données.
Chaque groupe est invité à partager son approche des problèmes proposés avec les autres
groupes.
Scénarios de défaillance
Pendant l'atelier, le formateur introduit divers problèmes dans la base de données. Vous pouvez
ainsi être confronté aux types de défaillance suivants :
• Perte d'un groupe de fichiers de journalisation
• Perte de fichiers de données
• Perte de fichiers de contrôle
• Défaillances physiques
• Corruption de blocs de données
• Erreur de l'utilisateur

Pratique intensive du diagnostic et de la résolution de problèmes
La section "atelier" de ce cours vise à vous faire acquérir une expérience pratique solide en vous
proposant de traiter différents scénarios de défaillance et de récupération. Les connaissances
théoriques et pratiques que vous avez accumulées pendant les deux premières journées de
formation vous seront utiles pour analyser correctement les scénarios de défaillance proposés par
l'atelier et pour récupérer efficacement la base de données.
Utilisez judicieusement les outils de diagnostic, les vues du dictionnaire de données et les vues V$
disponibles pour déterminer l'état de votre base de données et pour établir le diagnostic
des défaillances.
Solutions génériques
Cet atelier simule un environnement d'exploitation réaliste et ne fournit que des instructions
générales pour vous amener à résoudre les différents scénarios de défaillance. Au besoin,
vous pouvez vous reporter aux exposés théoriques du cours, à la documentation Oracle et
aux bulletins d'informations disponibles sur le site Oracle Worldwide Support.

Exigences associées à la base de données de l'atelier
Exigence Options de configuration
Disponibilité 24 heures sur 24, 7 jours sur 7
Fenêtre de maintenance de 8 heures, une

fois par mois
Sollicitation de la base variable en fonction

des fuseaux horaires
Pas de perte de données en cas de

défaillance
Tenez compte des exigences répertoriées dans la diapositive ci-dessus lorsque vous configurez
la base de données pour l'atelier pratique concluant ce cours.

Diagnostiquer les défaillances
1. Analysez la nature de la défaillance à l'aide de tous
les outils dont vous disposez : vues, fichiers trace,
fichiers journaux, commandes du système d'exploitation,
Enterprise Manager.
2. Déterminez si l'instance de base de données est
disponible et si la base est ouverte.
3. Essayez de démarrer l'instance de base de données.
4. Consultez le fichier d'alertes et les fichiers de trace.
5. Déterminez la méthode de récupération appropriée.
6. Si vous avez besoin d'informations supplémentaires,
consultez le plan de résolution proposé pour
le scénario correspondant dans le Manuel
d'activités.
Les étapes énoncées dans la diapositive décrivent la méthodologie générale à suivre pour
diagnostiquer les défaillances d'une base de données. Après avoir déterminé les causes
possibles de dysfonctionnement, vous pouvez vous reporter aux plans de résolution décrits dans
le Manuel d'activités pour plus d'informations.

Synthèse
Cet atelier vous a permis d'effectuer les tâches suivantes :

• Configurer votre base de données pour répondre à
des besoins métier définis
• Réaliser les sauvegardes requises en fonction de
ces besoins
• Procéder à la récupération de votre base de données
à la suite de différents scénarios de défaillance

Recherches personnelles

Présentation
Cette annexe fournit les références suivantes :

• Fiches aide-mémoire :
– Commandes DOS/Unix
– Editeur vi
• Options de formation complémentaire
• Autres ressources personnalisées
Cette annexe fournit quelques listes "aide-mémoire" qui peuvent être utiles au cours de cette
formation.
Elle présente également des options de formation ultérieure.
Votre formateur aura peut-être des suggestions à ajouter.
Pour plus d'informations sur l'utilisation d'Enterprise Manager Cloud Control, consultez l'annexe B
de ce cours.
Oracle Database 12c : Backup and Recovery Workshop A - 2

Petit abrégé des commandes DOS/UNIX
DOS UNIX Anglais
dir ll liste longue (nom, date, taille, propriétaire, etc.)
dir/w ls liste générique (pas de détails)
dir/s locate rechercher un fichier n'importe où
del rm supprimer ou retirer des fichiers
copy cp copier un fichier sur un autre
move mv déplacer un fichier vers un autre
ren mv renommer un fichier
cd pwd afficher le répertoire actif
cd .. cd .. passer dans le répertoire immédiatement supérieur
cd \ cd / passer dans le répertoire racine
C-A-D ps -ef traiter les statistiques (souvent avec grep)
top liste dynamique des processus les plus consommateurs
de ressources en pourcentage
md mkdir créer un répertoire
rd rmdir supprimer un répertoire
edit vi éditeur en mode caractères et plein écran (voir plus bas)
more more interrompre l'analyse d'un fichier (espace/entrée pour continuer)
tail -20 file1 afficher les 20 dernières lignes d'un fichier
type cat lister un fichier sans faire de pause
strings identique à cat mais pour des fichiers avec car. binaires
set set afficher toutes les variables d'environnement, notamment $HOME
help man pages (d'aide) manuelles
find grep rechercher un mot dans une ligne parmi une liste de lignes
prompt PS1='$PWD >' modifier l'invite pour inclure le répertoire en cours
logoff su - basculer vers un autre utilisateur (super-utilisateur généralement)
chkdsk df -h afficher la quantité d'espace disque disponible (en Go)
(n/a) which file1 rechercher les fichiers exécutables dans les chemins indiqués
ver uname –a version du logiciel d'exploitation du système
Rappels importants : La distinction entre majuscules et minuscules est importante dans UNIX.
Pour basculer vers un répertoire dont le nom est très long, tapez "cd Rea*".

Gedit
gedit est un éditeur wysiwyg. La première fois que vous l'exécutez, vous devez préciser la valeur
de & :
gedit filename &
Ensuite, vous pouvez utiliser simplement :
gedit filename
Commandes vi
Commande Description
:wq écrire, quitter
:q! quitter sans enregistrer
[esc] sortir du mode en cours pour passer en mode de commande
a ajouter un mode
A ajouter un mode à la fin de la ligne en cours
dd supprimer la ligne en cours
i mode d'insertion (peut également insérer des retours à la ligne)
o insérer une ligne vierge sous le curseur
p coller le contenu de la mémoire tampon après le curseur
r remplacer un seul caractère
:s/a/b/ remplacer "a" par "b"
. répéter la dernière substitution
u annuler les effets de la dernière modification
Y copier la ligne en cours
x supprimer un caractère
dd supprimer toute la ligne

Menus Enterprise Manager Database Express
http://<hostname>:<port>em
Entrez votre URL, puis un nom utilisateur et un mot de passe Oracle valides.
• Pour afficher le nom d'hôte dans Linux : hostname --long
• Le numéro de port par défaut est 5500.
• Dans les environnements de cours Oracle, vous pouvez utiliser le nom utilisateur SYS et le
mot de passe indiqué par le formateur, puis sélectionner as sysdba.
La diapositive ci-dessus présente les menus proposés par Enterprise Manager Express dans les
domaines suivants :
• Configuration
• Stockage
• Sécurité
• Performances

Traitement des requêtes dans EM Express
Servlet EM Express
• Authentifie et valide la
requête
Serveur Web Oracle • Traite la requête en
exécutant les
Servlet EM interrogations requises
Navigateur Express dans la base de
Web données
• Ecrit les résultats dans
le flux des réponses
Serveurs partagés
Requête Processus Répartiteur

Répartiteur
d'écoute
La diapositive ci-dessus fournit un aperçu du traitement des requêtes par EM Express.

Oracle SQL Developer : Connexions
Effectuer des opérations d'administration de base
de données dans le navigateur DBA à l'aide
de connexions DBA :
Oracle SQL Developer est un outil graphique autonome qui permet d'examiner et de développer
des objets de schéma de base de données, mais aussi d'exécuter des tâches d'administration de
base de données.
SQL Developer permet aux utilisateurs bénéficiant de privilèges d'administrateur de base de
données (DBA) d'afficher et de modifier certaines informations concernant les DBA et de réaliser
des opérations de DBA. Pour effectuer des opérations de DBA, vous utilisez le navigateur DBA
qui, comme le navigateur Connections, comprend des noeuds pour toutes les connexions de
base de données définies. Si le navigateur DBA n'est pas visible, sélectionnez View, puis DBA.
Vous ne pouvez ajouter que des connexions pour lesquelles l'utilisateur de base de données
associé a des privilèges de DBA ou au moins des privilèges autorisant les opérations voulues du
navigateur DBA sur la base concernée.

Oracle SQL Developer : Actions de DBA
Effectuer des tâches de DBA à l'aide du navigateur DBA :
Les opérations DBA suivantes sont possibles :

• Démarrage/arrêt d'une base de données pluggable
• Configuration d'une base de données : paramètres d'initialisation, gestion automatique de
l'annulation (undo), propriétés de la base, points de restauration, affichage de l'utilisation
des fonctionnalités de la base
• Affichage du statut de la base de données
• Travaux d'export et d'import Data Pump
• Actions de sauvegarde/récupération RMAN
• Configuration du gestionnaire de ressources
• Configuration du planificateur
• Configuration de la sécurité : paramètres d'audit, profils, rôles, utilisateurs
• Configuration du stockage des journaux archivés, des fichiers de contrôle, des fichiers de
données, des groupes de fichiers de journalisation, des tablespaces, des groupes de
tablespaces temporaires

Autres ressources pour approfondir votre formation
• Documentation
• Oracle Technology Network (OTN)
– Oracle Database > High Availability
– Communautés Oracle sur Social Applications
• Cours de formation Oracle University
• Cours d'autoformation Oracle University
• Oracle Learning Library (OLL)
• My Oracle Support (MOS)
• Vidéos YouTube sur le canal Oracle Learning
Documentation :
• Oracle Database Backup and Recovery User’s Guide
• Oracle Database Backup and Recovery Reference
Oracle Technology Network (OTN) : http://www.oracle.com/technetwork/index.html
Cours de formation Oracle University :
• Oracle Database 12c: Managing Multitenant Architecture
• Oracle Database 12c: RAC Administration
• Oracle Database 12c: Data Guard Administration
• Oracle Database 12c: Security
• Oracle Enterprise Manager Cloud Control 12c: Advanced Configuration Workshop
• Oracle Database 12c: Performance Tuning
Cours d'autoformation Oracle University : Oracle Database 12c New Features series
Oracle Learning Library (OLL) : https://www.oracle.com/goto/oll
Effectuez une recherche sur le sujet qui vous intéresse, par exemple MAA (Maximum Availability
Architecture).

Informations complémentaires
Pour obtenir des informations sur les sujets qui ne sont pas
traités dans ce cours, reportez-vous aux sources suivantes :
• Autres cours dispensés par des formateurs Oracle
University sur Oracle Database 12c
• Cours d'autoformation Oracle Database 12c: New Features
– Série complète de cours d'autoformation en ligne décrivant en
détail toutes les nouvelles fonctionnalités
– Démonstrations correspondant à tous les sujets traités dans
les cours en ligne :
http://www.oracle.com/goto/oll
• Séries OBE (Oracle By Example) : Oracle Database 12c
– http://www.oracle.com/technology/obe/demos/admin/demos.html
– http://www.oracle.com/technology/obe/start/index.html
• Evénements Oracle OpenWorld
– http://www.oracle.com/openworld/index.html
Pour obtenir des informations sur les sujets qui ne sont pas traités dans ce cours, reportez-vous
aux sources suivantes :
• Cours dispensés par des formateurs Oracle University sur Oracle Database 12c
• Cours d'autoformation en ligne Oracle Database 12c: New Features
• Séries OBE (Oracle By Example) : Oracle Database 12c
• Evénements Oracle OpenWorld

Cours ILT Oracle University recommandés
• Enterprise Manager Cloud Control

– Using Oracle Enterprise Manager Cloud Control 12c
– Oracle Enterprise Manager Cloud Control 12c: Install and
Upgrade
– Oracle Enterprise Manager Cloud Control 12c: Advanced
Configuration
– Oracle Enterprise Manager Cloud Control 12c: Cloud
Management workshop
• Installation et mise à niveau
– Oracle Database 12c: Install and Upgrade workshop
Cours complémentaires recommandés

Pour plus d'informations sur les principales technologies de cloud computing utilisées par les
produits Oracle et sur les autres nouveautés d'Oracle Database, suivez l'un des cours
complémentaires proposés par Oracle University.

Cours ILT Oracle University recommandés
• Real Application Cluster

– Oracle Database 12c: High Availability New Features Ed 1.
– Oracle Database 12c: Manage Clusterware Workshop
– Oracle Database 12c: Manage ASM Workshop
– Oracle Database 12c: RAC Administration Workshop
• Sécurité
– Oracle Database 12c: Security
• Performances
– Oracle Database 12c: Performance Tuning Workshop
• Exadata
– Exadata Database Machine Administration Workshop Ed1
Cours complémentaires recommandés

Pour plus d'informations sur les principales technologies de cloud computing utilisées par les
produits Oracle et sur les autres nouveautés d'Oracle Database, suivez l'un des cours
complémentaires proposés par Oracle University.

Utiliser Enterprise Manager Cloud Control

Objectifs

• décrire les différents composants de Cloud Control
• décrire l'architecture de Cloud Control
• énoncer les types de cible gérés par Cloud Control
• utiliser l'interface d'Oracle Enterprise Manager Cloud
Control
Remarque : Pour bien comprendre l'installation et l'utilisation d'Oracle Enterprise Manager Cloud
Control et de Database Express, reportez-vous aux manuels suivants dans la documentation
Oracle :
• Oracle Enterprise Manager Cloud Control Basic Installation Guide 12c Release 1
• Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide
12c Release 1
• Oracle Enterprise Manager Cloud Control Administrator’s Guide 12c Release 1
• Oracle Enterprise Manager Licensing Information 12c Release 1
Oracle Database 12c : Backup and Recovery Workshop B - 2

Principaux challenges pour les administrateurs
Les problèmes posés aux administrateurs augmentent avec

l'élargissement des centres de données à l'environnement de
cloud. Les principales difficultés à surmonter pour gérer un
centre de données concernent :
• le contrôle des performances et de la disponibilité
• la rapidité de détection et de résolution des problèmes
• la maîtrise des coûts d'exploitation
• l'adaptation des ressources informatiques aux priorités de
l'entreprise
A mesure qu'un centre de données se développe pour répondre aux besoins d'une activité
croissante, il devient de plus en plus difficile à gérer. Les administrateurs doivent relever de
nombreux défis et notamment :
• Assurer des niveaux élevés de performances et de disponibilité des applications
• Identifier rapidement les problèmes et les résoudre efficacement
• Permettre une utilisation rationnelle des ressources informatiques pour réduire les coûts
d'exploitation
• Aligner les ressources informatiques sur les priorités de production afin de garantir aux
entreprises une souplesse suffisante pour s'adapter à la fluctuation des besoins

Enterprise Manager Cloud Control
Tous les thèmes abordés ici sont traités en
détail dans la série de cours d'autoformation
Environnement Oracle Enterprise Manager Cloud Control
New Features.
conçu pour
l'entreprise
Gestion
Gestion de Cloud
d'applications
Planification de
Gestion de refacturation et de
middleware capacité
Gestion de
Gestion de base
systèmes Exadata
de données
et Exalogic
Gestion de la
Gestion de
qualité des
Approvisionnement configuration
applications
en logiciels et
application de
Ce cours fait appel à quelques patches
fonctionnalités d'Oracle
Enterprise Manager Cloud
Control.
Principaux objectifs visés par la conception d'Enterprise Manager Cloud Control

• Concevoir une structure de gestion capable de fournir des fonctionnalités de future
génération
• Simplifier la gestion des opérations d'application à disque
• Fournir une solution complète de cloud privé d'entreprise
Enterprise Manager Cloud Control comprend les fonctionnalités suivantes :
• Environnement conçu pour l'entreprise : Architecture modulaire et évolutive, modules
d'extension spécifiques aux cibles, entités auto-actualisables, Support Workbench intégré,
console centralisée de gestion des incidents
• Gestion de Cloud : Solution complète de gestion de cycle de vie en mode cloud
• Planification de refacturation et de capacité : Refacturation en fonction des types de
cible, utilisation d'AWR (Automatic Workload Repository) pour consolider les rapports AWR
provenant de plusieurs bases de données à travers l'entreprise
• Gestion de systèmes Exadata et Exalogic : Aperçu des composants matériels et logiciels
d'un équipement Exadata et gestion du cycle de vie de systèmes Exalogic
• Gestion de configuration : Ensemble intégré d'outils, repérage sans agent, intégration à
My Oracle Support, fonctionnalités de configuration personnalisée

• Approvisionnement en logiciels et application de patches : Profils pour
l'approvisionnement de configurations connues, procédures de déploiement définies par
l'utilisateur, bibliothèque de logiciels intégrée avec possibilités d'auto-mise à jour
• Gestion de la qualité des applications : Réexécution de base de données, réexécution de
serveur d'applications, Real Application Testing intégré avec le masquage de données,
gestion de base de données de test avec notamment le modèle de données d'application
(ADM)
• Gestion de base de données : Gestion de systèmes Oracle Database, notamment des
performances et du cycle de vie des modifications. Certains aspects de la gestion de base
de données sont traités en détail dans ce cours
• Gestion de middleware : Gestion des systèmes Oracle Fusion Middleware
• Gestion d'applications : Gestion des produits Fusion Applications
Remarque : Pour avoir une vision complète des usages d'Oracle Enterprise Manager
Cloud Control, reportez-vous aux sources d'informations suivantes :
• Cours Using Oracle Enterprise Manager Cloud Control
• Cours Oracle Enterprise Manager Cloud Control: Install and Upgrade
• Série de cours d'autoformation Oracle Enterprise Manager Cloud Control New Features
• Démonstrations Oracle Enterprise Manager 12c sur OLL (Oracle Learning Library)
(URL www.oracle.com/goto/oll)

Composants de Cloud Control
Agent OMA (Oracle Module d'extension

Management Agent) propre à la cible
Hôtes
gérés
Service OMS (Oracle

Management Service)
Console Cloud
Control
Référentiel OMR
(Oracle Management
Repository)
Enterprise Manager Cloud Control comprend les quatre composants principaux illustrés dans la
diapositive ci-dessus :
• Référentiel OMR (Oracle Management Repository)
• Service OMS (Oracle Management Service)
• Agent OMA (Oracle Management Agent) avec des modules d'extension spécifiques pour les
différentes cibles
• Console Cloud Control
Exécuté sur des hôtes, l'agent OMA recueille des données de mesure sur les environnements
concernés et utilise des modules d'extension pour surveiller la disponibilité, la configuration et les
performances et pour gérer les cibles exécutées sur les hôtes. Les agents communiquent avec le
service OMS pour charger les données de mesure que leurs modules d'extension et eux-mêmes
ont collectées. OMS stocke les données qu'il collecte dans le référentiel OMR où il peut y accéder
pour effectuer des tâches manuelles ou automatisées (création de rapports, opérations de
surveillance). OMS communique également avec les agents afin d'organiser la gestion de leurs
cibles surveillées. En plus de coordonner l'action des agents, OMS exécute également les pages
Web de la console Cloud Control qui sont utilisées par les administrateurs et les utilisateurs pour
surveiller, interroger et gérer l'environnement informatique visible depuis Cloud Control via les
agents et leurs modules d'extension.

Composants et flux de communication
Application
"Poussée" via SSH Cloud Control
7788 / 7801
4889 / 4900 Serveur
WebLogic
HTTP / HTTPS HTTP / HTTPS
Administrateur
OMA OMS
3872 / 3872
Agent(s) OMA
JDBC 1521
OMR
Oracle Management Repository
La diapositive ci-dessus illustre le flux de communication entre les composants de Cloud Control.
La communication entre l'agent OMA (Oracle Management Agent) et le service OMS (Oracle
Management Server) et entre le service OMS et la console est bidirectionnelle. Tous les numéros
de ports indiqués dans la diapositive sont des valeurs par défaut qui peuvent être modifiées
pendant l'installation, soit par le programme d'installation lorsqu'il recherche des ports
disponibles, soit explicitement par vous. Vous pouvez aussi modifier les numéros des ports après
l'installation.
• L'agent OMA charge les données dans le service OMS via HTTP sur le port 4889 ou via
HTTPS sur le port 4900. (Conception compatible avec WAN)
• Le service OMS communique avec l'agent OMA via HTTP ou HTTPS sur le port 3872.
• Les ports entre OMS et OMA sont séparés pour pouvoir communiquer entre eux de manière
asynchrone et simultanée.
• Le service OMS communique avec le référentiel OMR via JDBC sur le port 1521. OMR
renvoie des données à OMS, mais cela n'est pas considéré comme une communication
distincte, d'où la représentation d'un flux unidirectionnel de OMS vers OMR.
• Les utilisateurs de la console Cloud Control accèdent aux pages Web de Cloud Control via
HTTPS sur le port 7801 ou via HTTP sur le port 7788.
Il est important de connaître les ports utilisés dans votre installation Cloud Control, surtout si vous
gérez des hôtes situés derrière des pare-feu ou lorsque d'autres restrictions réseau s'appliquent,
car la communication doit être autorisée sur ces ports et dans les directions illustrées.

Référentiel OMR
Le référentiel OMR (Oracle Management Repository) :

• réside dans une base de données Oracle
• comprend des objets de schéma appartenant à SYSMAN
• doit être installé dans une base de données préexistante
• peut être installé dans une base RAC
Remarque : Il utilise une licence d'utilisation restreinte
d'Oracle Database
Le référentiel OMR est installé dans une base de données Oracle sous la forme d'un groupe
d'environ 4 000 objets de schéma appartenant à l'utilisateur SYSMAN qui sont stockés dans trois
tablespaces : MGMT_ECM_DEPOT_TS, MGMT_TABLESPACE et MGMT_AD4J_TS. Ces objets de
schéma contiennent des informations sur les utilisateurs et administrateurs d'Enterprise Manager
Cloud Control, sur les cibles et les applications qui sont surveillées et gérées par Enterprise
Manager Cloud Control et sur les groupes, systèmes, incidents et autres artefacts d'Enterprise
Manager Cloud Control. Le référentiel OMR est créé lors de l'installation dans une base de
données préexistante. Pour des besoins d'évolutivité, il peut être installé dans une base de
données RAC (Real Application Clusters). Dans ce cas, le deuxième noeud nécessite une licence
pour la base de données et les deux noeuds nécessitent une licence Oracle Real Application
Clusters.
La base de données utilisée pour héberger le référentiel OMR ne doit pas servir à d'autres
applications pour les raisons suivantes :
• L'utilisation de la base par Enterprise Manager Cloud Control ne doit pas rencontrer de
concurrence.
• L'utilisation de la base de données du référentiel pour d'autres applications peut limiter votre
capacité à appliquer les mises à niveau et les patches nécessaires au schéma et à la base
OMR.
• Enterprise Manager Cloud Control inclut une licence de base de données à usage restreint
qui ne peut servir que pour le référentiel OMR.
Remarque : Pour plus d'informations, reportez-vous à la section Enterprise Manager
Restricted-Use License du document Oracle Enterprise Manager Licensing Information
12c Release 1.

Contrôler la structure Enterprise Manager Cloud
Control
WebLogic
EM
OMS
Référentiel Agents
Utilitaires de contrôle des composants
Référentiel OMS Agent
sqlplus ou
srvctl emctl emctl
lsnrctl
Chaque composant de la structure Enterprise Manager Cloud Control comprend ses propres
utilitaires qui permettent de le surveiller, de le démarrer et de l'arrêter. Dans bien des cas, ces
utilitaires fournissent également quelques possibilités de configurer le composant en plus de la
simple fonctionnalité de démarrage et d'arrêt.
Les bases de données RAC nécessitent l'utilisation des commandes Server Control ; pour les
instances simples, vous avez le choix entre SQL*Plus et Server Control. Server Control est
utilisable lorsque Oracle Restart est installé et que la base est enregistrée dans OLR.
Pour démarrer et arrêter le processus d'écoute (listener), vous pouvez recourir à l'utilitaire Server
Control ou à la commande lsnrctl.
Exemples :
srvctl stop database -d orcl -o immediate
srvctl start database -d orcl -o open

Démarrer la structure
Pour démarrer la structure Cloud Control, effectuez les
1. Démarrez le processus d'écoute de la base de données du
référentiel.
2. Démarrez l'instance de la base de données du référentiel.
3. Démarrez le service OMS.
4. Démarrez l'agent sur le serveur du service OMS/référentiel.
5. Démarrez les agents sur les serveurs gérés.
WebLogic
EM
OHS
Référentiel OMS
Agents
Pour démarrer l'ensemble de la structure Enterprise Manager Cloud Control, procédez de la

manière suivante :
1. Démarrez le processus d'écoute (listener) du référentiel :
$ORACLE_HOME/bin/lsnrctl start
2. Démarrez l'instance de la base de données du référentiel :
$ORACLE_HOME/bin/sqlplus / as sysdba
SQL> startup
3. Démarrez le service OMS (y compris OHS et WebLogic Managed Server) :
$OMS_HOME/bin/emctl start oms
4. Démarrez l'agent sur l'hôte OMS/référentiel :
$AGENT_HOME/bin/emctl start agent
5. Démarrez les agents sur les serveurs gérés :
$AGENT_HOME/bin/emctl start agent
Remarque : Utilisez la commande SRVCTL si vous avez une instance RAC pour le référentiel.

Arrêter la structure
Pour arrêter la structure Enterprise Manager Cloud Control,
effectuez les opérations suivantes :
1. Arrêtez les agents sur les serveurs gérés.
2. Arrêtez l'agent sur le serveur OMS/référentiel.
3. Arrêtez le service OMS.
4. Arrêtez l'instance de la base de données du référentiel.
WebLogic
EM
OHS
Agents OMS Référentiel
Pour arrêter l'intégralité de la structure Enterprise Manager Cloud Control, effectuez les
1. Arrêtez les agents sur les serveurs gérés :
$AGENT_HOME/bin/emctl stop agent
2. Arrêtez l'agent sur l'hôte OMS/référentiel :
$AGENT_HOME/bin/emctl stop agent
3. Arrêtez le service OMS (y compris OHS et WebLogic Managed Server) :
$OMS_HOME/bin/emctl stop oms
4. Arrêtez l'instance de la base de données du référentiel :
$ORACLE_HOME/bin/sqlplus / as sysdba
SQL> shutdown immediate
Remarque : Utilisez la commande SRVCTL si vous avez une instance RAC pour le référentiel.

Types de cible
Enterprise Manager Cloud Control peut surveiller, administrer,

tenir à jour et gérer de nombreux types de cible différents,
notamment :
OMA
• Bases de données Oracle
• Processus d'écoute Oracle Database
• Produits Oracle Fusion Middleware BdD
• Oracle Application Server Cible
gérée
• Oracle WebLogic Server
Hôte
• Applications Oracle, notamment E-Business Suite,
SOA, Siebel et PeopleSoft
• Exadata et Exalogic
• Composants de Cloud Control : OMR et OMS
• Produits de fabricants tiers
Les cibles sont les entités qui sont gérées par Enterprise Manager Cloud Control. Pour cela, des
modules d'extension spécifiques aux types de cible et des agents spécifiques aux hôtes sont
utilisés.
Enterprise Manager Cloud Control peut surveiller, administrer, tenir à jour et gérer différents types
de cible répertoriés dans la diapositive ci-dessus. Vous pouvez ainsi accompagner l'évolution de
votre environnement en ajoutant ou supprimant des cibles dans Enterprise Manager Cloud
Control en fonction de vos besoins. Les cibles Oracle fréquemment utilisées (y compris les
composants d'Enterprise Manager Cloud Control, comme OMR et OMS) sont prédéfinies dans le
produit de base Enterprise Manager Cloud Control. Toutefois, Enterprise Manager Cloud Control
dispose d'une API ouverte qui vous permet de créer des cibles personnalisées.

Repérage des cibles
Serveur A Informations sur la cible hôte Repérage

automatique
Applications par OMA
tierces
OMA
E-Business
Suite
Repérage
Serveurs guidé
Processus Bases de
d'applications
d'écoute données
Une fois que l'agent OMA a été installé sur un hôte, il doit rechercher les cibles qu'il peut gérer.
En tant qu'administrateur d'Enterprise Manager Cloud Control, vous pouvez guider ce processus
à partir des pages de la console Cloud Control. Le repérage guidé permet de désigner une famille
de types de cible à rechercher, par exemple des bases de données et des processus d'écoute
(listeners), puis de préciser les agents où exécuter cette recherche. Si une nouvelle cible est
repérée, le module d'extension approprié est envoyé depuis le service OMS (s'il n'est pas déjà
installé sur l'agent), la cible est enregistrée dans le référentiel OMR et la surveillance commence.
Vous pouvez également configurer un repérage automatique qui s'exécute à intervalles réguliers
et qui obtient un agent pour rechercher les cibles connues sans surveillance, ce qui vous permet
d'examiner les résultats ultérieurement et de porter les cibles repérées au statut de cibles gérées.

La diapositive présente la page Enterprise Summary d'Oracle Enterprise Manager Cloud Control.
L'interface utilisateur comprend les fonctionnalités suivantes :
• Informations affichées dans des graphiques et des tableaux
• Informations de synthèse avec possibilité d'effectuer des analyses descendantes vers les
niveaux de détail pertinents
• Page d'accueil sélectionnée par l'utilisateur dans un ensemble prédéfini ou basée sur une
page quelconque de la console
• Navigation pilotée par des menus
• Recherche de cible globale
• Historique et favoris
• Pages d'accueil de cible personnalisables (par utilisateur)

Interface utilisateur
Choix de la page d'accueil : Navigation pilotée par menus :
• Page d'accueil prédéfinie • Définissez la page de votre
basée sur les rôles choix en tant que favorite
• Page quelconque pour y accéder rapidement.
Améliorations de l'interface utilisateur

L'interface utilisateur d'Enterprise Manager Cloud Control a été refondue dans Application
Development Framework (ADF). Lorsque vous vous connectez à la nouvelle interface, vous
utilisez des menus déroulants pour naviguer dans le produit.
• Choisissez votre propre page d'accueil. Lorsque vous vous connectez pour la première fois
à Enterprise Manager, une sélection de pages d'accueil prédéfinies sur la base des rôles
vous est proposée. Si votre but est de gérer des bases de données, vous pouvez choisir la
page d'accueil d'une base de données. Si les pages prédéfinies ne vous conviennent pas,
vous avez la possibilité de sélectionner n'importe quelle page de l'interface utilisateur
comme page d'accueil.
• Définissez la page de votre choix en tant que favorite afin de pouvoir y accéder rapidement.
Comme vous allez gérer certaines cibles plus fréquemment que d'autres, vous pouvez
marquer les pages d'accueil correspondantes comme favorites, plus ou moins de la même
manière que vous définissez un favori dans un navigateur. Toutefois, les favoris définis dans
Enterprise Manager sont stockés dans le référentiel, de sorte que si vous passez d'un
ordinateur client à un autre, vos favoris restent disponibles.
Pour plus d'informations sur la manière de personnaliser votre console Enterprise Manager Cloud
Control, suivez la démonstration Oracle Enterprise Manager 12c: Console Overview and
Customization proposée par Oracle Learning Library.

Sécurité : Présentation
Enterprise
Manager
Authentification
Enterprise Manager Authentification de cible
Cloud Control
Autorisation Enterprise Gestion des informations

Manager Cloud Control d'identification et de connexion
Structure conçue pour l'entreprise : Sécurité

Comme le montre le graphique ci-dessus, le système de sécurité d'Enterprise Manager comprend
quatre parties :
• Authentification d'Enterprise Manager Cloud Control
• Autorisation et privilèges d'Enterprise Manager Cloud Control
• Gestion des informations d'identification et de connexion (credentials) (les informations
d'identification et de connexion des hôtes peuvent être définies ici)
• Authenfication des cibles (les informations d'identification et de connexion des hôtes
peuvent être utilisées ici)

Gestion sécurisée avec les informations
d'identification et de connexion
• Stockage centralisé des informations
d'identification et de connexion pour
simplifier la gestion Utilisateurs EM
• Prise en charge de la gestion sans mot

de passe et d'informations Privilèges
H
s SS
d'authentification fortes Clé
ro s
– Tickets Kerberos rbe
e t Ke
T ic k
– Clés SSH
• Réutilisation et partage entre
utilisateurs (sans divulgation du Utilisateur EM 1
contenu sensible des informations
d'identification et de connexion)
• Accès contrôlé et protégé Utilisateur EM 2
• Prise en charge de sudo/PowerBroker
Sécurité et informations d'identification et de connexion

En tant qu'outil de gestion contrôlant un grand nombre de scripts et d'actions importantes comme
l'application de patches, Enterprise Manager est confronté à quantités d'informations
d'identification et de connexion (credentials) pour des hôtes, des bases de données et divers
autres objets. La gestion de toutes ces informations peut s'avérer problématique.
• Le stockage centralisé facilite les choses, car vous pouvez y nommer et stocker les
informations.
• Les informations d'identification sans mot de passe et avec authentification forte sont prises
en charge, notamment les tickets Kerberos et les paires de clés SSH.
• Les informations peuvent être réutilisées et partagées entre utilisateurs (sans divulgation
des contenus sensibles tels que les mots de passe). L'accès étant accordé au moyen de
privilèges, les utilisateurs ne connaissent pas le contenu des informations de connexion.
• L'accès aux informations d'identification et de connexion est contrôlé et protégé par des
privilèges.
• Le sous-système d'identification et de connexion d'Enterprise Manager permet de stocker
de manière sécurisée ces informations en tant que préférences ou codes opérationnels qui
peuvent ensuite être utilisés pour effectuer différentes activités de gestion de système.
Enterprise Manager prend également en charge l'emprunt d'identité basé sur
sudo/PowerBroker.

Types d'informations d'identification
et de connexion
• Informations d'identification et de connexion nommées
• Informations d'identification et de connexion enregistrées
• Informations d'identification et de connexion par défaut
• Niveau d'accès :
– View : permet d'utiliser l'information d'identification
– Edit : permet de modifier l'information d'identification (y
compris le nom et le mot de passe)
– Full : permet un accès total (y compris la possibilité de
supprimer l'information)
• Classes d'utilisation : travail, collecte et surveillance
Types d'informations d'identification et de connexion

L'administrateur Enterprise Manager peut stocker les informations d'identification et de connexion
(credentials) des utilisateurs (nom utilisateur/mot de passe, paire de clés privée/publique ou
certificat X509v3) en tant qu'informations d'identification nommées dans Enterprise Manager, à
utiliser pour effectuer des opérations telles que l'exécution de travaux, l'application de patches et
d'autres tâches de gestion système. Les objets indiquent ou pointent vers des informations
d'identification et de connexion nommées. Il s'agit d'espaces réservés qui facilitent notamment la
modification des mots de passe.
Il est possible de stocker, d'accéder et de modifier un nombre fixe de combinaisons constituées
d'un nom utilisateur et d'un mot de passe en tant qu'informations d'identification enregistrées
(dans le référentiel OMR) pour simplifier l'accès à des cibles gérées.
Vous pouvez définir des informations d'identification par défaut pour un type de cible particulier.
Elles seront disponibles pour toutes les cibles de ce type.
Les trois niveaux d'accès suivants peuvent être accordés :
• View : permet d'utiliser les informations d'identification
• Edit : permet de modifier les informations d'identification, y compris le nom et le mot de
passe
• Full : permet un accès total, y compris la possibilité de supprimer l'information nommée

Les informations d'identification et de connexion peuvent aussi être classifiées en fonction de leur
utilisation : identifications de travail (utilisées par le système de gestion de travaux (Job)),
identifications de collecte, identifications de surveillance (utilisées par les agents OMA).
Concepts et définitions de base :
• Le type des informations d'identification et de connexion (credentials) est le type
d'authentification pris en charge par un type de cible. Par exemple, un hôte peut prendre en
charge une authentification par nom utilisateur/mot de passe, par clé publique ou par ticket
Kerberos. Différents systèmes d'authentification sont possibles, notamment l'authentification
par agent natif et SSH.
• Un ensemble d'informations d'identification est un espace réservé pour une information
d'identification. Ces ensembles peuvent être utilisés pour distinguer des informations
d'identification et de connexion par rapport à celles utilisées par le système. Vous pouvez
modifier la correspondance entre un ensemble et les identifications nommées associées à une
cible sans modifier le système qui utilise ces informations. Par exemple, un ensemble peut être
créé pour les tâches d'application de patches.
• Une banque d'informations d'identification est un espace de stockage logique pour toutes les
identifications nommées d'un administrateur Enterprise Manager.
Les informations d'identification et de connexion peuvent être définies par :
• Un nom d'identification : La référence utilise le nom de l'identification dans la banque
d'informations d'identification.
• Un ensemble d'identification : La référence utilise le nom de l'ensemble d'informations
d'identification et le nom de la cible. La recherche obtient l'identification associée au nom de
l'ensemble et au nom de la cible.
• Une valeur directe : L'identification est précisée par la fourniture des valeurs des attributs.
Cette référence ne renvoie pas à une identification de la banque.
Pour plus d'informations sur la manière de définir des informations d'identification et de connexion,
suivez les démonstrations suivantes :
• Oracle Enterprise Manager 12c: Create and Use Named Credentials (dans Oracle Learning
Library)
• Oracle Enterprise Manager 12c: Create SSH Key Named Credentials (dans Oracle Learning
Library)
• OBE Enterprise Ready Framework: Create and Use Credentials

Quiz
Quelles cibles peuvent être gérées à l'aide d'Enterprise

Manager Cloud Control ?
a. Hôtes
b. Bases de données
c. Serveurs d'applications
d. Applications Web
e. OMS et OMR
f. Toutes les cibles ci-dessus
Réponse : f

Utiliser Enterprise Manager Cloud Control
Ces vidéos montrent comment :
• accéder à Enterprise Manager Cloud Control
• définir la page Summary comme page d'accueil
• ajouter une instance de base de données comme nouvelle
cible surveillée par EM CC
• créer une information d'identification et de connexion
(credential) nommée
• utiliser l'information d'identification et de connexion
nommée
Regardez la démonstration "Oracle Enterprise Manager 12c: Console Overview and

Customization" (sauf si votre formateur vient de la faire) (8 minutes).
Démonstrations facultatives disponibles sur des sujets connexes :
• Oracle Enterprise Manager 12c: Create an Enterprise Manager Administrator (6 minutes)
• Oracle Enterprise Manager 12c: Create and Use Named Credentials (6 minutes)
• Oracle Enterprise Manager 12c: Create SSH Key Named Credentials (3 minutes)
• Oracle Enterprise Manager 12c: Discover and Promote Unmanaged Hosts and Targets
Démonstrations OBE (Oracle By Example) facultatives disponibles sur des sujets connexes :
• Oracle Enterprise Manager 12c Enterprise Ready Framework: Create and Use Credentials
(60 minutes)
• Oracle Enterprise Manager 12c Enterprise Ready Framework: Create a Super Administrator
Account (5 minutes)

Cloud computing

Introduction
Introduction
Devenu une notion incontournable dans l'informatique d'entreprise au début du 21e siècle, le
"cloud computing" est désormais introduit progressivement dans la technologie proposée au
grand public. Le monde du cloud computing peut sembler complexe. Pourtant, il s'agit d'une
certaine façon d'un retour aux débuts de l'informatique, à l'époque où les ressources matérielles
étaient tellement onéreuses que, par nécessité, elles étaient généralement partagées par des
utilisateurs qui en ignoraient presque tout.
Oracle Database 12c : Backup and Recovery Workshop C - 2

Présentation du cloud computing
• Le terme "cloud" (nuage) est une métaphore pour décrire
la fourniture de services "dans l'ombre".
• Cette image n'est ni nouvelle, ni propre au domaine
informatique.
– Prenons l'exemple d'un appel téléphonique, autrefois
et aujourd'hui.
Autrefois 1 2
Aujourd'hui
1
Nous consommons des services de type cloud tous les jours

La métaphore du nuage peut s'appliquer chaque fois que les détails de l'implémentation ou de la
fourniture d'un service ne sont pas perceptibles par le consommateur final. Il existe de nombreux
exemples de services de type cloud dans la vie quotidienne, la téléphonie notamment. Avant
l'arrivée de la commutation automatique, un appel téléphonique impliquait plusieurs étapes dont
les usagers étaient pleinement conscients :
1. Appeler l'opérateur et demander une connexion à l'autre partie.
2. Attendre que l'opérateur établisse la communication.
3. Converser avec son interlocuteur (avec le risque que tout le trafic vocal soit écouté par
l'opérateur).
Par conséquent, lorsque vous téléphoniez, vous aviez conscience de la manière dont l'appel était
acheminé et pouviez même suivre les lignes téléphoniques par lesquelles il avait été transmis.
De nos jours, un appel téléphonique nécessite uniquement d'avoir accès à un service
téléphonique et de connaître le numéro de téléphone de son interlocuteur. La manière dont
l'appel est acheminé est noyée dans le cloud des télécommunications et, à l'époque des
communications mobiles, de la téléphonie IP (VoIP, Voice-over-IP) et de l'itinérance (roaming)
internationale, les moyens intervenant dans les communications sont encore plus occultés.
Il existe bien d'autres services de type cloud que chacun de nous utilise dans sa vie quotidienne :
• L'approvisionnement en lait. Autrefois, vous saviez quelle laiterie avait produit le lait que
vous consommiez, mais aujourd'hui cette information est impossible à obtenir à cause de
l'existence de grosses sociétés de production utilisant un réseau de distribution.

• L'approvisionnement en électricité. L'énergie électrique que vous consommez a pu être
générée dans un autre pays.
• La distribution du courrier. A une époque, vous saviez que votre courrier serait collecté, trié
et livré par un même organisme national. Aujourd'hui, plusieurs sous-traitants indépendants
peuvent intervenir entre l'expéditeur et son destinataire.
Dans tous ces exemples, ce n'est pas le service ou le produit que vous consommez qui a changé,
mais la manière dont il vous est fourni.
Prenons un autre cas illustrant à quel point le concept de cloud est déjà profondément ancré dans
notre vie courante :
• La consultation d'un site Web. Vous n'êtes en général pas conscient de l'itinéraire emprunté
par les paquets HTTP entre votre navigateur et les serveurs du site Web, ni même de
l'emplacement physique de ces derniers.

Présentation du cloud computing
• Du point de vue des consommateurs :

– Il s'agit d'une fonctionnalité ou d'un service informatique.
– Son implémentation est à la fois inconnue et sans
importance.
– Sa disponibilité est permanente en tout lieu.
• Du point de vue des fournisseurs :
– Les ressources informatiques peuvent être utilisées de façon
efficace, où qu'elles soient et de toutes les manières
possibles.
– Les ressources peuvent être allouées de manière souple
pour répondre à la demande fluctuante des consommateurs.
– Le respect des niveaux de service convenus est plus
important que tout.
Aux Etats-Unis, le NIST (National Institute of Standards and Technology) définit le cloud
computing comme un modèle permettant d'assurer en tout lieu et à la demande un accès réseau
pratique à un groupe partagé de ressources informatiques configurables (réseaux, serveurs,
espaces de stockage, applications, services...) qui peuvent être utilisées et libérées rapidement
au prix d'un effort de gestion minime et d'une intervention réduite des fournisseurs.
Des avantages multiples
Le cloud computing revêt différents aspects selon les points de vue, et tous ces aspects ont leurs
avantages propres.
Du point de vue du consommateur des ressources fournies par un cloud, il s'agit simplement
d'une fonctionnalité ou d'un service qu'il est possible d'utiliser sans savoir comment ni où son
implémentation est réalisée. La manière dont le produit consommable est fourni au
consommateur est occultée par la nature même de l'accès à ce produit via "le cloud". Le
consommateur n'ayant pas à se soucier des détails d'implémentation, il s'intéresse uniquement à
la disponibilité et à la commodité de la ressource.
Du point de vue d'un fournisseur de ressources, le cloud permet de répondre à la demande des
consommateurs en utilisant une multitude de ressources informatiques disponibles. Cela limite la
dépendance entre les ressources physiques et les topologies d'application et offre au fournisseur
la souplesse de déployer les ressources de la manière la plus efficace et rapide possible. De
même que les consommateurs de ressources en cloud, les fournisseurs sont aussi très
intéressés par les avantages de disponibilité et de commodité. En effet, la rentabilité de leur offre
est déterminée par la satisfaction des consommateurs, laquelle est généralement définie et
mesurée par le biais d'accords de niveau de service.

Caractéristiques essentielles du cloud computing
• Libre-service à la demande
– A tout moment, sans aucune intervention humaine
• Large accès réseau
– N'importe où, depuis n'importe quel périphérique
• Regroupement des ressources
– Ressources partagées pour satisfaire un grand nombre
de demandes
• Ajustement immédiat
– Réactivité transparente à la fluctuation des demandes
• Mesure des services
– Mesures et comptes-rendus de consommation
Cinq caractéristiques essentielles du cloud computing

La définition du NIST mentionne cinq caractéristiques fondamentales du cloud computing :
Les consommateurs peuvent demander et recevoir les ressources informatiques dont ils ont
besoin sans l'intervention d'un fournisseur humain.
Les ressources et les portails libre-service fournis par le cloud sont accessibles via des
périphériques standard connectés au réseau (téléphones mobiles, tablettes, ordinateurs
portables ou postes de travail fixes).
Les fournisseurs utilisent leurs ressources informatiques pour traiter les demandes de divers
clients selon un modèle colocatif. Tous les clients peuvent ainsi profiter de l'allocation
dynamique des ressources du pool pour satisfaire leurs besoins. Il peut s'agir, par exemple,
de ressources de stockage, de traitement, de mémoire ou de bande passante réseau.
La capacité du cloud peut être ajustée en fonction de la demande des consommateurs de
telle sorte que ces derniers ont l'impression de disposer de capacités illimitées.

Modèles de services offerts en cloud computing
• IaaS (Infrastructure as a Service)
• PaaS (Platform as a Service)
• SaaS (Software as a Service)
Personnalisations
SaaS
Application
PaaS
Plate-forme
IaaS
Infrastructure
Trois modèles de services fournis en cloud computing

La définition du NIST mentionne trois modèles de services fournis en cloud computing :
IaaS (Infrastructure as a Service)
Le fournisseur de cloud computing met à disposition des ressources de traitement, de réseau, de
stockage, etc. qui peuvent être demandées par les consommateurs. En général, l'infrastructure
fournie dans un cloud IaaS est virtualisée, mais cela n'est pas forcément perceptible par les
consommateurs. Le consommateur est chargé de fournir une plate-forme applicative et des
applications à déployer sur cette plate-forme. Il peut évidemment personnaliser ces applications à
son gré.
Par exemple, une demande adressée à un cloud IaaS peut consister en une machine virtuelle
Oracle Linux 5 Update 7 x86-64 avec 16 Go de RAM et 250 Go d'espace de stockage.
PaaS (Platform as a Service)
Le fournisseur de cloud computing met à disposition des plates-formes sur lesquelles
les consommateurs peuvent déployer leurs propres applications et les personnaliser si
nécessaire.
Par exemple, un cloud PaaS peut fournir des plates-formes Oracle Database (mono-instance et
RAC) et Oracle WebLogic Server.
SaaS (Software as a Service)
Le fournisseur de cloud computing met à disposition une application que les consommateurs
peuvent utiliser et personnaliser.
Par exemple, un cloud SaaS peut proposer les logiciels Oracle Fusion Applications et Oracle
Social Network.

Modèles de déploiement de cloud computing
• Privé
– Pour l'usage exclusif d'une organisation unique
• Communautaire
– Environnement commun à l'usage d'un groupe
d'organisations liées
• Public
– Environnements à l'usage de plusieurs organisations
(architecture colocative)
• Hybride
– Combinaison de clouds privés et publics à l'usage d'une
même organisation
Quatre modèles de déploiement du cloud computing

La définition du NIST mentionne quatre modèles de déploiement de cloud :
Cloud privé
L'hébergement et l'exploitation d'un cloud privé peuvent être externalisés vers un fournisseur de
services tiers, mais le cloud reste réservé à l'usage exclusif d'une seule organisation.
Cloud communautaire
Exemples de communauté : l'ensemble des corps d'armée, l'ensemble des universités dans une
région donnée, l'ensemble des fournisseurs d'un gros fabricant.
Cloud public
Toute l'infrastructure sous-jacente appartient au fournisseur du cloud public, qui en assure
également l'exploitation.
Cloud hybride
Il peut servir à implémenter un scénario de "cloud bursting" dans lequel une organisation utilise
un cloud privé pour la charge globale régulière d'une application. Si cette charge connaît un pic
important pendant des périodes limitées (fin du trimestre financier, saison estivale...), l'application
peut solliciter les ressources d'un cloud public, puis rendre ces ressources lorsqu'elles ne sont
plus nécessaires.

Avantages partagés du cloud computing
• Séparation entre la fourniture et l'utilisation des ressources
– Les consommateurs peuvent se concentrer sur leurs besoins
professionnels.
– Les fournisseurs peuvent se concentrer sur les ressources
nécessaires pour répondre à ces besoins.
• Flexibilité maximale de part et d'autre
– Les consommateurs utilisent le cloud en fonction de leurs
besoins.
– Les fournisseurs doivent juste répondre à la demande, ils n'ont
pas besoin de la surpasser.
• Les dépenses d'investissement des consommateurs
deviennent des dépenses de fonctionnement.
– Achat et maintenance d'équipements, climatisation et éclairage
des salles de machines, mise en réseau, etc.
• Les fournisseurs peuvent récupérer leurs coûts d'installation
auprès de plusieurs clients.
Un scénario gagnant-gagnant pour les fournisseurs et les consommateurs

Les avantages du cloud computing sont équitablement partagés entre les fournisseurs et les
consommateurs d'infrastructure et de services informatiques.
• Fournisseurs de ressources :
- Ils peuvent gérer l'infrastructure sous-jacente comme ils le veulent tant qu'ils honorent
les accords de niveau de service.
- Ils déploient les ressources à l'endroit et au moment où elles sont nécessaires.
- Ils mutualisent les ressources pour assurer l'évolutivité et l'architecture colocative.
- Ils utilisent le matériel informatique de manière à obtenir un retour sur investissement
optimal.
• Consommateurs de ressources :
- Ils peuvent se concentrer sur leur domaine d'intérêt et d'expertise.
- Ils peuvent laisser l'implémentation et la gestion de l'infrastructure sous-jacente aux
fournisseurs de ressources.
- Ils consomment juste les ressources dont ils ont besoin, quand ils en ont besoin.
Le principal avantage pour les consommateurs de services informatiques est que le cloud
regroupe toute l'infrastructure matérielle, logicielle et réseau dont ils ont besoin et qu'ils devraient
sinon posséder. Il appartient aux fournisseurs de services d'acquérir les ressources matérielles,
les composants réseau et les logiciels de base correctement dimensionnés en quantité et
puissance. Le fournisseur surveille l'utilisation des ressources et facture les consommateurs en
conséquence.

Le cloud computing permet aux fournisseurs de services informatiques d'offrir des capacités qui
peuvent dépasser de loin la consommation momentanée de chaque consommateur, grâce à la
consolidation et au partage de l'infrastructure. Par ailleurs, en desservant un groupe étendu de
consommateurs, le fournisseur peut proposer une gamme et une qualité accrues de ressources
en récupérant les dépenses d'infrastructure engagées via la mesure et la refacturation des
consommations.

Pourquoi implémenter un cloud ?
• Normalisation
• Consolidation
• Centralisation
• Optimisation
• Abstraction
• Souplesse
• Libre-service
Aspects attractifs du cloud computing

Le passage au cloud computing peut être attractif pour une organisation à bien des égards :
• Normalisation
- Le modèle en cloud se prête naturellement à l'adoption de normes, au niveau des
équipements, des plates-formes applicatives et des technologies d'intégration.
• Consolidation
- Combinaison des budgets d'informatique et d'infrastructure physique entre plusieurs
départements.
- Efficacité accrue des processus d'achat, d'installation, de maintenance et d'exploitation
- Réduction de la charge opérationnelle grâce au moindre nombre d'éléments
physiques d'infrastructure à gérer.
- Gains potentiels pour chaque déploiement d'application en termes de ressources de
calcul disponibles.
• Centralisation
- La consolidation peut aboutir au regroupement géographique d'une infrastructure
précédemment distribuée.
- La réduction de l'infrastructure entraîne une simplification des opérations.
• Optimisation
- Exploitation maximale des ressources disponibles sur un serveur donné.
- Réduction de la charge de travail des personnels opérationnels et système en raison
d'une moindre quantité de ressources à gérer.

• Abstraction
- Dans un déploiement en cloud, les plates-formes d'hébergement et de traitement
d'applications deviennent une abstraction de serveurs physiques exécutant des
logiciels installés : la dépendance avec les ressources physiques est éliminée.
• Souplesse
- Tant que les accords de niveau de service en vigueur ne sont pas enfreints, les
ressources informatiques peuvent être déployées et utilisées de manière libre.
- Les applications peuvent être déployées dans tout environnement répondant à leurs
besoins actuels de ressources.
• Libre-service
- Si cela est possible et approprié, il est bon de permettre aux usagers (développeurs,
par exemple) de demander des ressources et de laisser le système de gestion du
cloud fournir ces ressources. Cela allège le travail des administrateurs système et des
équipes chargées des opérations.
- Les utilisateurs finaux ont uniquement à tenir compte des quotas et autres restrictions
qui leur sont imposés. Ils n'ont pas à se demander où trouver les ressources dont ils
ont besoin car celles-ci sont fournies par le cloud privé.

Oracle et le cloud computing
• Solutions de cloud public
– Oracle Cloud
– Oracle dans des clouds publics tiers
– Exploitation de clouds publics tiers
• Solutions de cloud privé
– IaaS
– PaaS
– Cloud de base de données privé
• Systèmes de cloud privé
– Enterprise Manager Cloud Control 12c
– Ops Center 12c
– Plates-formes de cloud : Exadata Database Machine,
Exalogic Elastic Cloud, Oracle SPARC SuperCluster
Clouds Oracle
Oracle propose un certain nombre de solutions de cloud qui combinent différentes technologies.
Pour plus d'informations, consultez les sites suivants :
• http://cloud.oracle.com
• http://www.oracle.com/goto/cloud
• http://www.oracle.com/technetwork/topics/cloud/index.html

Clouds Enterprise Manager Cloud Control 12c
• IaaS
– S'appuie sur la plate-forme de virtualisation Oracle VM
pour x86
– Les demandes des utilisateurs créent des machines
virtuelles
• PaaS
– Base de données en tant que service avec Oracle
monoinstance, RAC et RAC mononoeud
– Middleware en tant que service avec WebLogic Server
• Mesure et refacturation
• Portail libre-service
• Utilisation du modèle de sécurité standard de Cloud
Control pour appliquer des limites colocatives
Enterprise Manager Cloud Control 12c: Clouds privés

Enterprise Manager Cloud Control 12c comprend tous les outils de gestion, de provisionnement,
de mesure et de libre-service nécessaires pour fournir les cinq caractéristiques essentielles du
cloud computing :
Le portail libre-service d'Enterprise Manager Cloud Control 12c permet aux utilisateurs en
libre-service d'examiner et d'effectuer des tâches de maintenance sur des demandes IaaS
et PaaS qui ont déjà été provisionnées, de programmer de nouvelles demandes et de
fournir des rapports sur la consommation et la facturation associée.
Les utilisateurs en libre-service ont juste besoin de l'accès au portail libre-service
d'Enterprise Manager Cloud Control 12c. En tirant parti de la topologie Cloud Control de
service OMS (Oracle Management Service) centralisé avec des hôtes gérés distribués, ils
peuvent utiliser facilement toutes les ressources du cloud auxquelles l'accès leur a été
accordé.
Enterprise Manager Cloud Control 12c peut gérer de nombreuses infrastructures IaaS et
PaaS, en appliquant un modèle de sécurité unifié à tous les clouds. Cela permet d'assurer
le respect des limites du modèle colocatif tout en distribuant les ressources disponibles
conformément aux demandes.

Les utilisateurs en libre-service peuvent définir des règles pour dimensionner
automatiquement leurs services en fonction de diverses mesures. Enterprise Manager Cloud
Control 12c réagit aux variations de la demande et implémente immédiatement les règles
appropriées.
• Mesure
La fonctionnalité de refacturation d'Enterprise Manager Cloud Control 12c permet aux
administrateurs de cloud de définir des règles génériques et détaillées pour calculer les
montants dus. Ces montants sont ensuite alloués à une hiérarchie de centre de coûts et les
rapports d'utilisation et de coûts sont mis à la disposition des administrateurs et des
utilisateurs en libre-service.

Cycle de vie de la gestion de cloud
Enterprise Manager Cloud Control 12c prend en charge

l'ensemble du cycle de vie de la gestion de cloud.
Planifier
Optimiser Configurer
Mesurer
Construire
et
facturer
Gérer Tester
Surveiller Déployer
Gérer le cloud du début à la fin

Oracle Enterprise Manager Cloud Control 12c facilite l'administration et la gestion de toutes les
phases du cycle de vie d'un cloud.
Planifier
Le planificateur de consolidation permet d'examiner les scénarios de simulation impliqués dans
les stades précoces d'analyse comparative entre consolidation et acquisition d'infrastructure. En
utilisant les mesures collectées auprès de vos hôtes gérés actuels, vous pouvez étudier la charge
du système et évaluer s'il est intéressant de consolider des applications sur de nouvelles plates-
formes matérielles, physiques ou virtualisées.
Configurer
Cloud Control 12c fournit des outils pour configurer les fondements de clouds IaaS, DBaaS et
PaaS. Il vous permet de définir les ressources matérielles et logicielles qui seront disponibles
dans votre cloud et d'établir les modèles de quotas de ressources et de sécurité à appliquer.
Construire
Des artefacts prêts à déployer peuvent être préparés et publiés dans Cloud Control 12c,
notamment des profils ou des ensembles pour le provisionnement de base de données.
Tester
Le portail libre-service permet aux développeurs d'artefacts de tester facilement et de manière
contrôlée leurs composants déployables avant de les mettre à la disposition des utilisateurs en
libre-service.

Déployer
Les utilisateurs du cloud peuvent demander autant de déploiements que l'autorisent les quotas de
ressources applicables. Ils peuvent aussi désigner la quantité de ressources informatiques (CPU
et mémoire notamment) à affecter à ces déploiements, ce qui leur permet de dimensionner les
modèles prédéfinis en fonction de leurs besoins.
Surveiller et gérer
Outre leur capacité à surveiller les performances de l'infrastructure de cloud sous-jacente, les
artefacts créés par les demandes des utilisateurs deviennent des cibles gérées dans Enterprise
Manager Cloud Control 12c. Cela permet aux administrateurs de surveiller et gérer les
performances du cloud comme s'il s'agissait d'une seule entité en utilisant les outils standard et la
structure de gestion des incidents.
Mesurer et facturer
Des plans de facturation peuvent être associés aux ressources et aux déploiements de cloud, ce
qui permet d'assurer le suivi et la mesure de la consommation de chaque utilisateur. Les
ressources et les utilisateurs du cloud peuvent également être affectés à une hiérarchie de
reporting pour permettre la détermination des sommes à payer au niveau d'un service, d'une
région ou autre.
Optimiser
Les ressources peuvent être allouées ou réallouées entre plusieurs clouds en fonction des
performances et de la demande.

Quiz
Quelles sont les cinq caractéristiques essentielles du cloud

computing ?
a. Ajustement immédiat
b. Conditionnement de puissance
c. Libre-service à la demande
d. Regroupement des ressources
e. Périphériques de stockage remplaçables à chaud
f. Mesure des services
g. Fiabilité
h. Large accès réseau
Réponse : a, c, d, f, h
Bien que le conditionnement de puissance, les périphériques de stockage remplaçables à chaud
et la fiabilité soient des caractéristiques souhaitables de tout centre de données, les
caractéristiques essentielles du cloud computing identifiées par le National Institute of Standards
and Technology concernent davantage les services que les équipements physiques.

Quiz
Quels clouds pouvez-vous créer avec Enterprise Manager

Cloud Control 12c ? (Sélectionnez toutes les réponses
correctes.)
a. PaaS (Platform as a Service)
b. Cirrus
c. Stratus
d. SaaS (Software as a Service)
e. Cumulonimbus
f. IaaS (Infrastructure as a Service)
Réponse : a, f
Enterprise Manager Cloud Control 12c ne fournit pas les outils nécessaires à l'implémentation
d'un cloud SaaS où l'infrastructure, la plate-forme et l'application sont mises à la disposition des
utilisateurs en libre-service. On pourrait opposer à cela que le modèle IaaS peut être utilisé pour
permettre aux utilisateurs de demander une pile complète comprenant infrastructure, plate-forme
et application. Au sens strict cependant, SaaS désigne un service d'application et non la capacité
de demander la fourniture d'un service d'application.

D78850FR20 sg2

Transféré par

Droits d'auteur :

Formats disponibles

D78850FR20 sg2

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 sg2

Transféré par

Droits d'auteur :

Formats disponibles

Oracle Database 12c: Backup

and Recovery Workshop

Manuel du stagiaire – Volume 2

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

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

Remarque : Oracle Secure Backup et Oracle Database présentent des

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

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

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

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

Opérations de base Opérations de système

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

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

Base de données Données du système de

Définir les données à Jeux de sauvegarde RMAN Jeux de données définis

Options de sauvegarde Utilisation des niveaux Plusieurs niveaux de

Fréquence des Sauvegardes récurrentes Sauvegardes récurrentes

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

Oracle Secure Backup et RMAN vous permettent de gérer facilement l'infrastructure

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

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

Utilisez RMAN pour gérer les éléments de sauvegarde RMAN.

Jeu de sauvegarde RMAN

Fichiers de Elément de Elément de

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

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

Volume Volume Volume

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

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

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

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

Dans une configuration qui inclut Oracle Secure Backup (OSB),

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

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

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

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

1. Connectez-vous en tant qu'utilisateur root.

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

Il est recommandé d'installer le logiciel Oracle Secure Backup dans le répertoire

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

• Utiliser des commandes obtool pour afficher les

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

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

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

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

Les utilisateurs préautorisés n'ont pas besoin de

Oracle Secure Backup effectue les vérifications

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

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

Fenêtre de récupération RMAN

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

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

Mises à jour Mises à jour

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

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

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

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

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

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