Administration d'une base de données

Soors Aurore

1

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

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

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. un objet y est « logiquement » stocké. Les tablespaces Les tablespaces sont des unités logiques. Un schéma contient les objets élémentaires comme les tables. La structure logique La structure logique est le niveau le plus abstrait : c'est une collection de schémas. 1. les vues.. Un schéma est répartis en zone logiques. Il est possible d'obtenir les tailles de tous les tablespaces d'une base en effectuant le script suivant : select t. dba_tablespaces t where f. la sécurité et les performances d'une base de données Oracle.1. ces segments sont composées d'extensions. l'utilisation de tablespaces permet d'éviter les risques de contentions et de saturations. 1.1. Soors Aurore 4 .. La taille d'un tablespace est la somme des tailles des fichiers qui le constitue. .1. L'utilisation de tablespaces améliore la maintenance. les déclencheurs.TABLESPACE_NAME. extensions et blocs) permettent de définir l'organisation de la base et le lien entre les niveaux physiques et logiques. En effet. Un tablespace permet à l'administrateur de : • contrôler l''allocation de disque de chacun • regrouper les objets (utilisateur. C'est la taille de ces fichiers qui détermine la capacité de stockage des tablespaces. Ces objets sont aussi appelés objets relationnels. round(sum(f.1.TABLESPACE_NAME group by t. ces tablespaces sont constitués de segments.TABLESPACE_NAM. 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. .TABLESPACE_NAME = t. ces dernières sont organisées en blocs. Ces quatre niveaux (tablespace. Un objet relationnel ne peut être associé qu'à un seul tablespace .bytes)/1024/1024) from dba_data_files f. tablespaces. application. identifiées par un nom.TABLESPACE_NAME order by t. segments. La taille d'une base Oracle est le total des tailles de ses tablespaces.

Si SYSAUX devient indisponible. Lorsqu'un segment est plein. 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 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. extensions et blocs. . Les extensions sont utilisées pour le stockage d'un type spécifique de données. Une extension est une suite de blocs contigus alloués simultanément. C'est l'unité de transfert entre les disques et la mémoire.2. Le tablespace SYSAUX est propre à Oracle 10g. Le bloc « en-tête » de chaque segment contient un répertoire de ses extensions.. Ce tablespace contient un ensemble d'occupants comme les informations systèmes associées à une option comme XDB. 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. OracleSpacial. • segment : est le troisième niveau. • extension : est le deuxième niveau. C'est un tablespace auxiliaire à SYSTEM. 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.1. Oracle alloue une nouvelle extension pour ce segment (allocation à la demande ou incremental extent). les fonctionnalités de base d'Oracle restent accessible. 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). 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 . Les segments.. L'objectif de ce tablespace est de réduire la charge du tablespace SYSTEM.

1.1. Arborescence des répertoires Oracle BASE Directory a la forme suivante \oralce\product\10. 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). Depuis Oracle 9i. 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. 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. Dans les versions antérieures à Oracle 9i.2.2.2. Il est le garant de la cohérence . • les redo log files • les control files 1. il est donc nécessaire d'en faire des copies miroir (trois par défaut). Le fichier de contrôle Le fichier de contrôle sert à localiser les fichiers de données et autres. un fichier de type « texte » est lu lors du démarrage de l'instance. La taille des data files est définie à la création de la base de données avec possibilité d'extension ultérieure.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. 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 .3.0. un fichier binaire réside sur le serveur de base de données appelé SPFILE (server parameter file). Leur localisation est variable excepté pour le premier fichier créé.2.

Pour fermer une base de données : shutdown • non montée (startup nomount) : dans cet état. le fichier d'initialisation est trouvé et lu. Il s'agit d'une zone de mémoire partagée et d'un ensemble de processus. Oracle alloue la zone mémoire (SGA) et démarre les processus d'arrière-plan. 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. Une instance est paramétrée par son INIT. il y a trois niveaux : • niveau fichier • niveau mémoire : qui correspond à l'organisation des données en mémoire centrale. 2.2. Une base de données peut.A. C'est le cas dans l'option R. Les utilisateurs quant à eux. 2. chaque base Oracle est associée à une instance Oracle.1. Indépendamment du serveur. Soors Aurore 7 . Instance de base de données 2. la cohérence de la base de données peut être évaluée. On peut. 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. L'emplacement des fichiers de données est connu et leur existence est traitée. La commutation entre ces instances se fait par la modification de la variable d'environnement ORACLE_SID.ORA.3. Les paramètres sont chargés en mémoire. Les caractéristiques de l'instance se trouvent dans son fichier de paramètres. se connectent à la base de données par l'intermédiaire de l'instance à laquelle ils accèdent. (Real Application Cluster). Au démarrage. 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. par exemple.C. Donc. • ouverte (alter database open) : les fichiers de données sont accessibles à tous les utilisateurs authentifiés. Lorsque l'on arrête une base. le processus de recovery peut être démarré à partir de cet état. on arrête les processus de l'instance. Elle permet de désigner l'instance à laquelle on souhaite se connecter. être accédée par plusieurs instances. de son système d'exploitation et des options d'Oracle.2. • montée (alter database mount) : le fichier de contrôle est lu. Certaines opérations de maintenance (ou al création de la base de données) sont possibles. On distingue les instances d'une base de données grâce au SID (System Identifier). Ensuite. c'est ce que l'on appelle l'instance. C'est l'état normal de la base de données en fonctionnement. agir sur les fichiers de contrôle. à l'inverse. Introduction Dans une instance. Oracle alloue une zone de mémoire appelée SGA (System Global Area) et démarre plusieurs processus propriétaires. Une instance correspond et accède à une et une seule base de données. 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. 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. le système vérifie que la base de données ne nécessite pas un recouvrement (recovery). Si c'est le cas. 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).

2. 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.ora STARTUP [FORCE] [RESTRICT] [PFILE = fichier d'initialisation] {[OPEN][RECOVER]/[MOUNT][NOMOUNT]}. Par défaut. 56463824 86480 22642688 33554432 180224 bytes bytes bytes bytes bytes • • • • • • 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 [ABORT/IMMEDIATE/NORMAL/TRANSACTIONAL]. Total System Global Area Fixed Size Variable Size Database Buffers Redo Buffers Database mounted. IMMEDIATE : refus de nouvelles connexion. sans enregistrement préalable des données contenues dans la SGA. arrêt de l'instance. attente de la déconnexion des utilisateurs et attente de fin de transaction avant l'arrêt. seul le compte SYS peut obtenir une connexion de ce type là.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. déconnexion des utilisateurs. Le mode sysdba Pour les opérations d'administration. NORMAL : mode par défaut : pas de nouvelles connexions et attente de la déconnexion des utilisateurs. 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 . SHUTDOWN • • • • ABORT : arrêt brutal.2. Il est évidemment possible de réaliser toutes ces étapes en une seule commande : sqlplus> startup open pfile=initora8i. TRANSACTIONAL : pas de nouvelles connexions.5. il faut utiliser le mode SYSDBA ou SYSOPER. fermeture de la base de données dans un état cohérent. un recouvrement sera nécessaire au redémarrage. annulation des transactions en cours.

2. 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 .6. La SGA Beaucoup de paramètres définissent la configuration d'une instance (fichier d'initialisation init<SID>. La SGA est l'équivalent du contrôleur dans un modèle MVC. La plus grande partie du travail de tunning est consacrée aux réglages des paramètres des structures contenues dans la SGA.ORA).

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.6.2. 2. Soors Aurore 10 . il doit lire le bloc sur le disque et le placer dans le cache. 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.6. Lorsqu'un processus sollicite l'accès à un bloc qui n'est pas déjà présent en mémoire. 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. NAME -------------------Fixed Size Variable Size Database Buffers Redo Buffers VALUE ---------53732 63677832 184320000 524288 2. Les informations contenues dans le buffer de reprise proviennent des zones mémoires réservées aux utilisateurs.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).

2. emplacements des extents. Soors Aurore 11 .6. Oracle utilise un algorithme LRU (Last Recently Used) pour gérer le cache : en cas de manque de place. Dans la pratique. nom des fichiers de données. 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. Lorsqu'une requête est exécutée pour la première fois. descriptions des tables et privilèges). le Library Cache ayant une taille finie. elle lit les tables du dictionnaire et place les informations extraites dans le cache du dictionnaire. Oracle stocke le résultat de l'analyse dans le Library Cache puis exécute la requête. 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). noms des segments. 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. Lorsque la même requête est de nouveau exécutée plus tard. 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).3.

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.1. • Dnnn (Dispatcher.2. 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. Les processus Oracle 3. • ORALSN .2. Les processus background Le but des ces processus est d'améliorer ses performances en présence de plusieurs utilisateurs. Chaque processus joue un rôle très précis. Il permet de dupliquer les fichiers Redo-Log dans un espace d'archivage • LCK (Lock) : processus permettant un verrouillage inter-instance. Un processus dispatcher permet qu'un processus serveur soit partagé par plusieurs processus utilisateurs (architecture à serveur partagé). 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 . 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. • 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. Dans la littérature. Ces processus sont automatiquement créés lors du démarrage d'une instance. 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. les processus d'arrière-plan (background process).3. nnnn représente une suite de nombre entiers) : les processus dispatcher sont nécessaires à l'architecture à serveur partagé. Le processus PMON Le processus PMON (Process Monitor) est responsable du recouvrement des processus utilisateurs en cas de problèmes.Listener 3. chaque processus utilisateur nécessite un processus serveur (architecture à serveurs dédié).1. Sans dispatcher. En plus des processus background. il y a également les processus clients et les processus serveurs (listener et dispatcher). on appelle ces processus. 3. Introduction Une instance oracle est composée d'un ensemble impressionnant de divers processus.

• 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.2. 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. 3. 3.3.3. 3. Le processus ORALSN Le processus listener ne fait pas précisément partie d'une instance mais est intégré à Oracle Net. il sera placé en attente. WHERE nom COMMIT. Soors Aurore 13 .2.2. et toute l'activé de la base sera suspendue jusqu'à la fin de l'archivage. Le processus utilisateur peut alors directement se connecter au dispatcher. Dans une architecture à serveur partagé. La communication entre processus dispatcher et listener se déroule de la manière suivante : • lors du démarrage de l'instance. 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. Pendant que ARCH recopie un fichier redo. 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). UPDATE professeurs SET salaire = salaire * 2 WHERE nom ='Lebucheron'. 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. le processus listener lui retourne l'adresse du dispatcher le moins chargé.5. il le verrouille de sorte qu'aucun autre processus ne puisse y accéder.4.3. 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. il démarre un serveur dédié auquel il connecte le client en question. 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. L'activation de ce processus permet de réaliser des sauvegardes à chaud de la base (hot backup). Lebucheron . 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. Si le processus listener ne peut rediriger un client vers un processus dispatcher. 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é. le processus revover résout les problèmes engendrés par la transaction concernée.4. 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).

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

