1) Introduction

Dans le cadre de la priorisation des exécutions de processus Oracle, DRM va nous donner la possibilité de définir des Plans d’exécution de Resources (”Resource Plan” ou “RP”).  Un RP est un élément logique permettant de définir un périmètre en matière de priorisation des taches en cours au sein d’une instance. Les limites et la nature de ce périmètre (CPU, nombre de sessions max, …) seront définis dans un second temps.

Un RP est donc une manière de répartir la consommation des ressources d’une instance Oracle selon les exigences de la production. Il conviendra, en fonction des fenêtres de votre activité, de construire plusieurs RP de production, par exemple, si un serveur d’application a une activité très faible la nuit, on donnera une importance assez grande aux batchs, alors qu’en plein jour, on la minimisera pour que les requêtes OLTP aient une puissance maximale.

2) Création d’un plan de ressources et des groupes de consommateurs :

2.1 - Création du Plan de Resource (”RP”):

Il faut détenir le grant SYSDBA pour pouvoir créer un RP, et l’instruction est la suivante:

SQL > dbms_resource_manager.create_plan(
      plan => 'PROD_JOUR'
      ,comment => 'Ceci est un plan de test');

Cette instruction a pour effet de créer un plan de ressource nommé ‘PROD_JOUR’, nous verrons en effet plus loin qu’il sera utile de définir, comme indiqué dans l’introduction, divers RP pour les différentes heures de la journée et correspondant aux exigences de votre Direction commerciale.

2.2 - Création des Groupes de consommateurs (”Consumer Group” ou “CG”):

Maintenant que le RP est créé, nous allons créer des groupes de consommateurs qui seront notamment associés à des notions de priorisations (valeurs limites, poids, …) qui définieront notre périmètre de consommation de ressources.

Un GP se crée avec l’instruction SYSDBA suivante:

dbms_resource_manager.create_consumer_group(
     consumer_group => 'OLTP'
     ,comment        => 'Comptes de prod pour
                         le serveur d'applis'
     ,cpu_mth => 'ROUND-ROBIN'
);

Dans cet exemple, nous créons un groupe de consommateurs nommé “OLTP’ dont les priorisations de ses utilisateurs seront fonction de la puissance CPU et dont la méthode de répartition de charge choisie sera du RoundRobbin.

Typiquement, le(s) user(s) utilisés par le serveur d’applications seront ensuite affectés à ce groupe.

Nous créons ensuite le deuxième CG pour les users de type batch :

dbms_resource_manager.create_consumer_group(
     consumer_group => 'BATCH'
     ,comment        => 'Comptes de prod pour
                         les batchs'
     ,cpu_mth => 'ROUND-ROBIN'
);

En dehors de la priorisation de la CPU, DRM permet de définir d’autres points de mesure (nombre de sessions max, etc), mais cela ne fait pas l’objet de ce billet, cf doc Oracle pour cela.

2.3 - Affectation des users Oracle aux groupes de consommateurs :

Une fois ces groupes définis, nous allons indiquer à l’instance quels sont les users qui les composent. Dans notre exemple, nous utiliseront deux users Oracle, le premier qui sert à notre serveur d’application à accèder à la database par l’intermédiaire d’un pilote JDBC, c’est le user “SERVEUR_APPLI”. Le deuxième, un user qui déclenchera les scripts SQL ou les blocs PLSQL de purge ou de traitement quelconque, c’est le user “TRAITEMENTS”.

dbms_resource_manager_privs.grant_switch_consumer_group(
    grantee_name=>'SERVEUR_APPLI'
    ,consumer_group=>'OLTP'
    ,grant_option=>false);
dbms_resource_manager_privs.grant_switch_consumer_group(
    grantee_name=>'TRAITEMENTS'    
    ,consumer_group=>'BATCH'
    ,grant_option=>false);

dbms_resource_manager.set_initial_consumer_group(
    user=>'SERVEUR_APPLI'
    ,consumer_group=>'OLTP');
dbms_resource_manager.set_initial_consumer_group(
   user=>'TRAITEMENTS'    
   , consumer_group=>'BATCH');

La fonction grant_switch_consumer_group du package dbms_resource_manager_privs permet de définir l’appartenance d’un user Oracle à un CG alors que la fonction set_initial_consumer_group du package dbms_resource_manager permet de définir le groupe de “départ” de chaque user.

En effet, nous verrons plus loin que nous pouvons définir des “politiques de glissement” d’un CG à un autre CG en fonction de différents êvènements, il faut donc bien préciser quel est le groupe de “départ” et l’autorisation d’un groupe à glisser (switch) dans un autre CG que son CG de départ.

Par exemple, si un package met trop de temps à s’exécuter, on peut le switcher automatique vers un CG qui a une priorisation CPU moins importante, etc.

3) Créations des directives de consommation

Une fois le RP créé, que les CG ont été définis, il faut définir, pour tous les groupes nommés dans les GC, des directives comportementales. Dans notre exemple basé sur la priorisation de la CPU, nous parlerons alors de directives en terme de droit à consommer de la CPU (80% pour le groupe OLTP, 10% pour le batch, …)  et de poids (Les transactions OLTP doivent prendre toute la CPU si elles le réclament, dans la négative les batchs peuvent consommer de la CPU , les users passent en troisème, etc ..)

3.1 - Introduction aux poids de consommation :

Le poid dans DRM est une notion de “priorité” en matière de répartition des ressources. Dans le cadre de la consommation CPU, nous allons définir plusieurs poids, sachant que les groupes bénéficiant des poids les plus faibles seront servis les premiers en matière de puissance CPU.

On peu définir, pour chaque poids, une politique de consommation maximale de la CPU (en %) répartie sur l’ensemble des groupes de consommateurs créés en 2.2.

Exemple:

             OLTP           BATCH          OTHER_GROUPS
poids 1      100%           0%             0%
poids 2      0%             80%            20%
poids 3      0%             0%             100%

Dans cet exemple, seul le groupe OLTP peut prendre toute la CPU s’il en a besoin, car il est le seul à bénéficier du poids 1 (le plus faible).

Si les users du CG OLTP n’ont pas besoin de la totalité de la CPU, alors Oracle va donner de la puissance aux users présents dans les groupes définis dans le poids 2, à savoir 80% de la puissance restante pour le batch (purges, stats, …) et 20% pour les autres utilisateurs qui ne sont définis dans aucun CG.

Si aucunne activité OLTP n’est requise et que aucun batch ne tourne, alors les autres utilisateurs peuvent exploiter la totalité de la CPU.

Remarque 1: Notez l’apparition dans notre exemple du groupe “OTHER_GROUPS”, vous n’avez pas à le définir, il est implicite et contient tous les users Oracle que vous n’aurez pas affecté à des CG.

Remarque 2: Un deuxième groupe implicite existe et fait par défaut partie du poids 1 : “SYSTEM_GROUP”, ce sont les SYSDBA, en effet, quoi qu’il se passe, il faut qu’un SYSDBA puisse à tout instant se connecter à une instance pour des opérations de maintenance.

3.2 - Définition des directives de poids :

Il s’agit simplement d’utiliser  dbms_resource_manager.create_plan_directive pour traduire le tableau précédent tel que:

dbms_resource_manager.create_plan_directive(
          plan              => 'PRODUCTION_PLAN'
          ,group_or_subplan => 'OLTP'
          ,comment          => 'Défintion des valeurs
                                CPU pour la prod / OLTP'
          ,cpu_p1           => 100
          ,cpu_p2           => 0
          ,cpu_p3           => 0
);
dbms_resource_manager.create_plan_directive(
          plan              => 'PRODUCTION_PLAN'
          ,group_or_subplan => 'BATCH'
          ,comment          => 'Défintion des valeurs
                                CPU pour la prod / BATCH'
          ,cpu_p1           => 0
          ,cpu_p2           => 80
          ,cpu_p3           => 0
);
dbms_resource_manager.create_plan_directive(
          plan              => 'PRODUCTION_PLAN'
          ,group_or_subplan => 'OTHER_GROUPS'
          ,comment          => 'Défintion des valeurs
                                CPU pour la prod / OTHERS'
          ,cpu_p1           => 0
          ,cpu_p2           => 20
          ,cpu_p3           => 100

);

Notez que la totalité des puissances CPU, pour chaque poids, doit faire exactement 100%.

4) La “Pending Area” :

Il serait très délicat de modifier le périmètre d’un Plan d’exécution alors que celui-ci est pris en compte par votre instance à un instant t. Pour cela, nous disposons de la “Pending Area”, qui est une aire de temporaire et intermédiaire de stockage des définitions concernant les objets des RP qui ne sera pris en compte au final que après validation et dont on peut effacer le contenu à tout instant.

Toutes les blocs d’instructions précédentes doivent être précédés de ces odres :

    dbms_resource_manager.clear_pending_area;
    dbms_resource_manager.create_pending_area;

    ... <opérations sur les RP> ...

    dbms_resource_manager.validate_pending_area;
    dbms_resource_manager.submit_pending_area;

Ceci assure la stabilité de votre instance pendant la modification des RP.

5) Prise en compte d’un plan d’exécution:

