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

40 40

41 41

42 42

43 Exemple de traitement d une requête d interrogation 1. Requête utilisateur : SELECT wage from EMP WHERE name = 'Jones ; 2. Recherche dans le cache Un ordre SQL identique 3. Analyse syntaxique et sémantique, etc., verrouillage, création du plan d exécution. 4. Récupération du bloc de données depuis le tablespaces vers le Buffer Cache. 5. Identifie et renvoie vers le processus serveur les enregistrements demandés 6. Retour du résultat : wage

44 Traitement d un ordre DML 1. Envoi de la requête : UPDATE EMP SET wage = 925 WHERE name = 'Jones' 2. Les informations à modifier sont ramenée dans le BUFFER CACHE (si nécessaire), les verrous sont placés 3. Les images avant et après sont copiées dans le BUFFER REDOLOG 4. Le bloc est dupliqué dans le CACHE; il est ensuite modifié; l ancienne version est gardée pour le ROLLBACK 5. L utilisateur est informé du résultat : 1 Record Updated 44

45 Traitement du COMMIT 1. L utilisateur envoie : commit 2. Le processus serveur envoie le commit vers le BUFFER REDO LOG, un System Change Number (SCN) est assigné 3. Le processus LOG WRITER écrit les entrées du BUFFER REDO dans le fichier REDOLOG 4. l utilisateur est informé que la transaction est terminée 5. Les blocs associés à la transaction (before et after images) sont libérés 45

46 Synoptique des mécanismes du noyau Ce chapitre a pour but de donner un aperçu des mécanismes internes du moteur Oracle afin d avoir une meilleure compréhension du fonctionnement des opérations de RECOVER. Il est également important de pouvoir différencier les mécanismes de gestion des transactions et ceux qui contrôlent l écriture des BUFFERS du CACHE dans la base de données. Ils sont exécutés par deux couches logicielles distinctes : TRANSACTION LAYER et CACHE LAYER. Les notions relatives à la couche TRANSACTION : SCN, «Transaction Recovery» et celles qui concerne la gestion du CACHE : «Check Point», «Cache Recovery» sont exposées ici. Zoom sur le bloc Oracle Modification d un bloc de données Oracle contrôle différents types de blocs en fonction des types de fichiers à gérer : Les blocs du CONTROLFILE et des REDOLOGS Les blocs des segments qui sont stockés dans les DATAFILES. Les types de segments qui nous intéressent dans ce chapitre sont : Les segments de données et d index Les «Rollbacks segment» La structure des blocs est constituée d un entête (HEADER) et d un contenu. Le HEADER de chaque type de bloc comporte une zone d information standard qui contient notamment : La «Data Block Adress» ou DBA. Elle correspond aux coordonnées d implantation physique du bloc dans la base de données. C est-à-dire au numéro de TABLESPACE, de fichier dans ce TABLESPACE et de bloc dans ce fichier. L «Incarnation number». Ce numéro indique la validité chronologique des informations que le bloc contient. Si le bloc est vide, ce numéro est à zéro. 46

47 La diapositive précédente montre la structure d un bloc de données. Lorsque celui-ci est modifié en mémoire par une instruction SQL DML (INSERT, UPDATE, DELETE), une entrée du tableau ITL (Interested Transaction List) de l entête est allouée. La taille de ce tableau est variable, elle est définie par les options INIT_TRANS et MAX_TRANS des instructions CREATE TABLE et/ou ALTER TABLE. Chaque entrée du tableau des ITL qui est utilisée pointe sur l enregistrement concerné par l opération et contient un identifiant de transaction. Cet identifiant est constitué d un numéro de «Rollback segment» (RBS), du slot (SLT) qui est mobilisé dans l entête du Rollback segment» et de l adresse des informations qui sont concernées par la modification du bloc en cours. «Rollback segment» Une transaction est identifiée par un numéro qui est attribué par le système : le SCN (System Change Number). A chaque SCN est associé un horodatage qui permet de déterminer la validité des informations par rapport au temps. Les «Rollbacks segments» sont constitués d un ensemble de blocs qui sont stockés dans les DATAFILES des TABLESPACES UNDO. Ils sont gérés par la couche logicielle TRANSACTION et stockent l ensembles des informations relatives à une transaction active. Le bloc d entête contient un tableau des points d entrée (slots) de toutes les transactions actives qui utilisent le «Rollback segment» pour sauvegarder les informations en cours de modification : l image avant. Tant qu une transaction est active, ses informations sont verrouillées dans les blocs du «Rollback segment». Le statut et le SCN de chaque transaction est indiqué dans le slot mobilisé par la transaction. Lorsqu une transaction se termine, le statut de l entrée associée est modifié. Si la transaction est validée (COMMIT), le SCN est alloué et est stocké dans le slot de l entête du «Rollback segment» affecté à la transaction. Les informations qui constituent l image avant sont déverrouillées et par conséquent peuvent être écrasées par des données plus récentes. Cependant, ces informations peuvent être éventuellement utilisées pour reconstituer une version cohérente des données demandées par des requêtes SQL associées à un SCN inférieur à celui de la transaction qui vient de se terminer. Si la transaction est annulée (ROLLBACK), les informations qui constituent l image avant sont restaurées dans les blocs d origine et le slot de la table des transactions est libéré. 47

48 L écriture dans le «Rollback segment» est circulaire, c est-à-dire que lorsque l on atteint la fin de celui-ci, les nouvelles «images avant» des transactions qui sont déjà actives sont écrites au début du segment. Une transaction utilise normalement qu un seul «Rollback segment» à la fois. Alimentation du BUFFER REDOLOG Toutes les opérations qui sont effectuées par la couche TRANSACTION sont exécutées en mémoire vive dans la SGA. Le noyau Oracle est conçu pour optimiser les applications transactionnelles (OLTP) en limitant et regroupant les entrées/sorties. Pour assurer la tolérance de panne, Oracle consigne chaque opération élémentaire qui modifie les blocs de la base de données dans les fichiers REDOLOGS. L écriture dans le REDOLOG est très fréquente et est effectuée par le processus LGWR lorsqu un des évènements suivants intervient : Un tiers du BUFFER REDO est rempli Une transaction COMMIT Un délai de trois secondes Quand les blocs du CACHE sont écrits dans la base Le BUFFER REDOLOG est alimenté en permanence par les processus qui exécutent les ordres SQL DML. L information des «Rollback segments» («before image») ainsi que les données de modification des blocs («after image») y sont stockés. 48

