BUFFER CACHE SHARED POOL LRU

Transcription

1 1

2 2

3 3

4 Taille des CACHEs de l instance La taille de la SGA est principalement dépendante de la taille du «BUFFER CACHE» et de l espace «SHARED POOL». L algorithme de gestion de ces espaces de mémoire est de type LRU (Least Recently Used), c est-à-dire que les informations les plus fréquemment sollicitées sont maintenues dans le CACHE. Pour obtenir de bonnes performances au niveau de l instance, il convient d agrandir ces espaces virtuels afin de limiter le plus possible les échanges entre la mémoire vive et les disques du système. Cependant, il faut éviter de définir des CACHES trop grands pour ne pas pénaliser le système de gestion de mémoire virtuelle du système d exploitation. Définir une SGA trop grande a pour effet de générer une pagination et/ou du «swap» trop intensif. A partir de la version 10g la taille des CACHE est automatiquement optimisée lorsque le paramètre d instance SGA_TARGET est défini. Le moteur Oracle Database calcule dynamiquement les tailles des CACHE en fonction de l activité. Il est possible de faire varier la valeur de SGA_TARGET sans avoir à redémarrer l instance. La limite est définie au démarrage par le paramètre SGA_MAX_SIZE En version 11g le même principe est utilisé et est étendu à la quantité de mémoire virtuelle que l instance Oracle utilise : SGA + PGA. C est le paramètre d instance MEMORY_TARGET qui permet de définir l espace de mémoire qui sera utilisé par Oracle. La limite est définie au démarrage par le paramètre MEMORY_MAX_TARGET. 4

5 «Buffer Cache Hit Ratio» La taille optimale du BUFFER CACHE se calcule en établissant le nombre de lectures de blocs dans la base de données («Physical read») par rapport au nombre de blocs demandés (consistent gets). Ce ratio doit être supérieur à 90%. La requête suivante permet de calculer le «Buffer Cache Hit Ratio» : Connect / as sysdba SELECT round((1 - (phys.value / (db.value + cons.value))) * 100, 2) "Cache Hit Ratio" / FROM v$sysstat phys, v$sysstat db, v$sysstat cons WHERE phys.name = 'physical reads' AND db.name = 'db block gets' AND cons.name = 'consistent gets' 5

6 Synchronisation du CACHE Les BUFFERs qui ont été modifiés dans le CACHE («dirty buffer») par les opérations DML (INSERT, UPDATE, DELETE) sont écrits dans la base de données par le processus DBWR. Ce type d opération est appelé CHECKPOINT. Les CHECKPOINT se produisent dans les cas suivants : Lorsqu il n y a plus de BUFFER disponibles dans le cache En fonction de la valeur des paramètres fast_start_mttr_target ou log_checkpoint_interval A la demande d un processus serveur pour libérer de l espace dans le CACHE Lors d une commutation de REDOLOG («log switch») Sur la commande «alter system checkpoint» Les paramètres d instance fast_start_mttr_target et log_checkpoint_interval permettent de régler la fréquence des CHECKPOINT. Le paramètre fast_start_mttr_target est exprimé en secondes. Il indique quel est le temps de RECOVER d instance désiré en cas de crash de cette dernière. Si sa valeur est faible, le moteur Oracle effectue des CHECKPOINT plus souvent pour optimiser le temps de RECOVER et par conséquent effectue plus d entrées/sorties. Inversement, si la valeur du paramètre est élevée (3600 secondes maximum) les performances seront meilleures mais le temps de RECOVER peut être plus long. Le paramètre log_checkpoint_interval est exprimé en nombre de bloc de 512 octets écrits dans le REDOLOG avant de déclencher un point de synchronisation. Ce paramètre est remplacé par fast_start_mttr_target à partir de la version 10g. Dans tous les cas, un CHECKPOINT est déclenché sur un «switch» de REDOLOG. Par conséquent, il est recommandé de créer des REDOLOG de grande taille afin de pouvoir optimiser la fréquence des CHECKPOINT en utilisant les paramètres d instance pour obtenir des temps de réponse optimums. 6