Une fois le RP créé et son périmètre défini, il faut indiquer à votre instance qu’elle doit le prendre en compte, vous utiliserez alors l’instruction suivante :

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN='PRODUCTION_PLAN';

Pour annuler toute prise en compte de plan d’exécution en cas de problème, il suffit de passer l’ordre

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN='';

N’hésitez pas à consuler le plan en cours d’exécution avec

SHOW PARAMETER RESOURCE_MANAGER_PLAN;

6) monitoring :

La vue v$rsrc_consumer_group vous permet de consulter, en quasi temps réel, la répartition des différents utilisateurs des différents CG en fonction de vos directives de consommations.

select name
,active_sessions
,execution_waiters
,requests
,cpu_wait_time
,cpu_waits
,consumed_cpu_time
,yields
,queue_length
,current_undo_consumption
from v$rsrc_consumer_group;

1 - Introduction / Rappels :

Les avantages d’une vue matérialisée sont globalement dans la rapidité d’accès aux données, en effet, si les tables dont sont issues les requêtes SQL induisant les vues matérialisées sont complexes, le fait d’y accéder par l’intermédiaire d’une vue matérialisée en rendra l’accès extrêmement plus rapide puisque celle-ci sont en fait recopiées physiquement dans la table de la dite vue et de nécessite plus l’interprétation d’un plan d’exécution complexe pour les récupérer.

Les vues matérialisées sont globalement utilisées pour accélérer l’accès à des données dont le quotient de mise à jour demeure faible. En effet, si les données d’une MV sont matérialisées dans une table, il peut exister à un instant <T> un décalage entre les données réellement présentes dans les tables pointées par la requête SQL et les données physiquement recopiées, une mise à jour de ces données physique est alors nécessaire pour se rapprocher des données réelles.

Dans ce contexte, nous verrons qu’il existe plusieurs méthodes pour mettre à jour une vue matérialisées, plus ou moins adaptées à l’utilisation que les utilisateurs en font et permettant aussi de faire au sens d’Oracle de la réplication de données entre hôtes distants.

2 - Création/Suppression d’une Vue Matérialisée :

La création d’une vue matérialisée se fait par l’instruction :

create materialized view <nom_vue_materialisée> as <requête_SQL>
                    [ refresh <mode> [ <type> ] [ with <cycle> ]
                      [ FORCE | FAST ] ]

Exemple:

SQL> create materialized view mv_personnes

2 as select c.nom, c.prenom, v.nomville from clients c,
ville v where c.id_ville=v.id_ville;

SQL> select * from mv_personnes;

NOM      PRENOM      NOMVILLE

------   -------     -------------------------------
NOM_1    PRENOM_1    ANGOULEME
NOM_2    PRENOM_2    BASTIA

Une vue matérialisée se détruit par un drop au sens classique du terme :

SQL> drop materialized view mv_personnes;

Note: Les vues systèmes USER_MVIEWS et DBA_MVIEWS permettent aux utilisateurs et aux DBAs d’obtenir toutes les informations sur les vues matérialisées auxquels ils ont accès. Le champ “query” permet notament d’indentifier la requête SQL induisant la vue matérialisée et “mview_name” le nom de la table physique créée pour matérialiser les données de cette requête.

3 - Modes de rafraichissement des vues matérialisées :

Comme nous l’avons évoqué précédement, la pertinence d’une vue matérialisée est caractérisée par la fréquence de mise à jour (ou de synchronisation) de ses données par rapport aux données des tables mères sur laquelle porte la requête SQL qui l’induit. En clair : quelle est la méthode et la fréquence de rafraichissement des données matérialisées de la vue par rapport aux données réélles existant dans les tables pointées par la requête SQL de la vue matérialisée?

3.1) Rafraichissement synchrone sur validation

Le mode de rafraichissement sur validation des vues matérialisation est celui qui vous permet d’assurer une équivalence parfaite entre les données matérialisées et celles dynamiques issues de la requête SQL caractéristique. Chaque validation transactionelle (commit) aura pour effet de rafraichir les données de la MV, une donnée validée dans une table mère impliquera au préalable une donnée inscrite dans la table de la MV.

L’équivalence des données de la MV est donc assurée de manière synchrone par rapport aux données situées dans les tables pointées par la requête SQL caractérisant la vue.

C’est la plus éfficace des mises à jour en terme fonctionel, c’est la moins efficace en CPU et consomation mémoire. Une telle façon de fonctionner est éfficace si la MV se fait sur la même database contenant les tables mères pointées par la requête SQL. Si la MV est distante, des problèmes de performance apparaissent très vite et cette méthode est déconseillée.

En clair, cette méthode vous permet d’améliorer des requêtes lourdes sur une instance de base de données.

Syntaxe :

 create ... refresh on commit;

3.2) Rafraichissement asynchrone sur demande

Une MV en mode de rafraichissement sur demande, comme son nom l’indique, possède des données matérialisées qui sont mises à jour de façon evènementielle sur demande (administrative, par automatisme PLSQL, …). La méthode de rafraichissement est donnée par le package DBMS_REFRESH et la procédure REFRESH(’<nom_MV>’),

Syntaxe :

 create materialized view MV1 ...;
 ...
 execute DBMS_REFRESH.REFRESH('MV1');

Note: Dans le cadre d’une réplication de tables, le package DBMS_REFRESH possède la méthode REFRESH_ALL_MVIEWS qui permet de rafraichir toutes les MV sans les nommer une à une.

3.3) Rafraichissement asynchrone différentiel cyclique

Ce mode de rafraichissement est bien plus souvent utilisé que ces prédécesseurs car il économise les ressources de la base de donénes maître en réduisant le nombre de mises à jour nécessaires entre les MVs et les tables maitresses.

Le commutateur “start with” va permettre de définir une fréquence de mise à jour des données en collaboration avec le commutateur “next” qui permettra de définir l’intervalle de future mise à jour après la première éffectuée.

Syntaxe:

create materialized view MV1
refresh
start with trunc(sysdate+1)+ 8/24
next trunc(sysdate + 1) + 24/24
as select * from t1, t2;

Dans cet exemple, MV1 verra ses données matérialisées créées à 8 heures puis rafraichies automatiquement tous les jours à minuit.

4 - Type de rafraichissement FORCE ou FAST :

4.1 - Introduction :

Il existe deux “types” de rafraichissement des données matérialisées, le type FORCE ou le type FAST.

Le mode FORCE est le mode par défaut et implique le comportement de tous les exemples décrits dans les paragraphes précédents, il est donc inutile d’en reparler ici.

Le mode FAST implique une notion de mise à jour RAPIDE en opposition à une mise à jour plus lente qu’est la mise à jour complète des données d’une MV. Vous l’aurez compris (ou intuité), nous parlons ici d’une mise à jour différentielle des données matérialisées.

4.2 - Type de mise à jour Rapide des données matérialisées :

Le typde mise à jour “rapide” d’une MV est un type incrémental. Afin de minimiser le temps de comparaison des données présentes dans les tables mères par rapport aux données présentes dans les tables des MV, un fichier de journalisation des données modifiées est créé à cet effet, ou plustot une “table” de journalisation des données matérialisées : on parle de MATERIALIZED VIEW LOG (tables “MLOG$_*”).

Ces tables de log “MLOG$_*” comprennent les modifications éffectuées sur les tables mères d’une MV (insert, update, delete) et permettent au MV de ne synchroniser que les enregistrements ayant subits des modifications, au contraire du type FORCE qui concerne l’ensemble des données de la MV (et donc des tables mères).

Ce type de fonctionnalité est donc précédé de la création de ces tables de LOG grâce à la commande :

SQL> create materialized view log on T;

Ceci ayant pour effet de créer une table MLOG$_T sur le host courant, une table qui contiendra à dater de cet nstant toutes les modifications des lignes de la table T. Il conviendra par la suite de créer une vue matérialisée sur T pour bénéficier de ce journal.

La problématique de la fréquence des mises à jour ne chande pas (sur demande, on commit, …) sauf que celle ci se fera à dater de ce moment de manière différentielle et non plus de manière complète, ce qui représentera un gain de temps fondamental.

Il convient ensuite de préciser que l’on souhaite une vue matérialisée dont le typde mise à jour est basé sur l’exploitation de ces tables de log Oracle pour éffectuer des mises à jours incrémentales selon une fréquence à définir:

SQL> create materialized view MV REFRESH FAST on select * from T;

La fréquence de lecture des journaux (tables) de log seront induites par les sous commutateurs start et next permettant de définir une condition initiale pour débuter une mise à jour et une récurence.

5 - Réplication de données :

5.1 - Introduction :

La réplication de données selon Oracle est assurée par la mise à jour de données de tables par les méthodes de synchronisations de données éffectuées grâce au concept de vue matérialisée.

Une réplication de données se fera donc à l’aide de l’utilisation des vues matérialisées, des notions qui seront accessibles à distance à l’aide de la notion de DB-LINK (Database Link) / liaison inter-bases de données.

Le principe d’un DB-LINK est d’accéder de manière transparente à des tables situées en dehors de l’instance de base de données principale, généralement située sur un autre hote accessible en TCP/IP. Un DB-LINK Oracle permet donc de lier des schémas de base de données inter instances entre elles.