Soors Aurore 15 .5. analyse et exécute les requêtes.3. 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.

Soors Aurore 16 .

Soors Aurore 17 .

créer une table ou se connecter à la base.2. Les privilèges systèmes permettent aux différents utilisateurs de réaliser des opérations ou des catégories d'opérations. Pour simplifier la gestion des privilèges. Les actions qui peuvent être exécutées sur chaque type d'objet sont autorisées via des privilèges séparés.1. Privilèges système Les privilèges système sont nécessaire pour pouvoir exécuter certaines commandes. 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. 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 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. 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. Un profil est créé au moyen de l'instruction create profil. 4. Ils offrent ainsi un contrôle de la sécurité d'accès très poussé. c'est celui par défaut qui est utilisé.1. La clause ANY permet de spécifier que le privilège porte sur tous les schémas de la base de données.4. 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. 4. il faut en être le propriétaire ou avoir reçu le privilège avec l'autorisation de le transmettre (clause with grant option). Ce profil spécifie une utilisation des ressources non limitées.3.1.1. Soors Aurore 18 . Lorsque aucun profil n'est défini.1. il est également possible de définir des rôles. Pour faciliter la gestion des ces privilèges. Privilèges objet Contrôle de l'accès aux objets au moyen de privilèges via la commande grant. Sécurité de compte Pour accéder aux données d'une base oracle. Ces privilèges ne portent pas sur un objet bien précis mais plutôt sur un type de commandes comme. Utilisateurs et privilèges 4. par exemple. Un compte de base de données peut aussi être lié à un compte du système d'exploitation.2. 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.