7 BUFFER REDOLOG Le BUFFER REDOLOG contient les enregistrements des images avant et après des données en cours de modification (seulement les octets modifiés). Ces informations sont écrites dans le fichier REDOLOG sur les évènements suivants : Quand un COMMIT survient Lorsque le BUFFER est rempli de plus d un tier Au bout d une période définie (quelques secondes) L utilisateur est averti lorsque le BUFFER a été vidé complètement. Pendant que le processus LGWR travaille, la SGA est verrouillée pour tous les processus serveurs qui tentent d y écrire. Par conséquent, si le temps d écriture dans le fichier REDOLOG est lent, les performances de toute l instance sont impactées. 7

8 Surveillance proactive des performances Oracle Database vous permet de surveiller et contrôler facilement le comportement et les performances. Les fonctions vitales (ou metrics) et les performances de votre database sont surveillées en permanence, la charge de travail est analysée afin d identifier les points sensibles qui méritent plus d attention. Les problèmes identifiés sont présentés comme des alertes et des résultats de performance sur la page d'accueil. Vous pouvez également configurer Oracle Enterprise Manager Database Control (contrôle de la base de données) pour vous informer par e- mail. 8

9 Surveillance Générale de l état de la base et de la charge de travail La figure ci-dessus montre la page d accueil de la console d Oracle Enterprise Manager. Elle vous permet de surveiller l état de la base ainsi que la charge de travail. La page est mise à jour régulièrement. Pour surveiller l état et la charge de travail de la base de données : 1. Aller sur la page d accueil. (Facultatif) cliquer sur le bouton «refresh» pour rafraîchir les informations. 2. Par défaut, la page d accueil est automatiquement rafraîchie toutes les 60 secondes. 3. Vous pouvez consulter un aperçu rapide de la database dans la section «General» 4. Cliquer sur View All Properties pour consulter le «Oracle home path» et savoir si la database est ouverte en lecture seule ou pas. 5. Consulter l utilisation CPU dans la section Host CPU 6. Étudier la section «Active Sessions», où vous pourrez explorer plus avant la cause des problèmes de performance, tels que votre base de données prenant la plus grande partie du temps processeur sur le serveur. 7. Consulter la section Diagnostic Summary 9

10 Collecte automatique des informations Le moteur Oracle collecte automatiquement des informations statistiques destinées à l optimisation des requêtes SQL et aux mesures de performance. Il y a deux types de statistiques : Les statistiques associées aux segments de la base (Tables et Index) qui permettent au moteur de base de données de déterminer le meilleur Plan d Exécution pour optimiser les temps de réponse des ordres SQL. Par exemple, le nombre de lignes (num_rows), le nombre de blocs (blocks) et la longueur moyenne d un enregistrement (avg_row_len) d une table de la base de données font partie des statistiques que le moteur d optimisation SQL peut exploiter pour améliorer les performances. Les informations statistiques de comportement de l instance de base de données sont collectées régulièrement (toutes les heures par défaut) et ces clichés sont stockés dans le référentiel de charge de travail AWR (Automatic Workload Repository). Ces clichés sont exploités par le moteur d analyse ADDM (Automatic Diagnostic Database Monitor) pour établir des diagnostics et des mesures de performance par comparaison. 10