La création d’un DB-LINK se réalise par la syntaxe suivante :

CREATE PUBLIC DATABASE LINK CONNECT TO <user> IDENTIFIED BY <pwd> USING '<tsn_conn>' ;

Avec les paramètres suivants :

- <user> : nom d’utilistateur de la DB distante

- <pwd>: le password de <user>

- <tsn_conn> :  la définition d’accès à la database distance par le TNS_NAME local.

Imaginons maintenant, à travers la définition de DB-LINK, qu’une table distante soit accessible depuis une instance de base de données locale, si nous créons sur la table distante un journal de log, rien ne nous empêche sur la base locale de créer alors une vue matérialisée en mode FAST, vue induuite par une requête utilisant cette même table distante caractérisée par un journal de log. Nous venons à cet instant précis d’alimenter une table d’une instance I1 par une table d’une instance I2, le tout, quel que soit la distantce, sur un réseau TCP/IP : Autrement dit : nous venons de faire de la réplication de données.

5.2 - Mise en place :

Un petit peu pressé par le temps, je publie cet article maintenant en l’absence de rédaction de ce paragraphe. Sous peu, vous aurez sous le 5.2) l’exacte syntaxe pour mettre en place concrètement et rapidement la réplication de données selon Oracle (i.e. à travers des MV en type FAST).

En attendant, certaines informations vous seront peut être utiles, d’où la publication rapide !

Nous postulons donc dans ce chapitre que toutes les bases sotn en mode ARCHIVELOG et qu’elles disposent égallement de zones de restauration rapides (FlashBack).

1) Introduction :

La commande qui permet à RMAN d’éffectuer une restauration de tout ou partie d’une base de données est RESTORE.

Dans certains cas, il sera nécessaire de demander à RMAN de pratiquer un recovery après une restauration de données afin de rendre la database cohérente grâce aux archivelogs au préalablement sauvegardés.La commande qui permet à RMAN d’éffectuer un recovery après est RECOVER (le terme francisé “officiel” Oracle est “RECUPERATION“)

Chaque opération de restauration peut amener des situation particulières, il faut donc, avant toute restauration, faire le point sur la situation afin de déterminer quelles sont les actions à mener et de ne pas se précipiter.

1.1) Restauration de données :

La restauration de données s’éffectue avec la commande RMAN RESTORE et permet de faire référence à un certain nombre d’objets (base de données, fichier de données, fichier de contrôle, fichier de paramètre, …).

Syntaxe : (le nombre d’options et de commutateur n’est pas exhaustif)

RESTORE
       [ DATABASE
       | DATAFILE    <liste_des_datafiles_par_nom_ou_#>
       | TABLESPACE  <liste_des_tablespaces>
       | CONTROLFILE [ to '<dest>' ] [ from [ autobackup | '<source>] ]
       | SPFILE      [ to '<dest>' ] [ from [ autobackup | '<source>] ]
       | ARCHIVELOG  [ ALL | [ FROM TIME '<date>' | UNTILE TIME '<date>'
                           | TIME BETWEEN '<d1>' AND '<d2>] ]
       ]
       [ PREVIEW [ SUMMARY ] ]
       [ VALIDATE [ BACKUP-SET ] ]
       ...
       (consulter la doc pour les autres commutateurs)

Info: L’option PREVIEW permet de lister les éléments dont RMAN va avoir besoin pour éffectuer l’ordre de restauration, cette commande peut s’avérer utile si vous disposez d’un outil de sauvegarde désynchronisé de RMAN (par exemple utilisation de RMAN pour sauvegarder vers du disque et déport du disque vers LTO avec un logiciel de sauvegarde de fichiers (TINA, TSM, …)). L’option PREVIEW peut être accompagnée de SUMMARY qui donnera un affichage détaillé de cette commande.

Info: L’option VALIDATE permet de tester si l’opération de restauration peut être exécutée sans erreur (vérification de l’existence et de la consistence de tous les fichiers nécéssaires à cette restauration avant restauration).

1.2) Récupération de données (”recovery”) :

La syntaxe de la commande RECOVER est la suivante :

RECOVER
       [ DATABASE
       | DATAFILE    <liste_des_datafiles_par_nom_ou_#>
       | TABLESPACE  <liste_des_tablespaces>
       ]
       [ DELETE ARCHIVELOG  [ MAXSIZE <size> [K|M|G] ] ]
       ...
       (consulter la doc pour les autres commutateurs)

Note: Les fichiers de journalisations archivés manquant et restaurés par RMAN le seront dans le répertoire de l’instance prévu à cet effet dans LOG_ARCHIVE_DEST_1. L’option “DELETE ARCHIVELOG” permet de supprimer les fichier de journalisés archivés restaurés au fure et à mesure que le recovery avance et en fonction d’une taille maximum d’occupation (MAXSIZE).

2) Restauration de données :

Cet article va présenter quelques cas de restauration et de recovery isolés, mais, dans une production, vous serez probablement confronté à des cas de restauration plus complexes car mettant en cause plusieurs points simultanément.

Note: Nous considérons ici, comme toujours dans une production sérieuse, que les base de données sont en mode archivage des fichiers de journalisation (ARCHIVELOG).

RMAN prévoyant l’inclusion systématique des fichiers de contrôle et des fichiers de paramètres d’instance, nous considérerons que ceux-ci sont toujours disponibles dans les sauvegardes restaurées : en effet, horsmis pour traiter quelque cas d’école, il est strictement inintéréssant de ne pas utiliser les fonctions de sauvegardes automatique de ces fichiers.

2.1) Restauration d’un fichier de paramètre serveur (SPFILE) :

La présence du SPFILE est la première chose dont à besoin l’instance Oracle pour démarrer, il est donc strictement indispensable d’en détenir des copies de sauvegarde. Vous pouvez même automatiser une simple copie régulière de ce fichier (en dehors de l’autobackup de RMAN) car celui-ci ne pèse vraiment pas lourd et se passer de lui peut poser problème.

Il est aisé de recréer le SPFILE à partir d’un simple fichier texte que vous aurez au préalablement sauvegardé, c’est aussi la méthode la plus rapide en dehors d’une sauvegarde par RMAN, il est dommage de s’en priver.

La méthode de restauration d’un SPFILE par RMAN est simple, un petit exemple se passe de commentaires :

1 : RMAN> set dbid 5687165146;

2 : RMAN> startup nomount;
échec du démarrage : ORA-01078 : failure in processing system parameters ...

3 : RMAN> restore spfile from autobackup;

4 : RMAN> shutdown;

5 : RMAN> startup;

Cette méthode permet de restaurer aisément un fichier de préférence serveur qui aurait été sauvegardé en mode automatique par RMAN (autobackup). Si vous désirez spécifier un chemin exact pour pointer une sauvegarde RMAN d’un SPFILE, il vous suffit de remplacer la ligne 3 par l’emplacement tel que :

3 : RMAN> restore spfile from '/datas/sauvegardes/mabase/spfile/01_mf_s_5687165146_.bck';

Les procédures de restauration des SPFILE doivent évidement se faire en mode NOMOUNT, une erreur sera alors détectée par RMAN après l’étape [2:] car le mode NOMOUNT (mode de démarrage minimal d’une instance) exige la présence et la lecture d’un fichier de préférence, hors c’est bien celui-ci que nous avons perdu. RMAN va alors dynamiquement mettre à disposition de l’instance un PFILE minimal permettant de la démarrer et de démarrer en mode NOMOUNT afin de procéder à la restauration du SPFILE sauvegardé.

2.2) restauration des fichiers de contrôles :

La restauration d’un fichier de contrôle doit se faire UNIQUEMENT si vous avez perdu toutes les occurences de votre fichier de contrôle car, inutile de vous le rapeller, un bon DBA multiplexe ses fichiers de contrôles sur des volumes séparés (sauf baie SAN) et sur des filesystem différents, ce qui minimise largement ce risque de perte.

a - Restauration à partir d’un fichier OS intact :

Le fichier d’alerte de l’instance doit normalement vous renseigner sur l’ensemble des fichiers de contrôles perdus et donc à remplacer à partir de copie d’un des fichiers de contrôle intact. Il ne vous reste plus qu’à remplacer les copies endommagées par des instances du fichier intact (copies OS), c’est tout.

b - Restauration à partir de RMAN :

Si RMAN est à l’origine de la sauvegarde de vos fichiers de contrôles, et que vous avez activé la sauvegarde automatique (AUTOBACKUP) comme nous vous l’avons conseillé, la méthode est simple, choisissez un chemin de destination <DEST> valide pour la restauration du fichier puis modifiez le fichier de paramètre pour qu’il le prenne en compre.

Exemple:

RMAN> restore control file to '/data/tmp/ctl.bck' from autobackup;

RMAN> sql "alter system set control_files='/data/databases/base1/ctl/1.ctl',
                                         '/data/tmp/ctl.bck' scope=SPFILE;
         ";
RMAN> shutdown;
RMAN> startup;

2.3) Restauration d’un fichier de journalisation :

La perte d’un fichier de journalisation n’est pas un drame en soit pour le peu que vous ayez correctement calibré votre instance de production, à savoir que vous ayez créé plusieurs MEMBRES par GROUPE de redologs et qu’il vous reste au moins un fichier dans chaque groupe : le multiplexage des journaux est indispensable pour garantir la stabilité de la base de données.

La méthode consiste à consulter dans le fichier d’alerte quel est le fichier redolog qui pose problème afin de le détruire en l’enlevant du référentiel de l’instance et de le re-créer.

Exemple: Ici, on suppose que le fichier d’alerte montre que le fichier g2m1.log du group 2 est invalide

SQL> alter database drop logfile member '/data/base/redos/g2m1.log';

SQL> alter database add logfile member '/data/base/redos/g2m1.log' to group 2;

Remarque: La vue v$logfile donne le status des fichiers redo (valid / invalid) en cas de problème d’accès sur l’un d’eux.

Remarque: même s’il est défecteux, il est interdit de supprimer le redolog courant, vous devrez forcer Oracle à passer au groupe suivant avec ALTER SYSTEM SWITCH LOGFILE avant de faire cette opération.

2.4) Restauration complète d’une base de données :

