Le document fournit une vue détaillée de l'administration d'une base de données Oracle, abordant des aspects tels que l'architecture, la structure logique et physique, ainsi que la gestion des instances et des processus. Il couvre également les utilisateurs, les privilèges, et les stratégies de sauvegarde et de récupération, tout en décrivant les composants tels que les tablespaces, segments et blocs. Les procédures pour le démarrage, l'arrêt et la restauration des bases de données sont aussi expliquées, avec un accent sur l'importance de la cohérence et de la sécurité des données.

1. Administration d'une base de données
Soors Aurore
1

2. Table des matières
1. Architecture d'une base de données..................................................................................4
1.1. La structure logique...............................................................................................4
1.1.1. Les tablespaces..............................................................................................4
1.1.2. Les segments, extensions et blocs........................................................................5
1.2. La structure physique.............................................................................................6
1.2.1. Les fichiers de paramètres................................................................................6
1.2.2. Le fichier de contrôle......................................................................................6
1.2.3. Arborescence des répertoires.............................................................................6
2. Instance de base de données..........................................................................................7
2.1. Introduction........................................................................................................7
2.2. Notion d'instance..................................................................................................7
2.3. Les états d'une base..............................................................................................7
2.4. Arrêt et démarrage d'une instance.............................................................................8
2.5. Le mode sysdba....................................................................................................8
2.6. La SGA...............................................................................................................9
2.6.1. Le database buffer cache................................................................................10
2.6.2. Le buffer de reprise (redo log buffer)..................................................................10
2.6.3. Le pool partagé............................................................................................11
3. Les processus Oracle...................................................................................................12
3.1. Introduction.......................................................................................................12
3.2. Les processus background......................................................................................12
3.2.1. Le processus SMON........................................................................................12
3.2.2. Le processus PMON........................................................................................12
3.2.3. Le processus RECO.........................................................................................13
3.2.4. Le processus ARCH.........................................................................................13
3.2.5. Le processus ORALSN......................................................................................13
3.3. Visualisation des processus connectés........................................................................13
3.4. La circulation des données.....................................................................................13
3.5. Variantes architecturales.......................................................................................15
4. Utilisateurs et privilèges..............................................................................................18
4.1. Niveaux de sécurité..............................................................................................18
4.1.1. Sécurité de compte........................................................................................18
4.1.2. Privilèges objet............................................................................................18
4.1.3. Privilèges système.........................................................................................18
4.2. Création d'un utilisateur........................................................................................18
5. Sauvegarde, restauration et récupération..........................................................................19
5.1. Vue d'ensemble...................................................................................................19
5.2. Archivage des fichiers de journalisation......................................................................19
5.3. Le mode Archivelog..............................................................................................19
5.4. Solutions de sauvegarde et restauration.....................................................................19
5.5. Stratégie de sauvegarde........................................................................................19
5.6. Outils logiques....................................................................................................20
5.6.1. Exportation de données : Export........................................................................20
5.6.2. Importation de données : Import........................................................................20
5.6.3. Un tablespace transportable.............................................................................20
5.6.4. Oracle Data Pump.........................................................................................21
5.6.4.1. Exportation avec Data Pump.......................................................................21
5.6.4.2. Importation avec Data Pump......................................................................22
5.7. Rappels............................................................................................................22
5.7.1. Définitions..................................................................................................22
5.7.2. Les fichiers redo...........................................................................................23
5.7.3. Que faut-il sauvegarder?..................................................................................23
5.8. Archivage des redo log files....................................................................................23
5.8.1. Mode opératoire...........................................................................................23
5.8.2. Problèmes courants........................................................................................24
5.9. Présentation de RMAN...........................................................................................24
5.9.1. RMAN........................................................................................................24
Soors Aurore
2

3. 5.9.2. Lancer RMAN...............................................................................................25
5.9.3. Configurer RMAN...........................................................................................25
5.10. Sauvegarde......................................................................................................25
5.10.1. Généralités................................................................................................25
5.10.2. Manipulations.............................................................................................26
5.10.2.1. Sauvegarde de la totalité de la base de données.............................................26
5.10.2.2. Sauvegarde de tablespaces ou fichiers de données...........................................26
5.10.2.3. Sauvegarde du fichier de contrôle et du spfile................................................26
5.10.2.4. Sauvegarde de fichier archivés ..................................................................26
5.10.2.5. Sauvegarde incrémentale.........................................................................26
5.10.2.6. Sauvegarde incrémentale.........................................................................27
5.10.3. Scénario....................................................................................................28
5.10.4. Sauvegarde complète (cohérente).....................................................................28
5.10.5. Sauvegarde complète (incohérente)..................................................................28
5.10.6. Sauvegarde partielle base ouverte....................................................................28
5.10.7. Sauvegarde incrémentale...............................................................................28
5.11. Le repository RMAN............................................................................................29
5.11.1. Trouver les informations................................................................................29
5.11.1.1. La Commande LIST.................................................................................29
5.11.1.2. La commande REPORT.............................................................................29
5.11.2. Gérer le repository.......................................................................................30
5.11.2.1. La commande CROSSCHECK......................................................................30
5.11.2.2. La commande DELETE.............................................................................30
5.11.2.3. La commande CATALOG ..........................................................................30
5.12. Restauration.....................................................................................................30
5.12.1. Vue d'ensemble...........................................................................................30
5.12.2. Principes généraux.......................................................................................31
5.12.2.1. En mode NOARCHIVELOG.........................................................................31
5.12.2.2. En mode ARCHIVELOG.............................................................................31
5.12.3. Incidents sur les fichiers de contrôle..................................................................31
5.12.4. Identification de la nature des problèmes............................................................32
5.12.5. Les commandes RMAN...................................................................................32
5.12.5.1. La commande RESTORE...........................................................................32
5.12.5.2. La commande RECOVER...........................................................................32
5.12.6. Scénarios de restauration...............................................................................32
5.12.6.1. Scénario 1 : Restauration du SPFILE.............................................................33
5.12.6.2. Scénario 2 : Restauration d'un fichier de contrôle............................................33
5.12.6.3. Scénario 3 : Restauration d'un fichier de journalisation.....................................34
5.12.6.4. Scénario 4 : Restauration complète de la totalité d'une base de données en mode
ARCHIVELOG....................................................................................................34
5.12.6.5. Scénario 5 : Restauration complète d'une partie d'une base de données en mode
ARCHIVELOG....................................................................................................34
5.12.6.6. Scénario 6 : Restauration des fichiers de contrôle en mode ARCHIVELOG.................35
5.12.6.7. Scénario 7 : Restauration incomplète en mode ARCHIVELOG...............................36
5.12.6.8. Scénario 8 : Restauration en mode NOARCHIVELOG..........................................36
5.12.6.9. Scénario 9 : Restauration à un emplacement différent......................................37
5.12.6.10. Scénario 10 : Tablespace temporaire géré localement......................................37
5.12.7. Techniques de flashback................................................................................37
Soors Aurore
3

4. 1. Architecture d'une base de données
Une base de données est composée de deux niveaux :
• niveau logique
• niveau physique
Les informations de description et de comportement constituant ces deux niveaux sont enregistrées dans
le dictionnaire.
1.1. La structure logique
La structure logique est le niveau le plus abstrait : c'est une collection de schémas.
Un schéma contient les objets élémentaires comme les tables, les vues, les déclencheurs, ... . Ces objets
sont aussi appelés objets relationnels.
Un schéma est répartis en zone logiques, tablespaces; ces tablespaces sont constitués de segments; ces
segments sont composées d'extensions; ces dernières sont organisées en blocs.
Ces quatre niveaux (tablespace, segments, extensions et blocs) permettent de définir l'organisation de la
base et le lien entre les niveaux physiques et logiques.
1.1.1. Les tablespaces
Les tablespaces sont des unités logiques, identifiées par un nom. Un objet relationnel ne peut être associé
qu'à un seul tablespace ; un objet y est « logiquement » stocké.
L'utilisation de tablespaces améliore la maintenance, la sécurité et les performances d'une base de
données Oracle. En effet, l'utilisation de tablespaces permet d'éviter les risques de contentions et de
saturations.
Un tablespace permet à l'administrateur de :
• contrôler l''allocation de disque de chacun
• regrouper les objets (utilisateur, application, groupe d'utilisateurs)
• définir un quota à chaque utilisateur
• contrôler la disponibilité des données (online/offline)
• réaliser des sauvegardes/recouvrements partiels
• répartir le stockage des données sur plusieurs disques
A un tablespace sont associés un ou plusieurs fichiers de données où seront stockés les objets lui
appartenant. C'est la taille de ces fichiers qui détermine la capacité de stockage des tablespaces.
La taille d'un tablespace est la somme des tailles des fichiers qui le constitue.
La taille d'une base Oracle est le total des tailles de ses tablespaces.
Il est possible d'obtenir les tailles de tous les tablespaces d'une base en effectuant le script suivant :
select t.TABLESPACE_NAM, round(sum(f.bytes)/1024/1024)
from dba_data_files f, dba_tablespaces t
where f.TABLESPACE_NAME = t.TABLESPACE_NAME
group by t.TABLESPACE_NAME
order by t.TABLESPACE_NAME;
Soors Aurore
4

5. Le tablespace SYSTEM contient les tables du dictionnaire et peut suffire pour une petite base de données.
Il est conseillé d'utiliser un autre tablespace pour les utilisateurs (séparation du dictionnaire) car cela
assure une meilleur flexibilité pour l'administration et une réduction des contentions.
Le tablespace SYSAUX est propre à Oracle 10g. C'est un tablespace auxiliaire à SYSTEM. L'objectif de ce
tablespace est de réduire la charge du tablespace SYSTEM. Si SYSAUX devient indisponible, les
fonctionnalités de base d'Oracle restent accessible. Ce tablespace contient un ensemble d'occupants
comme les informations systèmes associées à une option comme XDB, OracleSpacial, ...
Le tablespace UNDO : le journal des images avant peut être stocké dans un RS ou dans un tablespace de
type UNDO (automatic undo management mode).
Le journal des images avant permet :
• d'annuler les transactions
• de réaliser le recovery
• d'assurer la lecture cohérente des données
• des possibilités de « flashback »
1.1.2. Les segments, extensions et blocs.
Il y a trois niveaux de granularité utilisés par Oracle pour stocker les données :
• bloc de données (bloc logique) : est le niveau le plus fin. C'est l'unité de transfert entre les
disques et la mémoire.
• extension : est le deuxième niveau. Une extension est une suite de blocs contigus alloués
simultanément. Les extensions sont utilisées pour le stockage d'un type spécifique de données.
• segment : est le troisième niveau. Un segment est un ensemble d'extensions (pas forcément
contigüe) allouées à une certaine structure logique (comme par exemple les lignes d'une table).
Lorsqu'un segment est plein, Oracle alloue une nouvelle extension pour ce segment (allocation à la
demande ou incremental extent). Le bloc « en-tête » de chaque segment contient un répertoire
de ses extensions.
Il existe différents types de segments :
• segments de données
• segments d'index
• segment d'annulation
• segments temporaire
• segments d'amorçage
Soors Aurore
5

