Administration d'une base de donnes

Soors Aurore

Table des matires

1. Architecture d'une base de donnes..................................................................................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 paramtres................................................................................6 1.2.2. Le fichier de contrle......................................................................................6 1.2.3. Arborescence des rpertoires.............................................................................6 2. Instance de base de donnes..........................................................................................7 2.1. Introduction........................................................................................................7 2.2. Notion d'instance..................................................................................................7 2.3. Les tats d'une base..............................................................................................7 2.4. Arrt et dmarrage 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 connects........................................................................13 3.4. La circulation des donnes.....................................................................................13 3.5. Variantes architecturales.......................................................................................15 4. Utilisateurs et privilges..............................................................................................18 4.1. Niveaux de scurit..............................................................................................18 4.1.1. Scurit de compte........................................................................................18 4.1.2. Privilges objet............................................................................................18 4.1.3. Privilges systme.........................................................................................18 4.2. Cration d'un utilisateur........................................................................................18 5. Sauvegarde, restauration et rcupration..........................................................................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. Stratgie de sauvegarde........................................................................................19 5.6. Outils logiques....................................................................................................20 5.6.1. Exportation de donnes : Export........................................................................20 5.6.2. Importation de donnes : 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. Dfinitions..................................................................................................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 opratoire...........................................................................................23 5.8.2. Problmes courants........................................................................................24 5.9. Prsentation 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. Gnralits................................................................................................25 5.10.2. Manipulations.............................................................................................26 5.10.2.1. Sauvegarde de la totalit de la base de donnes.............................................26 5.10.2.2. Sauvegarde de tablespaces ou fichiers de donnes...........................................26 5.10.2.3. Sauvegarde du fichier de contrle et du spfile................................................26 5.10.2.4. Sauvegarde de fichier archivs ..................................................................26 5.10.2.5. Sauvegarde incrmentale.........................................................................26 5.10.2.6. Sauvegarde incrmentale.........................................................................27 5.10.3. Scnario....................................................................................................28 5.10.4. Sauvegarde complte (cohrente).....................................................................28 5.10.5. Sauvegarde complte (incohrente)..................................................................28 5.10.6. Sauvegarde partielle base ouverte....................................................................28 5.10.7. Sauvegarde incrmentale...............................................................................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. Grer 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 gnraux.......................................................................................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 contrle..................................................................31 5.12.4. Identification de la nature des problmes............................................................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. Scnarios de restauration...............................................................................32 5.12.6.1. Scnario 1 : Restauration du SPFILE.............................................................33 5.12.6.2. Scnario 2 : Restauration d'un fichier de contrle............................................33 5.12.6.3. Scnario 3 : Restauration d'un fichier de journalisation.....................................34 5.12.6.4. Scnario 4 : Restauration complte de la totalit d'une base de donnes en mode ARCHIVELOG....................................................................................................34 5.12.6.5. Scnario 5 : Restauration complte d'une partie d'une base de donnes en mode ARCHIVELOG....................................................................................................34 5.12.6.6. Scnario 6 : Restauration des fichiers de contrle en mode ARCHIVELOG.................35 5.12.6.7. Scnario 7 : Restauration incomplte en mode ARCHIVELOG...............................36 5.12.6.8. Scnario 8 : Restauration en mode NOARCHIVELOG..........................................36 5.12.6.9. Scnario 9 : Restauration un emplacement diffrent......................................37 5.12.6.10. Scnario 10 : Tablespace temporaire gr localement......................................37 5.12.7. Techniques de flashback................................................................................37

Soors Aurore

1. Architecture d'une base de donnes

Une base de donnes est compose de deux niveaux : niveau logique niveau physique Les informations de description et de comportement constituant ces deux niveaux sont enregistres dans le dictionnaire. 1.1. La structure logique La structure logique est le niveau le plus abstrait : c'est une collection de schmas. Un schma contient les objets lmentaires comme les tables, les vues, les dclencheurs, ... . Ces objets sont aussi appels objets relationnels. Un schma est rpartis en zone logiques, tablespaces; ces tablespaces sont constitus de segments; ces segments sont composes d'extensions; ces dernires sont organises en blocs. Ces quatre niveaux (tablespace, segments, extensions et blocs) permettent de dfinir l'organisation de la base et le lien entre les niveaux physiques et logiques. 1.1.1. Les tablespaces Les tablespaces sont des units logiques, identifies par un nom. Un objet relationnel ne peut tre associ qu' un seul tablespace ; un objet y est logiquement stock. L'utilisation de tablespaces amliore la maintenance, la scurit et les performances d'une base de donnes Oracle. En effet, l'utilisation de tablespaces permet d'viter les risques de contentions et de saturations. Un tablespace permet l'administrateur de : contrler l''allocation de disque de chacun regrouper les objets (utilisateur, application, groupe d'utilisateurs) dfinir un quota chaque utilisateur contrler la disponibilit des donnes (online/offline) raliser des sauvegardes/recouvrements partiels rpartir le stockage des donnes sur plusieurs disques

A un tablespace sont associs un ou plusieurs fichiers de donnes o seront stocks les objets lui appartenant. C'est la taille de ces fichiers qui dtermine 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

Le tablespace SYSTEM contient les tables du dictionnaire et peut suffire pour une petite base de donnes. Il est conseill d'utiliser un autre tablespace pour les utilisateurs (sparation du dictionnaire) car cela assure une meilleur flexibilit pour l'administration et une rduction des contentions. Le tablespace SYSAUX est propre Oracle 10g. C'est un tablespace auxiliaire SYSTEM. L'objectif de ce tablespace est de rduire la charge du tablespace SYSTEM. Si SYSAUX devient indisponible, les fonctionnalits de base d'Oracle restent accessible. Ce tablespace contient un ensemble d'occupants comme les informations systmes associes 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 raliser le recovery d'assurer la lecture cohrente des donnes des possibilits de flashback 1.1.2. Les segments, extensions et blocs. Il y a trois niveaux de granularit utiliss par Oracle pour stocker les donnes : bloc de donnes (bloc logique) : est le niveau le plus fin. C'est l'unit de transfert entre les disques et la mmoire. extension : est le deuxime niveau. Une extension est une suite de blocs contigus allous simultanment. Les extensions sont utilises pour le stockage d'un type spcifique de donnes. segment : est le troisime niveau. Un segment est un ensemble d'extensions (pas forcment contige) alloues 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-tte de chaque segment contient un rpertoire de ses extensions.

Il existe diffrents types de segments : segments de donnes segments d'index segment d'annulation segments temporaire segments d'amorage

Soors Aurore

1.2. La structure physique Il existe trois types de fichiers : les data files qui contiennent les donnes de la base c'est dire les objets dfinis par les utilisateurs et les objets ncessaires au bon fonctionnement de celle-ci. La taille des data files est dfinie la cration de la base de donnes avec possibilit d'extension ultrieure. Leur localisation est variable except pour le premier fichier cr. les redo log files les control files 1.2.1. Les fichiers de paramtres Les fichiers de paramtres contiennent les paramtres ncessaires la configuration d'un serveur dfinis dans un fichier de paramtres appel PFILE (parameter file). Dans les versions antrieures Oracle 9i, un fichier de type texte est lu lors du dmarrage de l'instance. Depuis Oracle 9i, un fichier binaire rside sur le serveur de base de donnes appel SPFILE (server parameter file). Modification de la valeur d'un paramtre : ALTER SYSTEM SCOPE = SPFILE (effectif au prochain redmarrage) SCOPE = MEMORY (immdiat mais non persistant) SCOPE = BOTH (immdiat et persistant) 1.2.2. Le fichier de contrle Le fichier de contrle sert localiser les fichiers de donnes et autres. Il est le garant de la cohrence ; il est donc ncessaire d'en faire des copies miroir (trois par dfaut). Le fichier de contrle comprend aussi : le nom de la base de donnes les noms et emplacements des fichiers de donnes les noms et emplacements des fichiers Redolog (journaux des images aprs ) une estampille prcisant la date de cration de la base de donnes