Dans le cas où vous avez perdu tous les fichiers de données, c’est sans doute l’opération la plus simple à réaliser, en voici la syntaxe et la procédure :

RMAN> startup mount;

RMAN> restore database;

RMAN> recover database;

RMAN> sql "alter database open";

2.5) Restauration partielle base de données ouverte :

Dans le cas où vous n’avez perdu qu’un fichier de données rendant par exemple inéxploitable un tablespace de votre database mais que les autres sont accessibles, vous n’avez pas besoin d’arreter l’instance pour restaurer du moment que vous êtes en mode ARCHIVELOG.

Il suffit de mettre OFFLINE les datafiles corrompus, de les restaurer, puis de les passer online avant de pratiquer un recivery pour rendre le fichier cohérent avec le reste de la database.

RMAN> startup mount;

RMAN> sql "alter database datafile 10 offline;";

RMAN> sql "alter database open";

RMAN> restore datafile 10;

RMAN> recover datafile 10;

RMAN> sql "alter database datafile 10 online;";

Les différents scénarios qui peuvent se présenter pour une sauvegarde sont en nombre très grand, nous ne pouvons pas tous les citer ici, le principe étant de bien comprendre la méthode et surtout, en cas de crash, de faire le bon disgnostique en analysant les messages d’erreurs apparaissant dans les fichiers d’alerte.

N’oubliez pas que le support Oracle est là aussi pour vous aider, n’hésitez pas à les apeller avant de faire un erestauration, ne serait-ce que pour avoir leur quitus technique.

La version 10g améliore énormément les techniques de FLASHBACK , la rend accessible en SQL, et permet aux DBAs de disposer véritablement d’une alternative aux recovery classiques (restauration et application des archivelogs) dans de nombreux cas. La notion ne varie quasiment pas en 11g.

1 - Introduction au FlashBack :

1.1) Sur quoi est basé la technologie FlashBack ?

Le FLASHBACK est un terme générique désignant un ensemble de fonctionalités permettant d’éviter les recovery en indiquant au moteur de base de données qu’il doit revenir à un état de la base pour un timestamp donné ou plustot pourun SCN donné.

Les archivelogs sont aux journaux d’une database ce que la zone de restauration rapide est aux segments d’annulations (UNDO SEGMENTS). En effet, les fonctionnalités de FLASHBACK utilisent les informations stockées dans les segments des tablespaces d’annulation pour “revenir en arrière” sur toute transaction jusqu’à une en particulier identifiée par un SCN précis (même s’il existe des approches temporelles comme nous le verrons plus loin).

Attention, seules les informations validées (COMMIT) des segments d’annulations de la zone de récupération rapide seront considérés, en effet, il serait stupide de vouloir revenir à un état de la database qui serait un état d’incohérence.

1.2) Rappels sur la conservation des blocs :

Le tablespace UNDO est caractérisé, entre autre, par le paramètre RETENION qui caractérise la manière dont la rétention est gérée dans les segments d’annulation, cette valeur peut être  :

a - “RETENTION GARANTEE” : indique que le tablespace UNDO garde toutes les transactions y compris celles qui n’ont pas abouties (ROLLBACK ou pas de COMMIT) (habituellement utilisé en production). Le paramètre UNDO_RETENTION spécifie alors le nombre de secondes (3600 par défaut) pendant lesquelles les données sont assurées d’ête conservées dans le tablespace UNDO.

b - “RETENTION NOGARANTEE” : les blocs sonts conservés uniquement pour les transactions commitées. (non recommandé en production)

La valeur des paramètre RENETENTION et UNDO_RENETION sont modifiables par “ALTER SYSTEM”.

1.3) Paramètrage du FLASHBACK:

1.3.a) Zones de stockage

Il est vivement conseillé aux DBAs d’utiliser la zone FLASHBACK sans lésiner sur l’espace disque utilisé par celle-ci. En effet, nous avons vu que la zone de flashback était liée à une sorte de stockage des informations stockées habituellement dans les segments d’annulation.

Lorsqu’une information présente dans un tablespace UNDO va expirer (UNDO_RENETION atteint par exemple) alors, si le FLASHBACK est activé, cette information va être stockée dans un journal UNDO. Il faut donc, en fonction de la vie de la database, des zones de stockage de ces “journaux” d’annulation plus ou moins grande. Lorsque cela est possible, Il convient de définir un espace suffisament grand pour stoquer toutes les informations transactionelle d’une ou deux journées afin pouvoir faire un “retour arrière” sur cette période.

En effet, une base qui ne fait que très peut de mise à jour n’aura pas besoin d’une zone de stockage des informations d’annulation à journaliser très grande.

La zone de stockage des données nécessaires au flashback est définie par DB_RECOVERY_FILE_DEST. La taille maximale à utiliser pour le FlashBack sous cette arborescence est DB_RECOVERY_FILE_DEST_SIZE.

1.3.b) Durée de rétention des informations FlashBack

Parallèlement à la notion de UNDO_RETENTION, il existe la même notion à appliquer aux informations journalisées de la zone de FlashBack, celle - ci se définie grâce au paramètre DB_FLASHBACK_RETENTION_TARGET. Attention, prenez garde à ce que cette valeur soit supérieure à UNDO_RETENTION.

1.4) Activation / Désactivation du FlashBack :

ALTER DATABASE FLASHBACK [ ON | OFF ]

Et c’est tout !

2) Les technologies de FlashBack :

Il existe en fait plusieurs façon d’aborder le flashback, le principe est globalement toujours le même, se servir des informations archivées des transactions (Undo Segments), mais les méthodes sont sensiblement différentes. Nous parlerons communément de “FlashBack de base de données”, de “FlashBack de Table” ou de gestion de la “Corbeille” ou encore de “FlashBack de données” (ou de lignes).

2.1) FlashBack Query : (ou FlashBack de lignes / de données)

2.1.a) Interrogation de données dans le temps

Le FlashBack Query permet d’interroger une ou plusieurs tables et de lire les données qu’elles contiennent à un SCN bien précis.

Cette information sera trouvée dans les segments d’annulation ou bien encore, si ceux-ci ne possèdent plus cette information car leur retention a expirée, dans les stockage de ces informations dans la zone DB_RECOVERY_FILE_DEST de la FlashBack.

Syntaxe:

[ Requete SQL de selection ] AS OF [ SCN | TIMESTAMP ] [ critères SQL de la requête ]

Exemple:

SQL> select current_scn from dual;

10/01/2008         11:00:20           176032

SQL> select valeur from compteur where id_compteur=1;

44

SQL> update compteur set valeur=valeur+1 from compteur where id_compteur=1;

SQL> commit;

SQL> select current_scn from dual;

10/01/2008         11:00:20           176054

SQL> select valeur from compteur where id_compteur=1;

45

SQL> update compteur set valeur=(select valeur from compteur AS OF SCN=176032 where id_compteur=1)
where id_compteur=1;

SQL> select valeur from compteur where id_compteur=1;
44

Nous avons ainsi pu consuler la valeur d’une donnée en revenant dans l’historisation des transactions et en parcourant les données des tablespaces UNDO ou des journaux de la zone de FlashBack.

2.1.b) Interrogation des données et de leurs différentes versions

Il se peut que vous ne disposiez pas exactement du SCN exact pour un retour arrière ou que vous ne sachiez pas exactement quelle valeur conviendrait correctement à un retour arrière cohérent. Il est possible de consulter un ensemble de versions de valeurs pour une ou plusieurs données situées entre deux SCN ou deux TIMESTAMP en guise d’intervalle (mot clé BETWEEN).

Lors des interrogation des versions d’une ligne, vous pouvez aussi spécifier dans votre requête des noms de pseudo-colonnes qui permettent de cibler l’information, à savoir :

Syntaxe:

[ requete SQL ] VERSIONS BETWEEN [ SCN1 | TS1 ] [ expression 1 | min] [ expression2 | max]

Exemple:

SQL> select version_startscn, versions_endscn

     from personnes 

     versions between scn 17000 and 18000

     where personne_id=24; /

2.1.b) La vue FLASHBACK_TRANSACTION_QUERY

Cette vue accessible aux DBAs permet de voir les modifications réalisées par une ou plusieurs transactions sur un certain intervalle de temps.