6. 1.2. La structure physique
Il existe trois types de fichiers :
• les data files qui contiennent les données de la base c'est à dire les objets définis par les
utilisateurs et les objets nécessaires au bon fonctionnement de celle-ci. La taille des data files est
définie à la création de la base de données avec possibilité d'extension ultérieure. Leur
localisation est variable excepté pour le premier fichier créé.
• les redo log files
• les control files
1.2.1. Les fichiers de paramètres
Les fichiers de paramètres contiennent les paramètres nécessaires à la configuration d'un serveur définis
dans un fichier de paramètres appelé PFILE (parameter file). Dans les versions antérieures à Oracle 9i, un
fichier de type « texte » est lu lors du démarrage de l'instance. Depuis Oracle 9i, un fichier binaire réside
sur le serveur de base de données appelé SPFILE (server parameter file).
Modification de la valeur d'un paramètre : ALTER SYSTEM
• SCOPE = SPFILE (effectif au prochain redémarrage)
• SCOPE = MEMORY (immédiat mais non persistant)
• SCOPE = BOTH (immédiat et persistant)
1.2.2. Le fichier de contrôle
Le fichier de contrôle sert à localiser les fichiers de données et autres. Il est le garant de la cohérence ; il
est donc nécessaire d'en faire des copies miroir (trois par défaut).
Le fichier de contrôle comprend aussi :
• le nom de la base de données
• les noms et emplacements des fichiers de données
• les noms et emplacements des fichiers Redolog (journaux des images « après »)
• une estampille précisant la date de création de la base de données
1.2.3. Arborescence des répertoires
Oracle BASE Directory a la forme suivante oralceproduct10.2.0.1, celle-ci contient un répertoire
• ORACLE_HOME
• oradata pour les fichiers de la base de données
• flash_recovery_area pour les opérations de recouvrement
• admin pour les fichiers d'administration de la base de données
Soors Aurore
6

7. 2. Instance de base de données
2.1. Introduction
Dans une instance, il y a trois niveaux :
• niveau fichier
• niveau mémoire : qui correspond à l'organisation des données en mémoire centrale. C'est un
ensemble de zones tampons allouées par Oracle pour contenir les données et certaines
informations de contrôle
• niveau processus : qui correspond aux différents processus Oracle assurant la gestion des données
(les processus utilisateurs exécutent les applications et les processus Oracle assurent la gestion
des données).
Indépendamment du serveur, de son système d'exploitation et des options d'Oracle, chaque base Oracle
est associée à une instance Oracle. Il s'agit d'une zone de mémoire partagée et d'un ensemble de
processus.
Au démarrage, Oracle alloue une zone de mémoire appelée SGA (System Global Area) et démarre plusieurs
processus propriétaires; c'est ce que l'on appelle l'instance.
Lorsque l'on arrête une base, on arrête les processus de l'instance.
2.2. Notion d'instance
L'ensemble des zones en mémoire ainsi que les différents processus d'arrière-plan alloués à une base de
données forment ce que l'on appelle une INSTANCE.
Quand une base de données est démarrée sur un serveur de base de données, Oracle alloue la zone
mémoire (SGA) et démarre les processus d'arrière-plan. La zone mémoire et les processus de l'instance
permettent de gérer les données de la base de données associée et de servir les utilisateurs de celle-ci.
Les caractéristiques de l'instance se trouvent dans son fichier de paramètres. Une instance correspond et
accède à une et une seule base de données. Une base de données peut, à l'inverse, être accédée par
plusieurs instances. C'est le cas dans l'option R.A.C. (Real Application Cluster).
Les utilisateurs quant à eux, se connectent à la base de données par l'intermédiaire de l'instance à
laquelle ils accèdent.
On distingue les instances d'une base de données grâce au SID (System Identifier).
La commutation entre ces instances se fait par la modification de la variable d'environnement
ORACLE_SID. Elle permet de désigner l'instance à laquelle on souhaite se connecter.
Une instance est paramétrée par son INIT.ORA.
2.3. Les états d'une base
Les différents états d'une base sont :
• fermée ou inexistante : elle doit être créée avec les paramètres contenus dans le fichier
d'initialisation. La base peut être fermée pour effectuer des opérations de sauvegardes complète
(à froid) ou éventuellement pour modifier des paramètres non dynamiques du fichier
d'initialisation et faire en sorte que l'instance les prenne en compte lors de son prochain
redémarrage. Pour fermer une base de données : shutdown
• non montée (startup nomount) : dans cet état, le fichier d'initialisation est trouvé et lu. Les
paramètres sont chargés en mémoire, la SGA est réservée selon sa définition dans le fichier de
paramètres et les processus d'arrière-plan sont démarrés. Certaines opérations de maintenance
(ou al création de la base de données) sont possibles. On peut, par exemple, agir sur les fichiers
de contrôle.
• montée (alter database mount) : le fichier de contrôle est lu. Donc, la cohérence de la base de
données peut être évaluée. L'emplacement des fichiers de données est connu et leur existence est
traitée. Ensuite, le système vérifie que la base de données ne nécessite pas un recouvrement
(recovery). Si c'est le cas, le processus de recovery peut être démarré à partir de cet état.
• ouverte (alter database open) : les fichiers de données sont accessibles à tous les utilisateurs
authentifiés. C'est l'état normal de la base de données en fonctionnement.
Soors Aurore
7

8. 2.4. Arrêt et démarrage d'une instance
sqlplus /nolog
sqlplus> connect sys/motdepasse as sysdba
sqlplus> startup nomount pfile=initora8i.ora
On obtient :
ORACLE instance started ORACLE instance started.
Total System Global Area
Fixed Size
Variable Size
Database Buffers
Redo Buffers
Database mounted.
56463824
86480
22642688
33554432
180224
bytes
bytes
bytes
bytes
bytes
La deuxième étape consiste à ouvrir les fichiers de contrôle :
sqlplus> alter database mount;
La troisième et dernière étape ouvre les fichiers redo et les fichiers de données :
sqlplus> alter database open;
Il est évidemment possible de réaliser toutes ces étapes en une seule commande :
sqlplus> startup open pfile=initora8i.ora
STARTUP
•
•
•
•
•
•
FORCE : permet de la fermer si elle ouverte puis de l'ouvrir
RESTRICT : filtrer les utilisateurs ayant accès à la base de données
OPEN : mode par défaut
RECOVER : permet de lancer un recouvrement avant ouverture
MOUNT : démarrage de l'instance et montage de la base de données
NOMOUNT : uniquement démarrage de l'instance
SHUTDOWN
•
•
•
•
[FORCE] [RESTRICT]
[PFILE = fichier d'initialisation]
{[OPEN][RECOVER]/[MOUNT][NOMOUNT]};
[ABORT/IMMEDIATE/NORMAL/TRANSACTIONAL];
ABORT : arrêt brutal, sans enregistrement préalable des données contenues dans la SGA, un
recouvrement sera nécessaire au redémarrage.
IMMEDIATE : refus de nouvelles connexion, annulation des transactions en cours, déconnexion des
utilisateurs, fermeture de la base de données dans un état cohérent, arrêt de l'instance.
NORMAL : mode par défaut : pas de nouvelles connexions et attente de la déconnexion des
utilisateurs.
TRANSACTIONAL : pas de nouvelles connexions, attente de la déconnexion des utilisateurs et
attente de fin de transaction avant l'arrêt.
2.5. Le mode sysdba
Pour les opérations d'administration, il faut utiliser le mode SYSDBA ou SYSOPER. Par défaut, seul le
compte SYS peut obtenir une connexion de ce type là.
L'authentification SYSDBA peut être vérifiée de deux façons :
• par le système d'exploitation
• par le fichier de mot de passe
Soors Aurore
8

9. 2.6. La SGA
Beaucoup de paramètres définissent la configuration d'une instance (fichier d'initialisation init<SID>.ORA).
La plus grande partie du travail de tunning est consacrée aux réglages des paramètres des structures
contenues dans la SGA. La SGA est l'équivalent du contrôleur dans un modèle MVC.
La SGA réside dans un segment de mémoire partagée et est la composante centrale d'une instance :
• toute opération sur une base utilise à un moment ou à un autre des informations contenues dans
une des structures de la SGA
• la SGA est partagée : beaucoup de processus y accèdent en même temps, en lecture/écriture
• la SGA est créée lors du démarrage (avant le montage) de l'instance et elle est détruite lorsque
l'instance est arrêtée (shutdown)
La SGA est composée de
• le pool partagé (shared pool)
• le cache des données (database buffer cache)
• le cache des images après (redo log buffer)
Soors Aurore
9