1.2.3. Arborescence des rpertoires Oracle BASE Directory a la forme suivante \oralce\product\10.2.0.1, celle-ci contient un rpertoire \ORACLE_HOME \oradata pour les fichiers de la base de donnes \flash_recovery_area pour les oprations de recouvrement \admin pour les fichiers d'administration de la base de donnes Soors Aurore 6

2. Instance de base de donnes

2.1. Introduction Dans une instance, il y a trois niveaux : niveau fichier niveau mmoire : qui correspond l'organisation des donnes en mmoire centrale. C'est un ensemble de zones tampons alloues par Oracle pour contenir les donnes et certaines informations de contrle niveau processus : qui correspond aux diffrents processus Oracle assurant la gestion des donnes (les processus utilisateurs excutent les applications et les processus Oracle assurent la gestion des donnes). Indpendamment du serveur, de son systme d'exploitation et des options d'Oracle, chaque base Oracle est associe une instance Oracle. Il s'agit d'une zone de mmoire partage et d'un ensemble de processus. Au dmarrage, Oracle alloue une zone de mmoire appele SGA (System Global Area) et dmarre plusieurs processus propritaires; c'est ce que l'on appelle l'instance. Lorsque l'on arrte une base, on arrte les processus de l'instance. 2.2. Notion d'instance L'ensemble des zones en mmoire ainsi que les diffrents processus d'arrire-plan allous une base de donnes forment ce que l'on appelle une INSTANCE. Quand une base de donnes est dmarre sur un serveur de base de donnes, Oracle alloue la zone mmoire (SGA) et dmarre les processus d'arrire-plan. La zone mmoire et les processus de l'instance permettent de grer les donnes de la base de donnes associe et de servir les utilisateurs de celle-ci. Les caractristiques de l'instance se trouvent dans son fichier de paramtres. Une instance correspond et accde une et une seule base de donnes. Une base de donnes peut, l'inverse, tre accde 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 donnes par l'intermdiaire de l'instance laquelle ils accdent. On distingue les instances d'une base de donnes grce au SID (System Identifier). La commutation entre ces instances se fait par la modification de la variable d'environnement ORACLE_SID. Elle permet de dsigner l'instance laquelle on souhaite se connecter. Une instance est paramtre par son INIT.ORA. 2.3. Les tats d'une base Les diffrents tats d'une base sont : ferme ou inexistante : elle doit tre cre avec les paramtres contenus dans le fichier d'initialisation. La base peut tre ferme pour effectuer des oprations de sauvegardes complte ( froid) ou ventuellement pour modifier des paramtres non dynamiques du fichier d'initialisation et faire en sorte que l'instance les prenne en compte lors de son prochain redmarrage. Pour fermer une base de donnes : shutdown non monte (startup nomount) : dans cet tat, le fichier d'initialisation est trouv et lu. Les paramtres sont chargs en mmoire, la SGA est rserve selon sa dfinition dans le fichier de paramtres et les processus d'arrire-plan sont dmarrs. Certaines oprations de maintenance (ou al cration de la base de donnes) sont possibles. On peut, par exemple, agir sur les fichiers de contrle. monte (alter database mount) : le fichier de contrle est lu. Donc, la cohrence de la base de donnes peut tre value. L'emplacement des fichiers de donnes est connu et leur existence est traite. Ensuite, le systme vrifie que la base de donnes ne ncessite pas un recouvrement (recovery). Si c'est le cas, le processus de recovery peut tre dmarr partir de cet tat. ouverte (alter database open) : les fichiers de donnes sont accessibles tous les utilisateurs authentifis. C'est l'tat normal de la base de donnes en fonctionnement. Soors Aurore 7

2.4. Arrt et dmarrage 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. La deuxime tape consiste ouvrir les fichiers de contrle : sqlplus> alter database mount; La troisime et dernire tape ouvre les fichiers redo et les fichiers de donnes : sqlplus> alter database open; Il est videmment possible de raliser toutes ces tapes en une seule commande : sqlplus> startup open pfile=initora8i.ora STARTUP [FORCE] [RESTRICT] [PFILE = fichier d'initialisation] {[OPEN][RECOVER]/[MOUNT][NOMOUNT]};

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 accs la base de donnes OPEN : mode par dfaut RECOVER : permet de lancer un recouvrement avant ouverture MOUNT : dmarrage de l'instance et montage de la base de donnes NOMOUNT : uniquement dmarrage de l'instance [ABORT/IMMEDIATE/NORMAL/TRANSACTIONAL];

SHUTDOWN

ABORT : arrt brutal, sans enregistrement pralable des donnes contenues dans la SGA, un recouvrement sera ncessaire au redmarrage. IMMEDIATE : refus de nouvelles connexion, annulation des transactions en cours, dconnexion des utilisateurs, fermeture de la base de donnes dans un tat cohrent, arrt de l'instance. NORMAL : mode par dfaut : pas de nouvelles connexions et attente de la dconnexion des utilisateurs. TRANSACTIONAL : pas de nouvelles connexions, attente de la dconnexion des utilisateurs et attente de fin de transaction avant l'arrt.

2.5. Le mode sysdba Pour les oprations d'administration, il faut utiliser le mode SYSDBA ou SYSOPER. Par dfaut, seul le compte SYS peut obtenir une connexion de ce type l. L'authentification SYSDBA peut tre vrifie de deux faons : par le systme d'exploitation par le fichier de mot de passe Soors Aurore 8

2.6. La SGA Beaucoup de paramtres dfinissent la configuration d'une instance (fichier d'initialisation init<SID>.ORA). La plus grande partie du travail de tunning est consacre aux rglages des paramtres des structures contenues dans la SGA. La SGA est l'quivalent du contrleur dans un modle MVC.

La SGA rside dans un segment de mmoire partage et est la composante centrale d'une instance : toute opration sur une base utilise un moment ou un autre des informations contenues dans une des structures de la SGA la SGA est partage : beaucoup de processus y accdent en mme temps, en lecture/criture la SGA est cre lors du dmarrage (avant le montage) de l'instance et elle est dtruite lorsque l'instance est arrte (shutdown) La SGA est compose de le pool partag (shared pool) le cache des donnes (database buffer cache) le cache des images aprs (redo log buffer)

Soors Aurore