Cette sauvegarde est aussi appelée « sauvegarde base fermée ». 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). Vue d'ensemble Assurer la sécurité est une des taches principales. restauration et récupération 5. La protection des fichiers de contrôles et de journalisation s'effectue par multiplexage. Le mode Archivelog permet de garantir 0 perte de données en cas d'incident sur un fichier de données. Les fichiers sauvegardés ne sont pas synchrones au niveau des modifications enregistrées. il est nécessaire d'utiliser le mode ARCHIVELOG • complète : totalité de la base • partielle : uniquement une partie de la base. Sauvegarde. 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. Il limite les risques de fausse manœuvre et peut être utilisé de manière graphique via le database control. 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. Le mode Archivelog Après T0. 5. fichiers de journalisation) • la mise en place d'une stratégie de sauvegarde/restauration adaptée aux contraintes de l'entreprise. générant des entrées dans les fichiers de journalisation.5. Pour utiliser cette stratégie de sauvegarde. Il faudra utiliser les fichiers de journalisation pour rendre les fichiers cohérents.5. 5. 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. Cet archivage est organiser de manière circulaire. Stratégie de sauvegarde • sauvegarde cohérente : sauvegarde de la totalité de la base après un arrêt propre. les fichiers de journalisation plein sont archivés.3. En T1. sauvegarde incohérente entre elle. Ces fichiers peuvent être ré-appliqués à une sauvegarde de fichiers de données. mode archivelog • incrémentale : on ne sauvegarde que les blocs modifiés depuis la dernière sauvegarde. le fichier de données est perdu. L'archivage étant activé. 5. pour rejouer les modifications survenues entre la sauvegarde et un incident ayant endommagé le fichier (restauration de média). La restauration du fichier consiste à prendre la dernière sauvegarde et à appliquer sur cette sauvegarde les fichiers de journalisation archivés. Solutions de sauvegarde et restauration L'outil Recovery Manager (RMAN) est un outil en ligne de commande.4. 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.1. l'activité de mise à jour se produit. Archivage des fichiers de journalisation Les fichiers de journalisation fichiers constituent un journal des modification apportées à la base de données.2. testée et documentée. 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. consultation la journée? (application décisionnelle) 5. un incident se produit. Soors Aurore 19 .

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. 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. il faut également déplacer le tablespace qui contient ses index. On place les tablespaces que l'on souhaite déplacer en mode read only : alter tablespace NEW_DATA read only. Export est appelé en ligne de commande et possède de nombreux paramètres. Ainsi. Un ensemble de tablespaces transportables contient tous les fichiers de données des tablespaces déplacés. 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. des index. 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. Outils logiques 5. Pour exporter des tables dont on n'est pas le propriétaire. ils ne devraient pas contenir d'objets dépendants d'autres objets extérieurs aux tablespaces transportés. des contraintes. .5. Mode Complet Utilisateur Table Description Exporte les données. mode ligne de commande et mode fichier de paramètres. import.6. alter tablespace NEW_DATA_IDX read only. si on souhaite déplacer une table. 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 Exporte les données. Import supporte pratiquement les mêmes paramètres que export.1. 5. il faut posséder le privilège système CREATE SESSION. 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 Exporte les données. par exemple. • générer un ensemble d'instructions SQL pouvant être utilisées pour créer des tables..3.2. ainsi qu'une copie exportée des métadonnées des tablespaces concernés.6.. Importation de données : Import L'utilitaire lit les fichiers créés à partir de export. Pour déterminer si un tablespace est fonctionnellement autonome. Les tablespaces doivent être fonctionnellement autonomes. Import possède exactement les même modes de fonctionnement que l'utilitaire export : mode interactif. il faut avoir le rôle EXP_FULL_DATABASE qui est compris dans le rôle DBA. Un tablespace transportable Un tablespace transportable permet de copier aisément et de déplacer un tablespace d'une base vers une autre. Le paramètre compress permet de reconstruire plus aisément une table morcelée en plusieurs extents en un seul extent. les données à extraire et où il faut les placer. Ces paramètres lui indiquent.6. Soors Aurore 20 .6. 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. • 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.