10. La SGA contient également
• les informations communiquées entre processus telles que les informations relatives au
verrouillage
• les files de requêtes et réponses (dans le cas de l'utilisation du serveur multi-thread)
V$sga contient des informations sommaires sur la SGA :
select * from v$sga;
NAME
-------------------Fixed Size
Variable Size
Database Buffers
Redo Buffers
VALUE
---------53732
63677832
184320000
524288
2.6.1. Le database buffer cache
Le buffer cache est organisé en deux listes :
• la liste des blocs modifiés mais non encore écrits sur le disque (dirty list)
• la liste des blocs les moins récemment utilisés (last recently used list) qui contient :
◦ les blocs libres
◦ les blocs actuellement utilisés (pinned buffers)
◦ les blocs modifiés non encore transférés dans la dirty list
La fin de la liste LRU contient les blocs les plus récemment utilisés (MRU). Lorsqu'un processus sollicite
l'accès à un bloc qui n'est pas déjà présent en mémoire, il doit lire le bloc sur le disque et le placer dans
le cache.
2.6.2. Le buffer de reprise (redo log buffer)
Le buffer de reprise est un tampon circulaire contenant des informations relatives aux modification
apportées à la base de données.
Les entrées de ce buffer contiennent les informations nécessaires à la reconstruction des changements
effectués par les opérations de LMD lors du processus de recovery.
Les informations contenues dans le buffer de reprise proviennent des zones mémoires réservées aux
utilisateurs.
Soors Aurore
10

11. 2.6.3. Le pool partagé
Le pool partagé est composé principalement de deux structures :
• le library cache
• le dictionnaire cache
Le library cache contient des information sur les ordres SQL et PL/SQL les plus récemment exécutés :
• le texte de l'ordre
• sa version analysée
• le plan d'exécution
Le dictionnaire cache contient les informations du dictionnaire de données Oracle les plus récemment
utilisées :
• description des tables
• droits des utilisateurs
• etc.
Lorsqu'une requête est exécutée pour la première fois, Oracle stocke le résultat de l'analyse dans le
Library Cache puis exécute la requête. Lorsque la même requête est de nouveau exécutée plus tard,
Oracle est en mesure de la retrouver dans le Library Cache et de l'exécuter directement sans refaire
l'analyse (ou tout au moins en faisant une analyse plus légère). Dans la pratique, le Library Cache ayant
une taille finie, Oracle utilise un algorithme LRU (Last Recently Used) pour gérer le cache : en cas de
manque de place, Oracle supprime du cache la requête utilisée la moins récemment.
Les informations relatives aux objets de la base de données sont stockées dans les tables du dictionnaire
(données de comptes d'utilisateurs, nom des fichiers de données, noms des segments, emplacements des
extents, descriptions des tables et privilèges). Lorsque la base a besoin de ces informations (par exemple
pour contrôler si un utilisateur est autorisé à exécuter une requête sur une table), elle lit les tables du
dictionnaire et place les informations extraites dans le cache du dictionnaire.
Soors Aurore
11

12. 3. Les processus Oracle
3.1. Introduction
Une instance oracle est composée d'un ensemble impressionnant de divers processus. Chaque processus
joue un rôle très précis.
Dans la littérature, on appelle ces processus, les processus d'arrière-plan (background process).
En plus des processus background, il y a également les processus clients et les processus serveurs (listener
et dispatcher).
3.2. Les processus background
Le but des ces processus est d'améliorer ses performances en présence de plusieurs utilisateurs. Ces
processus sont automatiquement créés lors du démarrage d'une instance. Sont concernés :
• SMON (System Monitor) : processus chargé de vérifier la cohérence de la base de données et
éventuellement sa restauration lors du démarrage si besoin
• PMON (Process Monitor) : processus chargé de nettoyer les ressources, les verrous et les processus
utilisateurs non utilisés
• DBWR (DataBase Writer ou Dirty Buffer Writer) : processus chargé d'écrire le contenu des buffers
dans les fichiers de données
• LGWR (Log Writer) : processus chargé d'écrire le contenu des buffers dans les fichiers Redo Log
• CKPT (CheckPoint) : périodiquement, tous les blocs modifiés du Database Buffer Cache sont écrits
dans les fichiers de données : c'est le mécanisme de synchronisation (checkpoint)
• RECO (Recoverer) : processus optionnel permettant de résoudre les transactions interrompues
brutalement dans un système de bases de données distribuées
• ARCH (Archiver) : processus optionnel et n'existant qu'en mode ARCHIVELOG. Il permet de
dupliquer les fichiers Redo-Log dans un espace d'archivage
• LCK (Lock) : processus permettant un verrouillage inter-instance.
• CJQn (Job Queue) : la gestion des files de jobs dans Oracle s'appuie sur les processus d'arrièreplan CJQn qui assurent l'actualisation des données (par exemple les vues matérialisées) et
exécutent d'autres jobs planifiés.
• Dnnn (Dispatcher, nnnn représente une suite de nombre entiers) : les processus dispatcher sont
nécessaires à l'architecture à serveur partagé. Sans dispatcher, chaque processus utilisateur
nécessite un processus serveur (architecture à serveurs dédié). Un processus dispatcher permet
qu'un processus serveur soit partagé par plusieurs processus utilisateurs (architecture à serveur
partagé).
• ORALSN - Listener
3.2.1. Le processus SMON
Le processus SMON (System Monitor) est responsable
• du recouvrement d'une instance lors de son démarrage
• de la libération des segments temporaires qui ne sont plus utilisés
• de regrouper les extensions libres contigües pour former des extensions libres plus larges
3.2.2. Le processus PMON
Le processus PMON (Process Monitor) est responsable du recouvrement des processus utilisateurs en cas de
problèmes, c'est à dire
• nettoyer le cache
• libérer toutes les ressources allouées pour un processus utilisateur :
◦ libérer les verrous
◦ retirer l'identification du processus (PID) de la liste des processus actifs
◦ réinitialiser le statut de la table des transactions actives
Soors Aurore
12

13. 3.2.3. Le processus RECO
Le processus RECO (recover) est utilisé uniquement dans le cadre de bases de données distribuées dont la
valeur du paramètre DISTRIBUTED_TRANSACTIONS autorise les transactions distribuées (valeur > 0).
Le processus recover résout automatiquement les problèmes survenus dans une transaction distribuée :
• chaque noeud participant à la transaction possède un processus recover;
• ce processus se connecte automatiquement aux autres BD impliquées dans la transaction
• s'il n'y arrive pas, d'autres tentatives se feront à intervalle de temps de plus en plus éloigné
• une fois la connexion établie entre les différents serveurs, le processus revover résout les
problèmes engendrés par la transaction concernée.
3.2.4. Le processus ARCH
Le processus ARCH (archiver) réalise la copie des fichiers de reprises ayant atteint leur taille maximale sur
un support d'archivage.
Il n'est actif que si les fichiers de reprises sont utilisés avec l'option LOG_ARCHIVE_START et que
l'archivage automatique est activé (mode ARCHIVELOG).
L'activation de ce processus permet de réaliser des sauvegardes à chaud de la base (hot backup).
Pendant que ARCH recopie un fichier redo, il le verrouille de sorte qu'aucun autre processus ne puisse y
accéder.
Il est important de nocer ceci à cause de la nature circulaire des fichiers redo : si LGWR doit basculer vers
un fichier de redo qui est toujours en train d'être archivé, il sera placé en attente, et toute l'activé de la
base sera suspendue jusqu'à la fin de l'archivage.
3.2.5. Le processus ORALSN
Le processus listener ne fait pas précisément partie d'une instance mais est intégré à Oracle Net.
Dans une architecture à serveur partagé, le rôle d'un processus listener consiste à attendre les demandes
de connexion des applications des utilisateurs (clients) pour les rediriger vers un processus dispatcher.
Si le processus listener ne peut rediriger un client vers un processus dispatcher, il démarre un serveur
dédié auquel il connecte le client en question.
La communication entre processus dispatcher et listener se déroule de la manière suivante :
• lors du démarrage de l'instance, chaque processus dispatcher communique au processus listener
l'adresse sur laquelle il se met à l'écoute des applications clientes
• lorsqu'un processus utilisateur émet une demande de connexion, le processus listener lui retourne
l'adresse du dispatcher le moins chargé. Le processus utilisateur peut alors directement se
connecter au dispatcher.
3.3. Visualisation des processus connectés
Plusieurs tables dynamiques de performance peuvent être utilisées pour visualiser les processus d'une
instance :
• v$process donne des informations sur tous les processus (background et autres) qui sont connecté
à la base
• v$bgprocess donne des informations sur les processus background
• v$session donne des informations sur l'ensemble des sessions connectées
3.4. La circulation des données
Considérons les étapes nécessaires au déroulement de la transaction suivante :
SELECT * FROM professeurs FROM professeurs
WHERE nom = 'Lebucheron'
FOR UPDATE OF salaire;
UPDATE professeurs
SET salaire = salaire * 2
WHERE nom ='Lebucheron'; WHERE nom
Lebucheron ;
COMMIT;
Soors Aurore
13

14. 1. Le programme client envoie l'instruction select au programme serveur.
2. Le processus serveur regarde dans le pool partagé si cette instruction s'y trouve déjà. S'il ne la
trouve pas, le processus serveur analyse l'instruction et la place dans le pool partagé.
Évidemment, l'analyse de l'instruction consomme des ressources CPU, et la placer dans le pool
partagé exige l'obtention d'un latch (verrou interne).
3. Le processus serveur recherche dans le buffer cache les données concernées par la requête. Si le
processus trouve ces données, il doit les déplacer vers la fin (most recently used) de la liste least
recently used. Ici aussi, le processus doit acquérir un latch.
4. Si les données ne sont pas dans le buffer cache, le processus serveur doit les extraire des disques.
Ceci entraine une ou plusieurs opérations d'entrées/sorties et l'acquisition d'un latch par bloc à
placer dans le buffer cache.
5. Le processus serveur renvoie les tuples trouvés au processus client. Ceci engendre en général une
communication réseau.
6. Lorsque le client émet l'instruction update, elle est analysée et les lignes doivent être retrouvées
comme dans les étapes précédentes. La mise à jour est alors réalisée dans les blocs adéquats du
buffer cache. Cette opération entraîne également des modifications dans les blocs des buffers des
rollback segment.
7. L'instruction update crée également une entry dans le buffer de reprise (redo log buffer).
8. Le processus DBWR recopie les blocs modifiés du buffer cache dans les fichiers de données.
9. Lorsque le commit est exécuté, le processus LGWR doit copier le contenu du buffer de reprise
dans le fichier de reprise. Ce n'est qu'après avoir copié ces blocs qu'Oracle considère que
l'instruction commit s'est bien déroulée.
10. Si la base a été démarrée en mode archivage, le processus ARCH se charge d'archiver les fichiers
de reprise lorsqu'ils sont complets. Un fichier de reprise complet n'étant pas réutilisable avant
qu'il ne soit archivé.
11. A intervalle régulier (par défaut 3 secondes), ou lors d'un changement de fichier de reprise, Oracle
réalise un checkpoint. Un checkpoint force le processus DBWR à recopier tous les blocs du buffer
cache modifiés sur disque.
Soors Aurore
14