11 Concernant les alertes Les alertes vont vous permettre de surveiller votre base de données. La plupart des alertes vous informent lorsque des métriques de seuils sont atteints. Pour chaque alerte critique, vous pouvez définir des seuils. Lorsque ces valeurs limites sont dépassées, cela indique que le système est dans un état indésirable. Par exemple, quand un Tablespace est à 97 plein, ce qui peut être considérée comme indésirable, la base de données Oracle va générer une alerte critique. D autres alertes correspondent à des événements tels que «Snapshot too old» ou «Resumable session suspend». Ces types d'alertes indiquent que l'événement a eu lieu. En plus des notifications standard, vous pouvez définir des alertes pour effectuer certaines actions telles que l'exécution d'un script. Par exemple, les scripts qui gèrent l espace utilisé au sein d un Tablespace peuvent être utiles pour contrôler ce type de problème. Par défaut, plusieurs alertes sont disponibles, notamment les suivantes : Espace de Tablespace utilisé (un avertissement à 85 %, critique à 97 %) Current Open Curseurs Count (un avertissement au-dessus de 1200) Session limite d'utilisation (un avertissement à 90 %, critique à 97 %) Broken Job Count and Failed Job Count (avertissement au-dessus de 0) Espace dump utilisé (un avertissement à 95 % de remplissage) Espace d archivage utilisé (un avertissement à 80 % de remplissage) Vous pouvez modifier ces alertes, et en définir d'autres en modifiant leurs paramètres. 11

12 Auto diagnostic de performances : Automatic Database Diagnostic Monitor Oracle Database comprend un moteur d auto diagnostic appelé «Automatic Database Diagnostic Monitor» (ADDM). ADDM permet d établir pour Oracle Database une analyse de ses propres performances et de déterminer comment résoudre les problèmes qui ont été identifiés. Afin de faciliter le diagnostic automatique de performances, ADDM collecte régulièrement des clichés de l état de la database et de la charge de travail. Ces clichés sont des regroupement d information sur l historique des temps de réponse et sont utilisés pour établir des comparaisons de performances par ADDM. L intervalle de collecte par défaut est d une heure. Ces clichés (snapshots) sont stockés dans le référentiel «Automatic Workload Repository (AWR)», qui réside dans le Tablespace SYSAUX avec une rétention de 8 jours. ADDM analyse les informations capturées dans AWR et détermine les principaux problèmes du système dans la plupart des cas, émet des recommandations, des solutions et quantifie les bénéfices escomptés. 12

13 Clichés AWR Le moteur Oracle Database prend des clichés de statistiques de performance à intervalles réguliers. La fréquence par défaut est d une heure, il est possible de la modifier en cliquant sur le lien «Référentiel de charge globale» de la section «Gestion des Statistiques» de l onglet «Serveur.» Il est également possible de créer des clichés en utilisant la procédure CREATE_SNAPSHOT du package DBMS_WORKLOAD_REPOSITORY afin de pouvoir mesurer les performances de l instance sur une durée spécifique. 13

14 Jeux de clichés AWR En utilisant des jeux de clichés, vous pouvez baliser des ensembles de données de cliché pour des périodes importantes. Un jeu de clichés est défini sur une paire de clichés. Ces derniers sont identifiés par leur numéro de séquence (snap_id). Chaque jeu de clichés correspond à une seule paire de clichés. Un jeu de clichés peut être identifié par un nom fourni par l'utilisateur ou par un identificateur généré par le système. Pour créer un jeu de clichés, il vous suffit d'exécuter la procédure DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE, et d'indiquer un nom et une paire d'identificateurs de cliché. Un identificateur est affecté au nouveau jeu de clichés. Les identificateurs de jeu de clichés sont uniques pour toute la durée de vie d'une base de données. Les jeux de clichés sont utilisés pour conserver les données de clichés. Par conséquent, les clichés appartenant à des jeux sont conservés jusqu'à la suppression de ces derniers. Vous pouvez configurer des jeux de clichés, généralement à partir de périodes représentatives dans le passé, afin de les utiliser pour une comparaison avec le comportement actuel du système. Vous pouvez également configurer des alertes basées sur des seuils à l'aide de jeux de clichés à partir de Database Control. Vous pouvez obtenir les numéros de séquence (snap_id) directement à partir de DBA_HIST_SNAPSHOT ou d'enterprise Manager Database Control. 14