49 «Rolling Forward» Le «Rolling Forward» est l opération qui consiste à reconstituer les blocs de la base qui n ont pas pu être écrits avant une panne de l instance. Il peut être exécuté soit automatiquement au démarrage du moteur de base de données lors d un «Instance Recovery», soit après une procédure de restauration de fichiers DATAFILES lors d un «Media Recovery». Les modifications qui ont été opérées pendant l exécution normale du système SGBD sont rejouées et restituent les blocs tels qu ils auraient du être s il n y avait pas eu de panne. Cette opération est en général exécutée jusqu au dernier point de cohérence de la base de données. 49

50 «Rolling Back» Cette opération peut être demandée explicitement pour annuler une transaction active pendant le fonctionnement normal de l instance de base de données. Lors d une procédure de RECOVERY, la fonction de «Rollback» peut être effectuée pour annuler les transactions qui ne sont pas fermées après l exécution du «Rolling Forward». La transaction est marquée comme annulée (ROLLBACK) en effaçant le slot associé à la transaction dans l entête du «Rollback segment». Les entêtes des blocs de données concernés par cette transaction seront nettoyés en différé à la prochaine sollicitation. Cette opération est désignée par «Delayed Bloc Cleanout». 50

51 «Check Points» Les points de synchronisation consistent à écrire dans la base de données le contenu des BUFFERS du CACHE marqués comme étant modifiés. Ce sont les BUFFERS DIRTY. Les «check points» se déclenchent sur les évènements suivants : A la demande des processus qui exécutent les instructions SQL afin de libérer de la place dans le CACHE. Sur l instruction ALTER TABLESPACE BEGIN BACKUP Avant la mise hors circuit d un TABLESPACE. Au moment du SWITCH de REDOLOG. Dans les trois premiers cas la synchronisation du CACHE est partielle et n intervient qu au niveau de quelques fichiers, c est le DATAFILE CHECKPOINT. Dans le dernier cas, tous les tampons «dirty» sont synchronisés dans la base de données. Cela peut générer beaucoup d entrées/sorties à ce moment là. Le moteur Oracle maintient en mémoire la liste des blocs «dirty» selon un algorithme LRU (Least Recently Use moins récemment utilisé). Lorsqu un «check point» intervient, les blocs qui contiennent des modifications antérieures à un SCN donné, sont écrits dans l ordre de parcours de la «dirty list» du coté LRU vers le coté MRU (Most Recently Used plus récemment utilisé). Ce «Check point SCN» est ensuite écrit dans la «check point structure» qui se trouve dans l entête de chaque DATAFILE qui participe à l opération. Cette structure d information contient également l adresse des informations REDO : la RBA qui est associée au «Check point SCN». La RBA est composée de la «Log Sequence» (N de REDOLOG) et de l adresse de l information dans le fichier REDOLOG. Ces mêmes informations sont stockées dans le CONTROLFILE. Les données contenues dans la «check point structure» permettent au noyau Oracle d identifier si le contenu des fichiers DATAFILE est en phase chronologique avec l état courant de la base qui est maintenu dans le fichier de contrôle. 51

52 Si l on tente d ouvrir la base de données avec des DATAFILES dont les informations de «check point» sont en retard par rapport à celles contenues dans le CONTROLFILE, le noyau Oracle indiquera qu il faut appliquer un RECOVERY pour remettre les fichiers à jour vis à vis du reste de la base de données. Pendant l exécution du RECOVERY, les entêtes des DATAFILES sont mis à jour en correspondance avec l avancement du «Rolling Forward». «Fractured blocks» Si la base fonctionne en mode ARCHIVELOG, Oracle autorise les sauvegardes à chaud avec des outils tiers fournis par le système. Pendant ce type d opération, le processus DBWR continue d écrire dans les fichiers DATAFILES qui sont en cours de sauvegarde. Si la taille des blocs de la base de données est supérieure à ceux du système d exploitation, l outil de sauvegarde peut générer occasionnellement des blocs corrompus. La figure ci-dessus illustre le mécanisme qui produit des «fractured blocks». Pour résoudre ce problème, Oracle modifie son mode de fonctionnement pour permettre la sauvegarde des TABLESPACES en ligne. Ce mode est activé avec la commande ALTER TABLESPACE nom_tbs BEGIN BACKUP et est arrêté avec la commande : ALTER TABLESPACE nom_tbs END BACKUP. L outil «Recovery Manager» est capable de détecter tout seul les blocs corrompus. Dans ce cas, le mode «begin backup» n est pas nécessaire. 52