15. 3.5. Variantes architecturales
Toute application doit exécuter deux parties de code pour pouvoir accéder à une instance Oracle :
• le code de l'application et
• le code d'un serveur oracle
Le code de l'application émet les requêtes SQL à l'instance. Le code du serveur, quant à lui, analyse et
exécute les requêtes.
Soors Aurore
15

16. Soors Aurore
16

17. Soors Aurore
17

18. 4. Utilisateurs et privilèges
4.1. Niveaux de sécurité
Il existe plusieurs niveaux de sécurité et des fonctionnalités pour procéder à l'audit de chacun de ces
niveaux.
Il y a trois niveaux de sécurité (Oracle) :
• sécurité de compte pour la validation des utilisateurs
• sécurité d'accès pour les objets de la base
• sécurité au niveau système pour la gestion des privilèges globaux
4.1.1. Sécurité de compte
Pour accéder aux données d'une base oracle, il faut disposer d'un accès à un compte dans cette base :
• direct : via des connexions utilisateur à la base
• indirect : les connexions s'appuient sur les autorisations définies dans des liens de base de données
Chaque compte doit disposer d'un mot de passe. Un compte de base de données peut aussi être lié à un
compte du système d'exploitation.
4.1.2. Privilèges objet
Contrôle de l'accès aux objets au moyen de privilèges via la commande grant.
Seul le propriétaire d'un objet possède tous les privilèges sur cet objet. Pour pouvoir accorder un privilège
sur un objet, il faut en être le propriétaire ou avoir reçu le privilège avec l'autorisation de le transmettre
(clause with grant option).
Pour simplifier la gestion des privilèges, il est également possible de créer des rôles dont l'avantage est
• d'avoir un groupe de privilèges nommés (utile pour les applications qui supportent un grand
nombre d'utilisateurs)
• d'avoir un niveau de sécurité supplémentaire à la base
4.1.3. Privilèges système
Les privilèges système sont nécessaire pour pouvoir exécuter certaines commandes.
Les actions qui peuvent être exécutées sur chaque type d'objet sont autorisées via des privilèges séparés.
Pour faciliter la gestion des ces privilèges, il est également possible de définir des rôles.
Les privilèges systèmes permettent aux différents utilisateurs de réaliser des opérations ou des catégories
d'opérations. Ces privilèges ne portent pas sur un objet bien précis mais plutôt sur un type de commandes
comme, par exemple, créer une table ou se connecter à la base. Ils offrent ainsi un contrôle de la sécurité
d'accès très poussé.
La clause ANY permet de spécifier que le privilège porte sur tous les schémas de la base de données.
4.2. Création d'un utilisateur
Create user
• username
• password
• default tablespace
• temporary tablespace
• quota
• profile
• account
• default role(s)
profile est utilisé pour limiter l'utilisation des ressources et mettre en application les règles de gestion des
mots de passe. Lorsque aucun profil n'est défini, c'est celui par défaut qui est utilisé. Ce profil spécifie
une utilisation des ressources non limitées. Un profil est créé au moyen de l'instruction create profil.
Soors Aurore
18

19. 5. Sauvegarde, restauration et récupération
5.1. Vue d'ensemble
Assurer la sécurité est une des taches principales. Cette sécurité est assurée par :
• la mise en œuvre d'une protection des fichiers sensibles de la base de données (fichiers de
contrôle, fichiers de journalisation)
• la mise en place d'une stratégie de sauvegarde/restauration adaptée aux contraintes de
l'entreprise, testée et documentée.
La protection des fichiers de contrôles et de journalisation s'effectue par multiplexage.
La stratégie de sauvegarde/restauration dépend de plusieurs facteurs :
• Peut on perdre des données?
• Peut on arrêter la base périodiquement?
• Peut on réaliser une sauvegarde complète de la base pendant l'arrêt?
Il faut également déterminer la nature des activités sur la base :
• Y a-t-il des mises à jour quotidiennes par les utilisateurs? (application transactionnelle)
• Y a-t-il des mises à jour périodique, consultation la journée? (application décisionnelle)
5.2. Archivage des fichiers de journalisation
Les fichiers de journalisation fichiers constituent un journal des modification apportées à la base de
données. Cet archivage est organiser de manière circulaire.
Ces fichiers peuvent être ré-appliqués à une sauvegarde de fichiers de données, pour rejouer les
modifications survenues entre la sauvegarde et un incident ayant endommagé le fichier (restauration de
média).
Le mode Archivelog permet de garantir 0 perte de données en cas d'incident sur un fichier de données.
5.3. Le mode Archivelog
Après T0, l'activité de mise à jour se produit, générant des entrées dans les fichiers de journalisation.
L'archivage étant activé, les fichiers de journalisation plein sont archivés.
En T1, un incident se produit, le fichier de données est perdu.
La restauration du fichier consiste à prendre la dernière sauvegarde et à appliquer sur cette sauvegarde
les fichiers de journalisation archivés, afin de ramener le fichier de données dans l'état où il se trouvait
avant l'incident (état de la dernière transaction validée).
5.4. Solutions de sauvegarde et restauration
L'outil Recovery Manager (RMAN) est un outil en ligne de commande. Il limite les risques de fausse
manœuvre et peut être utilisé de manière graphique via le database control.
5.5. Stratégie de sauvegarde
• sauvegarde cohérente : sauvegarde de la totalité de la base après un arrêt propre. Cette
sauvegarde est aussi appelée « sauvegarde base fermée ». Toutes les données se trouvent dans les
fichiers de données et c'est le seul mode de sauvegarde disponible lorsqu'on utilise le mode
NOARCHIVELOG
• sauvegarde incohérente : sauvegarde lorsque la base est ouverte et qu'il y a des activités en
cours. Les fichiers sauvegardés ne sont pas synchrones au niveau des modifications enregistrées. Il
faudra utiliser les fichiers de journalisation pour rendre les fichiers cohérents. Pour utiliser cette
stratégie de sauvegarde, il est nécessaire d'utiliser le mode ARCHIVELOG
• complète : totalité de la base
• partielle : uniquement une partie de la base; sauvegarde incohérente entre elle; mode archivelog
• incrémentale : on ne sauvegarde que les blocs modifiés depuis la dernière sauvegarde; cette
sauvegarde peut être partielle ou complète
Le mode Archivelog est utilisé lorsqu'aucune perte n'est autorisée et lorsque la base ne peut pas être
fermée. La base de données peut restée ouverte lorsqu'un incident survient sur un fichier de données qui
n'appartient pas aux tablespaces SYSTEM et UNDO.
Soors Aurore
19

20. 5.6. Outils logiques
5.6.1. Exportation de données : Export
Ce programme réalise une extraction et une copie binaire des données qui est lisible uniquement par son
homologue, import.
Export est appelé en ligne de commande et possède de nombreux paramètres. Ces paramètres lui
indiquent, par exemple, les données à extraire et où il faut les placer.
Il permet de réaliser les opérations suivantes :
• écrire un fichier de résultats qui contient toutes les instructions SQL nécessaires pour recréer
l'infrastructure d'une base;
• générer un ensemble d'instructions SQL pouvant être utilisées pour créer des tables, des index,
des contraintes, ...
• copier les données d'un schéma dans un autre schéma
• déplacer les données depuis un serveur vers un autre
• alimenter une nouvelle base de données
Pour pouvoir créer un export, il faut posséder le privilège système CREATE SESSION. Pour exporter des
tables dont on n'est pas le propriétaire, il faut avoir le rôle EXP_FULL_DATABASE qui est compris dans le
rôle DBA.
Le paramètre compress permet de reconstruire plus aisément une table morcelée en plusieurs extents en
un seul extent.
Mode
Description
Complet
Exporte les données, les définitions de données et d'objets stockés requis pour reconstruire
la base de données à l'exception de l'utilisateur SYS
Utilisateur
Exporte les données, définitions de données et objets stockés appartenant à un ou plusieurs
utilisateurs dont le nom est spécifié au moyen du paramètre owner
Table
Exporte les données, définitions de données (mais pas les objets stockés) de l'utilisateur qui
exécute l'export ou du schéma dont les tables sont mentionnées dans le paramètre tables
5.6.2. Importation de données : Import
L'utilitaire lit les fichiers créés à partir de export.
Il permet de réaliser de nombreuses tâches :
• reconstruire une base de données ou un schéma d'une base de données
• restaurer une copie d'un objet tel qu'il existait au moment de l'export
• restaurer les lignes supprimées d'une table suite à une erreur de programmation
• déplacer des données vers une autre plate-forme.
Import possède exactement les même modes de fonctionnement que l'utilitaire export : mode interactif,
mode ligne de commande et mode fichier de paramètres.
Import supporte pratiquement les mêmes paramètres que export.
5.6.3. Un tablespace transportable
Un tablespace transportable permet de copier aisément et de déplacer un tablespace d'une base vers une
autre.
Un ensemble de tablespaces transportables contient tous les fichiers de données des tablespaces
déplacés, ainsi qu'une copie exportée des métadonnées des tablespaces concernés.
Les tablespaces doivent être fonctionnellement autonomes, ils ne devraient pas contenir d'objets
dépendants d'autres objets extérieurs aux tablespaces transportés. Ainsi, si on souhaite déplacer une
table, il faut également déplacer le tablespace qui contient ses index.
Pour déterminer si un tablespace est fonctionnellement autonome, on peut utiliser la procédure
TRANSPORT_SET_CHECK du package DBMS_TTS qui indique sont résultat dans la table du dictionnaire
TRANSPORT_SET_VIOLATIONS : un résultat vide correspond au fait que le tablespace est fonctionnellement
autonome.
On place les tablespaces que l'on souhaite déplacer en mode read only :
alter tablespace NEW_DATA read only;
alter tablespace NEW_DATA_IDX read only;
Soors Aurore
20