15 Créer un jeu de clichés AWR Pour créer un ensemble de clichés AWR : 1. Cliquez sur l onglet «Serveur» en haut de la page d accueil. 2. Dans la section «Gestion des Statistiques», cliquez sur «Référentiel de charge globale automatique» («Automatic Workload Repository.») 3. Cliquez sur le lien «Clichés» 4. Cliquer sur le bouton «Exécuter un rapport AWR). 5. Cocher le radio bouton «Par clichés». 6. Sélectionner le cliché de début (utiliser le bouton liste de valeurs). 6. Sélectionner le cliché de fin et cliquer sur le bouton «Générer le rapport». Le rapport AWR peut être généré avec SQL*Plus en tant que SYSDBA en exécutant le script $ORACLE_HOME/rdbms/admin/awrrpt.sql. 15

16 Analyse d un jeu de clichés Le détail d un ensemble de clichés AWR résume les statistiques de comportement de l instance de base de données pour une période spécifique. Pour tracer un éventuel problème de performances, vous pouvez générer plusieurs ensembles de clichés sur des périodes différentes en procédant par comparaison. Pour chaque période vous pouvez également créer un rapport de performances AWR en cliquant sur le lien «Rapport» comme sur la figure ci-dessus ou manuellement en exécutant la commande SQL suivante : SQL> connect / as sysdba Le «?» remplace $ORACLE_HOME sous Unix/Linux 16

17 Rapport de performances AWR Une technique efficace pour pister un problème de performances est de générer un rapport AWR pour consulter les paragraphes «Wait events Statistics» et «SQL Statistics.» «Wait events Statistics» vous informe sur les évènements d attentes les plus longs. C est une indication précieuse qui vous met rapidement sur la piste du problème. «SQL Statistics» montre tous les ordres SQL par ordre de consommation et de temps de réponse. 17

18 Onglet Performances L onglet performance affiche une vue d ensemble et un accès rapide au comportement général de l instance. En cliquant sur le lien «Taux d activité les plus élevés» de la section «liens de surveillance supplémentaires» vous pouvez accéder en temps réel à la page de surveillance des requêtes SQL actives. Ainsi l on peut analyser et intercepter les ordres SQL les plus consommateurs. 18

19 Concernant les conseillés Les conseillers sont de puissants outils de gestion de bases de données. Ils fournissent des conseils précis sur la manière d'aborder les principaux défis en matière de gestion de base de données, couvrant un large éventail de domaines, y compris l'espace, les performances et la gestion des transactions («rollback»). En général, les conseillers produisent plus de recommandations que les alertes. La génération d'alerte est destinée à être peu coûteuse et a un impact minimal sur les performances, tandis que les conseillers consomment d avantage de ressources et effectuent une analyse plus détaillée. Les conseillers sont fournis pour aider à améliorer les performances de la base de données. Ces conseillers comprennent également «Automatic Database Diagnostic Monitor» (ADDM), «SQL advisor» ainsi que les conseillers de la mémoire. Par exemple, l'un des conseillers de la mémoire, le «Shared Pool Advisor», affiche graphiquement l'impact sur la performance en fonction de l'évolution de la taille de ce composant du Système Global Area (SGA). Les conseillés de performance ainsi que les autres sont détaillés ci-dessous : Automatic Database Diagnostic Monitor (ADDM) - ADDM permet à Oracle Database de diagnostiquer sa propre performance et de déterminer comment résoudre la plupart des problèmes identifiés. SQL Advisors - Le conseillé «SQL Tuning Advisor» analyses un ou plusieurs ordres SQL et emet des recommendations pour améliorer les performances. Il est exécuté automatiquement pendant les périodes de maintenance et peut être également lancé manuellement. Le conseillé «SQL Access Advisor» effectue automatiquement les réglages de schéma pour une charge de travail donnée. Par exemple, SQL Access Advisor peut produire des recommendations pour la création d index, de vue matérialisées ou de tables partitionnées. Memory Advisors - Les Memory Advisors produisent des analyses graphiques concernant les tailles de la SGA, la PGA ou des composants de la SGA. En fonction du mode de gestion de la mémoire les différents conseillés sont disponibles. Si l «Automatic Memory Management» est actif, seul le Memory Advisor est disponible. Ce conseillé fournit des recommandations globales pour l ensemble total de l instance. Si l «Automatic Shared Memory Management» est actif, les conseillés pour la SGA et la PGA sont disponibles. Si la gestion manuelle de la Shared Memory est activée, le Shared Pool Advisor, Buffer Cache Advisor et le PGA Advisor» sont disponibles. Autres conseillés - Le «Segment Advisor» produit des recommandations sur la réorganisation des segments candidats à des opérations de réduction d espace lorsqu ils sont fragmentés. Le conceillé rend compte également de l historique d agrandissement des segments. Le «Undo Advisor» offre une assistance au dimensionnement du «undo tablespace». Le «Undo Advisor» peut également fournir des recommandations pour définir la valeur du seuil d une période de rétention «undo» nécessaire à «Oracle Flashback.» 19