des métadonnées et des informations de contrôle d'une base pour les enregistrer dans un ou plusieurs fichiers de transfert. etc). 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. Ils présentent des analogies avec export et import des versions antérieures d'Oracle mais sont en fait différents. Soors Aurore 21 . 5. copy.dbf. des packages. Ces utilitaires servent à transporter des données et des métadonnées d'une base à une autre. • 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. seules les métadonnées sont exportées. • tablespace transportable : dans ce mode. 5. 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. Les principales fonctionnalités de cet utilitaire sont • l'extraction des instruction LDD sans les exécuter. dont le format propriétaire ne peut être lu que par DP Import. par exemple.1. alter tablespace NEW_DATA_IDX read write. Les métadonnées extraites par ce package sont au format XML.4. dans une base de données cible sur un autre serveur et un système d'exploitation différent. grâce au package DBMS_DATAPUMP.dbf. Les éléments contenus dans ces fichiers dump. via DP Import. Il reste à connecter les tablespaces déplacés à la table cible : imp TRANSPORTABLE TABLESPACE=Y DATAFILES=(new_data1. des instructions LDD de tables.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. • exportation de tablespace : permet d'exporter toutes les tables stockées dans les tablespaces spécifiés dans le paramètre tablespace. des vues.new_data_idx. Il permet l'exportation de un ou plusieurs schémas de la base de données. 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. DP Export peut extraire des données de tables. etc.new_data2. • exportation de schéma : c'est le mode par défaut. Exportation avec Data Pump L'utilitaire s'appelle expdp. peuvent être chargés. 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).4. ftp. des privilèges.Ensuite. ils offrent des performances supérieures en utilisant le traitement parallèle.6. • exportation de table : permet d'exporter des tables ou des partitions ainsi que les objets dépendants. ou fichier dump.6. • importation directe via le réseau en utilisant comme source une base de données plutôt que des fichier dump. En effet.dbf) On termine en plaçant les tablespaces en module lecture-écriture dans la base cible : alter tablespace NEW_DATA read write.