21. Ensuite, on exporte les tablespaces et leurs métadonnées en utilisant les paramètres
TRANSPORT_TABLESPACE et TABLESPACES de l'utilitaire export :
exp TRANSPORTABLE_TABLESPACE=Y
TABLESPACES=(new_data,new_data_idx)
CONSTRAINTS=N GRANTS=Y TRIGGERS=N
On procède alors à la copie des fichiers de données et le fichier d'export vers la base cible (cp, ftp, copy,
etc).
Il reste à connecter les tablespaces déplacés à la table cible :
imp TRANSPORTABLE TABLESPACE=Y
DATAFILES=(new_data1.dbf,new_data2.dbf,new_data_idx.dbf)
On termine en plaçant les tablespaces en module lecture-écriture dans la base cible :
alter tablespace NEW_DATA read write;
alter tablespace NEW_DATA_IDX read write;
5.6.4. Oracle Data Pump
Oracle data pump est une nouvelle technologie de Oracle 10g sur laquelle s'appuie les deux nouveaux
utilitaires DP Export (expdp) et DP Import (impdp).
Ces utilitaires servent à transporter des données et des métadonnées d'une base à une autre.
Ils présentent des analogies avec export et import des versions antérieures d'Oracle mais sont en fait
différents. En effet, grâce au package DBMS_DATAPUMP, ils offrent des performances supérieures en
utilisant le traitement parallèle.
Data Pump permet de déplacer une partie ou la totalité des données et métadonnées d'une base de
données aux moyens de filtres qui sont implémentés par ces utilitaires.
DP Export peut extraire des données de tables, des métadonnées et des informations de contrôle d'une
base pour les enregistrer dans un ou plusieurs fichiers de transfert, ou fichier dump, dont le format
propriétaire ne peut être lu que par DP Import.
Les éléments contenus dans ces fichiers dump, par exemple, des instructions LDD de tables, des
privilèges, des packages, des vues, etc, peuvent être chargés, via DP Import, dans une base de données
cible sur un autre serveur et un système d'exploitation différent.
Les principales fonctionnalités de cet utilitaire sont
• l'extraction des instruction LDD sans les exécuter;
• importation directe via le réseau en utilisant comme source une base de données plutôt que des
fichier dump;
• redémarrage possible des jobs data pump au moyen du paramètre start_job
• possibilité de définir via le paramètre parallel le nombre maximal de threads et le degré de
parallélisme pour les tâches d'exportation et d'importation
• surveillance possible des jobs par rattachement et détachement aux jobs en cours d'exécution
• évaluation possible de la quantité d'espace qui sera occupé par un fichier d'exportation au moyen
de la clause estimate_only
Les procédures de data pump sont implémentées dans le package dbms_datapump et celles de l'API
métadata dans le package dbms_metadata. Les métadonnées extraites par ce package sont au format
XML.
5.6.4.1. Exportation avec Data Pump
L'utilitaire s'appelle expdp. Il possède cinq modes d'exécution mutuellement exclusifs :
• exportation complète : elle peut servir à la reconstruction intégrale d'une base de données;
• exportation de schéma : c'est le mode par défaut. Il permet l'exportation de un ou plusieurs
schémas de la base de données;
• exportation de table : permet d'exporter des tables ou des partitions ainsi que les objets
dépendants;
• exportation de tablespace : permet d'exporter toutes les tables stockées dans les tablespaces
spécifiés dans le paramètre tablespace;
• tablespace transportable : dans ce mode, seules les métadonnées sont exportées.
Soors Aurore
21

22. Un des grands intérêts de DP Export est la possibilité d'utiliser des filtres sur :
• les données : pour filtrer on utilise paramètre query. Le filtre est appliqué une fois par table et
par job
• les métadonnées : pour filtrer on utilise le paramètre exclude et include. Si plusieurs filtres
s'appliquent à un même job, ils sont reliés par l'opérateur and.
Exemples d'exportation :
• exportation complète d'une base de données :
expdp system/manager
DUMPFILE=expdata.dmp
FULL=Y LOGFILE=export.log
• exportation des tables clients et ventes du schéma scott :
expdp system/manager
DUMPFILE=scott.dmp
TABLES=scott.clients, scott.ventes
LOGFILE=export.log
5.6.4.2. Importation avec Data Pump
impdp permet de réaliser des importations à partir des fichiers dump construit par expdp.
Il possède cinq modes de fonctionnement qui correspondent à ceux de l'exportation.
Il est cependant possible de réaliser une importation à partir d'une exportation plus élevée dans la
hiérarchie. Par exemple, il est possible d'importer une table à partir de l'exportation d'un schéma, d'une
tablespace et de la base complète. Ceci est même possible par le réseau et il est également permis
d'utiliser des filtres.
Exemple : importation complète d'une base de données :
impdp system/manager
DUMPFILE=expdata.dmp
FULL=Y LOGFILE=import.log
5.7. Rappels
5.7.1. Définitions
• Sauvegarde (backup) : copie d'un ensemble de fichiers (de données, de contrôles redo, ...) sur un
support (disque, bande, dvd, ...) autre que ceux contenant les données originales.
• Restauration (restore) : remplacement des fichiers altérés à partir d'une sauvegarde.
• Récupération ou recouvrement (recovery) : reconstruction d'une base en utilisant le journal des
images après.
• Sauvegarde à chaud : signifie que la base est accessible pendant la sauvegarde : les utilisateurs
restent donc connectés. Ces derniers peuvent même modifier les données pendant la sauvegarde.
• Sauvegarde à froid : signifie que tous les utilisateurs sont déconnectés et que la base est
arrêtées. On dit aussi que la sauvegarde est cohérente par rapport au fait que tous les fichiers
constituant la base on été estampillés à la même heure lors de la fermeture des fichiers et de
l'arrêt de l'instance.
• Récupération complète : implique de ré-appliquer toutes les instructions consignées dans le
journal des images après. En principe, elle ne s'accompagne d'aucune perte de données.
• Récupération incomplète : consiste à ré-appliquer seulement une partie du journal des images
après, disons jusqu'à un point précis dans le temps. Elle sert souvent à rétablir la base dans l'état
où elle était juste avant qu'un incident ne survienne. Par exemple, l'exécution malheureuse d'un
drop tablespace.
Soors Aurore
22

23. 5.7.2. Les fichiers redo
Lorsque les données sont modifiées dans Oracle, les tampons du cache des données le sont également
pour refléter ces changements.
Pour des raisons de performances, ces tampons ne sont, en général, pas immédiatement recopiés sur
disque. Le contenu des tampons est d'abord consigné dans le cache des fichiers redo.
Lorsqu'une transaction est validée, tous les enregistrements redo qui la concernent et qui se trouvent en
cache sont écrits dans le journal redo sur disque accompagnés d'un numéro de changement système
unique appelé SCN (System Change Number) et d'une identification d'heure.
Les fichier redo assurent ainsi la protection des données en attendant qu'elles soient ultérieurement
recopiées dans les fichiers de données.
Les entrées redo et les données modifiées ne sont donc pas enregistrée sur disque en même temps :
• les première le sont systématiquement lorsqu'une transaction est validée, mais pas les secondes;
• c'est le processus d'arrière-plan DBWn qui est chargé d'écrire dans les fichiers de données les
tampons contenant les données modifiées (dirty buffer) afin de libérer de l'espace dans le cache
des données au sein de la SGA.
• DBWn est invoqué à intervalle régulier par le processus d'arrière-plan CKPT qui met à jour l'en-tête
de tous les fichiers de données ainsi que les fichiers de contrôle avec les informations du dernier
checkpoint.
Oracle écrit dans les fichiers de redo de manière circulaire :
• lorsque le fichier courant est rempli, il écrit dans le suivant, et ainsi de suite jusqu'à utiliser le
premier;
• dès lors, pour avoir un véritable journal des images après, il faut, avant d'écraser un fichier de
redo l'avoir recopié ailleurs. On dit qu'il faut archiver les fichier redo.
• Lorsqu'une base est configurée pour qu'elle archive les fichiers de redo, on dit qu'elle fonctionne
en mode archivelog. L'archivage des fichiers redo est le mécanisme fournit par Oracle pour
garantir la disponibilité permanente des données de la base autorisant leur sauvegarde à chaud.
5.7.3. Que faut-il sauvegarder?
• Le code oracle désigne les programmes qui constituent le logiciel Oracle une fois installé sur le
serveur. La restauration est plus rapide que l'installation, les CD (DVD) sources ou site web.
• Les fichiers de paramètres : le fichier de paramètre au format texte, init.ora ou celui au format
binaire, spfile.ora. Ces fichiers changent très peu, mais devraient être sauvegardés de sorte que
l'état courant de l'instance puisse être recrée.
• Les fichiers de contrôles : contiennent des renseignements indispensables au démarrage de la
base et utiles pour le processus de récupération : l'historique des fichiers redo archivés, le nom du
fichier redo en ligne courant et des informations sur le dernier checkpoint.
• Les fichiers redo archivés
• Tablespace undo ou segments d'annulation
• Les fichiers de données
• Les fichiers de trace : dans certaines circonstances, le support Oracle les demande pour analyser
certain problèmes.
• Le fichier des alertes : ce fichier consigne de nombreux évènements tels que les démarrages et
arrêts, les checkpoints, ainsi que les SCN qui correspond à l'incarnation courante de la base de
données. Il peut être très utile de disposer de ces informations en cas de récupération
incomplète. Par exemple, ce fichier permet de retrouver à quelle heure a eu lieu un drop
tablespace malheureux
5.8. Archivage des redo log files
5.8.1. Mode opératoire
1. Modifier dans le spfile les paramètres concernant les processus d'archivage
2. Arrêter proprement la base de données
3. Monter la base de données
4. Passer la base de données en mode ARCHIVELOG
5. (Sauvegarder la base de données)
6. Ouvrir la base de données
Soors Aurore
23