Les champs de cette vue sont :

Il peut être intéressant par exemple de rechercher toutes les opérations de DELETE sur la table personnes la dernière journée afin de réappliquer les ordres sql inverses (UNDO_SQL) sans pour cela annuler les éventuelles mises à jour (UPDATES) qui auraient été éffectuées, ce qui aurait été malheureusement le cas lors d’un recovery!

2.2) FlashBack Table :

Les opérations FlashBack de niveau “TABLE” permettent d’éffectuer un retour arrière complet sur des opérations LMD de tables. Depuis la version 10g, cette notion a été étendue aux opérations DDL, une utilisation à manier avec précaution.

2.2.a) FlashBack TABLE LMD :

Cette opération permet d’effectuer un retour arrière sur les valeurs d’une table, avec ou non l’activation de ses triggers (non recommandés dans bien des cas : valeur par défaut non activé), que cela-soit en fonction d’un SCN ou d’un TimeStamp.

Syntaxe :

FLASHBACK TABLE <table_name> to [ TimeStamp | SCN ] <expression> [ enable TRIGGERS ]

Note: L’utilisateur qui donne un ordre FLASHBACK TABLE doit disposer des privileges “flashback any tables”, “[insert / select / alter] sur la table correspondante. La table à restaurer doit autoriser le déplacement de lignes (ALTER TABLE <table_name> ENABLE ROW MOVMENT)

2.2.b) FlashBack TABLE DDL (ou “FlashBack DROP” ou gestion de la “CORBEILLE”) :

Attention : Cette fonctionalité n’existe que depuis la version 10g.

Cette fonctionalité, dite aussi “gestion de la corbeille”, permet de revenir en arrière sur un ordre DDL de type DROP TABLE, ce que n’inculait pas le FLASHBACK TABLE.

En fait, si les fonctions de FlashBack sont activées, une table n’est pas supprimée après un DROP mais simplement renommée et son espace n’apparait plus dans DBA_FREE_SPACE (cette méthodologie est également valable pour les index des tables droppées).

Les objets temporairement renommés ne sont pas écrasés tant qu’un éventuel manque de place ne survient pas dans le tablespace concerné. Oracle commencera alors par supprimer les objets les plus anciennements supprimés, comme dans une gestion “classique” de corbeille sous votre OS préféré (FIFO).

La corbeille est à tout moment interrogeable à travers les vues USER_RECYCLEBIN ou DBA_RECYCLEBIN.

Syntaxe:

FLASHBACK TABLE <table_name> to BEFORE DROP [ rename to <new_tablename>]

Note: Les DROP de tables spécifiés avec l’expression PURGE ne pourront pas être récupérés dans la corbeille.

Note: La corbeille peut être vidée de son contenu par “PURGE DBA_RECYCLEBIN”.

Note: Attention aux surprises lors de la restauration d’une table qui est dans la corbeille : n’oubliez pas par exemple que certains triggers ont pu être activés lors du DROP et que les contraintes d’intégrité référentielles ne fonctionneront probablement plus à la restauration. Cette opération peut être utile pour récupérer les données proprement dites de cette table mais il est rare de pouvoir restaurer une table sans problème avec cette méthode en production, à moins que celle-ci ne soit liée à aucunne autre donnée (table paramètre, …).

Note: Le Flashback Table BEFORE DROP n’a aucun rapport avec le stockage des données UNDO (archivées ou non) dans la zone de restauration rapide. En effet, une table droppée sur une database où la Corbeille est activée ne sera pas supprimée mais simplement renommée  avec un nom barbare du style “$RECYCLEBIN_379837983 …” (l’espace que celle-ci consomme dans les segments deumeurera par ailleur le même jusqu’à purge de la corbeille). Une restauration de table dropée sera un simple renommage inverse de table. Une problèmatique existe cependant en 10g et 11g : les index associés et les primary key gardent les noms des tables stockées en corbeille ($RECYCLEBIN_ …) ce qui pose un réél problème d’exploitation par la suite .. à méditer.

2.3) FlashBack Database :

le FlashBack DATABASE est sans aucun doute la plus puissante des options de FlashBack puisqu’elle permet de ramenner la database à un état précis sans pratiquer de recovery.

Cette méthode consiste à parcourir les logs de la flashback (ie les journaux d’annulations archivés de la fhashback_recovery_area) à l’envers: il est donc inutile de restaurer une version cohérente et antérieure de la database pour lui appliquer classiquement des archivelogs, ce qui est un gain de temps énorme!

La seule difficulté est de dimensionner correctement la zone de flashback car, si celle ci est trop petite, Oracle réduira alors sans vous le dire la durée de rétention des informations d’annulation archivées (DB_FLASHBACK_RENTETION) et vous ne pourrez peut être plus remonter aussi loin dans le temps que vous l’auriez souhaité.

Syntaxe SQL :

FLASHBACK DATABASE TO [ SCN | TIMESTAMP ] <expression>

Syntaxe SQL sous RMAN :

FLASHBACK DATABASE TO [ SCN | TIMESTAMP ] [ = ] <expression>

ATTENTION : Une database qui a subit un flashback est cohérente au SCN demandé, il faut absoluement vider les journaux en ligne et de les synchroniser avec ce SCN pour pouvoir ouvrir cette base de données.

Exemple:

SQL> shutdown immediate;

SQL> startup mount;

SQL> flashback database to timestamp sysdate-1/24;

Flashback terminé.

SQL> alter database open RESETLOGS;

Base de données modifiée.

SQL> alter database open;

D’une simplicité enfantine, d’une rapidité déconcertante.

Remarque: Il n’est pas recommandé (au contraire de ce qui est fait dans cet exemple) d’éffectuer un flashback (ou une autre opération de recovery) à l’aide d’un TimeStamp mais plustot à l’aide d’un SCN si vous en avez la possibilité. En effet, Oracle ne connait que les SCN et les valeurs temporelles sont approximées et peuvent parfois s’avérer fausse! Vous pouvez ainsi restaurer une database à un point qui n’est pas vraiment celui qui avait été voulu…

Remarque: Avant tout flashback, faites une sauvegarde complète de tous les fichiers de la base de données y compris ceux de la FlashBackArea : Cette opération vous permettra d’éffectuer de nouveau un FlashBack au cas où le SCN demandé ou le TimeStamp demandé n’était pas exactement celui souhaité dans une première tentative.

]]> http://www.startupmount.com/2009/06/01/zones-de-restauration-rapides/feed/ http://www.startupmount.com/2009/05/27/introduction/ http://www.startupmount.com/2009/05/27/introduction/#comments Wed, 27 May 2009 16:40:17 +0000 DBA01 http://www.startupmount.com/?p=174 startupmount.com est un site web dédié à Oracle, les utilisateurs avertis l’auront vite deviné.Vous trouverez sur ce site un certain nombre d’informations relatives aux possibilités d’administration du moteur de bases de données relationnelles le plus puissant du marché, des techniques de sauvegardes et de restauration, des fiches techniques, etc.

A titre informatif, même si cela paraît évident pour certains, ce site web est strictement indépendant de la firme Oracle ainsi que de tous ses produits, commerciaux ou gratuits.

Ce site est ouvert aux commentaires, aux articles, aux suggestions et aux expériences en tout genre des internautes pourvu qu’ils soient DBAs. En effet, la rédaction de startupmount.com est ouverte sans restriction à ceux désireux d’apporter leur pierre à l’édifice, si humble soit il, mais dans la masse des bonnes intentions, il faut bien fixer quelque niveau afin d’éviter d’entrer dans la catégorie des sites trop souvent généralistes : Demander à ce que les rédacteurs soient des DBA n’est pas du tout prétentieux, ne nécessite aucun diplome de la part du rédacteur,  mais permet simplement de s’assurer que celui-ci sait de quoi il parle, ce qui parrait essentiel !

Bonne lecture !

Comme indiqué dans le chapitre REFERENTIEL RMAN, RMAN peut utiliser les fichiers de contrôle d’une base de données pour y stoquées les informations utiles pour ses sauvegardes (et donc ses restaurations), mais cela pose de nombreux problèmes en cas de perte de ceux ci. L’altéernative est de stoquer le catalogue dans une database prévue à cet effet (ce que nous vous conseillons).

1 - Nomenclature:

RMAN peut éffectuer de simples copies des fichiers de données, on parle alors de “IMAGE COPY“, ou de gérer l’ensemble des copies qu’il éffectue pour vous dans un format propriétaire nommé “BACKUP SET“.

Une ImageCopy est exactement la même chose que si vous aviez copié des fichiers par l’OS : c’est de loin la meilleure option.

Le BackupSet en revanche permet de ne sauvegarder que les blocs oracles utilisés dans les datafiles, ce qui allège considérablement le poids des sauvegardes avec un rapport de 1/5, ce qui est loin d’être négligeable. De plus, un BackupSet peut être découpé logiquement en plusieurs parties nommées “BACKUP PIECES” ceci pour répondre à des problématiques de limite de stockage (un DBF de 10Go sur une bande de 4Go par exemple).