53 Fonctionnement du mode «begin backup» Lorsque la commande BEGIN BACKUP est exécutée plusieurs actions sont appliquées sur chaque DATAFILE associé au TABLESPACE en question : Un «check point» est appliqué afin de stocker le SCN de début de la sauvegarde dans la «check point structure» Des indicateurs son positionnés dans l entête du DATAFILE : le «hotbackup-fuzzy bit» qui indique l état de sauvegarde en ligne du fichier et le «online-fuzzy bit» qui est effacé le temps de l opération de sauvegarde. L entête des DATAFILES ainsi que l enregistrement (l entrée) correspondant à chacun d eux dans le CONTROLFILE sont figés pendant toute la durée du «backup». Cela a pour effet de conserver les informations de «check point» dans la copie de sauvegarde du DATAFILE. Le «block before image logging» est activé. Ce mécanisme copie dans le BUFFER REDOLOG l intégralité de chaque bloc associé au TABLESPACE qui est en mode BEGIN BACKUP lorsque celui-ci est sollicité par une opération de modification. Cette fonctionnalité permet de restaurer les «fractured block» potentiels pendant le RECOVERY après la restauration du DATAFILE de sauvegarde. Attention : le «block before image logging» entraîne une surcharge d activité en entrées/sorties et rempli rapidement les fichiers REDOLOGS. Il n est pas recommandé de mettre tous les TABLESPACES en mode BEGIN BACKUP simultanément. Ce type de sauvegarde en ligne n a d intérêt que si l on utilise des outils tiers fournis par le système d exploitation ou des logiciels de «backup» indépendants. En effet, l utilisation de «Recovery Manager» ne nécessite pas de mettre les TABLESPACES en mode BEGIN BACKUP. La commande END BACKUP remet le TABLESPACE dans son état initial. L entête est mis à jour en phase avec le dernier état cohérent, le «block before image logging» est désactivé. 53

54 54

55 Présentation de Recovery Manager «Recovery Manager» est la fonction de sauvegarde/restauration du noyau Oracle. Cet outil permet de gérer et d automatiser les procédures de sauvegarde et de restauration par un langage script qui lui est propre. Cela permet de réduire les risques d erreur comme, par exemple, la restauration de la mauvaise sauvegarde, l oubli de sauvegarder un TABLESPACE qui vient d être ajouter au système SGBD. RMAN facilite la mise en œuvre du mode ARCHIVELOG, il peut être également utilisé avec des instances qui fonctionnent en mode NOARCHIVELOG. RMAN collabore avec la plupart des logiciels de sauvegarde du marché comme Netbackup par une API (Application Program Interface) fournie par l éditeur du logiciel de sauvegarde. La liste des éditeurs de logiciel de sauvegardes compatibles avec RMAN est fournie sur (voir «Oracle Backup Solutions Program»). Les caractéristiques de Recovery Manager sont : La compression des sauvegardes des DATAFILES, ne prend pas les blocs inutilisés L exécution des sauvegardes incrémentielles en mode différentiel et/ou cumulatif pour optimiser les volumes et/ou les temps de sauvegarde. La génération de fichiers de sauvegarde des DATAFILES ou des ARCHIVELOGS sur bande magnétique : "Backup Sets" La copie (duplication) de DATAFILE sur d autres disques. La détection des corruptions dans la base pendant la sauvegarde L utilisation d un référentiel des sauvegardes dans une base Oracle appelé «Recovery Catalog» La sauvegarde au niveau des blocs de la base offre les avantages suivants : Seul les blocs qui ont été utilisés (cf "incarnation number") sont sauvegardés Un Mécanisme de détection dynamique des blocs incohérents ("split" ou "fractured blocks") permet de ne pas saturer les "REDOLOGS" pendant les «Backup ONLINE" car les ordres "BEGIN/END BACKUP" ne sont plus nécessaires. Les fichiers de sauvegarde «Backup set» ne sont pas des "DATAFILES" 55

56 Architecture de Recovery Manager A la différence des stratégies de sauvegardes que proposait Oracle dans les versions précédentes à la 8i, ce sont des processus Oracle (serveurs oracle «shadow» sous Unix) qui exécutent les sessions de sauvegardes/restaurations des fichiers DATAFILES et ARCHIVELOGS. Lorsque «Recovery Manager» est couplé avec un logiciel tiers de gestion de média pour le stockage des «backups» (comme Netbackup, Legato Networker, Tivoli, etc ) les processus Oracle des sessions de sauvegarde passent les blocs directement aux processus du logiciel tiers par l intermédiaire d une couche logicielle : MML («Media Management Layer»). La partie dans le cadre bleu de la figure ci-dessus ne peut être mise en œuvre qu avec un outil tiers. S il n y a pas de logiciel de sauvegarde, «Recovery Manager» est capable de produire les «Backupsets" sous forme de fichiers sur disques. Le «recovery catalog» est facultatif, il doit être installé dans une base Oracle de version identique ou supérieure de préférence. C est le référentiel des opérations de sauvegardes des bases cibles («Target Database»), il est indispensable pour des environnements de production à haute disponibilité de type «business» ou «mission critical». La session «Recovery Manager» peut être opérée en mode ligne (prompt RMAN>), en mode batch sous Unix lancé par un logiciel tiers comme Netbackup ou dans l environnement graphique (GUI) d Oracle Enterprise Manager (OEM ->Backup Manager). 56

57 Commandes Recovery Manager La gestion des opérations de sauvegarde et restauration s effectue avec un langage script de commandes propres à RMAN. Ces commandes sont interprétées et exécutées par les procédures des "packages" PL/ SQL du moteur Oracle. Il y a plusieurs types de commandes RMAN : Les commandes autonomes (Stand-Alone) qui servent principalement à l administration du catalogue. catalog, create catalog, drop catalog, upgrade catalog : administration du référentiel create script, delete script, replace script : gestion des scripts dans le catalogue. change, crosscheck, delete expired backup : synchronisation du catalogue avec le référentiel des sauvegardes de l outil tiers ou avec le système d exploitation. list, report : liste des composants des bases cibles, états et diagnostics des sauvegardes/ restaurations à opérer. Les commandes de travail (Job) qui exécutent les tâches de sauvegarde et de restauration. La majorité des ces ordres seront exécutés dans un bloc run délimité par des accolades : run { }. allocate channel : ouverture d un canal de sauvegarde/restauration. C est cette commande qui provoque l activation d un processus serveur Oracle. switch : effectue la commutation d emplacement de fichiers DATAFILES. backup, copy, duplicate : commandes de sauvegarde proprement dites. La commande copy est obsolète en 10g. restore, recover : commandes de restauration et de restitution des transactions. Les exceptions sont des commandes qui peuvent être appelées à l intérieur ou à l extérieur d un : exécution de script RMAN sous forme de fichiers host, send : appel d une commande du système d exploitation, envoi de directives au logiciel tiers. startup, shutdown : lancement et arrêt de la base cible dans la session RMAN. sql : envoi d ordres SQL spécifiques au sein d une session RMAN. 57