log • exportation des tables clients et ventes du schéma scott : expdp system/manager DUMPFILE=scott.. Soors Aurore 22 . Importation avec Data Pump impdp permet de réaliser des importations à partir des fichiers dump construit par expdp. Il est cependant possible de réaliser une importation à partir d'une exportation plus élevée dans la hiérarchie. d'une tablespace et de la base complète. scott.. Elle sert souvent à rétablir la base dans l'état où elle était juste avant qu'un incident ne survienne.7.. . • Sauvegarde à froid : signifie que tous les utilisateurs sont déconnectés et que la base est arrêtées.log 5. bande. 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. Définitions • Sauvegarde (backup) : copie d'un ensemble de fichiers (de données.dmp FULL=Y LOGFILE=import.dmp FULL=Y LOGFILE=export.1.4. il est possible d'importer une table à partir de l'exportation d'un schéma. l'exécution malheureuse d'un drop tablespace. disons jusqu'à un point précis dans le temps.) autre que ceux contenant les données originales.dmp TABLES=scott. Par exemple..ventes LOGFILE=export. .clients.) sur un support (disque. Si plusieurs filtres s'appliquent à un même job. • Sauvegarde à chaud : signifie que la base est accessible pendant la sauvegarde : les utilisateurs restent donc connectés. Exemple : importation complète d'une base de données : impdp system/manager DUMPFILE=expdata. Ceci est même possible par le réseau et il est également permis d'utiliser des filtres.7.2. • Restauration (restore) : remplacement des fichiers altérés à partir d'une sauvegarde. 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. • Récupération complète : implique de ré-appliquer toutes les instructions consignées dans le journal des images après. • Récupération incomplète : consiste à ré-appliquer seulement une partie du journal des images après. Il possède cinq modes de fonctionnement qui correspondent à ceux de l'exportation. dvd. • Récupération ou recouvrement (recovery) : reconstruction d'une base en utilisant le journal des images après. Ces derniers peuvent même modifier les données pendant la sauvegarde. elle ne s'accompagne d'aucune perte de données. de contrôles redo.log 5. En principe. Exemples d'exportation : • exportation complète d'une base de données : expdp system/manager DUMPFILE=expdata. Par exemple.6. Rappels 5. ils sont reliés par l'opérateur and.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 contenu des tampons est d'abord consigné dans le cache des fichiers redo.7. 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. Passer la base de données en mode ARCHIVELOG 5. Que faut-il sauvegarder? • Le code oracle désigne les programmes qui constituent le logiciel Oracle une fois installé sur le serveur. Oracle écrit dans les fichiers de redo de manière circulaire : • lorsque le fichier courant est rempli. les CD (DVD) sources ou site web. pas immédiatement recopiés sur disque. ces tampons ne sont. 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. init. La restauration est plus rapide que l'installation. • Le fichier des alertes : ce fichier consigne de nombreux évènements tels que les démarrages et arrêts. 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. les tampons du cache des données le sont également pour refléter ces changements. en général. avant d'écraser un fichier de redo l'avoir recopié ailleurs. les checkpoints.3.5. • Les fichiers de paramètres : le fichier de paramètre au format texte. ainsi que les SCN qui correspond à l'incarnation courante de la base de données. Mode opératoire 1. et ainsi de suite jusqu'à utiliser le premier. il écrit dans le suivant. Ces fichiers changent très peu. (Sauvegarder la base de données) 6.7. 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.8. spfile. Modifier dans le spfile les paramètres concernant les processus d'archivage 2. Arrêter proprement la base de données 3. le support Oracle les demande pour analyser certain problèmes. • Lorsqu'une base est configurée pour qu'elle archive les fichiers de redo. On dit qu'il faut archiver les fichier redo.1. Par exemple. pour avoir un véritable journal des images après. Les fichiers redo Lorsque les données sont modifiées dans Oracle. Pour des raisons de performances. Ouvrir la base de données Soors Aurore 23 . mais pas les secondes. • dès lors. mais devraient être sauvegardés de sorte que l'état courant de l'instance puisse être recrée. • 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.ora. 5.2. ce fichier permet de retrouver à quelle heure a eu lieu un drop tablespace malheureux 5. on dit qu'elle fonctionne en mode archivelog. Archivage des redo log files 5. Il peut être très utile de disposer de ces informations en cas de récupération incomplète. • Les fichiers redo archivés • Tablespace undo ou segments d'annulation • Les fichiers de données • Les fichiers de trace : dans certaines circonstances.8. • 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. Monter la base de données 4. le nom du fichier redo en ligne courant et des informations sur le dernier checkpoint. • 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. il faut.ora ou celui au format binaire.