Rappel: Que cela soit avec RMAN ou un autre outil de sauvegarde, il n’y a pas de miracle, une sauvegarde à chaud d’une database ne peut s’éffectuer QUE si celle si l’archivage des fichiers journaux (archivelogs) est activé, sinon cela n’est pas possible. Une sauvegarde “à chaud”, avec ou sans RMAN, est de toute façon incohérente, il conviendra d’appliquer les journaux archivés aux fichiers de données restaurés pour obtenir une sauvegarde “cohérente”.

2 - Sauvegarde non incrémentale :

Comme vous pouvez vous en douter, BACKUP est l’instruction de RMAN qui va vous permettre d’effectuer une sauvegarde de votre base de données complète ou partielle, full ou incrémentale. Elle vous permet de sauvegarder un fichier de données, un tablespace, la database entière, le spfile et les fichiers de contrôles, les journaux et journaux archivés.

La syntaxe est assez simple :  RMAN> BACKUP <ordre> <options>

Les [] symbolisent ici des éléments non obligatoires, les caractères gras les commutateurs les plus habituels en production.

2.1 - Ordres de la commande BACKUP :

[ incremental level <n> [ cumulative] ]

permet les sauvegardes incrémentales de niveau 0 ou 1, avec l’option de cumuler les sauvegardes pour l’amélioration des performances à la restauration

[ validate ]

Doit - on vérifier la sauvegarde après sa génération ?

[ as [ copy | [compressed] backupset ]

Quel est le type de sauvegarde ? (”backup set” recommandé)

[ database | tablespace <ts_name> | datafile <df_name> | current controlfile | spfile ]

que sauvegarder ?

[ archivelog <cible> ]

faut il sauvegarder les archivelogs et où ?

2.2 - Options de la commande BACKUP :

[ include current controlfile ]

généralement à faire, sauve si sauvegarde automatique du CTL file déjà prévue (voir plus loin)

[ plus archivelog ]

à effectuer en mode archivelogs dans le cas des sauvegardes à chaud car c’est indispensable pour obtenir une database cohérente après restauration.

[ delete [ all ] input ]

généralement à effectuer : détruit les archivelogs qui ne sont plus nécessaires

[ format = '<format>' ]

format de la sauvegarde (voir plus loin)

[ tag = '<libelle_de_marqueur>' ]

Très utile : ajouter un tag (marqueur informatif) à une sauvegarde. Il sera possible d’interroger RMAN sur ces tags.

[ not backed up <clause>]

[ ALL | FROM TIME <time> | UNTIL TIME <time> | TIME BETWEEN <t1> AND <t2> ]

Exemples d’utilisation:

RMAN> backup validate database tag=’full_20080701_2015′ plus archivelog delete input;

RMAN> backup tablespace datats, indexts include current controlfile;

RMAN> backup datafile 7, ‘/data/madatabase/datafiles/mondbf01.dbf’;

Remarque 1 :

Une sauvegarde RMAN est une sauvegarde (intelligente) des fichiers composants la base de données (entre autre les datafiles). Ces fichiers, quel que soit le mode de sauvegarde (database, datafile, …) sont copiés les uns après les autres, il est don cfort à parier que, si la base de données “vie” un minimum, que les fichiers soient positionnés à des SCN différents lors de leur sauvegarde.

Les journaux et les journaux archivés sont alors indispensables lors de la restauration car il faudra pratiquer un recovery après restauration des datafiles pour rendre l’ensemble de la base “cohérente” (cad toutes les en-têtes des fichiers sont de même SCN).

Les commutateurs “PLUS ARCHIVELOG” sont alors strictement nécessaires, nes les oubliez pas !

Remarque 2 : Il est possible de sauvegarder manuellement les archivelogs par la commande “BACKUP ARCHIVELOG ALL’”.

Remarque 3: Nous verrons par la suite qu’il est souvent inutile de préciser certains commutateurs car ceux ci font partie d’une conguration globale de RMAN et sont donc inclus par défaut.

3 - Sauvegarde incrémentale :

Note: Cette option n’existe quà partir du niveai de licence “Enterprise”.

3.1 - Incrémentale basée sur les traçage de blocs indiqué par Oracle :

La sauvegarde incrémentale au sens de RMAN peut appuyer sur la technologie de traçage des blocs modifiés d’une instance Oracle par le moteur de base de données.  Cette option activée indique au moteur de base de données qu’il doit spécifier dans un fichier particulier l’ensemble des blocs modifiés depuis l’instant T. Cette liste sera consultée par RMAN dans le cadre d’une sauvegarde incrémentale et celui-ci n’ira alors sauvegardé que les blocs marqués par Oracle comme modifiés dans ce fichier de trace.

Syntaxe:

SQL> database enable block change tracking using file '<chemin_fichier>';

3.2 - Incrémentale basée sur les traçages de blocs non indiqués par Oracle :

Le traçage de blocs Oracle par le moteur de base de données comme indiqué dans 3.1) n’est pas obligatoire pour éffectuer une sauvegarde incrémentale avec RMAN mais, dans ce cas là, celui-ci ne peut pas connaitre la liste exhaustive des blocs modifiés et est obligé de parcourir tous les blocs d’un tablespace afin de déterminer quels sont les blocs modifiés depuis sa dernière sauvegarde.

Le résultat sera exactement le même qu’avace le traçage de blocs Oracle par le moteur de base de données mais les performances s’écroulent : n’hésitez pas à utiliser le traçage de blocs Oracle par le moteur de base de données !

3.3 - Niveau de sauvegarde :

Une sauvegarde incrémentale au sens de RMAN possède un NIVEAU. Le niveau d’une sauvegarde incrémentale indique à RMAN quelle est la sauvegarde de base que celui-ci doit considérer pour évaluer le “delta” avec une situation actuelle à sauvegarder.

- NIVEAU 0 : Même si la sauvegarde est dite incrémentale, le niveau 0 indique en fait à RMAN que tout doit être sauvegardé, même si RMAN ne considère pas une telle sauvegarde comme FULL, elle contient pourtant tous les blocs de la base de données et est restaurable.

- NIVEAU 1 : Si une incrémentale est de niveau 1, alors RMAN ne sauvegardera QUE la différence avec la dernière sauvegarde équivalente de niveau 1 ou de niveau 0 : C’est une sauvegarde différentielle.

Le principe étant de faire régulièrement des sauvegardes de niveau 0 et, périodiquement, des sauvegardes de niveau 1 alors beaucoup plus rapides à éffectuer.

3.4 - Sauvegarde cumulative

Une sauvegarde cumulative est une sauvegarde de niveau 1 qui contient tous les blocs modifiés depuis la dernière sauvegarde de niveau 0, même si des sauvegardes intermédiaires de niveau 1 ont été éffectées.

Ce type de sauvegarde consiste à demander à RMAN de repérer tous les blocs modifiés depuis la dernière sauvegarde de niveau 0, puis de les sauvegarer, une opération qui peut s’avérer lourde si la date de la dernière sauvegarde de niveau 0 est ancienne et que l’activité de la database est importante. Pour réduire ce phénomène, on pourra faire appel au pointage des blocs modifiés par le moteur de base de donnés Oracle et non par RMAN comme indiqué dans 3.1).

L’avantage est évidement : les opérations de restaurations sont beaucoup plus rapides puisque aucunne sauvegarde de niveau 1 non cumulative n’est à appliquer.

La syntaxe générale d’une sauvegarde incrémentale est :

RMAN> BACKUP INCREMENTAL LEVEL [0 | 1 ] [ CUMULATIVE ] <ordre> <option>

]]> http://www.startupmount.com/2009/05/25/rman-sauvegarde/feed/ http://www.startupmount.com/2009/05/17/rman-configuration-elementaire/ http://www.startupmount.com/2009/05/17/rman-configuration-elementaire/#comments Sun, 17 May 2009 17:31:42 +0000 Méandre http://www.startupmount.com/?p=143 RMAN est l’outil de sauvegarde des bases Oracle fourni par Oracle, il est à même de discuter avec le moteur de base de données pour les opérations de recovery. Même s’il existe de nombreux outils de sauvegarde sur le marché,  il apparait que RMAN est le meilleur outil pour être certain de sauvegarder correctement.

De plus, l’interface utilisateur de RMAN est d’une simplicité affligente pour 90% des cas de sauvegardes / restaurations, les 10% restants nécessitant il est vrai une certaine connaissance du produit, mais, n’est-ce pas le cas pour tous les outils de sauvegarde ?

Cet  article permet au DBA d’appréhender les 90% RMAN dans de bonnes conditions.

1 - Introduction

RMAN peut utiliser différent référentiels de sauvegardes dont vous devez prendre connaissance avant même de consulter cet article. En effet, il est possible d’utiliser les fichiers de controles d’une instance de base de données comme référentiel (ce qui n’est pas recommandé, en effet, une perte du fichier empecherait un recovery), ou une instance de base de données spécialisée à cet effet.

La connection au référentiel de sauvegarde s’éffectue de la manière suivante  dans le cadre de l’utilisation d’un catalogue de récupération :

rman target <chaine_de_connexion_vers_la_database> catalog <chaine_de_connexion_au_catalogue>

La connection au référentiel de sauvegarde s’éffectue de la manière suivante  dans le cadre de l’utilisation de l’utilisation des fichiers de controles comme référentiel de sauvegarde :