24. SQL
2
3
SQL
2
3
SQL
SQL
SQL
SQL
> ALTER SYSTEM SET
log_archive_format=‘redo_%S_%R_%T.arc’
SCOPE=SPFILE;
> ALTER SYSTEM SET
log_archive_dest_1=‘LOCATION=<repertoire>’
SCOPE=SPFILE;
> SHUTDOWN IMMEDIATE
> STARTUP MOUNT
> ALTER DATABASE ARCHIVELOG;
> STARTUP OPEN
•
•
•
%s : numéro de séquence
%t : numéro d'instance (thread)
%r : identifiant de remise à zéro des fichiers de journalisation
•
•
LOG_ARCHIVE_FORMAT
LOG_ARCHIVE_DEST(_n)
◦ destinations en parallèle (max 10)
◦ une des destinations au moins doit être locale
◦ il est possible de désigner une base de secours comme cible
◦ les répertoires ne sont pas créés par Oracle
◦ zone flashback utilisée par défaut
LOG_ARCHIVE_DUPLEX_DEST
ARCHIVE_LAG_TARGET
◦ durée entre deux archivages
◦ 0 = désactivé / entre 1minutes et 2heures
•
•
SQL > CONNECT / AS SYSDBA
SQL > ARCHIVE LOG LIST
Vues utiles : v$database / v$log / v$archived_log / v$archive_dest
5.8.2. Problèmes courants
• manque d'espace
• destination inaccessible
SQL
2
3
SQL
> ALTER SYSTEM SET
log_archive_dest_1=‘LOCATION=<rep>’
SCOPE=MEMORY; 3 SCOPE=MEMORY;
> ALTER SYSTEM ARCHIVE LOG START
5.9. Présentation de RMAN
5.9.1. RMAN
RMAN permet la réalisation de sauvegarde et de restauration. Il utilise un repository pour stocker des
informations sur sa configuration, les sauvegardes réalisées, la structure de la base de données, les
fichiers archivés, etc.
Le repository est stocké dans le fichier de contrôle et peut également être stocké dans un catalogue de
récupération.
Si utilisation d'une flash recovery area, il est possible de bénéficier des fonctionnalités de sauvegarde et
de restauration.
RMAN gère les sauvegardes obsolètes, ce qui permet d'indiquer combien de temps une sauvegarde doit
être conservée (définition complémentaire).
Pour chaque opération, RMAN utilise un « canal » : connexion entre le client RMAN et un processus serveur
de la base de données.
Une sauvegarde peut se faire sous la forme d'une « copie image » (copie identique du fichier) ou d'un « jeu
de sauvegarde » (un ou plusieurs fichiers de sauvegarde).
Soors Aurore
24

25. 5.9.2. Lancer RMAN
Ligne de commande :
> RMAN target /
> RMAN target sys/aletest@aletest.world
Options :
• target => paramètre ORACLE_SID par défaut
• CATALOG
• CMDFILE => possibilité de batch
• LOG
• APPEND
Remarque : les options et commandes SQLPLUS sont utilisables (SET ECHO, SPOOL, etc).
5.9.3. Configurer RMAN
RMAN dispose de plusieurs réglages persistants utilisés par défaut.
Configurer la politique de conservation, rétention :
• fenêtre de restauration : nombre de jours dans le passé où on veut revenir
• fenêtre de redondance : indique combien de sauvegardes de chaque fichier doivent être
conservées (par défaut une)
RMAN > CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF n DAYS;
RMAN > CONFIGURE RETENTION POLICY TO REDUNDANCY n;
Configurer la sauvegarde automatique du fichier de contrôle :
• par défaut sauvegarde dans la zone de récupération rapide (flash recovery area )
• possibilité de destination par défaut spécifique
• active aussi la sauvegarde automatique du SPFILE
• sauvegarde automatique à chaque modification de structure de la base de données ou une
sauvegarde RMAN est enregistrée dans le fichier de contrôleur
RMAN > CONFIGURE CONTROLFILE AUTOBACKUP ON;
RMAN > CONFIGURE CONTROLFILE AUTOBACKUP
FORMAT FOR DEVICE TYPE DISK TO ‘<format>’;
L'utilisation de la zone de récupération rapide
• offre des fonctionnalités automatiques
• conseil d'utiliser un disque séparé pour cette zone
• sous répertoire avec différents types de fichiers (règles de nommage)
• une même zone peut être employée par plusieurs base de données à condition qu'elles aient un
nom unique
5.10. Sauvegarde
5.10.1. Généralités
Commande :
RMAN > BACKUP [comment] quoi [option]
Il faut que la base de données soit montée ou ouverte car il est nécessaire d'accéder au fichier de contrôle
de la base de donnée cible.
RMAN peut sauver des fichiers de données, de contrôle, de paramètres serveur, des éléments de
sauvegarde.
Une sauvegarde RMA peut être réalisée sous la forme d'une copie image ou d'un jeu de sauvegarde
(défaut). Dans un jeu de sauvegarde, il n'y a pas de sauvegarde des blocs jamais utilisés des bloc (et donc
gain de place) et compression possible.
Soors Aurore
25

26. Paramètres courants :
• comment?
◦ INCREMENTALE LEVEL n [CUMULATIVE]
◦ VALIDATE (simulation comme nero)
◦ AS COPY ou AS BACKUPSET
• quoi?
◦ DATABASE
◦ TABLESPACE cible
◦ DATAFILE cible
◦ CURRENT CONTROLFILE
◦ SPFILE
◦ ARCHIVELOG cible
• option:
◦ INCLUDE CURRENT CONTROL FILE
◦ PLUS ARCHIVELOG
◦ FORMAT='<format>'
◦ NOT BACKED UP clause_depuis
5.10.2. Manipulations
5.10.2.1. Sauvegarde de la totalité de la base de données
RMAN > BACKUP [VALIDATE] DATABASE;
5.10.2.2.
RMAN >
RMAN >
RMAN >
Sauvegarde de tablespaces ou fichiers de données
BACKUP TABLESPACE user, index;
BACKUP DATAFILE 1,2, ‘<rep/fichier>’;
BACKUP TABLESPACE system DATAFILE 5;
5.10.2.3.
RMAN >
RMAN >
RMAN >
RMAN >
Sauvegarde du fichier de contrôle et du spfile
BACKUP … INCLUDE CURRENT CONTROLFILE;
BACKUP CURRENT CONTROLFILE;
BACKUP AS COPY CURRENT CONTROLFILE;
BACKUP SPFILE;
5.10.2.4. Sauvegarde de fichier archivés
Si pas multiplexé et si pas archivés dans la zone de récupération rapide
RMAN > BACKUP ARCHIVELOG ALL;
RMAN > BACKUP ARCHIVELOG FROM TIME ‘SYSDATE-1’ DELETE ALL INPUT;
RMAN > BACKUP AS COMPRESSED BACKUPSET ARCHIVELOG FROM TIME
‘SYSDATE-7’ NOT BACKED UP 2 TIMES;
RMAN > BACKUP DATABASE PLUS ARCHIVELOG;
RMAN > BACKUP DATABASE PLUS ARCHIVELOG DELETE ALL INPUT;
Commande BACKUP ... PLUS ARCHIVELOG :
1. Archivage du fichier de journalisation courant
2. Sauvegarde de tous les fichiers de journalisation archivés
3. Sauvegarde des autres éléments
4. Archivage, à nouveau, du fichier de journalisation courant
5. Sauvegarde des fichiers de journalisation archivés générés depuis le début de la sauvegarde
Option NOT BACKED UP : pour ne pas sauvegarder que les fichiers de journalisation archivés qui n'ont pas
déjà été sauvegardés un nombre de fois ou depuis un certain temps
5.10.2.5. Sauvegarde incrémentale
Elle permet de sauvegarder uniquement les blocs qui ont été modifiés depuis la dernière sauvegarde. A
utiliser plutôt lorsque l'activité de mise à jour est relativement faible
RMAN > BACKUP INCREMENTAL LEVEL 0 DATABASE;
RMAN > BACKUP INCREMENTAL LEVEL 1 DATABASE;
Soors Aurore
26

27. 5.10.2.6. Sauvegarde incrémentale
• différentielle ou cumulative / Niveau 0 ou Niveau 1
• incrémentale niveau 0 : sauvegarde tous les blocs utilisés des fichiers de données (sauvegarde
complète)
• différentielle niveau 1 : tous les blocs modifiés depuis la dernière sauvegarde de niveau 0 ou 1
(défaut)
• cumulative niveau 1 : tous les blocs modifiés depuis la dernière sauvegarde de niveau 0
Incrémentale cumulative
Cumulative cumulative
Soors Aurore
27

28. 5.10.3. Scénario
Hypothèses de départ:
• une zone de récupération rapide est utilisée
• la sauvegarde automatique des fichiers de contrôle a été activée
Scénarios :
• sauvegarde complète base fermée
• sauvegarde complète base ouverte
• sauvegarde partielle base ouverte
• sauvegarde incrémentale
5.10.4. Sauvegarde complète (cohérente)
Commande (avec RMAN) :
RMAN > SHUTDOWN IMMEDIATE;
RMAN > STARTUP MOUNT;
RMAN > BACKUP DATABASE;
RMAN > SQL « ALTER DATABASE OPEN »;
5.10.5. Sauvegarde complète (incohérente)
Sauvegarde complète + sauvegarde des fichiers de journalisation + suppression des fichiers de
journalisation archivés sauvegardés.
Commande :
RMAN > BACKUP DATABASE PLUS ARCHIVELOG DELETE INPUT
5.10.6. Sauvegarde partielle base ouverte
La totalité de la base de données est sauvegardée en 3 fois en 3 jours :
# Sauvegarde 1 : fichiers de données 1 et 2
RMAN > BACKUP DATAFILE 1,2 PLUS ARCHIVELOG DELETE INPUT;
# Sauvegarde 2 : fichiers de données 3 et 4
RMAN > BACKUP DATAFILE 3,4 PLUS ARCHIVELOG DELETE INPUT;
# Sauvegarde 3 : le reste
RMAN > BACKUP DATABASE NOT BACKED UP SINCE
TIME=‘SYSDATE-3’ PLUS ARCHIVELOG DELETE INPUT;
5.10.7. Sauvegarde incrémentale
Sauvegarde incrémentale cumulative sur un cycle d'une semaine :
# Dimanche : sauvegarde incrémentale de niveau 0
RMAN > BACKUP INCREMENTAL LEVEL 0 DATABASE;
# Lundi au Samedi : sauvegarde incrémentale cumulative de niveau 1
RMAN > BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;
Soors Aurore
28