les sauvegardes réalisées. 3 SCOPE=MEMORY.SQL 2 3 SQL 2 3 SQL SQL SQL SQL • • • • • > ALTER SYSTEM SET log_archive_format=‘redo_%S_%R_%T. Présentation de RMAN 5. Il utilise un repository pour stocker des informations sur sa configuration. Si utilisation d'une flash recovery area. > ALTER SYSTEM SET log_archive_dest_1=‘LOCATION=<repertoire>’ SCOPE=SPFILE. la structure de la base de données. ce qui permet d'indiquer combien de temps une sauvegarde doit être conservée (définition complémentaire). Le repository est stocké dans le fichier de contrôle et peut également être stocké dans un catalogue de récupération. Pour chaque opération. > SHUTDOWN IMMEDIATE > STARTUP MOUNT > ALTER DATABASE ARCHIVELOG. les fichiers archivés.2. > 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. Problèmes courants • manque d'espace • destination inaccessible SQL 2 3 SQL > ALTER SYSTEM SET log_archive_dest_1=‘LOCATION=<rep>’ SCOPE=MEMORY. RMAN RMAN permet la réalisation de sauvegarde et de restauration. RMAN gère les sauvegardes obsolètes. > ALTER SYSTEM ARCHIVE LOG START 5. Soors Aurore 24 .arc’ SCOPE=SPFILE.1.8.9.9. etc. 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). il est possible de bénéficier des fonctionnalités de sauvegarde et de restauration.

Sauvegarde 5. 5. 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.10. de contrôle. de paramètres serveur.5. RMAN > CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ‘<format>’.9. Configurer RMAN RMAN dispose de plusieurs réglages persistants utilisés par défaut.2. 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. SPOOL.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. Une sauvegarde RMA peut être réalisée sous la forme d'une copie image ou d'un jeu de sauvegarde (défaut). Configurer la politique de conservation. Soors Aurore 25 .10. RMAN > CONFIGURE RETENTION POLICY TO REDUNDANCY n. des éléments de sauvegarde. etc).3. Dans un jeu de sauvegarde. 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.9. il n'y a pas de sauvegarde des blocs jamais utilisés des bloc (et donc gain de place) et compression possible. RMAN peut sauver des fichiers de données. Lancer RMAN Ligne de commande : > RMAN target / > RMAN target sys/aletest@aletest.1. 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.

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.3.2.2.10. du fichier de journalisation courant 5. Soors Aurore 26 . Archivage. 5.2. Sauvegarde des autres éléments 4. à nouveau.2. RMAN > BACKUP ARCHIVELOG FROM TIME ‘SYSDATE-1’ DELETE ALL INPUT.2. 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. index. Manipulations 5. RMAN > BACKUP DATABASE PLUS ARCHIVELOG DELETE ALL INPUT.10. 5. BACKUP SPFILE. Sauvegarde du fichier de contrôle et du spfile BACKUP … INCLUDE CURRENT CONTROLFILE. RMAN > BACKUP INCREMENTAL LEVEL 1 DATABASE. Sauvegarde de tous les fichiers de journalisation archivés 3. BACKUP TABLESPACE system DATAFILE 5. Sauvegarde de la totalité de la base de données RMAN > BACKUP [VALIDATE] DATABASE. PLUS ARCHIVELOG : 1. RMAN > RMAN > RMAN > 5.. RMAN > BACKUP AS COMPRESSED BACKUPSET ARCHIVELOG FROM TIME ‘SYSDATE-7’ NOT BACKED UP 2 TIMES.10. Archivage du fichier de journalisation courant 2. BACKUP AS COPY CURRENT CONTROLFILE.2..10.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. RMAN > BACKUP DATABASE PLUS ARCHIVELOG.10.5.2.10. Sauvegarde incrémentale Elle permet de sauvegarder uniquement les blocs qui ont été modifiés depuis la dernière sauvegarde. ‘<rep/fichier>’.2. A utiliser plutôt lorsque l'activité de mise à jour est relativement faible RMAN > BACKUP INCREMENTAL LEVEL 0 DATABASE.1. BACKUP CURRENT CONTROLFILE.4. Commande BACKUP . RMAN > RMAN > RMAN > RMAN > Sauvegarde de tablespaces ou fichiers de données BACKUP TABLESPACE user. BACKUP DATAFILE 1.

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

5.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. Commande : RMAN > BACKUP DATABASE PLUS ARCHIVELOG DELETE INPUT 5.5. RMAN > SQL « ALTER DATABASE OPEN ».10.10. Sauvegarde complète (incohérente) Sauvegarde complète + sauvegarde des fichiers de journalisation + suppression des fichiers de journalisation archivés sauvegardés. 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.6. # Sauvegarde 3 : le reste RMAN > BACKUP DATABASE NOT BACKED UP SINCE TIME=‘SYSDATE-3’ PLUS ARCHIVELOG DELETE INPUT. RMAN > BACKUP DATABASE.10. Soors Aurore 28 . 5.2 PLUS ARCHIVELOG DELETE INPUT.10.5. # Lundi au Samedi : sauvegarde incrémentale cumulative de niveau 1 RMAN > BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE. RMAN > STARTUP MOUNT. 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. Sauvegarde complète (cohérente) Commande (avec RMAN) : RMAN > SHUTDOWN IMMEDIATE.4. # Sauvegarde 2 : fichiers de données 3 et 4 RMAN > BACKUP DATAFILE 3.7.4 PLUS ARCHIVELOG DELETE INPUT.

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