58 Session RMAN La session Recovery Manager est activée par la commande système rman. Si l on utilise une base "catalog", il y aura deux connexions simultanées : celle vers la base cible et celle vers la base catalogue. L une des deux connexion peut être directe sans utiliser SQL*Net : $ rman target sys/secret rcvcat rman/rman@refoem Remarque : REFOEM est un alias SQL*Net (chaîne de connexion réseau) et non un ORACLE_SID dans ce contexte. La connexion peut également s effectuer dans la session RMAN : RMAN> connect target 'sys/secret' ; RMAN> connect catalog 'rman/rman@refoem' ; Lorsque Recovery Manager collabore avec un outil tiers de sauvegarde comme Netbackup ou Tivoli, la session RMAN peut être activée en mode batch par un script shell avec l argument cmdfile : $ cat script_rman.ksh #!/bin/ksh rman cmdfile script_rman.rcv $ cat script_rman.rcv connect target 'sys/secret' ; connect catalog 'rman/rman@refoem' ; run { execute script sauvegarde_complete ; } 58

59 Composants de sauvegarde Recovery Manager produit trois types de fichiers de sauvegarde : "Backup Sets" de DATAFILES Ce sont des collections de blocs extraits des fichiers DATAFILES de la base cible. Ils peuvent contenir la sauvegarde complète du fichier de contrôle si la clause "include current controlfile" ou "current controlfile" de la commande "backup" a été ajoutée. La sauvegarde du fichier de contrôle se trouve alors au début du "Backup Set". La sauvegarde des blocs du Tablespace SYSTEM provoque automatiquement celle du fichier de contrôle dans le "Backup Set". Les "Backup Sets" de DATAFILES ne sont pas des fichiers de base directement utilisables par le moteur Oracle. Lorsqu ils sont restaurés, RMAN recrée le fichier DATAFILE vide puis y replace les blocs contenus dans le "Backup Set". "Backup Sets" d ARCHIVELOGS Ils regroupent un certain nombre de fichiers ARCHIVELOGS classés en ordre séquentiel croissant (les ARCHIVELOGS sont numérotés avec le numéro de séquence de REDOLOG). Les "Backup Sets" d ARCHIVELOGS ne peuvent pas contenir de blocs provenant de fichiers DATAFILES et vice versa. La restauration replace les fichiers ARCHIVELOG dans le répertoire pointé par le paramètre log_archive_dest. Les fichiers ARCHIVELOG peuvent être supprimés automatiquement de ce répertoire après la sauvegarde avec la clause "delete input" de l ordre "backup archivelog". "Images copies" Ce sont les copies intégrales des DATAFILES ou des ARCHIVELOGS sur d autres disques de la machine qui héberge la base cible. Les copies de fichiers DATAFILES sont très efficaces pour effectuer des restaurations rapides puisqu il n y a pas de fichier à restaurer depuis une bande magnétique. La commande " switch " de Recovery Manager permet de commuter instantanément sur la copie du fichier DATAFILE et il n y a plus que l opération de restitution (RECOVER) à réaliser pour pouvoir remettre le fichier en ligne. Cette opération sera d autant plus courte que la copie du fichier est récente. 59

60 Sauvegarde en ligne d un TABLESPACE Ce scénario suppose que le logiciel gestionnaire de bande magnétique fonctionne avec RMAN. La base fonctionne en mode ARCHIVELOG. Le script défini le type de périphérique par défaut qui sera utilisé pour les sauvegardes et passe les paramètres spécifiques au gestionnaire de média. Les périphériques de type disque sont également définis dans l exemple ci-dessous : configure default device type to sbt; configure channel device type sbt parms '<paramètres gestionnaire de média>'; # nombre de processus serveurs pour les canaux de type disque configure device type disk parallelism 2; configure channel device type disk format '/backup/ora_df%t_s%s_s %p'; configure controlfile autobackup format for device type disk to '/ backup/%f'; La sauvegarde en ligne utilise le canal par défaut de type bande magnétique. run { backup tablespace tbs1; } 60

61 Sauvegarde en ligne incrémentielle niveau 0 C est le début du cycle de sauvegardes. La fenêtre de rétention est définie sur un mois (30 jours). Vous pouvez utiliser la commande DELETE OBSOLETE pour supprimer les sauvegardes qui ont été marquées comme obsolètes par les opérations de sauvegarde. Important : Vous devez noter l identifiant affiché par la sortie de RMAN si vous ne comptez pas utiliser de CATALOG de récupération. Cet identifiant est nécessaire pour les procédures de restauration du fichier de contrôle et les «disaster recovery». configure retention policy to recovery window of 30 days; # Activation de la sauvegarde automatique du CONTROLFILE. configure controlfile autobackup on; # Activation des sauvegardes optimisées. configure backup optimization on; run { backup incremental level 0 database filesperset 4; backup archivelog all; delete archivelog until time 'sysdate-7'; } 61

62 Restauration en ligne d un TABLESPACE Ce type de restauration suppose que seuls les fichiers qui constituent le TABLESPACE sont endommagés. L opération s effectue base ouverte. La diapositive montre les instructions essentielles pour effectuer la restitution en ligne du TABLESPACE. Ci-dessous le script contient en commentaire des exemples de syntaxe ou la destination des fichiers restaurés est différente. run { sql 'alter tablespace tbs_1 offline'; } # si vous désirez restaurer les fichiers à un autre emplacement, # supprimez les caractères # de mise en commentaire. # set newname for datafile 5 to '/newdirectory/new_filename_for_5.f'; # set newname for datafile 6 to '/newdirectory/new_filename_for_6.f'; # set newname for datafile 7 to '/newdirectory/new_filename_for_7.f'; restore tablespace tbs_1; # switch datafile all; recover tablespace tbs_5; sql 'alter tablespace tbs_5 online'; 62