20 20

21 21

22 22

23 Présentation d Oracle Data Pump Oracle «Data Pump» est une amélioration des outils classiques Export/Import. Il offre les fonctionnalités suivantes : Un mode d exécution en parallèle. Cela permet d accroître considérablement les performances. Une API afin de pouvoir intégrer l outil avec d autres applications. Un mode de contrôle d exécution des travaux et d exécution en mode «batch». 23

24 Mise en œuvre d Oracle Data Pump La diapositive ci-dessus montre un exemple d utilisation de Data Pump. L extraction est effectuée par le USER RADI. Les commandes Data Pump sont associées à un directory qui doit être créé préalablement. Le rechargement des données est effectué dans le schéma RADI2. La directive REMAP_SCHEMA indique cette conversion. La directive TRANSFORM indique que les attributs de stockage des tables sont conservés. 24

25 Migration avec Export/Import Bien que cette technique soit simple et robuste, il est tout de même nécessaire de contrôler la cohérence des jeux de caractères entre la base source et la cible. Des conversions implicites peuvent se produire en fonction des jeux de caractère utilisés. La diapositive ci-dessus illustre les mécanismes de conversion qui peuvent éventuellement se produire. Les informations sont automatiquement converties si les jeux de caractères sont différents entre la source et la cible. La variable d environnement NLS_LANG a une influence sur les conversions des jeux de caractères, il ne faut pas oublier que sa valeur par défaut est «American_America.US7ASCII». Le jeu de caractères US7ASCII est encodé sur 7 bits et cela peut générer des erreurs de conversion. Data Pump et les versions récentes d Export et Import gèrent correctement ces problèmes de conversion de jeux de caractères. 25

26 Migration avec Oracle Data Pump La méthode de migration la plus efficace avec cet outil est sûrement d importer directement les informations dans la base cible via un lien inter bases : Exemple : select * from dba_db_links; select * from dba_directories; base source grant exp_full_database, resource, connect to schema_source; base cible connect system/syspwd create database link migrate_dblink connect to schema_source identified by secret using 'ALIAS_NET'; impdp system/syspwd schemas=schema_source \ transform=segment_attributes:n:table \ remap_schema=schema_source:schema_cible directory=data_pump_dir \ network_link=migrate_dblink 26

27 27

28 28

29 Une bonne stratégie de sauvegarde/restauration dépend souvent des choix et de l analyse des problèmes qui peuvent se poser sur un système d information. Dans bien des cas, la politique de sauvegarde peut s avérer inopérante car elle est bâtie sur des postulats qui sont faux. Une panne survient souvent là où on ne l attend pas et ne se manifeste pas dans les mêmes circonstances et sous la même forme que pendant les scénarios de simulation qui ont servis à élaborer la stratégie de sauvegarde/restauration. Les techniques de sauvegarde divergent en fonction des types de système d information à sauvegarder, par exemple : «Operating system» copie de fichiers (cp, copy) duplication de disques (ufsdump, dd) copie de système de fichiers (tar, cpio, xcopy) Logiciels de sauvegarde : Netbackup, Networker, Tivoli, etc Bases de données : extractions logiques (export, sqlplus) duplication physique avec arrêt du SGBD (problèmes de disponibilité) copie physique des fichiers sans arrêt de l exploitation sauvegarde des blocs de la base contenant des informations Les bases de données ont d autres contraintes d exploitation : les problèmes de réorganisation engendrent des risques d indisponibilité les besoins de garantir la cohérence des données Le modèle transactionnel part d un état consistant vers un autre état consistant, il n y pas d état intermédiaire. Il faut donc un système de sauvegarde de base de données différent des systèmes classiques et capable de répondre aux exigences d exploitation des SGBD. 29