2.11.12.1.12. Lister les sauvegardes obsolètes RMAN > REPORT OBSOLETE [condition]. Gérer le repository 5. RMAN > CROSSCHECK ARCHIVELOG [ALL | filtre_archive]. 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].11. Variantes possibles : • supprimer des sauvegardes ou fichiers de journalisation • supprimer les sauvegardes obsolètes. RMAN > CROSSCHECK {BACKUPSET | BACKUPPIECE}{liste_cles | tags}. Au minimum une sauvegarde du fichier de contrôle et des ficher de journalisation en ligne. 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.11. 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. Restauration 5.2. 5.2.1. 5. 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. 5.2. Cas possibles : • mauvais emploi de DELETE. Options : • Conditions ◦ recovery window of n days ◦ redundancy = n 3.3.2. Soors Aurore 30 . réaliser une sauvegarde complète de la base endommagée. La commande DELETE Elle permet de supprimer des sauvegardes (suppression physique + dans le repository).2. Afficher la liste des fichiers de données de la base de données RMAN > REPORT SCHEMA.11.

2.12. Principes généraux 5. 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.2.12. 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.1. 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. Soors Aurore 31 .2.2.12. si des fichiers de journalisation sont perdus 5. 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.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. ◦ 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.3.

RMAN recherche les fichiers de journalisation archivés dont il a besoin en premier lieu sur le disque.5. d'abord résoudre ces problèmes avant de traiter le cas des fichiers de données.1.12.5. 5. Scénarios de restauration 1. ou de contrôle.6. 4. Ensuite RMAN se charge de tout : • identifier les sauvegardes à utiliser. 3. 5. 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. 7. • en extraire les fichiers requis. Soors Aurore 32 . ou de journalisation est perdu. • identifier les fichiers de journalisation archivés nécessaires • les extraire d'une sauvegarde s'ils ont été sauvegardés puis supprimés 5.5.12.2. Les fichiers de journalisation archivés manquant sont automatiquement restaurés à partir de sauvegardes. 8.12.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. vers le répertoire d'archivage défini par le paramètre LOG_ARCHIVE_DEST_1 5. La commande RECOVER RMAN > RECOVER cible [options] Lors de l'opération de récupération. 10.12. 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. 9. 2. Les commandes RMAN L'objectif principal est de bien choisir la cible en fonction de la nature du problème. 6. 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.

Mode opératoire : 1. Utiliser le fichier d'alerte de l'instance pour identifier les fichiers perdus 3. SQL > SHUTDOWN IMMEDIATE SQL > STARTUP Soors Aurore 33 . Mode opératoire : 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. il faut modifier le paramètre CONTROL_FILES dans le fichier du SPFILE.5. # si cela échoue.6. Démarrer l'instance sans la monter 2. 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. Dupliquer une version valide du fichier de contrôle pour la mettre à la place de celui endommagé 4. # redémarrer l’instance et l’ouvrir RMAN > SHUTDOWN RMAN > STARTUP 5. Redémarrer la base de données Si le fichier de contrôle est dupliqué à un autre emplacement que celui d'origine. restaurer à partir d’une sauvegarde spécifique RMAN > RESTORE SPFILE FROM ‘<fichier>’. RMAN > RESTORE SPFILE FROM AUTOBACKUP. ou si utilisation d’une sauvegarde qui n’est pas une sauvegarde automatique.6. 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.2. Modifier le paramètre CONTROL_FILES du SPFILE 3.1.12. 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.12. Arrêter la base de données 2.

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. Supprimer le membre endommagée SQL > ALTER DATABASE DROP LOGFILE MEMBER ‘nom_fichier’.12.6. Identifier le/les fichier(s) endommagé(s) dans le fichier des alertes. # récupérer la DB #p RMAN > RECOVER DATABASE DELETE ARCHIVELOG MAXSIZE 200M.12. Dans ce cas. 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). et qu'elle ne peut pas être ouverte tout de suite. # ouvrir la DB RMAN > SQL « ALTER DATABASE OPEN ».5. 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. 4.6. Mode opératoire : 1. Si la base de données est fermée. 5. 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. Scénario 3 : Restauration d'un fichier de journalisation Même stratégie avec la recréation des fichiers. on peut reporter la correction du problème à plus tard. Ajouter un nouveau membre au groupe concerné SQL > ALTER DATABASE ADD LOGFILE MEMBER ‘nom_fichier’ TO GROUP numero.4.3.6.5. 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 . 5. dans le fichier de trace de LGWR ou dans la vue V$LOGFILE 2. 3.12.