29. 5.11. Le repository RMAN
5.11.1. Trouver les informations
5.11.1.1. La Commande LIST
Elle permet d'afficher des informations sur les sauvegardes et les fichiers de journalisation archivés.
RMAN > LIST cible [BY FILE | SUMMARY] [filtre_sauvegarde];
RMAN > LIST {BACKUPSET | BACKUPPIEC}{liste_clés | tag=‘nom’};
RMAN > LIST ARCHIVELOG [ALL | filtre_archive][info_sauvegarde];
Exemples :
RMAN > LIST
RMAN > LIST
RMAN > LIST
RMAN > LIST
RMAN > LIST
RMAN > LIST
RMAN > LIST
RMAN > LIST
BACKUP
BACKUP
BACKUP
BACKUP
BACKUP
BACKUP
BACKUP
BACKUP
OF DATABASE;
OF DATAFILE 1;
OF TABLESPACE system, sysaux.
OF CONTROLFILE SPFILE;
OF ARCHIVELOG ALL
OF ARCHIVELOG UNTIL TIME ‘SYSDATE_1’;
TAG=‘DBINC0’;
COMPLETED AFTER ‘SYSDATE_1’;
RMAN > LIST BACKUPSET 8;
RMAN > LIST BACKUPSET TAB=‘DBINC0’;
RMAN > LIST BACKUPPIECE 76;
RMAN > LIST ARCHIVELOG ALL;
# dans la dernière heure
RMAN > LIST ARCHIVELOG FROM TIME ‘SYSDATE_1/24’;
# archives sauvegardées 2 fois sur disque
RMAN > LIST ARCHIVELOG ALL BACKED UP 2 TIMES TO DEVICE TYPE DISK;
# archives jamais sauvegardées sur disque
RMAN > LIST ARCHIVELOG ALL BACKED UP 0 TIMES;
5.11.1.2. La commande REPORT
• réaliser des interrogations plus évoluées
• utilisations principales :
1. lister les éléments qui nécessitent une sauvegarde
2. lister les sauvegardes obsolètes
3. afficher la liste des fichiers de données de la base de données
1. Lister les éléments qui nécessitent une sauvegarde :
RMAN > REPORT NEED BACKUP [condition][objets];
Options :
• Condition :
◦ DAYS = n
◦ incremental = n
◦ recovery window of n days
◦ redundancy = n
• Objets :
◦ database
◦ database <liste>
◦ tablespace <liste>
Soors Aurore
29

30. 2. Lister les sauvegardes obsolètes
RMAN > REPORT OBSOLETE [condition];
Options :
• Conditions
◦ recovery window of n days
◦ redundancy = n
3. Afficher la liste des fichiers de données de la base de données
RMAN > REPORT SCHEMA;
5.11.2. Gérer le repository
5.11.2.1. La commande CROSSCHECK
• vérifier que les informations enregistrées dans le dictionnaire correspondent bien à des fichiers
existants
• trois status possibles : expired / available / unavailable
RMAN > CROSSCHECK cible [filtre_sauvegarde];
RMAN > CROSSCHECK {BACKUPSET | BACKUPPIECE}{liste_cles | tags};
RMAN > CROSSCHECK ARCHIVELOG [ALL | filtre_archive];
5.11.2.2. La commande DELETE
Elle permet de supprimer des sauvegardes (suppression physique + dans le repository).
Variantes possibles :
• supprimer des sauvegardes ou fichiers de journalisation
• supprimer les sauvegardes obsolètes.
5.11.2.3. La commande CATALOG
Elle permet d'indiquer à RMAN l'existence de fichiers de journalisation archivés ou d'éléments de
sauvegarde qui ne sont pas enregistrés dans le référentiel RMAN.
Cas possibles :
• mauvais emploi de DELETE, le fichier physique est toujours la
• récupération avec mauvais fichier de contrôle
• recréation de fichier de contrôle (il est vide)
• erreur sur le fichier de contrôle
• déplacement du fichier physique
5.12. Restauration
5.12.1. Vue d'ensemble
Plusieurs facteurs dépendants :
• nature du/des fichiers endommagé(s) ou perdu(s)
• mode de fonctionnement de la base (archivelog ou non)
• sauvegarde possible
Que faire :
• identifier la nature du problème
• définir le mode opératoire
Conseil inital : avant de commencer toute opération de restauration, réaliser une sauvegarde complète de
la base endommagée. Au minimum une sauvegarde du fichier de contrôle et des ficher de journalisation
en ligne.
Soors Aurore
30

31. Deux étapes :
• restauration : extraire d'une sauvegarde les fichiers nécessaires
• récupération : appliquer les fichiers de journalisation aux fichiers récupérés de la sauvegarde
5.12.2. Principes généraux
5.12.2.1. En mode NOARCHIVELOG
• mode opératoire :
◦ restaurer la dernière sauvegarde complète de la base
◦ redémarrer la base
• toutes les modifications apportées depuis la dernière sauvegarde sont perdues
• dans certaines situations, il peut être possible de récupérer tout ou une partie des modifications
apportées depuis la dernière sauvegarde
• dans certaines situations,
◦ un cycle complet de basculement des fichiers de journalisation n'a pas eu lieu depuis la
sauvegarde --> restauration comme si en mode archivelog
◦ le fichier de données perdu n'est pas critique pour la base de donnée (il n'appartient pas au
tablespace SYSTEM ni au tablespace UNDO) et la base de données a été arrêtée lors de
l'incident --> pas de restauration nécessaire au prochain démarrage ou suppression/recréation
◦ tous les fichiers de contrôles sont perdu mais les autres sont intacts
5.12.2.2. En mode ARCHIVELOG
• mode opératoire :
◦ restaurer la dernière sauvegarde de chaque fichier perdu
◦ appliquer les fichiers de journalisation (archives puis ceux en ligne)
◦ redémarrer la base (si la restauration ne s'est pas fait base ouverte)
• récupération complète
• type de restauration simple et ne pose pas de problèmes s'il reste au moins un fichier de contrôle,
un membre par groupe de fichier de journalisation sont disponibles
• différentes situations peuvent conduire à une récupération incomplète (point in time recovery) :
◦ volontairement, pour s'arrêter devant un ordre SQL malencontreux
◦ involontairement, si des fichiers de journalisation sont perdus
5.12.3. Incidents sur les fichiers de contrôle
Les incidents « peu graves » :
• perte d'un ou plusieurs fichiers de contrôle (du moment qu'il en reste au moins un)
• perte d'un ou plusieurs fichiers de journalisation
Les incidents « graves » :
• perte de tous les fichiers de contrôle
• perte de tous les membre d'un groupe de fichier de journalisation (gravité dépendant du statut du
groupe perdu)
Ces situations sont évitées si on multiplexe correctement les fichiers de contrôle et de journalisation,
Soors Aurore
31

32. 5.12.4. Identification de la nature des problèmes
• message d'erreur concernant les fichiers de contrôle : ORA-00204 à ORA-00206
• message d'erreur concernant les fichiers de journalisation : ORA-00312 à ORA-00321
• message d'erreur concernant les fichiers de données : ORA-01157 à ORA-01110
Lorsque la base de données montée ou ouverte, on peut interroger la vue V$RECOVER_FILE pour
déterminer la liste des fichiers de données sur lesquels il existe un problème.
5.12.5. Les commandes RMAN
L'objectif principal est de bien choisir la cible en fonction de la nature du problème. Ensuite RMAN se
charge de tout :
• identifier les sauvegardes à utiliser;
• en extraire les fichiers requis;
• identifier les fichiers de journalisation archivés nécessaires
• les extraire d'une sauvegarde s'ils ont été sauvegardés puis supprimés
5.12.5.1. La commande RESTORE
RMAN > RESTORE cible [options]
Options :
• PREVIEW : lister les sauvegardes dont RMAN a besoin pour réaliser la restauration correspondante
• VALIDATE : tester si la restauration peut être restaurée
5.12.5.2. La commande RECOVER
RMAN > RECOVER cible [options]
Lors de l'opération de récupération, RMAN recherche les fichiers de journalisation archivés dont il a besoin
en premier lieu sur le disque. Les fichiers de journalisation archivés manquant sont automatiquement
restaurés à partir de sauvegardes, vers le répertoire d'archivage défini par le paramètre
LOG_ARCHIVE_DEST_1
5.12.6. Scénarios de restauration
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Restauration du SPFILE
Restauration d'un fichier de contrôle
Restauration d'un fichier de journalisation
Restauration complète de la totalité d'une base de données en mode ARCHIVELOG
Restauration complète d'une partie d'une base de données en mode ARCHIVELOG
Restauration de tous les fichiers de contrôle en mode ARCHIVELOG
Restauration incomplète en mode ARCHIVELOG
Restauration en mode NOARCHIVELOG
Restauration à un emplacement différent
Tablespace temporaire géré localement
Hypothèses de départ :
• la sauvegarde automatique du fichier de contrôle et du SPFILE est activée
• utilisation d'une zone de récupération rapide
• pas de base de données annexe pour stocker le repository RMAN
Remarque : si le fichier SPFILE, ou de contrôle, ou de journalisation est perdu, d'abord résoudre ces
problèmes avant de traiter le cas des fichiers de données.
Soors Aurore
32

33. 5.12.6.1. Scénario 1 : Restauration du SPFILE
Deux possibilités :
• le recréer à partir d'un fichier de paramètres texte (méthode la plus simple)
• le restaurer à partir d'une sauvegarde RMAN
Pour restaurer à partir d'une sauvegarde RMAN :
#positionner le DBID correspondant à la DB
RMAN > SET DBID <nombre> RMAN > SET DBID <nombre>
#démarrer l’instance sans la monter (RMAN va utiliser un spfile temporaire pour
démarrer l’instance
RMAN > STARTUP NOMOUNT RMAN > STARTUP NOMOUNT
#restaurer le fichier de paramètres serveur à partir d’une sauvegarde
automatique
RMAN > RESTORE SPFILE FROM AUTOBACKUP; RMAN > RESTORE SPFILE FROM AUTOBACKUP;
# si cela échoue, ou si utilisation d’une sauvegarde qui n’est pas une
sauvegarde automatique, restaurer à partir d’une sauvegarde spécifique
RMAN > RESTORE SPFILE FROM ‘<fichier>’;
# redémarrer l’instance et l’ouvrir
RMAN > SHUTDOWN
RMAN > STARTUP
5.12.6.2. Scénario 2 : Restauration d'un fichier de contrôle
Dans le cas où l'on a perdu un ou plusieurs fichiers de contrôle mais qu'il en reste au moins un, il ne faut
PAS repartir d'une sauvegarde de fichier de contrôle. Il faut simplement dupliquer un des fichiers de
contrôle restants pour remplacer les fichiers perdus.
Mode opératoire :
1. Arrêter la base de données
2. Utiliser le fichier d'alerte de l'instance pour identifier les fichiers perdus
3. Dupliquer une version valide du fichier de contrôle pour la mettre à la place de celui endommagé
4. Redémarrer la base de données
Si le fichier de contrôle est dupliqué à un autre emplacement que celui d'origine, il faut modifier le
paramètre CONTROL_FILES dans le fichier du SPFILE.
Mode opératoire :
1. Démarrer l'instance sans la monter
2. Modifier le paramètre CONTROL_FILES du SPFILE
3. Redémarrer l'instance
Exemple :
SQL > STARTUP NOMOUNT
SQL > ALTER SYSTEM SET CONTROL_FILES=
1 ‘<rep + nom fichier>’
2 ‘<nouveau rep et nom fichier>’
3 SCOPE=SPFILE;
SQL > SHUTDOWN IMMEDIATE
SQL > STARTUP
Soors Aurore
33