30 Une base Oracle fonctionne par défaut en mode NOARCHIVELOG sauf si à sa création le mode ARCHIVELOG a été définis explicitement. En mode NOARCHIVELOG il n est pas recommandé et supporté par Oracle de prendre une sauvegarde des fichiers de la base si l instance est ouverte et ce même s il n y a aucune session active pendant la copie des fichiers. Oracle ne garanti pas le redémarrage d une base restaurée qui avait été sauvegardée à chaud en mode NOARCHIVELOG. En d autres termes, on peut dire qu Oracle ne propose pas de solution particulière en matière de sauvegarde/restauration si la base fonctionne en NOARCHIVELOG. La stratégie de sauvegarde de la base est laissée au niveau du système d exploitation. Dans ce mode, seules les dernières transactions actives en mémoire au moment d un crash de l instance seront récupérées automatiquement (instance recovery) au redémarrage de celle-ci. En cas de perte d un composant de la base (DATAFILE, REDOLOG, Controlfile), une sauvegarde complète doit être restaurée et toutes les transactions qui ont été passées au-delà de cette sauvegarde seront perdues. V1.0 30

31 Le mode ARCHIVELOG est la réelle solution d Oracle en matière de stratégie de sauvegarde/ restauration lorsque les enjeux du système d information sont importants. Pour commuter le mode de fonctionnement en ARCHIVELOG procéder comme suit : stopper l instance proprement : "shutdown" normal ou "immediate " (surtout pas ABORT) monter l instance : SQL> STARTUP MOUNT entrer la commande DDL : SQL> ALTER DATABASE ARCHIVELOG arrêter à nouveau l instance prendre une sauvegarde complète de tous les fichiers de la base : DATAFILES, REDOLOGS, CONTROLFILE modifier les paramètres d instance : log_archive_dest_1 répertoire de destination des fichiers Archivelogs log_archive_format format du nom de fichier des fichiers Archivelogs L intégralité des données et des transactions actives seront récupérées dans la majorité des cas de figures de panne sur une base Oracle qui fonctionne en mode ARCHIVELOG. Ce mode de fonctionnement fourni d autre avantages : Sauvegarde de la base sans arrêter l exploitation Sauvegardes entrelacées avec l exploitation Restauration en ligne de la plupart des Tablespaces (sauf les Tablespaces SYSTEM, SYSAUX) Une stratégie de sauvegarde/restauration bien élaborée peut permettre des temps de restauration très courts gestion des cas limites (DISASTER RECOVERY) 31

32 Le mode ARCHIVELOG assure la sauvegarde permanente des fichiers REDOLOGS qui tracent les transactions actives. Lorsque le système commute sur le fichier REDOLOG suivant, le fichier REDOLOG précédent est automatiquement copié dans le répertoire destiné aux fichiers ARCHIVELOGS. Oracle conserve ainsi la continuité des fichiers journaux des transactions et par conséquent est capable de refaire ou rejouer les opérations qui ont modifié les données de la base. Le mode ARCHIVELOG garanti qu un fichier REDOLOG ne sera pas écrasé tant qu il n aura pas été archivé par Oracle. Si l on oublie de purger le répertoire qui contient les fichiers des REDOLOGS archivés, le disque risque d être saturé et le mécanisme ARCHIVELOG sera bloqué. Pour débloquer cette situation il suffit de sauvegarder quelques fichiers «Archivelogs» et de les supprimer du répertoire. Cette fonction est automatiquement prise en charge avec l outil «Recovery Manager». 32