63 Restauration en ligne d un DATAFILE Ce scénario suppose que le DATAFILE numéro 5 est endommagé. Les autres fichiers sont intacts et l opération se déroule base ouverte. run { sql 'alter database datafile 5 offline'; # si vous désirez restaurer le fichier à un autre emplacement, # supprimez les caractères '#' de mise en commentaire. } # set newname for datafile 5 to '/newdirectory/new_filename.f'; restore datafile 5; # switch datafile all; recover datafile 5; sql 'alter database datafile 5 online'; 63

64 Restauration standard à froid Ce cas de figure suppose que ce sont les fichiers DATAFILE du TABLESPACE SYSTEM qui sont endommagés. Les autres fichiers sont intacts, la restauration se fait base fermée. $ rman target / catalog rman/rman@rcvcat RMAN> shutdown abort; RMAN> startup mount; run { restore database; recover database; alter database open; } 64

65 65

66 66

67 . 67

68 Caractéristiques des «Backup sets» Un "Backup Set" est constitué d un ou plusieurs fichiers physiques, chaque fichier correspond à une "Backup Piece". Si la taille de ces "Backup Piece" n est pas définie, le "Backup Set" sera constitué d une seule "Backup Piece". Vous pouvez limiter la taille des fichiers physiques qui constituent un "Backup Set" comme l illustre l exemple ci-dessous. Run { } allocate channel c1 device type sbt maxpiecesize 2G ; backup database ; La taille des "Backup Pieces" dépend donc de la taille des supports de sauvegarde utilisés. Il est également recommandé de ne pas définir de fichiers physiques trop grands afin de ne pas pénaliser les opérations de restauration en imposant des temps de rembobinage trop long. V1.0 68

69 Multiplexage Lorsque Oracle sauvegarde plusieurs DATAFILES dans un même "Backup Set", les blocs de chacun des fichiers sont rangés entrelacés. Ce multiplexage permet de maintenir un flux d écriture constant sur la bande magnétique pendant une sauvegarde car la répartition des blocs qui contiennent des données dans les DATAFILES n est pas linéaire. Lorsque le serveur Oracle de la session RMAN lit un DATAFILE, il peut parcourir un grand nombre de blocs vides contigus avant d envoyer des données vers la bande magnétique. Si plusieurs fichiers DATAFILES sont lus simultanément, le nombre de blocs lus contenant des données sera plus important dans un intervalle de temps court et le flux de sauvegarde sera plus conséquent. A l inverse, le temps de restauration d un seul DATAFILE sera proportionnel au nombre de fichiers contenus dans le "Backup Set". C est le paramètre filesperset qui permet de limiter le nombre de DATAFILES contenus dans un "Backup Set". La syntaxe des commandes RMAN est différente d une version à l autre. L option «set limit channel» n est plus utilisée en Oracle 10g. Exemple de multiplexage en 10g : RMAN> backup incremental level 0 database filesperset 4; Remarque : en Oracle 10g l optimisation du multiplexage est géré automatiquement si le paramètre «filesperset» n est pas renseigné. Exemple de multiplexage en version 8i : Run { } allocate channel c1 type disk ; set limit channel c1 kbytes = ; backup filesperset = 10 (database) ; 69

70 Parallélisme des sauvegardes Si l on souhaite créer plusieurs «Backup Set» et allouer plusieurs canaux de sauvegarde, RMAN effectue automatiquement la sauvegarde en parallèle et écrit sur plusieurs bandes magnétiques simultanément pour répartir la charge de travail. Chaque «Backup Set» est pris en charge par un seul canal de sauvegarde, il n est pas possible de partager une même «Backup Piece» par plusieurs canaux. Exemple : RMAN> configure default device type to disk; RMAN> configure device type disk parallelism 3; RMAN> backup incremental level 0 database fileperset 4; 70

71 Exécution des sauvegardes en ligne avec RMAN «Recovery Manager» détecte automatiquement les blocs fracturés. Lorsque RMAN exécute une sauvegarde en ligne, le processus DBWR peut modifier un bloc pendant la lecture de celui-ci. Le bloc est alors cassé, cependant, chaque bloc contient une information de contrôle d intégrité (Checksum) dans l entête et dans le pied. Quand le bloc a été lut intégralement, l information du pied est comparée avec celle de l entête. Si elles diverges, RMAN considère que le bloc est fracturé et refait une lecture de celui-ci. Puisque RMAN est capable de détecter les «fractured blocks» pendant la sauvegarde, il n est pas nécessaire de mettre les TABLESPACES en mode BEGIN BACKUP (c est même une erreur de le faire) pendant un «backup» à chaud. Cela a pour bénéfice de ne pas surcharger l instance et de ne pas remplir les fichiers REDOLOGS trop rapidement. 71

72 Interface avec le logiciel tiers L interface entre le logiciel tiers qui pilote les sauvegardes sur bande magnétique et Recovery Manager se fait via l API Media Management. Elle est fournie par l éditeur du logiciel tiers sous la forme d une "Library" dynamique partagée : libobk.so (.sl,.a en fonction de la plate-forme) Par défaut, le noyau Oracle est lié à la bibliothèque du logiciel LEGATO de Networker. Pour remplacer la "Library" MML libobk.so de LEGATO par celle de Netbackup procéder comme suit : Etablir un lien symbolique Unix avec le fichier libobk.so de Netbackup dans le répertoire $ORACLE_HOME/lib : 1. préserver l ancien lien symbolique : $ cd $ORACLE_HOME/lib $ mv libobk.so libobk.old 2. créer le lien avec Netbackup : $ ln -s /distrib/veritas/netbackup/bin/libobk.so libobk.so 3. vérifier la liaison avec l exécutable Oracle et libobk.so (Solaris) : $ cd $ORACLE_HOME/bin $ ldd oracle grep libobk.so En 10g, vous pouvez également passer le lien vers la «library» en paramètres avec l option PARMS Sur la commande ALLOCATE CHANEL ou CONFIGURE CHANEL : RMAN> configure chanel c1 device type sbt 2> PARMS='SBT_LIBRARY=/mediavendor/lib/libobk.so 3> ENV=(NSR_SERVER=tape_ srv,nsr_group=oracle_tapes)'; 72

73 Les procédures de sauvegarde RMAN avec Netbackup sont construites sur un modèle unique : Un script Korn shell (suffixe.ksh) et deux scripts RMAN (suffixe.rcv). Le nom de chaque script contient celui de la base correspondante à la procédure de sauvegarde. Par exemple : hot_database_backup_vertst.ksh pour la base VERTST. Le nom des scripts Recovery Manager indique le type et le niveau de sauvegarde incrémentielle : 0 ou 1 C est Netbackup qui est l initiateur des sauvegardes. Le script Korn shell appelle l un ou l autre script RMAN en fonction des arguments passés par le logiciel Netbackup. Oracle prend les opérations de sauvegarde en charge lorsque la session RMAN est établie. Quand la sauvegarde est terminée, RMAN repasse le contrôle des opérations au script Korn shell de Netbackup. 73

74 L interface RMAN avec Tivoli se fait également par le biais d une bibliothèque : libobk.a dans l environnement IBM AIX. Le lien s effectue de manière similaire à Veritas Netbackup : $ cd $ORACLE_HOME/lib $ mv libobk.a libobk.old $ ln s /usr/lib/libobk.a libobk.a Le fonctionnement avec Tivoli nécessite un passage de paramètres sur la commande «allocate chanel» comme le montre la diapositive ci-dessus. Les paramètres d environnement principaux sont : DSMO_NODE : indique le nom du nœud pour TDP (Tivoli Data Protection). C est normalement le nom retourné par la commande UNIX hostname. DSMO_AVG_SIZE : C est la taille moyenne d un objet à sauvegarder exprimée en MB. Cette information est utilisée par TSM pour déterminer le type de périphérique et d espace de stockage. La taille par défaut est de 50MB. DSMI_ORC_CONFIG : pointe sur le fichier de configuration du client TSM. DSMI_LOG : pointe sur le répertoire de destination du fichier d erreurs dsierror.log de l API TSM. DSMO_FS : nom de l espace fichier utilisé par TSM serveur. Plusieurs noms d espace fichier peuvent être utilisés pour indiquer différentes classes de gestion. DSMO_OWNER : nom de l utilisateur UNIX qui exécute la session TSM. C est normalement celui qui est retourné par la commande UNIX id. DSMO_DEBUG=49 : quand cette variable est définie, un fichier trace orcagent.log est créé dans le répertoire $ORACLE_HOME/dbs. 74

75 Sauvegarde différentielle La sauvegarde incrémentielle lit intégralement le fichier DATAFILE et envoi dans le «Backup Set» seulement les blocs qui ont été modifiés depuis la sauvegarde précédente. Chaque bloc dans un DATAFILE contient un SCN (System Change Number) qui évolue à chaque modification. Pendant une sauvegarde incrémentielle, Oracle compare le SCN de chacun des blocs avec le SCN du point de synchronisation (début du «Backup») de la sauvegarde précédente. En 10g Il y a deux niveaux de sauvegarde incrémentielle : 0, 1. Le niveau 0 correspond à la sauvegarde en mode incrémentiel de tous les blocs de la base qui contiennent des données. Le niveau 1 exécute la sauvegarde incrémentielle par rapport à la sauvegarde de niveau 0 précédente. Les blocs qui contiennent des données sont identifiés par un numéro d incarnation (incarnation number) qui est attribué chaque fois que le bloc est alloué par un objet de la base (par exemple une table). Si l objet est détruit, le bloc est libéré et pourra être ré-alloué par un autre objet ultérieurement. «Recovery Manager» permet d exécuter deux types de sauvegarde incrémentielle : les différentielles et les cumulatives : Une sauvegarde incrémentielle différentielle de niveau 1 prend tous les blocs qui ont été modifiés depuis la dernière sauvegarde de niveau 0 ou de niveau 1. Run { } allocate channel t1 device type sbt ; backup incremental level 0 filesperset = 10 (database) ; 75

76 Sauvegardes cumulatives Ce type de sauvegarde permet de réduire les volumes à copier sur les bandes magnétiques. Par contre, les temps de restauration sont plus longs car ils peuvent nécessiter plusieurs bandes de sauvegarde intermédiaires en plus de la dernière sauvegarde de niveau 0. Une sauvegarde incrémentielle cumulative de niveau 1 prend tous les blocs qui ont été modifiés depuis la dernière sauvegarde de niveau 0. Ce type de sauvegarde introduit une redondance des blocs sauvegardés tous en réduisant les volumes à copier sur les bandes magnétiques. Les temps de restauration sont plus courts que pour les sauvegardes différentielles car il n y a que deux sauvegardes à rétablir : la dernière de niveau 0 et la dernière cumulative. Run { } allocate channel t1 device type sbt ; backup incremental level 1 cumulative filesperset = 10 (database) ; Si l on ne désire pas utiliser le mode de sauvegarde incrémentielle on peut effectuer des "backup" complets sans l option «incremental». Une telle sauvegarde ne peut pas participer à une stratégie de sauvegarde incrémentielle. 76

77 Caractéristiques du référentiel RMAN L utilisation d un référentiel «Recovery Manager» pour administrer les opérations de sauvegarde et de restauration est un plus qui permet d accroître considérablement la fiabilité du système. S il y a plusieurs bases de données sur le réseau, le CATALOG permet de centraliser les opérations de gestion des sauvegardes/restaurations et de standardiser les stratégies de «backup». Les informations de gestion des opérations RMAN sont stockées nativement dans le CONTROLFILE de la base cible. En cas de perte de celui-ci, la procédure de reconstruction est beaucoup plus délicate. Si l on utilise un CATALOG RMAN, le contenu du fichier de contrôle est automatiquement répliqué dans le référentiel. Si l on perd le CONTROLFILE, la restauration est effectuée à partir des informations du CATALOG ce qui simplifie les procédures de restauration et de restitution de la base de données. Les informations qui sont gérées dans le référentiel RMAN sont : l historique des sauvegardes qui ont été effectuées sur les bases cibles la liste des fichiers qui constituent chaque base de données la liste des fichiers des «backup sets» et des «images copies» les informations d horodatage qui sont stockées dans chaque CONTROLFILE Installation Le CATALOG doit être installé dans un schéma d une base de données Oracle séparée. Cette base doit être installée de préférence sur une machine différente des machines qui hébergent les bases cibles. La version de la base CATALOG doit être de niveau le plus à jour par rapport à la version la plus élevée des bases cibles. Par exemple, s il y a des versions 9i et 10g à gérer sur votre réseau, la version de la base du référentiel RMAN doit être 10g. Par défaut, chaque base Oracle est préconfigurée avec un schéma utilisateur RMAN. Ce «user» peut être utilisé pour héberger le CATALOG. Si le nom RMAN ne vous convient pas vous pouvez créer un autre utilisateur. Vous devez lui affecter les rôles CONNECT et RECOVERY_CATALOG_OWNER. La procédure de création s effectue en ouvrant une session RMAN sur ce compte utilisateur et en exécutant la commande CREATE CATALOG comme le montre la diapositive ci-dessus. 77

78 Inscription d une base cible Cette opération s effectue en ouvrant une session RMAN sur la base CATALOG et la base TARGET simultanément. Exécutez la commande REGISTER DATABASE pour inscrire la base cible dans le CATALOG. Vous pouvez lister les base inscrites dans le référentiel en entrant la commande suivante : RMAN> list incarnation of database; CONTROLFILE AUTOBACKUP Pour restaurer une base dans des circonstances où l on a perdus tous les fichiers y compris le fichier de contrôle il faut procéder en deux temps : 1. Restaurer un CONTROLFILE de sauvegarde 2. Restaurer et reconstituer les autres éléments à partir du CATALOG du fichier de contrôle que l on vient de récupérer. La fonction de sauvegarde automatique du CONTROLFILE permet de simplifier la procédure car l on peut disposer d un fichier de contrôle de «backup» récent, stocké dans un endroit connu sur un disque du système qui héberge la base endommagée. Cette fonction s active avec la commande : CONFIGURE CONTROLFILE AUTOBACKUP ON. La désactivation s effectue avec la commande CONFIGURE CONTROLFILE AUTOBACKUP OFF. Par défaut, cette fonction n est pas active. Le format de destination est défini avec la commande CONFIGURE CONTROLFILE AUTOBACKUP FORMAT. La chaîne de caractère du format du fichier de sauvegarde doit obligatoirement inclure le code générateur %F. Ce code permet à Oracle de retrouver automatiquement le fichier de sauvegarde lors de la restitution avec la commande : RESTAURE CONTROLFILE FROM AUTOBACKUP. 78

79 Lorsque la sauvegarde automatique du CONTROLFILE est exécutée, le fichier de paramètres SPFILE est également inclus dans le «backup set» généré. Ce type de «backup» est effectué dans les circonstances suivantes : - Après toute opération de sauvegarde exécutée par la commande BACKUP de «Recovery Manager» - Lorsque les structures physiques de la base sont modifiées. Politique de conservation des sauvegardes La commande configure retention policy permet de définir la stratégie de conservation des fichiers de sauvegarde selon deux modes : soit en suivant une fenêtre de reconstruction chronologique - par exemple garder les fichiers de backup pendant au moins une semaine. soit en indiquant le nombre d exemplaires de sauvegarde d un même élément exemple : conserver les 3 sauvegardes les plus récentes de chaque fichier. Ces deux modes sont mutuellement exclusifs. Les éléments qui ne satisfont plus à la clause de rétention sont marqués comme obsolètes. Ils peuvent être alors supprimés avec la commande RMAN : delete obsolete. Pour rechercher les sauvegardes obsolètes vous pouvez utiliser la commande RMAN : report obsolete. Pour annuler la politique de rétention utiliser la commande : RMAN> configure retention policy to none; 79

80 Exemple d utilisation de la fenêtre de rétention chronologique Dans l exemple de la diapositive ci-dessus, la fréquence des sauvegardes est de 15 jours. La politique de rétention est définie sur une fenêtre de une semaine. Dans cette perspective, seuls les éléments inutiles pour reconstruire la base jusqu à un point spécifique antérieur à 7 jours du dernier point de mise à jour (date et heure courante) seront marqués obsolètes. Dans l exemple ci-dessus, il s agit de tous les ARCHIVELOGS générés avant le 14 janvier. Les éléments générés entre le 14 janvier et le point de reconstruction du 23 janvier seront conservés tant que le point de reconstruction n aura pas atteint la sauvegarde du 28 janvier. 80

81 Consultation des opérations RMAN Les commandes RMAN LIST et REPORT affichent des états sur l activité de sauvegarde basés sur le contenu du référentiel. La commande SHOW permet d afficher la configuration définie avec la commande RMAN CONFIGURE (voir les paragraphes suivants). Les exemples de la diapositive cidessus donnent un aperçu des différentes utilisations les plus communes. Commande LIST : «list backup» - affiche la liste des sauvegardes connues dans le référentiel. «list copy of datafile» - liste des copies d images seulement pour les DATAFILES indiqués. «list backup of archivelog from sequence» - affiche la liste des sauvegardes d ARCHIVELOGS à partir d une LOG SEQUENCE spécifique. Commande REPORT : «report need backup database» - affiche la liste des fichiers qui doivent être sauvegardé en fonction de la stratégie de rétention qui a été définie. «report obsolete» - liste des sauvegardes qui sont périmées par rapport à la stratégie de rétention qui a été définie. «report unrecoverable» - détermine quelle sont les sauvegardes qui ne peuvent être reconstruites avec la commande RECOVER, les fichiers ARCHIVELOGS étant manquants. «report schema» - affiche la liste des fichiers qui constituent la base cible en cours. 81

82 Expiration manuelle des sauvegardes La liste des sauvegardes qui ont été répertoriées dans le CATALOG RMAN peut être déphasée par rapport à la réalité si ces sauvegardes ont été manuellement supprimées sur le disque qui contient les «backup sets». Les sauvegardes peuvent également être supprimées avec le logiciel qui gère les bandes magnétiques. La commande CROSSCHECK de RMAN permet d effectuer facilement la vérification et de détecter le déphasage entre les fichiers de sauvegarde existants et leurs références dans le CATALOG (le CATALOG peut être celui du CONTROLFILE de la base cible). CROSSCHECK s applique également pour les «images copies». Les éléments inexistants sont marqués comme expirés dans le CATALOG de sauvegarde RMAN. Remarque : Les références des sauvegardes ne sont jamais détruites automatiquement. Pour mettre à jour le CATALOG vous pouvez utiliser la commande RMAN DELETE. La diapositive ci-dessus vous montre le mode opératoire. Suppression des sauvegardes périmées La commande DELETE peut également remettre le CATALOG à jour en détruisant les références des sauvegardes marquées «obsoletes». Si les fichiers de sauvegarde sont encore présents ils peuvent être supprimés en indiquant l option FORCE sur la commande DELETE : RMAN> delete force obsolete backup; 82

83 Sauvegardes optimisées «backup optimization» est une fonction qui évite de générer des copies de DATAFILE lorsque les fichiers n ont pas évolué depuis la dernière sauvegarde. Quand la fonction est active, l opération de «backup» saute les fichiers qui sont identiques à la sauvegarde précédente. Par exemple, les DATAFILES qui constituent les TABLESPACES en mode lecture seule ou hors circuit (OFFLINE) ne sont pris que s ils n ont pas encore été sauvegardés. Les DATAFILES des autres TABLESPACES permanents peuvent également ne pas être pris dans la sauvegarde s ils n ont pas évolués depuis le point de sauvegarde précédent. La stratégie de rétention peut avoir une influence avec l option des sauvegardes optimisées. Si la sauvegarde précédente d un fichier sort de la fenêtre chronologique de rétention ou ne correspond plus à la redondance spécifiée, une nouvelle sauvegarde est effectuée même lorsque la fonctionnalité «backup optimization» est active. Mise en oeuvre Cette fonctionnalité ne fonctionne qu avec les commandes RMAN suivantes : backup database backup archivelog avec les clauses all ou like backup backupset all Activation : RMAN> configure backup optimisation on; Désactivation : RMAN> configure backup optimisation off; 83

84 «restartables backups» La commande «BACKUP DATABASE NOT BACKUP SINCE TIME» permet de relancer la sauvegarde seulement pour les éléments qui n ont pas été pris en compte lors de l opération précédente. L unité de reprise est au niveau du «backup set». Par exemple, si la sauvegarde constituée de deux «backup sets» échoue pendant la génération du deuxième ensemble de sauvegarde, l exécution suivante avec l option «not backup since» ne sauvegardera que les fichiers qui n ont pas été copiés lors de l opération précédente. Vous pouvez utiliser l option MAXSETSIZE conjointement avec cette fonction afin de pas avoir à tout re-sauvegarder en cas d erreur sur une opération de «backup». Exemple : RMAN> backup database maxsetsize=500m ; Erreur d exécution RMAN> backup database not backup ; Sans l option «since time», RMAN sauvegarde seulement les fichiers qui n ont pas été sauvegardés. Gestion des plages d exécution des sauvegardes La commande RMAN «backup duration 4:00» permet de définir un intervalle d exécution de la sauvegarde de 4 heures. Si le temps est dépassé, la sauvegarde s arrête et un message d erreur est généré. Cependant, les «backup sets» qui ont été générés avant l erreur sont conservés et peuvent être utilisés pour restaurer la base en cas de panne. Lorsque la sauvegarde est relancée avec l option DURATION, les fichiers qui ont été sauvegardés le moins récemment sont pris en premier. Si vous ne voulez pas que RMAN retourne de message d erreur, utilisez l option PARTIAL, le message retourné vous indique alors la liste des fichiers qui n ont pas pu être sauvegardés. Avec l option DURATION, vous pouvez également spécifier si l exécution dans la plage impartie doit se faire le plus rapidement possible ou à l inverse s effectuer en minimisant l impact sur les performances de l instance Oracle. Exemples : RMAN> backup duration 4:00 partial minimize time database ; RMAN> backup duration 4:00 partial minimize load database ; 84

85 Gestion des erreurs d exécution des sauvegardes RMAN «Recovery Manager» détecte et gère deux types d erreur pendant l exécution d une sauvegarde : Les erreurs d entrées/sortie en lecture sur les fichiers DATAFILE ou en écriture sur les «backup pieces» ou les «images copies». L exécution du «backup» est normalement stoppée, sauf si plusieurs canaux ont été définis ou si des copies de sauvegarde redondantes ont été créées. Les corruptions de blocks elles sont de deux types : les corruptions physiques ou logiques. Les blocs corrompus nouvellement détectés sont enregistrés dans le fichiers de contrôle et dans le fichiers des alertes. La sauvegarde en cours est interrompue. Si l option MAXCORRUPT est spécifiée sur la commande de sauvegarde, l exécution se poursuit tant que le nombre de blocs en erreur nouvellement détecté est inférieur à la valeur spécifiée sur cette option. Les corruptions logiques sont détectées si le paramètre LOGICAL est ajouté à la commande de sauvegarde (voir l exemple ci-dessus). La vue V $DATABASE_BLOCK_CORRUPTION vous permet de consulter les informations sur les blocs en erreurs. 85