La SGA contient galement les informations communiques entre processus telles que les informations relatives au verrouillage les files de requtes et rponses (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 modifis mais non encore crits sur le disque (dirty list) la liste des blocs les moins rcemment utiliss (last recently used list) qui contient : les blocs libres les blocs actuellement utiliss (pinned buffers) les blocs modifis non encore transfrs dans la dirty list

La fin de la liste LRU contient les blocs les plus rcemment utiliss (MRU). Lorsqu'un processus sollicite l'accs un bloc qui n'est pas dj prsent en mmoire, 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 apportes la base de donnes. Les entres de ce buffer contiennent les informations ncessaires la reconstruction des changements effectus par les oprations de LMD lors du processus de recovery. Les informations contenues dans le buffer de reprise proviennent des zones mmoires rserves aux utilisateurs.

Soors Aurore

10

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 rcemment excuts : le texte de l'ordre sa version analyse le plan d'excution Le dictionnaire cache contient les informations du dictionnaire de donnes Oracle les plus rcemment utilises : description des tables droits des utilisateurs etc. Lorsqu'une requte est excute pour la premire fois, Oracle stocke le rsultat de l'analyse dans le Library Cache puis excute la requte. Lorsque la mme requte est de nouveau excute plus tard, Oracle est en mesure de la retrouver dans le Library Cache et de l'excuter directement sans refaire l'analyse (ou tout au moins en faisant une analyse plus lgre). Dans la pratique, le Library Cache ayant une taille finie, Oracle utilise un algorithme LRU (Last Recently Used) pour grer le cache : en cas de manque de place, Oracle supprime du cache la requte utilise la moins rcemment. Les informations relatives aux objets de la base de donnes sont stockes dans les tables du dictionnaire (donnes de comptes d'utilisateurs, nom des fichiers de donnes, noms des segments, emplacements des extents, descriptions des tables et privilges). Lorsque la base a besoin de ces informations (par exemple pour contrler si un utilisateur est autoris excuter une requte sur une table), elle lit les tables du dictionnaire et place les informations extraites dans le cache du dictionnaire.

Soors Aurore

11

3. Les processus Oracle

3.1. Introduction Une instance oracle est compose d'un ensemble impressionnant de divers processus. Chaque processus joue un rle trs prcis. Dans la littrature, on appelle ces processus, les processus d'arrire-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'amliorer ses performances en prsence de plusieurs utilisateurs. Ces processus sont automatiquement crs lors du dmarrage d'une instance. Sont concerns : SMON (System Monitor) : processus charg de vrifier la cohrence de la base de donnes et ventuellement sa restauration lors du dmarrage si besoin PMON (Process Monitor) : processus charg de nettoyer les ressources, les verrous et les processus utilisateurs non utiliss DBWR (DataBase Writer ou Dirty Buffer Writer) : processus charg d'crire le contenu des buffers dans les fichiers de donnes LGWR (Log Writer) : processus charg d'crire le contenu des buffers dans les fichiers Redo Log CKPT (CheckPoint) : priodiquement, tous les blocs modifis du Database Buffer Cache sont crits dans les fichiers de donnes : c'est le mcanisme de synchronisation (checkpoint) RECO (Recoverer) : processus optionnel permettant de rsoudre les transactions interrompues brutalement dans un systme de bases de donnes distribues 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'arrireplan CJQn qui assurent l'actualisation des donnes (par exemple les vues matrialises) et excutent d'autres jobs planifis. Dnnn (Dispatcher, nnnn reprsente une suite de nombre entiers) : les processus dispatcher sont ncessaires l'architecture serveur partag. Sans dispatcher, chaque processus utilisateur ncessite un processus serveur (architecture serveurs ddi). 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 dmarrage de la libration des segments temporaires qui ne sont plus utiliss de regrouper les extensions libres contiges 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 problmes, c'est dire nettoyer le cache librer toutes les ressources alloues pour un processus utilisateur : librer les verrous retirer l'identification du processus (PID) de la liste des processus actifs rinitialiser le statut de la table des transactions actives

Soors Aurore

12

3.2.3. Le processus RECO Le processus RECO (recover) est utilis uniquement dans le cadre de bases de donnes distribues dont la valeur du paramtre DISTRIBUTED_TRANSACTIONS autorise les transactions distribues (valeur > 0). Le processus recover rsout automatiquement les problmes survenus dans une transaction distribue : chaque noeud participant la transaction possde un processus recover; ce processus se connecte automatiquement aux autres BD impliques 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 diffrents serveurs, le processus revover rsout les problmes engendrs par la transaction concerne. 3.2.4. Le processus ARCH Le processus ARCH (archiver) ralise 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 utiliss avec l'option LOG_ARCHIVE_START et que l'archivage automatique est activ (mode ARCHIVELOG). L'activation de ce processus permet de raliser 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 accder. 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 prcisment partie d'une instance mais est intgr Oracle Net. Dans une architecture serveur partag, le rle 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 dmarre un serveur ddi auquel il connecte le client en question. La communication entre processus dispatcher et listener se droule de la manire suivante : lors du dmarrage 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 connects Plusieurs tables dynamiques de performance peuvent tre utilises 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 connectes 3.4. La circulation des donnes Considrons les tapes ncessaires au droulement 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 COMMIT;

Lebucheron ;

Soors Aurore

13

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 dj. 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 donnes concernes par la requte. Si le processus trouve ces donnes, il doit les dplacer vers la fin (most recently used) de la liste least recently used. Ici aussi, le processus doit acqurir un latch. 4. Si les donnes ne sont pas dans le buffer cache, le processus serveur doit les extraire des disques. Ceci entraine une ou plusieurs oprations d'entres/sorties et l'acquisition d'un latch par bloc placer dans le buffer cache. 5. Le processus serveur renvoie les tuples trouvs au processus client. Ceci engendre en gnral une communication rseau. 6. Lorsque le client met l'instruction update, elle est analyse et les lignes doivent tre retrouves comme dans les tapes prcdentes. La mise jour est alors ralise dans les blocs adquats du buffer cache. Cette opration entrane galement des modifications dans les blocs des buffers des rollback segment. 7. L'instruction update cre galement une entry dans le buffer de reprise (redo log buffer). 8. Le processus DBWR recopie les blocs modifis du buffer cache dans les fichiers de donnes. 9. Lorsque le commit est excut, le processus LGWR doit copier le contenu du buffer de reprise dans le fichier de reprise. Ce n'est qu'aprs avoir copi ces blocs qu'Oracle considre que l'instruction commit s'est bien droule. 10. Si la base a t dmarre 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 rutilisable avant qu'il ne soit archiv. 11. A intervalle rgulier (par dfaut 3 secondes), ou lors d'un changement de fichier de reprise, Oracle ralise un checkpoint. Un checkpoint force le processus DBWR recopier tous les blocs du buffer cache modifis sur disque.

Soors Aurore

14

3.5. Variantes architecturales Toute application doit excuter deux parties de code pour pouvoir accder une instance Oracle : le code de l'application et le code d'un serveur oracle Le code de l'application met les requtes SQL l'instance. Le code du serveur, quant lui, analyse et excute les requtes.

Soors Aurore

15

Soors Aurore

16

Soors Aurore

17

4. Utilisateurs et privilges
4.1. Niveaux de scurit Il existe plusieurs niveaux de scurit et des fonctionnalits pour procder l'audit de chacun de ces niveaux. Il y a trois niveaux de scurit (Oracle) : scurit de compte pour la validation des utilisateurs scurit d'accs pour les objets de la base scurit au niveau systme pour la gestion des privilges globaux 4.1.1. Scurit de compte Pour accder aux donnes d'une base oracle, il faut disposer d'un accs un compte dans cette base : direct : via des connexions utilisateur la base indirect : les connexions s'appuient sur les autorisations dfinies dans des liens de base de donnes Chaque compte doit disposer d'un mot de passe. Un compte de base de donnes peut aussi tre li un compte du systme d'exploitation. 4.1.2. Privilges objet Contrle de l'accs aux objets au moyen de privilges via la commande grant. Seul le propritaire d'un objet possde tous les privilges sur cet objet. Pour pouvoir accorder un privilge sur un objet, il faut en tre le propritaire ou avoir reu le privilge avec l'autorisation de le transmettre (clause with grant option). Pour simplifier la gestion des privilges, il est galement possible de crer des rles dont l'avantage est d'avoir un groupe de privilges nomms (utile pour les applications qui supportent un grand nombre d'utilisateurs) d'avoir un niveau de scurit supplmentaire la base 4.1.3. Privilges systme Les privilges systme sont ncessaire pour pouvoir excuter certaines commandes. Les actions qui peuvent tre excutes sur chaque type d'objet sont autorises via des privilges spars. Pour faciliter la gestion des ces privilges, il est galement possible de dfinir des rles. Les privilges systmes permettent aux diffrents utilisateurs de raliser des oprations ou des catgories d'oprations. Ces privilges ne portent pas sur un objet bien prcis mais plutt sur un type de commandes comme, par exemple, crer une table ou se connecter la base. Ils offrent ainsi un contrle de la scurit d'accs trs pouss. La clause ANY permet de spcifier que le privilge porte sur tous les schmas de la base de donnes. 4.2. Cration 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 rgles de gestion des mots de passe. Lorsque aucun profil n'est dfini, c'est celui par dfaut qui est utilis. Ce profil spcifie une utilisation des ressources non limites. Un profil est cr au moyen de l'instruction create profil.

Soors Aurore

18

5. Sauvegarde, restauration et rcupration

5.1. Vue d'ensemble Assurer la scurit est une des taches principales. Cette scurit est assure par : la mise en uvre d'une protection des fichiers sensibles de la base de donnes (fichiers de contrle, fichiers de journalisation) la mise en place d'une stratgie de sauvegarde/restauration adapte aux contraintes de l'entreprise, teste et documente. La protection des fichiers de contrles et de journalisation s'effectue par multiplexage. La stratgie de sauvegarde/restauration dpend de plusieurs facteurs : Peut on perdre des donnes? Peut on arrter la base priodiquement? Peut on raliser une sauvegarde complte de la base pendant l'arrt? Il faut galement dterminer la nature des activits sur la base : Y a-t-il des mises jour quotidiennes par les utilisateurs? (application transactionnelle) Y a-t-il des mises jour priodique, consultation la journe? (application dcisionnelle) 5.2. Archivage des fichiers de journalisation Les fichiers de journalisation fichiers constituent un journal des modification apportes la base de donnes. Cet archivage est organiser de manire circulaire. Ces fichiers peuvent tre r-appliqus une sauvegarde de fichiers de donnes, pour rejouer les modifications survenues entre la sauvegarde et un incident ayant endommag le fichier (restauration de mdia). Le mode Archivelog permet de garantir 0 perte de donnes en cas d'incident sur un fichier de donnes. 5.3. Le mode Archivelog Aprs T0, l'activit de mise jour se produit, gnrant des entres dans les fichiers de journalisation. L'archivage tant activ, les fichiers de journalisation plein sont archivs. En T1, un incident se produit, le fichier de donnes est perdu. La restauration du fichier consiste prendre la dernire sauvegarde et appliquer sur cette sauvegarde les fichiers de journalisation archivs, afin de ramener le fichier de donnes dans l'tat o il se trouvait avant l'incident (tat de la dernire transaction valide). 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 manuvre et peut tre utilis de manire graphique via le database control. 5.5. Stratgie de sauvegarde sauvegarde cohrente : sauvegarde de la totalit de la base aprs un arrt propre. Cette sauvegarde est aussi appele sauvegarde base ferme . Toutes les donnes se trouvent dans les fichiers de donnes et c'est le seul mode de sauvegarde disponible lorsqu'on utilise le mode NOARCHIVELOG sauvegarde incohrente : sauvegarde lorsque la base est ouverte et qu'il y a des activits en cours. Les fichiers sauvegards ne sont pas synchrones au niveau des modifications enregistres. Il faudra utiliser les fichiers de journalisation pour rendre les fichiers cohrents. Pour utiliser cette stratgie de sauvegarde, il est ncessaire d'utiliser le mode ARCHIVELOG complte : totalit de la base partielle : uniquement une partie de la base; sauvegarde incohrente entre elle; mode archivelog incrmentale : on ne sauvegarde que les blocs modifis depuis la dernire sauvegarde; cette sauvegarde peut tre partielle ou complte Le mode Archivelog est utilis lorsqu'aucune perte n'est autorise et lorsque la base ne peut pas tre ferme. La base de donnes peut reste ouverte lorsqu'un incident survient sur un fichier de donnes qui n'appartient pas aux tablespaces SYSTEM et UNDO.

Soors Aurore

19

5.6. Outils logiques 5.6.1. Exportation de donnes : Export Ce programme ralise une extraction et une copie binaire des donnes qui est lisible uniquement par son homologue, import. Export est appel en ligne de commande et possde de nombreux paramtres. Ces paramtres lui indiquent, par exemple, les donnes extraire et o il faut les placer. Il permet de raliser les oprations suivantes : crire un fichier de rsultats qui contient toutes les instructions SQL ncessaires pour recrer l'infrastructure d'une base; gnrer un ensemble d'instructions SQL pouvant tre utilises pour crer des tables, des index, des contraintes, ... copier les donnes d'un schma dans un autre schma dplacer les donnes depuis un serveur vers un autre alimenter une nouvelle base de donnes Pour pouvoir crer un export, il faut possder le privilge systme CREATE SESSION. Pour exporter des tables dont on n'est pas le propritaire, il faut avoir le rle EXP_FULL_DATABASE qui est compris dans le rle DBA. Le paramtre compress permet de reconstruire plus aisment une table morcele en plusieurs extents en un seul extent. Mode Complet Utilisateur Table Description Exporte les donnes, les dfinitions de donnes et d'objets stocks requis pour reconstruire la base de donnes l'exception de l'utilisateur SYS Exporte les donnes, dfinitions de donnes et objets stocks appartenant un ou plusieurs utilisateurs dont le nom est spcifi au moyen du paramtre owner Exporte les donnes, dfinitions de donnes (mais pas les objets stocks) de l'utilisateur qui excute l'export ou du schma dont les tables sont mentionnes dans le paramtre tables

5.6.2. Importation de donnes : Import L'utilitaire lit les fichiers crs partir de export. Il permet de raliser de nombreuses tches : reconstruire une base de donnes ou un schma d'une base de donnes restaurer une copie d'un objet tel qu'il existait au moment de l'export restaurer les lignes supprimes d'une table suite une erreur de programmation dplacer des donnes vers une autre plate-forme. Import possde exactement les mme modes de fonctionnement que l'utilitaire export : mode interactif, mode ligne de commande et mode fichier de paramtres. Import supporte pratiquement les mmes paramtres que export. 5.6.3. Un tablespace transportable Un tablespace transportable permet de copier aisment et de dplacer un tablespace d'une base vers une autre. Un ensemble de tablespaces transportables contient tous les fichiers de donnes des tablespaces dplacs, ainsi qu'une copie exporte des mtadonnes des tablespaces concerns. Les tablespaces doivent tre fonctionnellement autonomes, ils ne devraient pas contenir d'objets dpendants d'autres objets extrieurs aux tablespaces transports. Ainsi, si on souhaite dplacer une table, il faut galement dplacer le tablespace qui contient ses index. Pour dterminer si un tablespace est fonctionnellement autonome, on peut utiliser la procdure TRANSPORT_SET_CHECK du package DBMS_TTS qui indique sont rsultat dans la table du dictionnaire TRANSPORT_SET_VIOLATIONS : un rsultat vide correspond au fait que le tablespace est fonctionnellement autonome. On place les tablespaces que l'on souhaite dplacer en mode read only : alter tablespace NEW_DATA read only; alter tablespace NEW_DATA_IDX read only;

Soors Aurore

20

Ensuite, on exporte les tablespaces et leurs mtadonnes en utilisant les paramtres 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 procde alors la copie des fichiers de donnes et le fichier d'export vers la base cible (cp, ftp, copy, etc). Il reste connecter les tablespaces dplacs la table cible : imp TRANSPORTABLE TABLESPACE=Y DATAFILES=(new_data1.dbf,new_data2.dbf,new_data_idx.dbf) On termine en plaant 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 donnes et des mtadonnes d'une base une autre. Ils prsentent des analogies avec export et import des versions antrieures d'Oracle mais sont en fait diffrents. En effet, grce au package DBMS_DATAPUMP, ils offrent des performances suprieures en utilisant le traitement parallle. Data Pump permet de dplacer une partie ou la totalit des donnes et mtadonnes d'une base de donnes aux moyens de filtres qui sont implments par ces utilitaires. DP Export peut extraire des donnes de tables, des mtadonnes et des informations de contrle d'une base pour les enregistrer dans un ou plusieurs fichiers de transfert, ou fichier dump, dont le format propritaire ne peut tre lu que par DP Import. Les lments contenus dans ces fichiers dump, par exemple, des instructions LDD de tables, des privilges, des packages, des vues, etc, peuvent tre chargs, via DP Import, dans une base de donnes cible sur un autre serveur et un systme d'exploitation diffrent. Les principales fonctionnalits de cet utilitaire sont l'extraction des instruction LDD sans les excuter; importation directe via le rseau en utilisant comme source une base de donnes plutt que des fichier dump; redmarrage possible des jobs data pump au moyen du paramtre start_job possibilit de dfinir via le paramtre parallel le nombre maximal de threads et le degr de paralllisme pour les tches d'exportation et d'importation surveillance possible des jobs par rattachement et dtachement aux jobs en cours d'excution valuation possible de la quantit d'espace qui sera occup par un fichier d'exportation au moyen de la clause estimate_only Les procdures de data pump sont implmentes dans le package dbms_datapump et celles de l'API mtadata dans le package dbms_metadata. Les mtadonnes extraites par ce package sont au format XML. 5.6.4.1. Exportation avec Data Pump L'utilitaire s'appelle expdp. Il possde cinq modes d'excution mutuellement exclusifs : exportation complte : elle peut servir la reconstruction intgrale d'une base de donnes; exportation de schma : c'est le mode par dfaut. Il permet l'exportation de un ou plusieurs schmas de la base de donnes; exportation de table : permet d'exporter des tables ou des partitions ainsi que les objets dpendants; exportation de tablespace : permet d'exporter toutes les tables stockes dans les tablespaces spcifis dans le paramtre tablespace; tablespace transportable : dans ce mode, seules les mtadonnes sont exportes.

Soors Aurore

21

Un des grands intrts de DP Export est la possibilit d'utiliser des filtres sur : les donnes : pour filtrer on utilise paramtre query. Le filtre est appliqu une fois par table et par job les mtadonnes : pour filtrer on utilise le paramtre exclude et include. Si plusieurs filtres s'appliquent un mme job, ils sont relis par l'oprateur and. Exemples d'exportation : exportation complte d'une base de donnes : expdp system/manager DUMPFILE=expdata.dmp FULL=Y LOGFILE=export.log exportation des tables clients et ventes du schma 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 raliser des importations partir des fichiers dump construit par expdp. Il possde cinq modes de fonctionnement qui correspondent ceux de l'exportation. Il est cependant possible de raliser une importation partir d'une exportation plus leve dans la hirarchie. Par exemple, il est possible d'importer une table partir de l'exportation d'un schma, d'une tablespace et de la base complte. Ceci est mme possible par le rseau et il est galement permis d'utiliser des filtres. Exemple : importation complte d'une base de donnes : impdp system/manager DUMPFILE=expdata.dmp FULL=Y LOGFILE=import.log

5.7. Rappels 5.7.1. Dfinitions Sauvegarde (backup) : copie d'un ensemble de fichiers (de donnes, de contrles redo, ...) sur un support (disque, bande, dvd, ...) autre que ceux contenant les donnes originales. Restauration (restore) : remplacement des fichiers altrs partir d'une sauvegarde. Rcupration ou recouvrement (recovery) : reconstruction d'une base en utilisant le journal des images aprs. Sauvegarde chaud : signifie que la base est accessible pendant la sauvegarde : les utilisateurs restent donc connects. Ces derniers peuvent mme modifier les donnes pendant la sauvegarde. Sauvegarde froid : signifie que tous les utilisateurs sont dconnects et que la base est arrtes. On dit aussi que la sauvegarde est cohrente par rapport au fait que tous les fichiers constituant la base on t estampills la mme heure lors de la fermeture des fichiers et de l'arrt de l'instance. Rcupration complte : implique de r-appliquer toutes les instructions consignes dans le journal des images aprs. En principe, elle ne s'accompagne d'aucune perte de donnes. Rcupration incomplte : consiste r-appliquer seulement une partie du journal des images aprs, disons jusqu' un point prcis dans le temps. Elle sert souvent rtablir la base dans l'tat o elle tait juste avant qu'un incident ne survienne. Par exemple, l'excution malheureuse d'un drop tablespace.

Soors Aurore

22

5.7.2. Les fichiers redo Lorsque les donnes sont modifies dans Oracle, les tampons du cache des donnes le sont galement pour reflter ces changements. Pour des raisons de performances, ces tampons ne sont, en gnral, pas immdiatement recopis sur disque. Le contenu des tampons est d'abord consign dans le cache des fichiers redo. Lorsqu'une transaction est valide, tous les enregistrements redo qui la concernent et qui se trouvent en cache sont crits dans le journal redo sur disque accompagns d'un numro de changement systme unique appel SCN (System Change Number) et d'une identification d'heure. Les fichier redo assurent ainsi la protection des donnes en attendant qu'elles soient ultrieurement recopies dans les fichiers de donnes. Les entres redo et les donnes modifies ne sont donc pas enregistre sur disque en mme temps : les premire le sont systmatiquement lorsqu'une transaction est valide, mais pas les secondes; c'est le processus d'arrire-plan DBWn qui est charg d'crire dans les fichiers de donnes les tampons contenant les donnes modifies (dirty buffer) afin de librer de l'espace dans le cache des donnes au sein de la SGA. DBWn est invoqu intervalle rgulier par le processus d'arrire-plan CKPT qui met jour l'en-tte de tous les fichiers de donnes ainsi que les fichiers de contrle avec les informations du dernier checkpoint. Oracle crit dans les fichiers de redo de manire circulaire : lorsque le fichier courant est rempli, il crit dans le suivant, et ainsi de suite jusqu' utiliser le premier; ds lors, pour avoir un vritable journal des images aprs, 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 configure pour qu'elle archive les fichiers de redo, on dit qu'elle fonctionne en mode archivelog. L'archivage des fichiers redo est le mcanisme fournit par Oracle pour garantir la disponibilit permanente des donnes de la base autorisant leur sauvegarde chaud. 5.7.3. Que faut-il sauvegarder? Le code oracle dsigne 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 paramtres : le fichier de paramtre au format texte, init.ora ou celui au format binaire, spfile.ora. Ces fichiers changent trs peu, mais devraient tre sauvegards de sorte que l'tat courant de l'instance puisse tre recre. Les fichiers de contrles : contiennent des renseignements indispensables au dmarrage de la base et utiles pour le processus de rcupration : l'historique des fichiers redo archivs, le nom du fichier redo en ligne courant et des informations sur le dernier checkpoint. Les fichiers redo archivs Tablespace undo ou segments d'annulation Les fichiers de donnes Les fichiers de trace : dans certaines circonstances, le support Oracle les demande pour analyser certain problmes. Le fichier des alertes : ce fichier consigne de nombreux vnements tels que les dmarrages et arrts, les checkpoints, ainsi que les SCN qui correspond l'incarnation courante de la base de donnes. Il peut tre trs utile de disposer de ces informations en cas de rcupration incomplte. 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 opratoire 1. Modifier dans le spfile les paramtres concernant les processus d'archivage 2. Arrter proprement la base de donnes 3. Monter la base de donnes 4. Passer la base de donnes en mode ARCHIVELOG 5. (Sauvegarder la base de donnes) 6. Ouvrir la base de donnes Soors Aurore 23

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 : numro de squence %t : numro d'instance (thread) %r : identifiant de remise zro des fichiers de journalisation LOG_ARCHIVE_FORMAT LOG_ARCHIVE_DEST(_n) destinations en parallle (max 10) une des destinations au moins doit tre locale il est possible de dsigner une base de secours comme cible les rpertoires ne sont pas crs par Oracle zone flashback utilise par dfaut LOG_ARCHIVE_DUPLEX_DEST ARCHIVE_LAG_TARGET dure entre deux archivages 0 = dsactiv / 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. Problmes 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. Prsentation de RMAN 5.9.1. RMAN RMAN permet la ralisation de sauvegarde et de restauration. Il utilise un repository pour stocker des informations sur sa configuration, les sauvegardes ralises, la structure de la base de donnes, les fichiers archivs, etc. Le repository est stock dans le fichier de contrle et peut galement tre stock dans un catalogue de rcupration. Si utilisation d'une flash recovery area, il est possible de bnficier des fonctionnalits de sauvegarde et de restauration. RMAN gre les sauvegardes obsoltes, ce qui permet d'indiquer combien de temps une sauvegarde doit tre conserve (dfinition complmentaire). Pour chaque opration, RMAN utilise un canal : connexion entre le client RMAN et un processus serveur de la base de donnes. 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

5.9.2. Lancer RMAN Ligne de commande : > RMAN target / > RMAN target sys/aletest@aletest.world Options : target => paramtre ORACLE_SID par dfaut 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 rglages persistants utiliss par dfaut. Configurer la politique de conservation, rtention : fentre de restauration : nombre de jours dans le pass o on veut revenir fentre de redondance : indique combien de sauvegardes de chaque fichier doivent tre conserves (par dfaut 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 contrle : par dfaut sauvegarde dans la zone de rcupration rapide (flash recovery area ) possibilit de destination par dfaut spcifique active aussi la sauvegarde automatique du SPFILE sauvegarde automatique chaque modification de structure de la base de donnes ou une sauvegarde RMAN est enregistre dans le fichier de contrleur RMAN > CONFIGURE CONTROLFILE AUTOBACKUP ON; RMAN > CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO <format>; L'utilisation de la zone de rcupration rapide offre des fonctionnalits automatiques conseil d'utiliser un disque spar pour cette zone sous rpertoire avec diffrents types de fichiers (rgles de nommage) une mme zone peut tre employe par plusieurs base de donnes condition qu'elles aient un nom unique 5.10. Sauvegarde 5.10.1. Gnralits Commande : RMAN > BACKUP [comment] quoi [option] Il faut que la base de donnes soit monte ou ouverte car il est ncessaire d'accder au fichier de contrle de la base de donne cible. RMAN peut sauver des fichiers de donnes, de contrle, de paramtres serveur, des lments de sauvegarde. Une sauvegarde RMA peut tre ralise sous la forme d'une copie image ou d'un jeu de sauvegarde (dfaut). Dans un jeu de sauvegarde, il n'y a pas de sauvegarde des blocs jamais utiliss des bloc (et donc gain de place) et compression possible.

Soors Aurore

25

Paramtres 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 donnes RMAN > BACKUP [VALIDATE] DATABASE; 5.10.2.2. RMAN > RMAN > RMAN > 5.10.2.3. RMAN > RMAN > RMAN > RMAN > Sauvegarde de tablespaces ou fichiers de donnes BACKUP TABLESPACE user, index; BACKUP DATAFILE 1,2, <rep/fichier>; BACKUP TABLESPACE system DATAFILE 5; Sauvegarde du fichier de contrle et du spfile BACKUP INCLUDE CURRENT CONTROLFILE; BACKUP CURRENT CONTROLFILE; BACKUP AS COPY CURRENT CONTROLFILE; BACKUP SPFILE;

5.10.2.4. Sauvegarde de fichier archivs Si pas multiplex et si pas archivs dans la zone de rcupration 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 archivs 3. Sauvegarde des autres lments 4. Archivage, nouveau, du fichier de journalisation courant 5. Sauvegarde des fichiers de journalisation archivs gnrs depuis le dbut de la sauvegarde Option NOT BACKED UP : pour ne pas sauvegarder que les fichiers de journalisation archivs qui n'ont pas dj t sauvegards un nombre de fois ou depuis un certain temps 5.10.2.5. Sauvegarde incrmentale Elle permet de sauvegarder uniquement les blocs qui ont t modifis depuis la dernire sauvegarde. A utiliser plutt lorsque l'activit de mise jour est relativement faible RMAN > BACKUP INCREMENTAL LEVEL 0 DATABASE; RMAN > BACKUP INCREMENTAL LEVEL 1 DATABASE; Soors Aurore 26

5.10.2.6. Sauvegarde incrmentale diffrentielle ou cumulative / Niveau 0 ou Niveau 1 incrmentale niveau 0 : sauvegarde tous les blocs utiliss des fichiers de donnes (sauvegarde complte) diffrentielle niveau 1 : tous les blocs modifis depuis la dernire sauvegarde de niveau 0 ou 1 (dfaut) cumulative niveau 1 : tous les blocs modifis depuis la dernire sauvegarde de niveau 0

Incrmentale cumulative

Cumulative cumulative

Soors Aurore

27

5.10.3. Scnario Hypothses de dpart: une zone de rcupration rapide est utilise la sauvegarde automatique des fichiers de contrle a t active Scnarios : sauvegarde complte base ferme sauvegarde complte base ouverte sauvegarde partielle base ouverte sauvegarde incrmentale

5.10.4. Sauvegarde complte (cohrente) Commande (avec RMAN) : RMAN > SHUTDOWN IMMEDIATE; RMAN > STARTUP MOUNT; RMAN > BACKUP DATABASE; RMAN > SQL ALTER DATABASE OPEN ; 5.10.5. Sauvegarde complte (incohrente) Sauvegarde complte + sauvegarde des fichiers de journalisation + suppression des fichiers de journalisation archivs sauvegards. Commande : RMAN > BACKUP DATABASE PLUS ARCHIVELOG DELETE INPUT 5.10.6. Sauvegarde partielle base ouverte La totalit de la base de donnes est sauvegarde en 3 fois en 3 jours : # Sauvegarde 1 : fichiers de donnes 1 et 2 RMAN > BACKUP DATAFILE 1,2 PLUS ARCHIVELOG DELETE INPUT; # Sauvegarde 2 : fichiers de donnes 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 incrmentale Sauvegarde incrmentale cumulative sur un cycle d'une semaine : # Dimanche : sauvegarde incrmentale de niveau 0 RMAN > BACKUP INCREMENTAL LEVEL 0 DATABASE; # Lundi au Samedi : sauvegarde incrmentale cumulative de niveau 1 RMAN > BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;

Soors Aurore

28

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 archivs. RMAN > LIST cible [BY FILE | SUMMARY] [filtre_sauvegarde]; RMAN > LIST {BACKUPSET | BACKUPPIEC}{liste_cls | 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 dernire heure RMAN > LIST ARCHIVELOG FROM TIME SYSDATE_1/24; # archives sauvegardes 2 fois sur disque RMAN > LIST ARCHIVELOG ALL BACKED UP 2 TIMES TO DEVICE TYPE DISK; # archives jamais sauvegardes sur disque RMAN > LIST ARCHIVELOG ALL BACKED UP 0 TIMES; 5.11.1.2. La commande REPORT raliser des interrogations plus volues utilisations principales : 1. lister les lments qui ncessitent une sauvegarde 2. lister les sauvegardes obsoltes 3. afficher la liste des fichiers de donnes de la base de donnes 1. Lister les lments qui ncessitent 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

2. Lister les sauvegardes obsoltes RMAN > REPORT OBSOLETE [condition]; Options : Conditions recovery window of n days redundancy = n 3. Afficher la liste des fichiers de donnes de la base de donnes RMAN > REPORT SCHEMA; 5.11.2. Grer le repository 5.11.2.1. La commande CROSSCHECK vrifier que les informations enregistres 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 obsoltes. 5.11.2.3. La commande CATALOG Elle permet d'indiquer RMAN l'existence de fichiers de journalisation archivs ou d'lments de sauvegarde qui ne sont pas enregistrs dans le rfrentiel RMAN. Cas possibles : mauvais emploi de DELETE, le fichier physique est toujours la rcupration avec mauvais fichier de contrle recration de fichier de contrle (il est vide) erreur sur le fichier de contrle dplacement du fichier physique 5.12. Restauration 5.12.1. Vue d'ensemble Plusieurs facteurs dpendants : 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 problme dfinir le mode opratoire Conseil inital : avant de commencer toute opration de restauration, raliser une sauvegarde complte de la base endommage. Au minimum une sauvegarde du fichier de contrle et des ficher de journalisation en ligne.

Soors Aurore

30

Deux tapes : restauration : extraire d'une sauvegarde les fichiers ncessaires rcupration : appliquer les fichiers de journalisation aux fichiers rcuprs de la sauvegarde

5.12.2. Principes gnraux 5.12.2.1. En mode NOARCHIVELOG mode opratoire : restaurer la dernire sauvegarde complte de la base redmarrer la base toutes les modifications apportes depuis la dernire sauvegarde sont perdues dans certaines situations, il peut tre possible de rcuprer tout ou une partie des modifications apportes depuis la dernire 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 donnes perdu n'est pas critique pour la base de donne (il n'appartient pas au tablespace SYSTEM ni au tablespace UNDO) et la base de donnes a t arrte lors de l'incident --> pas de restauration ncessaire au prochain dmarrage ou suppression/recration tous les fichiers de contrles sont perdu mais les autres sont intacts 5.12.2.2. En mode ARCHIVELOG mode opratoire : restaurer la dernire sauvegarde de chaque fichier perdu appliquer les fichiers de journalisation (archives puis ceux en ligne) redmarrer la base (si la restauration ne s'est pas fait base ouverte) rcupration complte type de restauration simple et ne pose pas de problmes s'il reste au moins un fichier de contrle, un membre par groupe de fichier de journalisation sont disponibles diffrentes situations peuvent conduire une rcupration incomplte (point in time recovery) : volontairement, pour s'arrter devant un ordre SQL malencontreux involontairement, si des fichiers de journalisation sont perdus 5.12.3. Incidents sur les fichiers de contrle Les incidents peu graves : perte d'un ou plusieurs fichiers de contrle (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 contrle perte de tous les membre d'un groupe de fichier de journalisation (gravit dpendant du statut du groupe perdu) Ces situations sont vites si on multiplexe correctement les fichiers de contrle et de journalisation, Soors Aurore 31

5.12.4. Identification de la nature des problmes message d'erreur concernant les fichiers de contrle : ORA-00204 ORA-00206 message d'erreur concernant les fichiers de journalisation : ORA-00312 ORA-00321 message d'erreur concernant les fichiers de donnes : ORA-01157 ORA-01110 Lorsque la base de donnes monte ou ouverte, on peut interroger la vue V$RECOVER_FILE pour dterminer la liste des fichiers de donnes sur lesquels il existe un problme. 5.12.5. Les commandes RMAN L'objectif principal est de bien choisir la cible en fonction de la nature du problme. Ensuite RMAN se charge de tout : identifier les sauvegardes utiliser; en extraire les fichiers requis; identifier les fichiers de journalisation archivs ncessaires les extraire d'une sauvegarde s'ils ont t sauvegards puis supprims 5.12.5.1. La commande RESTORE RMAN > RESTORE cible [options] Options : PREVIEW : lister les sauvegardes dont RMAN a besoin pour raliser la restauration correspondante VALIDATE : tester si la restauration peut tre restaure 5.12.5.2. La commande RECOVER RMAN > RECOVER cible [options] Lors de l'opration de rcupration, RMAN recherche les fichiers de journalisation archivs dont il a besoin en premier lieu sur le disque. Les fichiers de journalisation archivs manquant sont automatiquement restaurs partir de sauvegardes, vers le rpertoire d'archivage dfini par le paramtre LOG_ARCHIVE_DEST_1 5.12.6. Scnarios de restauration 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Restauration du SPFILE Restauration d'un fichier de contrle Restauration d'un fichier de journalisation Restauration complte de la totalit d'une base de donnes en mode ARCHIVELOG Restauration complte d'une partie d'une base de donnes en mode ARCHIVELOG Restauration de tous les fichiers de contrle en mode ARCHIVELOG Restauration incomplte en mode ARCHIVELOG Restauration en mode NOARCHIVELOG Restauration un emplacement diffrent Tablespace temporaire gr localement

Hypothses de dpart : la sauvegarde automatique du fichier de contrle et du SPFILE est active utilisation d'une zone de rcupration rapide pas de base de donnes annexe pour stocker le repository RMAN Remarque : si le fichier SPFILE, ou de contrle, ou de journalisation est perdu, d'abord rsoudre ces problmes avant de traiter le cas des fichiers de donnes.

Soors Aurore

32

5.12.6.1. Scnario 1 : Restauration du SPFILE Deux possibilits : le recrer partir d'un fichier de paramtres texte (mthode 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> #dmarrer linstance sans la monter (RMAN va utiliser un spfile temporaire pour dmarrer linstance RMAN > STARTUP NOMOUNT RMAN > STARTUP NOMOUNT #restaurer le fichier de paramtres serveur partir dune sauvegarde automatique RMAN > RESTORE SPFILE FROM AUTOBACKUP; RMAN > RESTORE SPFILE FROM AUTOBACKUP; # si cela choue, ou si utilisation dune sauvegarde qui nest pas une sauvegarde automatique, restaurer partir dune sauvegarde spcifique RMAN > RESTORE SPFILE FROM <fichier>; # redmarrer linstance et louvrir RMAN > SHUTDOWN RMAN > STARTUP 5.12.6.2. Scnario 2 : Restauration d'un fichier de contrle Dans le cas o l'on a perdu un ou plusieurs fichiers de contrle mais qu'il en reste au moins un, il ne faut PAS repartir d'une sauvegarde de fichier de contrle. Il faut simplement dupliquer un des fichiers de contrle restants pour remplacer les fichiers perdus. Mode opratoire : 1. Arrter la base de donnes 2. Utiliser le fichier d'alerte de l'instance pour identifier les fichiers perdus 3. Dupliquer une version valide du fichier de contrle pour la mettre la place de celui endommag 4. Redmarrer la base de donnes Si le fichier de contrle est dupliqu un autre emplacement que celui d'origine, il faut modifier le paramtre CONTROL_FILES dans le fichier du SPFILE. Mode opratoire : 1. Dmarrer l'instance sans la monter 2. Modifier le paramtre CONTROL_FILES du SPFILE 3. Redmarrer 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

5.12.6.3. Scnario 3 : Restauration d'un fichier de journalisation Mme stratgie avec la recration des fichiers. Mode opratoire : 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 endommage 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. Ritrer les deux oprations prcdentes avec tous les membres endommags 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 excut que si la base de donnes est ouverte. Si la base de donnes est ferme, et qu'elle ne peut pas tre ouverte tout de suite, on peut reporter la correction du problme plus tard, 5.12.6.4. Scnario 4 : Restauration complte de la totalit d'une base de donnes en mode ARCHIVELOG Hypothses : tous les fichiers de donnes perdus instance arrte Mode opratoire : # monter la DB RMAN STARTUP MOUNT RMAN > STARTUP MOUNT # restaurer la DB RMAN > RESTORE DATABASE; # rcuprer la DB #p RMAN > RECOVER DATABASE DELETE ARCHIVELOG MAXSIZE 200M; # ouvrir la DB RMAN > SQL ALTER DATABASE OPEN ; 5.12.6.5. Scnario 5 : Restauration complte d'une partie d'une base de donnes en mode ARCHIVELOG Hypothse : perte d'un ou plusieurs fichiers de donnes (mais pas tous). Il y a deux possibilits de ralisations selon la nature du problmes : base ferme : ferme initialement fichier de donnes du tablespace SYSTEM ou UNDO base ouverte : autres fichiers de donnes

Soors Aurore

34

Restauration avec une base de donnes ferme : un fichier du tablespace SYSTEM est perdu mode opratoire : # monter la DB RMAN > STARTUP MOUNT # restaurer fichiers de donnes souhait via restore tablespace/datafile RMAN > RESTORE TABLESPACE system; # rcuprer les fichiers de donnes # rcuprer les fichiers de donnes RMAN > RECOVER TABLESPACE system; # ouvrir la DB RMAN > SQL ALTER DATABASE OPEN ; Restauration avec une base de donnes ouverte : un fichier du tablespace INDEX est perdu mode opratoire : partie optionnelle si la base est dj 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 concerns offline RMAN > SQL ALTER DATABASE indx OFFLINE IMMEDIATE ; #restaurer les fichiers de donnes souhaites RMAN > RESTORE DATAFILE 6; #rcuprer les fichiers de donnes RMAN > RECOVER DATAFILE 6; #passer ONLINE les tablespaces concerns RMAN > SQL ALTER TABLESPACE indx ONLINE; 5.12.6.6. Scnario 6 : Restauration des fichiers de contrle en mode ARCHIVELOG Hypothses : perte de tous les fichiers de contrle et un fichier de donnes on dispose de sauvegarde automatique du fichier de contrle et les fichiers de journalisation en ligne sont disponibles l'instance est arrte Mode opratoire : 1. Positionner le SID correspondant 2. Dmarrer l'instance sans la monter 3. Restaurer les fichiers de contrle partir d'une sauvegarde automatique 4. Monter la base de donne 5. Restaurer les fichiers perdus 6. Rcuprer la base de donnes (pas uniquement les fichiers de donnes car on repart d'une sauvegarde de fichier de contrle; sous entendu un CROSSCHECK et CATALOG) 7. Ouvrir la base de donnes 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

5.12.6.7. Scnario 7 : Restauration incomplte en mode ARCHIVELOG Hypothse : tout est perdu : fichier SPFILE, fichier de contrle, fichier de donnes, fichier de journalisation en ligne. Ce type de restauration est ncessaire dans les cas suivants : perte de tous les redo log file perte d'un fichier de journalisation archiv ncessaire une rcupration 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 opratoire : 1. Positionner le SID 2. Dmarrer l'instance sans la monter 3. Restaurer le fichier de paramtres serveur 4. Redmarrer l'instance sans la monter (dmarrage avec le SPFILE) 5. Restaurer les fichiers de contrle 6. Monter la base 7. Synchroniser le rfrentiel 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. Scnario 8 : Restauration en mode NOARCHIVELOG Hypothses : perte de tout ou une partie de la base de donnes mode noarchivelog Solution : ramener la base de donne l'tat o elle se trouvait lors de la dernire sauvegarde complte base ferme. 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 dernire sauvegarde, on peut alors tenter une restauration de type archivelog. Si la rcupration signale une erreur, la situation est priori dsespre. Dans ce cas, on peut tenter une restauration en mode NOARCHIVELOG. Mode opratoire : 1. Positionner le SID 2. Dmarrer l'instance sans la monter 3. Restaurer les fichiers de contrle partir d'une sauvegarde automatique 4. Monter la base 5. Restaurer la base 6. (ventuellement) restauration incrmentale 7. Ouvrir la base de donnes 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

5.12.6.9. Scnario 9 : Restauration un emplacement diffrent Hypothse : impossible de restaurer les fichiers de donnes dans l'arborescence d'origine. Solution : utiliser deux commandes supplmentaires dans le processus de restauration (dans un bloc run) : Avant la restauration : SET NEWNAME FOR DATAFILE ancien TO nouveau; Aprs la restauration mais avant la rcupration : 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. Scnario 10 : Tablespace temporaire gr localement Les fichiers de donnes des tablespaces temporaires grs localement ne sont jamais sauvegards par RMAN et ne peuvent donc pas tre restaurs. Aprs une restauration, il faut donc recrer les fichiers de donnes des tablespaces grs localement. 5.12.7. Techniques de flashback Fonctionnalit permettant d'interroger les donnes telles qu'elles taient un instant donn du pass. Trois niveaux : niveau ligne : requte, 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 donnes : permet de ramener la totalit de la base de donne l'tat o elle tait un certain moment dans le pass.

Soors Aurore

37