33 Lorsqu une corruption se produit sur un fichier de la base de données il est nécessaire de le restaurer. Le fichier de sauvegarde restauré est en retard avec l état consistant de la base. Si l on tente de remettre l élément restauré en ligne, Oracle indique par un message d erreur (ORA 1113) qu il faut exécuter un RECOVER du fichier («media recovery») pour le remettre en phase avec les autres. Cette opération consiste à appliquer les fichiers ARCHIVELOGS qui contiennent les données des transactions qui ont été produites après la sauvegarde du fichier restauré. Pour exécuter cette opération il faut entrer la commande DDL : «RECOVER», Oracle proposera automatiquement l emplacement et le nom des fichiers ARCHIVELOGS nécessaires pour effectuer le RECOVERY. Lorsque tous les fichiers d archives ont été appliqués, Oracle affiche le message : «media recovery complete». Il suffit alors de remettre l élément restauré en ligne. 33

34 Principe basique de sauvegarde d un Tablespace en ligne Le mode ARCHIVELOG permet d effectuer des sauvegarde de la base sans pour autant arrêter l exploitation de la base de données. Le principe basique de sauvegarde en ligne existe bien avant l arrivée de l outil Recovery Manager. Ce principe est encore supporté si l on ne désire pas utiliser RMAN. Il permet de comprendre comment fonctionne le mode ARCHIVELOG. La figure ci-dessus illustre l opération. La commande «ALTER TABLESPACE BEGIN BACKUP» permet d indiquer au serveur Oracle qu une sauvegarde va être prise avec un outil tiers du système d exploitation. Quand la copie de sauvegarde a été prise, il faut indiquer au moteur Oracle que la procédure de sauvegarde est terminée pour ce Tablespace. Exemple : $ sqlplus / as sysdba SQL> alter tablespace system begin backup ; SQL>! cp /data/oradata1/db10g/syst01.dbf /data/oradata2/db10g/syst01.dbf SQL> alter tablespace system end backup ; 34

35 Sauvegarde en ligne du CONTROLFILE La commande de sauvegarde ci-dessus prend une copie binaire du fichier de contrôle. Si l on utilise ce fichier pour restaurer le CONTROLFILE, il faudra ensuite exécuter une procédure de récupération avec la clause USING BACKUP CONTROLFILE. Il est également possible de recréer le fichier de contrôle à partir de l ordre : «CREATE CONTROLFILE» Pour générer le script SQL de recréation du fichier de contrôle qui utilise cette instruction entrer la commande : ALTER DATABASE BACKUP CONTROLFILE TO TRACE Le script généré est un fichier trace (suffixe.trc) et se trouve dans le répertoire pointé par le paramètre user_dump_dest. 35 6

36 Restauration et RECOVER d un TABLESPACE en ligne Ce type de restauration peut s appliquer sur tous les TABLESPACES sauf pour les TABLESPACE SYSTEM. Le temps de récupération (RECOVERY) sera d autant plus court que la sauvegarde du fichier est récente. Il peut être intéressant d effectuer des sauvegardes à chaud des TABLESPACES le plus fréquemment possible afin d optimiser les temps de reconstruction (RECOVERY) sur les systèmes à haute disponibilité. 36