rman target / (en tant que sysdba sur le host local)

OU

rman <chaine_de_connexion_vers_la_database>

Tout ajout / modification d’une configuration par rman se fera avec l’attribut CONFIGURE.

2 - Nomenclature de RMAN

RMAN, comme tous les outils de sauvegarde, utilise une nomenclature de nommage des objets qu’il convient de connaitre afin de bien comprendre les manipulations que l’on entreprend avec ce type d’outil.

En voici une liste (non exhaustive) :

2.1 - CANAL ET PERIPHERIQUE RMAN

2.1.1 - Introduction

Une sauvegarde par RMAN doit avoir (au moins) un chemin de destination ou “channel” sur (au moins) un périphérique physique ou “device type”. Les notions rman sont alors celles de CHANNEL ou de DEVICE TYPE.

Un CHANNEL rman représente la possibilité de sauvegarder et de paralléliser éventuellement des opérations à travers différents chemins sur différents périphériques en médias. Un channel possède DEVICE TYPE qui peut représenter un disque dur (local / distant) ou un périphérique externe (Lecteur LTO, …).

Dans la plupart des configurations “modernes” des serveurs de sauvegardes rman, les canaux de sauvegardes de celles-ci seront associés à de périphériques de type disque (généralement des volumes de baies de disques) qui seront parallèlement sauvegardés par des programmes de sauvegardes de fichiers indépendant des bases de données (TINA, TSM, etc  …).

Syntaxe:

CONFIGURE CHANNEL DEVICE TYPE [ DISK | TAPE] [ < option > ]

Note: Le channel par défaut de rman est associé à un device type DISK (stokage sur disque dur).

2.1.2 - Options de stokage

En fonction du type de stockage et du média utilisé, le DBA peut être amenné à découper un jeu de sauvegarde (BACKUP SET) en plusieurs parties (BACKUP PIECE) afin de les segmenter et d’adapter leur taille à la taille maximale que peut supporter le média associé au DEVICE TYPE (par exemple une K7 LTO3). Cette possibilité est offerte à travers le commutateur FORMAT.

Les options de format sont nombreuses, consultez la doc de rman pour en obtenir la liste.

De plus, il est possible de suffixer, à l’aide du commutateur MAXPIECESIZE, le fichier de sauvegarde (backup set / piece) à l’aide de variables permettant d’en défini’ l’unicité, de l’associer au nom d’une database ou à son dbid, à un nom de tablesapce, etc.

Exemple:

CONFIGURE CHANNEL
          DEVICE TYPE DISK
          FORMAT '/data/mabase/sav/%U'
          MAXPIECESIZE 2G;

Remarque : Effacer toutes vos commandes de configuration pour revenir à la configuration par défaut est possible avec ‘CONFIGURE CHANNEL DEVICE TYPE CLEAR’

2.3 - Politique de conservation des données

Il existe deux types de politique de conservation des données sous rman par database à sauvegarder :

a) Redondance de sauvegardes (REDUNDANCY)

b) Nombre de jours de restaurations (WINDOW)

L’option a) permet de s’assurer via rman qu’à une database correspondra toujours un certain nombre fixe de sauvegardes au minimum. Par exemple, certaines production exige de pouvoir revenir, quel que soit le moment, à deux niveaux de versions antérieur, pour des sauvegardes régulières journalières, ce qui porterait le nombre de redondance de sauvegarde à 3 (versions).

L’option b) permet de s’assurer via rman qu’il sera toujours possible de remonter à j-n, n étant à fixer. Dans cet exemple, le nombre de redondance de sauvegarder n’a pas d’interet pourvu que l’on puisse revenir à la dernière sauvegarde du mois dernier par exemple, ce qui porterait ce paramètre à 30 (jours) environ.

Syntaxe:

CONFIGURE RETENTION POLICY
[ TO [ RECOVERY OF <n> DAYS | REDUNDANCY <n> ]
| CLEAR ];

2.4 - Sauvegarde automatique des fichiers de contrôles

Lorsque vous sauvegardez une database, il est indispensable, hormis les fichiers de données, de sauvegarder un certain nombre d’éléments dont les fichiers de controles et les fichier d’initialisation. Cette opération est éffectuée, si vous le souhaitez, automatiquement par rman qui les intégrera aux backup set.

Syntaxe:

CONFIGURE CONTROLFILE AUTOBACKUP ON;

]]> http://www.startupmount.com/2009/05/17/rman-configuration-elementaire/feed/ http://www.startupmount.com/2009/05/17/rman-presentation-et-referentiel/ http://www.startupmount.com/2009/05/17/rman-presentation-et-referentiel/#comments Sun, 17 May 2009 15:27:51 +0000 Méandre http://www.startupmount.com/?p=138 RMAN (Recovery Manager) est l’outil d’Oracle pour la sauvegarde des bases de données, il est donc dommage (pour ne pas employer d’autre terme) d’utiliser un autre utilitaire que celui-ci pour sauvegarder les données Oracle.

RMAN permet de sauvegarder des données à froid comme à chaud en toute sécurité. Les sauvegardes peuvent être FULL, différentielles ou cumulatives et sont basées sur un référentiel nommé REPOSITORY qui peut se trouver dans les fichiers de dontrole d’une database ou qui peut être externalisé dans une instance prévue à cet effet (REPOSITORY CATALOG ou “catalogue de récupération”).

0 - Utilisation de RMAN avec les fichiers de contrôles

Si vous utilisez les fichiers de controle comme référentiel RMAN, il est encore plus critique de ne pas les perdres, le multiplexage sur plusieurs disques et/ou plusieurs fileSystem est une obligation pour s’assurer de pouvoir restaurer une sauvegarde !

Les données conservées dans un fichier de contrôle ne sont pas éternelles et sont fixées par le paramètre d’init de l’instance CONTROL_FILE_RECORD_KEEP_TIME. La valeur par défaut de ce paramètre est 7 (une semaine), dans le cadre de l’utilisation de RMAN, je vous conseille de porter ce chiffre à 15 voire 30 !

1 - Utilisation de RMAN avec un catalogue de récupération (recommandé)

1.1 Introduction

La méthode de connexion d’un client RMAN sur la catalogue de récupération (instance de base de données dédiée à stoquer les informations RMAN dans une databse plustot que dans les fichiers de controles) est la suivante :

> rman TARGET <user_db>/<pass_bd>@<alias_db> CATALOG <user_cat>/<pass_cat>@<alias_cat>

Il faut bien différencier dans cette commande le TARGET qui concerne les informations sur la base de données à sauvegarde ou à restaurer du CATALOG qui indique la chaine de connexion au catalogue de récupération.

1.2 Création du catalogue

L’opération consiste, dans l’instance de base de données prévue à cet effet, à créer un tablespace et un user pour rman, puis, d’éffectuer un grant particulier au user rman:

# ORACLE_SID=rmancat
# sqlplus / as sysdba
SQL> create tablespace rman_ts datafile '/data/rman/ts/ts01.dbf' size 50M next 10M unlimited;
Tablespace Created
SQL> create user rman identified by rmanpass default tablespace rman_ts;
SQL> grant connect, resource, recovery_catalog to rman;
SQL> exit

Et voilà : le grant RECOVERY_CATALOG suffit à indiquer que l’utilisateur rman a le droit d’interroger et d’interragir avec Oracle pour toute opération de sauvegarde / restauration.

1.3 Utilisation du catalogue

A chaque nouvelle base de données à sauvegarder par rman, il faut informer rman qu’il doit l’inscrire au préalablement dans le catalogue (fichier de controle ou catalogue de récupération). Ceci se fait par la commande

RMAN> register database;

Un DBID est affecté par rman au référentiel afin de différencier toutes les databases qui peuvent provenir de différents hosts et donc avoir les mêmes dbdid locaux ou dbname. Toutes les informations nécessaires aux futures sauvegardes / restaurations sont égallement créées (fichiers à sauvegarder, emplacements des journaux, …)

1.4 Consultation du catalogue

1.4.1 Commande REPORT

La commande rman REPORT permet d’obtenir des informations sur l’état des sauvegardes, par exemple :

report schema : quelle est la structure de la base de données ?

report need backup : quels sont les fichiers qui nécessitent une sauvegarde ?

report need backup incremental 3 : même question pour les incrémentales de niveau 3

report need backup days 3 : même question pour les fichiers non sauvegardés depuis 3 jours

report obsolete : quels sont les fichiers qui peuvent être éffacés (conformément à la politique de sauvegarde)?

report unrecoverables : quels sont les fichiers introuvables et non restaurables ?

…

1.4.2 Commande LIST

La commande rman LIST permet d’obtenir des détails sur des sauvegardes ou certains éléments d’une sauvegarde, par exemple :

list backup; (liste de toutes les sauvegardes)

list backupset; (liste de tous les backupsets)

list backupset of datafile ‘/data/mabase/tablespaces/data/data01.dbf’; (liste de tous les backupsets de ce fichier)

etc…

Note 1 : Le détail des commandes de consultation du catalogue seront plus profondément approfondies dans l’aspect sauvegarde / restauration des bases de données à l’aide de rman et n’ont pas vocation à être étudiée dans cet article qui a pour unique but d’attirer l’attention du DBA sur la qualité du référentiel RMAN.