sous entendu un CROSSCHECK et CATALOG) 7. Positionner le SID correspondant 2. Restaurer les fichiers de contrôle à partir d'une sauvegarde automatique 4. # récupérer les fichiers de données # récupérer les fichiers de données RMAN > RECOVER TABLESPACE system. Monter la base de donnée 5. Ouvrir la base de données avec l'option « RESETLOGS » (obligatoire) Exemple : RMAN > SET DBID <numero> RMAN > STARTUP NOMOUNT RMAN > RESTORE CONTROLFILE FROM AUTOBACKUP. ◦ #mettre les TBS concernés offline RMAN > SQL « ALTER DATABASE indx OFFLINE IMMEDIATE ». #récupérer les fichiers de données RMAN > RECOVER DATAFILE 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. 5. # ouvrir la DB RMAN > SQL « ALTER DATABASE OPEN ».6.12. 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 ». 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. #restaurer les fichiers de données souhaitées RMAN > RESTORE DATAFILE 6. #passer ONLINE les tablespaces concernés RMAN > SQL « ALTER TABLESPACE indx ONLINE. Soors Aurore 35 .6. Démarrer l'instance sans la monter 3.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. RMAN > SQL « ALTER DATABASE MOUNT ». RMAN > RESTORE DATAFILE 5. RMAN > RECOVER DATABASE. RMAN > SQL « ALTER DATABASE OPEN RESTLOGS ». Restaurer les fichiers perdus 6. # ouvrir la DB # ouvrir la DB RMAN > SQL « ALTER DATABASE OPEN ».

Mode opératoire : 1. Démarrer l'instance sans la monter 3. on peut « tenter » une restauration en mode NOARCHIVELOG.6. Restaurer le fichier de paramètres serveur 4. RMAN > RECOVER DATABASE NOREDO. Dans ce cas.8. 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. Restaurer la base 6. Restaurer les fichiers de contrôle 6. RMAN > CATALOG RECOVERY AREA NOPROMPT . RMAN > SQL « ALTER DATABASE MOUNT ». Monter la base 7. Positionner le SID 2. etc) Dans tous les cas. on peut alors tenter une restauration de type archivelog. Monter la base 5.] RMAN > SQL « ALTER DATABASE OPEN RESETLOGS ». il faut identifier le point de retour (SCN. 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. RMAN > SQL « ALTER DATABASE MOUNT ». Démarrer l'instance sans la monter 3. 5. Positionner le SID 2.5. fichier de contrôle. Restaurer les fichiers de contrôle à partir d'une sauvegarde automatique 4. sequence) souhaité.12.7. Ouvrir la base de données avec option RESETLOGS Exemple : RMAN > SET DBID <numero> RMAN > STARTUP NOMOUNT RMAN > RESTORE CONTROLFILE FROM AUTOBACKUP. Si la récupération signale une erreur. RMAN > CATALOG START WITH ‘rep’ NOPROMPT.6. 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. la situation est à priori désespérée. Scénario 7 : Restauration incomplète en mode ARCHIVELOG Hypothèse : tout est perdu : fichier SPFILE. fichier de données. Soors Aurore 36 . (éventuellement) restauration incrémentale 7. Mode opératoire : 1. RMAN > RESTORE CONTROLFILE FROM AUTOBACKUP. Redémarrer l'instance sans la monter (démarrage avec le SPFILE) 5. RMAN > STARTUP NOMOUNT FORCE.12. RMAN > SQL « ALTER DATABASE OPEN RESETLOGS ». 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>’. timestamp. RMAN > RESTORE DATABASE .

} 5.5.6.9. RESTORE TABLESPACE data. • niveau table : permet de ramener la table à l'état où elle était à un certain moment dans le passé ou juste avant un drop.12. SWITCH DATAFILE ALL. Exemple : RUN { STARTUP MOUNT SET NEWNAME FOR DATAFILE <fichier> TO <fichier>. transaction (modification par une ou plusieurs transactions sur un intervalle de temps). il faut donc recréer les fichiers de données des tablespaces gérés localement. Soors Aurore 37 .7.10. 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’. version.12. RECOVER TABLESPACE data. • 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é. Après une restauration. 5. Trois niveaux : • niveau ligne : requête. 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.12. Scénario 9 : Restauration à un emplacement différent Hypothèse : impossible de restaurer les fichiers de données dans l'arborescence d'origine. Techniques de flashback Fonctionnalité permettant d'interroger les données telles qu'elles étaient à un instant donné du passé. • Après la restauration mais avant la récupération : SWITCH DATAFILE ALL. SWITCH DATAFILE ALL. SQL « ALTER DATABASE OPEN ».6.

Sign up to vote on this title
UsefulNot useful