37 Restauration et RECOVER d un DATAFILE en ligne Ce type de restauration est similaire au mode précédent mais avec un niveau plus fin de dépannage. Si le TABLESPACE concerné par le dysfonctionnement est constitué par plusieurs fichiers DATAFILE, il n est pas nécessaire de mettre hors circuit l intégralité du TABLESPACE. Seul le DATAFILE corrompu sera déconnecté et restauré. Les autres fichiers restent en ligne pendant l opération de dépannage. Le temps de récupération sera proportionnel au nombre de fichier ARCHIVELOG à appliquer. Ce nombre est en fonction de la date de la dernière sauvegarde du DATAFILE restauré. Si elle est récente le temps de récupération sera court. Il peut être très intéressant de sauvegarder très fréquemment à chaud les fichiers des TABLESPACES sur d autres disques de la machine. Cela va permettre d optimiser considérablement les temps de restauration et de RECOVER des DATAFILES. En effet, il suffira de commuter les noms de fichier des DATAFILES avec la commande DDL: ALTER TABLESPACE RENAME DATAFILE pour restaurer instantanément la sauvegarde. Le temps de dépannage sera proportionnel à la durée d exécution de la récupération. 37

38 Restauration à froid La restauration base fermée est équivalente aux cas précédents. Elle devrait normalement être effectuée que s il y a une panne sur le TABLESPACE SYSTEM. Il est inutile et dangereux de restaurer tous les fichiers DATAFILE si seulement quelques un sont endommagés. Si les sauvegardes sont bien faites, la récupération remettra en phase tous les fichiers même s ils n ont pas été sauvegardés au même moment. Il y a un risque de tout restaurer systématiquement. Certains fichiers peuvent être défectueux sur les bandes de sauvegarde par exemple. En les restaurant, les DATAFILES qui n étaient pas endommagés seront écrasés par des fichiers corrompus. La probabilité de rencontrer ce genre de cas de figure est d autant plus importante que la base est volumineuse. Restauration et restitution incomplète Les cas qui justifient une restauration incomplète sont rares. Ils se présentent dans des circonstances particulières où plusieurs facteurs d anomalie se sont manifestés conjointement. Par exemple, la perte de tous les membres du CURRENT REDOLOG causée par une erreur de manipulation (cela ne devrait jamais se produire si les fichiers sont installés dans des répertoires différents inaccessibles à des utilisateurs non avertis). La restauration incomplète utilise la clause UNTIL de la commande RECOVER qui indique que la récupération ne sera pas exécutée jusqu au bout. Il est donc important de restaurer l intégralité des DATAFILES de la base pour que ceux-ci soient en phase au point d arrêt de l opération RECOVER. 38

39 La restauration intégrale de tous les fichiers de la base peut être très coûteuse en temps si la base est très volumineuse. A partir de la version 10g il est possible de remplacer dans certaines circonstances la restauration de tous les fichiers DATAFILES par une opération «Flash Back». Cette fonctionnalité doit être configurée au préalable. Pour plus d information à ce sujet consulter la documentation «Oracle Database Backup and Recovery Advanced User's Guide 10g Release 1 (10.1)» chapitre 9. Cette documentation est disponible sur Il y a trois possibilités pour la clause UNTIL de la commande RECOVER : RECOVER UNTIL CANCEL : les ARCHIVELOGS et/ou les REDOLOGS seront appliqués jusqu au moment ou l opérateur DBA décide l arrêt de la récupération en entrant CANCEL sur le prompt de SVRMGRL, RMAN ou SQL*Plus (selon la version). RECOVER UNTIL TIME... : Le RECOVER s arrêtera lorsqu il aura atteint la date et l heure indiquée par l opérateur sur cette commande. RECOVER UNTIL CHANGE : L opération de récupération s arrêtera lorsqu on aura atteint le SCN spécifié sur cette commande. Quand l opération de récupération est terminée il faut ouvrir la base avec l option RESETLOGS pour vider le contenu des REDOLOGS que l on ne va pas rejouer. Si les REDOLOGS ont été perdus lors de la panne, ils seront automatiquement recréés par la commande RESETLOGS. La LOG SEQUENCE est repassée à 0 à l ouverture de la base et il est impératif de lancer une sauvegarde complète de celle-ci avant de relancer l exploitation. En 10g de nouvelles fonctionnalités ont été aménagées pour ne pas avoir à exécuter immédiatement une sauvegarde derrière une ouverture en mode RESETLOGS. 39