Note 2 : N’ oubliez pas que, si vous perdez le recovery_catalog, vous ne pourrez plus restaurer aucune de vos sauvegardes de sera plus restaurable, il est donc primordial de le sauvegarder régulièrement. Le poids du catalogue étant très léger, vous n’aurez aucun problème à réaliser une sauvegarde complète journalière de celle-ci à froid, hors période de sauvegardes de vos autres databases.

Ces utilitaires sont obsolètes depuis la version 10g et sont remplacés au profit de Datapump (expdp et impdp), mais exp et imp demeurent présents en 10g pour des raisons de compatibilité, ceux-ci seront sans doute supprimés dans la version 12x même s’ils existent encore dans la 11g.

1 - Introduction

L’export de données est apporté par l’utilitaire Oracle $ORACLE_BASE/bin/exp. Même si on en parle comme un outil de sauvegarde de données par abus de langage, cet outil doit plutôt être considéré comme un outil de transport de données (d’une machine à une autre, d’une version à une autre) car il demeure très pauvre en matière fonctionnelle comparé aux autres outils de sauvegardes définis comme tel par Oracle tels que RMAN.

Les outils d’export/import permettent néanmoins de reconstruire tous les objets présents dans une base de données, mais pas la base de données elle-même, ce qui signifie que vous devrez éventuellement créer une base vierge pour accueillir les données exportées et que, en aucun cas, l’export/import ne sait traiter cette phase là : Export / Import n’est pas un outil de sauvegarde de base de données mais ou outil d’isolation de données logiques (ordres SQL seulement).

Nous verrons par la suite que, la pluspart du temps, si la base de données est accessible par les utilisateurs en modification, il est fort à parier que l’export mette à disposition des données incohérentes et qu’il faille pour éviter cela stopper les accès tout en laissant la base ouverte… Nous vous avons dit que exp/imp n’était pas un “outil de sauvegarde” !

2 - L’outil d’export de données EXP

L’export permet donc, selon certains critères ou filtres, de générer dans un fichier DUMP Oracle (dmp) certaines instructions SQL capables de reconstruire les données à l’aide de l’outil d’import (imp).

L’export, qui exportera les données de la database définie par la variable d’nevironnement ORACLE_SID) utilise principalement les commutateurs suivants :

userid (chaine de connection Oracle à l'instance au sens de SqlPlus)
owner  (nom d'un schéma à exporter plustot que tous les schémas de la base)
rows   (doit on expoter les données (Y) ou seulement les structures de tables)
indexes(doit on exporter les index (Y))
grants (doit on exporter les grants (Y))
table  (si on ne doit export que certaines tables)
file   (nom du dump généré)
log    (nom du fichier log pour trace)
full   (doit on exporter toute la database (N))
statistics (méthode d'exportation des stats (estimate|none))
consistent (les données doivent-elles être consistantes (N))
etc ... (faire exp HELP=Y pour afficher tous les commutateurs)

exemple :
exp "'sys/oracle as sysdba'"
    owner=SCOTT
    file=/data/export_scott.dmp
    log=/data/export.log
    statistics=none
    consistent=Y

Export FULL:

Attention au commutateur FULL : il permet d’exporter toute la base de données, mais vous risquez d’avoir des problèmes à l’import, pensez à ne pas importer en mode FULL égallement sous peine de voir éclater vos tablespaces SYSTEM, SYSAUX, … par ceux importés et de d”étruire votre base de données ! Si un export est FULL, l’import doit être filtrant. Si un export est filtré, l’import peut être FULL.

Données consistantes :

Le commutateur CONSISTENT n’est pas Y par défaut, ce qui signifie que votre export risque de comporter des données inconsistantes. En fait, durant l’exportation d’une table (et seulement d’une table) il se peut que des données soient modifiées en fin de fichier alors que vous avez déjà sauvegardé le début de fichier, et dans ce cas là, vous possèderez peut être des données orphelines (données filles qui n’ont pas de parent) ce qui peut rendre votre applicatif purement inexpoitable.

Pour éviter cela, le commutateur CONSITENT doit être fixé à Y. Le SCN courant est alors observé par exp au début de la sauvegarde d’une table et l’ensemble des requêtes de sélection que va éffectuer l’export se fera par rapport à ce SCN => Les données insérées ou modifiées pendant la sauvegarde ne seront pas vues.

Attention, si vos tables sont très grandes, n’oubliez pas que votre tablespace UNDO doit être correctement dimensionné car auquel cas, vous risquez d’obtenir en résultat un message d’erreur “SNAPSHOT TOO OLD” car les données dont vous auriez eu besoin pour terminer l’export de votre table ont été éffacées par d’autres données indispensables à l’exécution de nouvelles transactions…

ATTENTION : Ce type de traitement ne vous enlève pas le risque d’avoir des données insonsistantes entre plusieurs tables, le paramètre CONSISTENT ne vous règle le problème que au sein d’une table, c’est pour cela qu’il est VIVEMENT CONSEILLE de stopper les accès utilisateurs à la database pendant un export (fermeture des serveurs d’applications, fermeture des listeners, toute bonne méthode au choix du DBA …).

3 - L’outil d’import de données IMP

L’import IMP est donc l’outil capable de lire des dumps réalisés par l’export d’Oracle, l’ordre dans lequel imp effectue les opérations est le suivant:

1:  création des tables (sans contraintes)

2: insertion des données des tables

3: créations des index

4: application des contraintes d’intégrité référentielles

5: création des triggers, des index bitmaps, …

Les commutateurs sont globalement les même que pour EXP, vous pouvez en avoir le détail avec IMP HELP=Y, mais en voici quelques uns indispensables :

userid  (chaine de connection Oracle à l'instance au sens de SqlPlus)
fromuser(liste des schémas à importer plustot que tous les schémas de la base)
tomuser (dans quels schémas faut il importer les données)
rows    (doit on importer les données (Y) ou seulement les structures de tables)
indexes (doit on exporter les index (Y))
grants  (doit on exporter les grants (Y))
table   (si on ne doit export que certaines tables)
file    (nom du dump généré)
log     (nom du fichier log pour trace)
full    (doit on exporter toute la database (N))
commit  (faut-il commiter chaque instruction SQL (N))

exemple :
imp "'sys/oracle as sysdba'"
    file=/data/export_scott.dmp
    log=/data/import.log
    full=Y <-- car on part du principe que l'exp n'est pas full!

Remarque:

Un export ou un import ne doit signaler aucunne erreur ni aucun warniong sous peine d’avoir des surprises lors de l’exploitation de vos données… Cependant, si vous n’avez pas pu fermer l’accès aux données lors de votre export et que IMP soit incapable d’appliquer les contraintes référentielles car certaines données sont incohérentes, vous pouvez toujours demander à Oracle de ne pas tenir compte des contraintes pour les données existantes mais d’en tenir compte pour les futures insertions avec la commande suivante :

ALTER TABLE <table_name> CONSTRAINT <constraint_name> ENABLE NOVALIDATE;

Attention, ceci vous permettra sans doute de démarrer votre instance et d’ouvrir votre database mais, vous l’aurez compris, à n’utiliser qu’en cas de dernier recours car ici, forcément, certaines données sont maintenant orphelines … Danger !

La sauvegarde de tablespace à chaud permet au DBA de ne jamais stopper son instance de production et de ne jamais interrompre l’accès aux données (par exemple en mettant les tablespaces offline, ce qui enlève l’intéret de la sauvegarde à chaud).

Le principe est de provoquer un CHECKPOINT afin de s’assurer que tous les datafiles d’un tablespace sont synchronisés (au même niveau de SCN) et d’indiquer à Oracle qu’à dater de cet instant, les transactions provoquent des écritures dans les datafiles mais ceux ci ne sont plus synchronisés avec les datafiles des données en cours de sauvegarde, la sauvegarde est dite “incohérente”.

Lorsque la sauvegarde physique des fichiers de données d’un tablespace en mode “sauvegarde à chaud”, on l’indique à Oracle et celui-ci va alors synchroniser l’ensemble des fichiers de données de la database.

Les séquences suivantes suffisent à sauvegarder à chaud un tablespace T :

alter tablespace T begin backup;

host copy /data/madatabase/tablespaces/T/*.dbf
          /data/madatabasesau/sauvegardes/tablespaces/T/

alter tablespace T end backup;

Pendant la copie des datafiles (entre le begin backup et le end backup), les blocs Oracle d’un fichier de données ne sont donc pas automatiquement synchronisés avec les SCN présents dans les entêtes des mêmes fichiers de données.

L’état des tablespaces en cours de sauvegarde peut être visualisé grace à la vue v$backup.

Remarque: Lorsque un tablespace en cours de sauvegarde est solicité pour des mises à jour, des informations de récupérations supplémentaires sont alors stoquées dans les fichiers de journaux et les journaux archivés, ce qui peut provoquer un nombre très importants de fichiers journaux comparé à une production en mode normal. De plus, cette écriture supplémentaire peut altérer les performances globales de l’accès aux données de la database, c’est pour cela que ce mode de sauvegarde n’est pas recommandé.