34. 5.12.6.3. Scénario 3 : Restauration d'un fichier de journalisation
Même stratégie avec la recréation des fichiers.
Mode opératoire :
1. Identifier le/les fichier(s) endommagé(s) dans le fichier des alertes, dans le fichier de trace de
LGWR ou dans la vue V$LOGFILE
2. Supprimer le membre endommagée
SQL > ALTER DATABASE DROP LOGFILE MEMBER ‘nom_fichier’;
3. Ajouter un nouveau membre au groupe concerné
SQL > ALTER DATABASE ADD LOGFILE MEMBER ‘nom_fichier’ TO GROUP numero;
4. Réitérer les deux opérations précédentes avec tous les membres endommagés
Remarque : on ne peut supprimer le membre si il appartient au groupe courant. Dans ce cas, il faut
changer de groupe courant :
SQL > ALTER SYSTEM SWITCH LOGFILE
Cet ordre ne peut être exécuté que si la base de données est ouverte. Si la base de données est fermée,
et qu'elle ne peut pas être ouverte tout de suite, on peut reporter la correction du problème à plus tard,
5.12.6.4. Scénario 4 : Restauration complète de la totalité d'une base de données en mode ARCHIVELOG
Hypothèses :
• tous les fichiers de données perdus
• instance arrêtée
Mode opératoire :
# monter la DB
RMAN STARTUP MOUNT RMAN > STARTUP MOUNT
# restaurer la DB
RMAN > RESTORE DATABASE;
# récupérer la DB #p
RMAN > RECOVER DATABASE DELETE ARCHIVELOG MAXSIZE 200M;
# ouvrir la DB
RMAN > SQL « ALTER DATABASE OPEN »;
5.12.6.5. Scénario 5 : Restauration complète d'une partie d'une base de données en mode ARCHIVELOG
Hypothèse : perte d'un ou plusieurs fichiers de données (mais pas tous).
Il y a deux possibilités de réalisations selon la nature du problèmes :
• base fermée :
◦ fermée initialement
◦ fichier de données du tablespace SYSTEM ou UNDO
• base ouverte :
◦ autres fichiers de données
Soors Aurore
34

35. Restauration avec une base de données fermée :
• un fichier du tablespace SYSTEM est perdu
• mode opératoire :
# monter la DB
RMAN > STARTUP MOUNT
# restaurer fichiers de données souhaité via restore tablespace/datafile
RMAN > RESTORE TABLESPACE system;
# récupérer les fichiers de données # récupérer les fichiers de données
RMAN > RECOVER TABLESPACE system;
# ouvrir la DB
RMAN > SQL « ALTER DATABASE OPEN »;
Restauration avec une base de données ouverte :
• un fichier du tablespace INDEX est perdu
• mode opératoire :
◦ partie optionnelle si la base est déjà ouverte :
# monter la DB
RMAN > STARTUP MOUNT
# mettre offline les fichiers perdus
RMAN > SQL « ALTER DATABASE DATAFILE 6 OFFLINE »;
# ouvrir la DB # ouvrir la DB
RMAN > SQL « ALTER DATABASE OPEN »;
◦
#mettre les TBS concernés offline
RMAN > SQL « ALTER DATABASE indx OFFLINE IMMEDIATE »;
#restaurer les fichiers de données souhaitées
RMAN > RESTORE DATAFILE 6;
#récupérer les fichiers de données
RMAN > RECOVER DATAFILE 6;
#passer ONLINE les tablespaces concernés
RMAN > SQL « ALTER TABLESPACE indx ONLINE;
5.12.6.6. Scénario 6 : Restauration des fichiers de contrôle en mode ARCHIVELOG
Hypothèses :
• perte de tous les fichiers de contrôle et un fichier de données
• on dispose de sauvegarde automatique du fichier de contrôle et les fichiers de journalisation en
ligne sont disponibles
• l'instance est arrêtée
Mode opératoire :
1. Positionner le SID correspondant
2. Démarrer l'instance sans la monter
3. Restaurer les fichiers de contrôle à partir d'une sauvegarde automatique
4. Monter la base de donnée
5. Restaurer les fichiers perdus
6. Récupérer la base de données (pas uniquement les fichiers de données car on repart d'une
sauvegarde de fichier de contrôle; sous entendu un CROSSCHECK et CATALOG)
7. Ouvrir la base de données avec l'option « RESETLOGS » (obligatoire)
Exemple :
RMAN > SET DBID <numero>
RMAN > STARTUP NOMOUNT
RMAN > RESTORE CONTROLFILE FROM AUTOBACKUP;
RMAN > SQL « ALTER DATABASE MOUNT »;
RMAN > RESTORE DATAFILE 5;
RMAN > RECOVER DATABASE;
RMAN > SQL « ALTER DATABASE OPEN RESTLOGS »;
Soors Aurore
35

36. 5.12.6.7. Scénario 7 : Restauration incomplète en mode ARCHIVELOG
Hypothèse : tout est perdu : fichier SPFILE, fichier de contrôle, fichier de données, fichier de
journalisation en ligne.
Ce type de restauration est nécessaire dans les cas suivants :
• perte de tous les redo log file
• perte d'un fichier de journalisation archivé nécessaire à une récupération
• retour avant un ordre SQL malencontreux (drop table, etc)
Dans tous les cas, il faut identifier le point de retour (SCN, timestamp, sequence) souhaité.
Mode opératoire :
1. Positionner le SID
2. Démarrer l'instance sans la monter
3. Restaurer le fichier de paramètres serveur
4. Redémarrer l'instance sans la monter (démarrage avec le SPFILE)
5. Restaurer les fichiers de contrôle
6. Monter la base
7. Synchroniser le référentiel RMAN avec le contenu de la zone
Exemple :
RMAN > SET DBID <numero>
RMAN > STARTUP NOMOUNT
RMAN > RESTORE SPFILE FROM ‘<rep+nom fichier>’;
RMAN > STARTUP NOMOUNT FORCE;
RMAN > RESTORE CONTROLFILE FROM AUTOBACKUP;
RMAN > SQL « ALTER DATABASE MOUNT »;
RMAN > CATALOG RECOVERY AREA NOPROMPT ;
RMAN > CATALOG START WITH ‘rep’ NOPROMPT;
RMAN > SQL « ALTER DATABASE OPEN RESETLOGS »;
5.12.6.8. Scénario 8 : Restauration en mode NOARCHIVELOG
Hypothèses :
• perte de tout ou une partie de la base de données
• mode noarchivelog
Solution : ramener la base de donnée à l'état où elle se trouvait lors de la dernière sauvegarde complète
base fermée. Si les fichiers de journalisation sont disponibles et qu'il n'y a pas eu un cycle complet de
basculement des fichiers de journalisation depuis la dernière sauvegarde, on peut alors tenter une
restauration de type archivelog. Si la récupération signale une erreur, la situation est à priori désespérée.
Dans ce cas, on peut « tenter » une restauration en mode NOARCHIVELOG.
Mode opératoire :
1. Positionner le SID
2. Démarrer l'instance sans la monter
3. Restaurer les fichiers de contrôle à partir d'une sauvegarde automatique
4. Monter la base
5. Restaurer la base
6. (éventuellement) restauration incrémentale
7. Ouvrir la base de données avec option RESETLOGS
Exemple :
RMAN > SET DBID <numero>
RMAN > STARTUP NOMOUNT
RMAN > RESTORE CONTROLFILE FROM AUTOBACKUP;
RMAN > SQL « ALTER DATABASE MOUNT »;
RMAN > RESTORE DATABASE ;
RMAN > RECOVER DATABASE NOREDO;]
RMAN > SQL « ALTER DATABASE OPEN RESETLOGS »;
Soors Aurore
36

37. 5.12.6.9. Scénario 9 : Restauration à un emplacement différent
Hypothèse : impossible de restaurer les fichiers de données dans l'arborescence d'origine.
Solution : utiliser deux commandes supplémentaires dans le processus de restauration (dans un bloc run) :
• Avant la restauration :
SET NEWNAME FOR DATAFILE ‘ancien’ TO ‘nouveau’;
•
Après la restauration mais avant la récupération :
SWITCH DATAFILE ALL;
Exemple :
RUN
{
STARTUP MOUNT
SET NEWNAME FOR DATAFILE <fichier> TO <fichier>.
RESTORE TABLESPACE data;
SWITCH DATAFILE ALL; SWITCH DATAFILE ALL;
RECOVER TABLESPACE data;
SQL « ALTER DATABASE OPEN »;
}
5.12.6.10. Scénario 10 : Tablespace temporaire géré localement
Les fichiers de données des tablespaces temporaires gérés localement ne sont jamais sauvegardés par
RMAN et ne peuvent donc pas être restaurés.
Après une restauration, il faut donc recréer les fichiers de données des tablespaces gérés localement.
5.12.7. Techniques de flashback
Fonctionnalité permettant d'interroger les données telles qu'elles étaient à un instant donné du passé.
Trois niveaux :
• niveau ligne : requête, version, transaction (modification par une ou plusieurs transactions sur un
intervalle de temps).
• niveau table : permet de ramener la table à l'état où elle était à un certain moment dans le passé
ou juste avant un drop.
• niveau base de données : permet de ramener la totalité de la base de donnée à l'état où elle était
à un certain moment dans le passé.
Soors Aurore
37