LES DBLINK ORACLE : DESCRIPTION, CONFIGURATION ET UTILISATION (2ème PARTIE)

II - CREATION DES DBLINKS

Les privilèges nécessaires
Pour créer un dblink, l'utilisateur doit disposer de privilèges appropriés que nous récapitulons dans le tableau ci-dessous.

Privilège	Base de données	Requis pour
CREATE DATABASE LINK	locale	La création d'un dblink privé
CREATE PUBLIC DATABASE LINK	locale	La création d'un dblink public
CREATE SESSION	distante	La création de tous types de dblink

La requête qui suit permet à l'utilisateur de connaître les privilèges relatifs à la création des dblinks et disponibles pour l'utilisateur courant :
SQL> select distinct privilege "privileges de dblink" from role_sys_privs
SQL> where upper(privilege) in ('create session','create database link', 'create public database link') ;

Spécification des utilisateurs du dblink lors de la création
Un dblink définit toujours un chemin de communication depuis une base de données jusqu'à une autre. Quand une application utilise un dblink pour accéder à une base de données distante, Oracle établit une session de base de données dans la base distante au nom de la requête applicative locale.
La spécification d'utilisateur du dblink lors de la création répond à la question de savoir en tant que quel utilisateur Oracle l'utilisateur du dblink sera reconnu dans la base de données distante.
Trois possibilités s'offrent au créateur du dblink :
- indiquer que l'on souhaite se connecter à la base distante sous le même nom d'utilisateur Oracle que celui qui est déjà en cours dans la base locale. C'est ce que les anglais appellent "Current User database link". Cela se fait l'aide de l'option "CONNECT TO CURRENT_USER".
- indiquer de façon explicite le nom de l'utilisateur Oracle sous lequel on souhaite se connecter à la base distante. Ce nom est en général différent de celui déjà en cours dans la base de données locale. C'est ce que les anglais appellent "Fixed User Database Link".Cela se fait à l'aide de l'option "CONNECT TO IDENTIFIED BY "
- ne pas inclure les éléments d'identification et d'authentification d'utilisateur (ce que les anglais appellent les "credentials") dans la définition du dblink de sorte que ceux (les credentials) effectivement utilisés pour se connecter à la base distante puissent changer en fonction de l'utilisateur qui référence le dblink et de l'opération effectuée par l'application. Les anglais appellent cette possibilité "Connected User Database Link". Elle se met en œuvre en omettant la clause "CONNECT TO" avec la syntaxe suivante :
SQL> CREATE [SHARED] [PUBLIC] DATABASE LINK USING '' ;

Méthode de travail dans la définition d'un dblink

Hypothèses de travail :
- Base locale : pagenetdb1
- Base distante : pagenetdb2 avec nom global : db2.world
- Alias (nom de service réseau) de la base distante dans le tnsnames.ora du poste local : my_db2.world
Travail à faire : en utilisant pagenetdb1 comme database locale et pagenetdb2 comme database distance, créer et utiliser un dblink opérationnel.

Etapes de travail
1) Créer sur la base de données distante un utilisateur Oracle et lui attribuer les privilèges nécessaires. Appelons-le dbluser et attribuons lui le mot de passe pwdblu.
SQL> create user dbluser identified by pwdblu ;
SQL> grant dba to dbluser ;
SQL> grant unlimited tablespace to dbluser ;
SQL> alter user dbluser identified by pwdblu default tablespace userdata ;
SQL> alter user dbluser quota unlimited on USERDATA ;
SQL> connect dbluser/ pwdblu
2) Une fois connecté à la base distante, interroger la vue global_name pour trouver la valeur de global_name et faire "show parameter global" pour vérifier si global_names est positionné à TRUE.
SQL> connect dbluser
Password :
Connected.
SQL> select * from global_name ;
GLOBAL_NAME
-------------------------------------------------------------
db2.world
3) Sur la machine hébergeant la base de données locale, trouver le fichier tnsnames.ora qui devrait nous montrer les noms de service réseau (alias) des bases de données. Pour pagenetdb2, on devrait voir que l'alias est "my_db2.world".
4) Créer le dblink avec le même nom que celui de la base de données distante en s'assurant que l'on utilise le bon alias indiqué dans le fichier tnsnames.ora.
SQL> CREATE [PUBLIC] DATABASE LINK db2 CONNECT TO dbluser identified by pwdblu USING ' my_db2.world' ;
5) Exécuter une requête à travers le dblink sur la base db2 (à partir de la database db1) pour s'assurer que la création a eu lieu avec succès et que le nouveau lien est bien opérationel
SQL> select * from global_name@db2 ;
Il est à remarquer que si l'utilisateur décide d'appeler le dblink en cours de création dbl2db2 comme dans la commande SQL "CREATE [PUBLIC] DATABASE LINK dbl2db2 CONNECT TO dbluser identified by pwdblu USING ' my_db2.world' ;" et qu'il lance la requête ci-dessus il va obtenir le message d'erreur suivant :
ORA-02085: database link dbl2db2.world connects to db2.world

III - VISUALISATION DES INFORMATIONS RELATIVES AUX DBLINK

Informations relatives aux dblinks définis dans la database locale
Ces informations sont stockées dans le dictionnaire de données et peuvent être récupérées en interrogeant les vues DBA_DB_LINKS, ALL_DB_LINKS et USER_DB_LINKS. Nous les synthétisons dans le tableau ci-dessous.

Colonne	Quelles vues ?	Description
OWNER	Toutes sauf USER_*	L'utilisateur ayant créé le dblink. Si le lien est public, PUBLIC est indiqué.
DB_LINK	Toutes	Le nom du dblink
USERNAME	Toutes	Si la définition du lien contient un utilisateur fixé (fixed user), alors cette colonne affiche le nom d'utilisateur du "fixed user", sinon cette colonne affice NULL.
PASSWORD	Seules USER_*	Le mot de passe pour se loguer à la database distante.
HOST	Toutes	Le nom de service réseau utilisé pour se connecter à la database distante.
CREATED	Toutes	Date de création du dblink

Informations relatives aux connexions dblinks qui sont ouvertes
La vue v$dblink liste tous les dblinks ouverts dans la session de l'utilisateur, c'est-à-dire tous les dblinks avec la colonne IN_TRANSACTION positionnée à YES. En environnement RAC, il existe aussi la vue gv$dblink.
La table ci-dessous décrit brièvement le contenu de ces vues.

Colonne	Description
DB_LINK	Le nom du dblink
OWNER_ID	Le propriétaire du dblink
LOGGED_ON	Indique si une connexion est en cours sur le dblink
HETEROGENEOUS	Indique si le dblink est homohène (NO) ou hétérogène (YES).
PROTOCOL	Le protocole de communication pour le dblink
OPEN_CURSORS	Indique si des curseurs sont ouverts pour le dblink.
IN_TRANSACTION	Indique si le dblink est accédé dans une transaction qui n'a pas encore été validée ou annulée.
UPDATE_SENT	Indique s'il y avait une mise à jour sur le dblink.
COMMIT_POINT_STRENGHT	La "force" du point de validation des transactions utilisant le dblink.

Informations de sécurité relatives aux dblinks partagés
Sans entrer dans les détails, notons que les dblinks partagés sont souvent utilisés dans les environnements de configuration de serveurs partagés (multithreaded server environment – MTS). Un dblink paratagé est un dblink dans lequel de multiples utilisateurs du lien peuvent partager la même connexion réseau sous-adjacente.
La création d'un dblink paratagé se fait à l'aide du mot clé SHARED et de la clause AUTHENTICATED BY qui doit spécifier un utilisateur et mot de passe valide sur le système distant. D'où la syntaxe :
SQL> CREATE SHARED PUBLIC DATABASE LINK LFARO AUTHENTICATED BY dummy_user IDENTIFIED BY secret USING 'LFARO' ;

Lorsqu'un utilisateur quelconque se connecte à sa base locale en tant que scott/tiger et utilise et utilise le dblink que nous venons de créer, la séquence d'événements suivante va se produire :

1. Oracle s'authentifie à la base distante à l'aide de dummy_user/ secret en vue d'ouvrir le lien.
2. Ensuite Oracle tente de connecter l'utilisateur à la base de données distante à l'aide de scott/tiger.

Par ailleurs Oracle va stocker les informations scott/tiger et dummy_user/secret dans les colonnes USERNAME, PASSWORD, AUTHUSR et AUTHPWD de la table SYS.LINK$ respectivement. On remarquera au passage que le nom d'utilisateur et mot de passe fournis dans les clauses AUTHENTICATED BY et IDENTIFIED BY de la commande de création d'un dblink partagé sont renseignés dans les colonnes AUTHUSR et AUTHPWD
L'accès aux données de la table SYS.LINK$ est limité à l'utilisateur SYS, aux utilisateurs qui se connectent avec le privilège SYSDBA, aux comptes auxquels ont été attribué un privilège objet spécifique pour la table LINK$ et enfin aux comptes auxquels ont été attribué le privilège système SELECT ANY DICTIONARY.
Nous donnons ci-dessous, à titre indicatif, une requête faisant la jointure entre la vue DBA_DB_LINKS et SYS.LINK$ et fournit des informations idoines de liens et de mot de passe.
COL OWNER FORMAT A8
COL DB_LINK FORMAT A15
COL USERNAME FORMAT A8 HEADING "CON_USER"
COL PASSWORD FORMAT A8 HEADING "CON_PWD"
COL AUTHUSR FORMAT A8 HEADING "AUTH_USER"
COL AUTHPWD FORMAT A8 HEADING "AUTH_PWD"
COL HOST FORMAT A7 HEADING "SERVICE"
COL CREATED FORMAT A10
select distinct d.owner, d.db_link, d.username, l.password, l.authusr, l.authpwd, d.host, d.created
from dba_db_link d, sys.link$ l
where password is not null
and d.username = l.userid ;

IV - BIBLIOGRAPHIE
1°) Managing a distributed database - par Oracle – http://www.cs.umb.edu/cs634/ora9idocs/server.920/a96521/ds_admin.htm
2°) Note Metalink 1071984.6 : How to create private or Public database link – par Oracle – 25-oct-2005
3°) Note Metalink 117759.1 : Database link (dblink) troubleshooting – par Oracle – 17-mar-2003
4°) Note Metalink 117171.1 : Understanding and configuration of shared Database Link – par Oracle – 17-janv-2005
5°) Note Metalink 172421.1 : How to close and expire database link – par Oracle – 05-may-2004

LES DBLINK ORACLE : DESCRIPTION, CONFIGURATION ET UTILISATION (1ère PARTIE)

I – GENERALITES SUR LES DBLINK ORACLE
Un dblink ou database link (ou encore lien de base de données en français) est un objet de schéma qui fait qu'Oracle se connecte à une base de données distante pour y accéder à un objet. C'est donc un objet d'une base de données qui permet, entre autres, d'exécuter des requêtes sur une autre base de données, que cette dernière se trouve physiquement sur la même machine ou non.
Pour faire court, nous dirons qu'un dblink est un pointeur dans une base de données local qui permet à l'utilisateur d'accéder aux objets sur une base de données distante.
On distingue trois types de dblink :
- Les dblink privés ; c'est le type de dblink qui est créé par défaut lorsque l'utilisateur ne donne aucune précision sur le type, en particulier quand il ne précise pas le mot-clé PUBLIC lors de la création ;
- Les dblink publics ; lors de leur création, l'utilisateur précise le type par le mot-clé PUBLIC ;
- Les dblink globaux

La création des dblink comporte quelques contraintes que l'on ne peut bien appréhender qu'en ayant à l'esprit le fonctionnement de certains paramètres d'initialisation et vues du dictionnaire de données de la base de données distante.
Global_names est un paramètre d'initialisation dynamique de type booléen qui spécifie, lorsqu'il est positionné à 'true' sur la base de données distante, si un dblink doit avoir le même nom que la base de données à laquelle il connecte. Sa valeur par défaut est 'false'.
Global_name (attention : il n'y a pas de 's' à la fin) est une vue Oracle qui ne contient en général qu'une seule ligne et une seule colonne du même nom (global_name) donnant le nom global de la base de donnée.
Dans un système distribué de base de données, chaque base de données devrait avoir un nom global unique de base de données qui identifie de façon unique la base de données dans le système.
Un nom global de base de donnée comprend deux composants : un nom de base de données et un domaine. Le nom de base de données et le domaine sont déterminés par les paramètres DB_NAME et DB_DOMAIN comme indiqué dans le tableau qui suit :

Composant	Paramètre	Contraintes	Exemple
Nom de base	DB_NAME	Doit comporter huit caractères au plus.	pagenet
Domaine	DB_DOMAIN	Doit suivre les conventions standard d'internet	fr.oracle.com

Le paramètre DB_DOMAIN est important seulement lors de la création de la base de données lorsqu'il est utilisé, ensemble avec le paramètre DB_NAME, pour former le nom global de la base de données. A partir de ce moment le nom global de la base est stocké dans le dictionnaire de données. Après la création de la base de données, le changement du paramètre d'initialisation DB_DOMAIN n'a aucun effet sur le nom global de la base ou sur la résolution des noms de dblink. C'est pourquoi, pour changer le domaine dans un nom global de base de données, on doit utiliser impérativement la commande :
SQL> ALTER DATABASE RENAME GLOBAL_NAME TO nom_database.nom_domain;
Bien sûr, après un tel changement il est souhaitable de modifier le paramètre DB_DOMAIN pour qu'il reflète le changement opéré dans le nom de domaine avant le prochain redémarrage de la base.

Le nom que l'on peut donner à un lien sur la base de données locale dépend du fait que la base de données distante à laquelle on souhaite accéder a "forcé" le nommage global ou pas.
Pour déterminer si le nommage global est "forcé" sur une base de données, on peut, soit examiner le fichier de paramètres d'initialisation de la base, soit lancer la commande sql 'show parameter …' soit interroger la vue de performance dynamique v$parameter comme indiqué dans la requête qui suit :
SQL> col name format a12
SQL> col value format a6
SQL> select name, value from v$parameter where name='global_names' ;
Pour visualiser un nom global de base de données, on utilise la vue du dictionnaire de données GLOBAL_NAME avec la requête suivante :
SQL> select * from GLOBAL_NAME ;


Commande de création d'un dblink
La syntaxe SQL de création d'un dblink se présente comme suit :
SQL> CREATE [PUBLIC] DATABASE LINK nom_de_lien_de_base_de_données [CONNECT TO utilisateur_oracle IDENTIFIED BY mot_de_passe_utilisateur_oracle_distant] USING ' chaîne_de_base_de_données' ;
Où :
- On utilise l'option CONNECT TO si on veut accéder à la base distante avec un nom d'utilisateur oracle différent, c'est-à-dire pas le même qui est en cours dans la session de la base locale.
- nom_de_lien_de_base_de_données doit correspondre au nom de la base de données à laquelle le dblink se réfère, si le paramètre GLOBAL_NAMES vaut 'true'.
- chaîne_de_base_de_données est une chaîne de connexion SQL*NET valide trouvée dans le fichier tnsnames.ora.

Un exemple concret
Nous disposons d'une base locale appelée pagenetdb1 et nous souhaitons pouvoir nous connecter depuis cette base locale, à la base distante pagenetdb2. Aussi la définition du nom de service (alias) de la base distante dans le fichier tnsnames.ora de notre base locale se présente comme suit :
db2=
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=TCP)(HOST=machfde)(PORT=1543)
)
)
(CONNECT_DATA=
(SID=pagenetdb2)
)
)
Enfin les analyses sur la base distance donnent :
- db_name = pagenetdb2
- global_names=true
- global_name=pagenetdb2.world
Pour créer un dblink dans ce contexte, l'utilisateur pourra utiliser l'une des deux syntaxes suivantes de la commande "create database link" :
SQL> CREATE [PUBLIC] DATABASE LINK pagnetdb2 CONNECT TO scott IDENTIFIED BY tiger USING 'db2' ;
Ou
SQL> CREATE [PUBLIC] DATABASE LINK pagnetdb2 CONNECT TO scott IDENTIFIED BY tiger USING 'db2.world' ;

[ A SUIVRE ... ]

RESTAURATION D'UNE DB ORACLE (3ème PARTIE)

IV – ANNEXE – Exemple de travail
RMAN> connect target /
connected to target database: PAGENET (DBID=2093727724)
RMAN> list backup summary ;
using target database controlfile instead of recovery catalog
List of Backups
===============
Key TY LV S Device Type Completion Time #Pieces #Copies Tag
------- -- -- - ----------- --------------- ------- ------- ---
1356 B F A DISK 13/02/06 1 1
1365 B F A DISK 14/02/06 1 1
1366 B A A DISK 15/02/06 1 1 TAG20060214T220245
1367 B A A DISK 15/02/06 1 1 TAG20060214T220245
1368 B F A DISK 15/02/06 1 1 TAG20060214T220247
1369 B F A DISK 15/02/06 1 1 TAG20060214T220247
1370 B F A DISK 15/02/06 1 1 TAG20060214T220247
1371 B F A DISK 15/02/06 1 1 TAG20060214T220247
1372 B A A DISK 15/02/06 1 1 TAG20060214T220454
1373 B A A DISK 15/02/06 1 1 TAG20060214T220454
1374 B F A DISK 15/02/06 1 1
1375 B A A DISK 16/02/06 1 1 TAG20060215T220242
1376 B A A DISK 16/02/06 1 1 TAG20060215T220242
1377 B F A DISK 16/02/06 1 1 TAG20060215T220244
1378 B F A DISK 16/02/06 1 1 TAG20060215T220244
1379 B F A DISK 16/02/06 1 1 TAG20060215T220244
1380 B F A DISK 16/02/06 1 1 TAG20060215T220244
1381 B A A DISK 16/02/06 1 1 TAG20060215T220457
1382 B A A DISK 16/02/06 1 1 TAG20060215T220457
1383 B F A DISK 16/02/06 1 1
1384 B A A DISK 16/02/06 1 1 TAG20060216T220247
1385 B A A DISK 16/02/06 1 1 TAG20060216T220247
1386 B F A DISK 16/02/06 1 1 TAG20060216T220250
1387 B F A DISK 16/02/06 1 1 TAG20060216T220250
1388 B F A DISK 16/02/06 1 1 TAG20060216T220250
1389 B F A DISK 16/02/06 1 1 TAG20060216T220250
1390 B A A DISK 16/02/06 1 1 TAG20060216T220502
1391 B A A DISK 16/02/06 1 1 TAG20060216T220502
1392 B F A DISK 16/02/06 1 1

RESTAURATION D'UNE DB ORACLE (2ème PARTIE)

III - Restauration-récupération incomplète basée sur le temps d'une base Oracle à l'aide de RMAN
Plusieurs possibilités s'offrent à l'administrateur. Avant de les analyser, listons les. Il s'agit de :
- Restauration-récupération incomplète avec utilisation d'un fichier de contrôle provenant d'une sauvegarde (scénario 1) ;
- Restauration-récupération incomplète après désactivation de quelques jeux de sauvegarde (scénario 2) ;
- Restauration-récupération incomplète avec choix explicite du jeu de sauvegarde à utiliser (scénario 3) ;
- Restauration-récupération incomplète avec choix implicite du jeu de sauvegarde à utiliser (scénario 4) ;
Afin de rendre les explications qui vont suivre plus intelligibles, appuyons-nous sur un cas concret que nous avons rencontré en production.
Notre base de données (appelons-le pagenet) est sauvegardée (sauvegarde complète) tous les jours à 22h00. Le jeudi 16 février 2006 à 17h45, suite à un incident qu'un administrateur junior (donc non expérimenté) jugeait mineur, il refait une sauvegarde totale de la base. De l'analyse approfondie de l'incident, il ressort qu'il est dû à un chargement massif de données erronées dans la base de données.

Conclusion : il est urgent de restaurer la base de données en évitant d'utiliser la dernière sauvegarde totale faite par l'administrateur junior ou plus précisément en utilisant la sauvegarde totale faite le 16 février 2006 à 11heures00 après des travaux de maintenance. Toutes les sauvegardes totales comportent toujours une sauvegarde du fichier de contrôle et une sauvegarde du fichier d'initialisation SPFILE. L'identifiant de la base de données est DBID=2093727724.

Les développements qui suivent s'appuyent sur un exemple que le lecteur/internaute trouvera dans la 3ème partie intitulée "ANNEXE - EXEMPLE DE TRAVAIL".

III – 1) Scénario 1
Nous supposons que le jeu de sauvegarde (backupset) qui inclut le fichier de contrôle est le 1383. On peut trouver le nom du fichier correspondant à ce jeu de sauvegarde à l'aide de la commande RMAN list comme suit :
RMAN> list backupset 1383;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
1383 Full 18M DISK 00:00:01 16/02/06
BP Key: 1356 Status: AVAILABLE Tag:
Piece Name: /sauvebd/PAGENET/backup_ctl_c-2093727724-20060216-00
Controlfile Included: Ckp SCN: 308507599 Ckp time: 16/02/06
RMAN>

Après avoir arrêté la base de données, se connecter à la base et exécuter la séquence qui suit :
$ rman
RMAN> connect target /
RMAN> startup nomount ;
RMAN> set dbid 2093727724 ;
RMAN> run { restore controlfile from '/sauvebd/PAGENET/backup_ctl_c-2093727724-20060216-00' ;
alter database mount ;
set until time "to_date('16/02/2006 17:43:00', 'DD/MM/YYYY HH24:MI:SS')";
restore database ;
recover database ;
}
RMAN> alter database open resetlogs ;


III – 2) Scénario 2
Nous faisons l'hypothèse que l'administrateur ne souhaite pas procéder à la restauration à partir des jeux de sauvegarde de la sauvegarde la plus récente (la plus optimale du point de vue de RMAN). En ce qui concerne notre exemple de travail (voir en annexe), l'administrateur ne souhaite pas utiliser les jeux de sauvegarde dont les numéros vont de 1384 à 1392. Il va donc les désactiver en leur affectant le status "UNAVAILABLE (U) à l'aide de la commande RMAN "change backupset unavailable ;". La séquence de commandes donne ce qui suit :
$ rman
RMAN> connect target /
RMAN> startup mount ;
RMAN> change backupset 1384, 1385, 1386, 1387, 1388, 1389, 1390, 1391, 1392 unavailable ;
RMAN> run { set until time "to_date('16/02/2006 17:43:00', 'DD/MM/YYYY HH24:MI:SS')";
restore database ;
recover database ;
}
RMAN> alter database open resetlogs ;
Une fois la restauration effectuée, l'administrateur peut toujours réactiver les jeux de sauvegarde précédemment désactivés en tapant la commande suivante :
RMAN> change backupset 1384, 1385, 1386, 1387, 1388, 1389, 1390, 1391, 1392 available ;

III – 3) Scénario 3
En analysant bien notre exemple en annexe, le lecteur se rendra compte que tous les jeux de sauvegarde de datafiles d'une même sauvegarde ont le même tag ou étiquette. Le scénario 3 s'appuyera sur cette étiquette pour demande la restauration à partir d'une sauvegarde bien précise. Dans le cadre de notre exemple l'étiquette est TAG20060215T220244. Il en résulte la séquence qui suit :
$ rman
RMAN> connect target /
RMAN> startup mount ;
RMAN> run { set until time "to_date('16/02/2006 17:43:00', 'DD/MM/YYYY HH24:MI:SS')";
restore database from tag 'TAG20060215T220244' ;
recover database ;
}
RMAN> alter database open resetlogs ;

III – 4) Scénario 4
Il arrive parfois des situations dans lesquelles on peut aboutir au résultat escompté, rien qu'en jouant sur les dates au sens large du terme c'est-à-dire dates et heures. Appliquons ce scénario à notre contexte. Rappelons ledit contexte : une sauvegarde totale a eu lieu le 15/02/2006 à 22heures ; une autre a eu lieu le 16/02/2006 à 11heures et enfin la dernière a eu lieu le 16/02/2006 à 17h45.
Il est à noter que lorsque plusieurs sauvegardes totales sont faites dans la même journée, le champ "Completion time" du résultant de la commande RMAN "list" ne permet pas de les distinguer. Or il est capital de connaître les heures afin de s'assurer que l'on a bien choisi la bonne sauvegarde. Pour cela il vaut mieux interroger l'une des deux vues v$backup_piece ou v$backup_set. Voici deux exemples d'interrogations de ces vues
SQL> select recid, piece#, handle, to_char(completion_time, 'DD/MM/YYYY HH24:MI:SS') moment

SQL> from v$backup_piece where status = 'A'
SQL> and to_char(completion_time, 'DD/MM/YYYY') = '16/02/2006' ;

SQL> select recid, pieces, to_char(completion_time, 'DD/MM/YYYY HH24:MI:SS') moment,

SQL> backup_type
SQL> from v$backup_set

SQL> where to_char(completion_time, 'DD/MM/YYYY') = '16/02/2006' ;

Pour atteindre notre but il suffit de demande une restauration-récupération incomplète jusqu'à une minute avant la sauvegarde totale qui comporte les mauvaises données c'est-à-dire 17h44. Dans la mesure où la dernière sauvegarde totale (la mauvaise) n'existait pas le 16/02/2006 à 17:44, RMAN évitera automatiquement d'utiliser cette sauvegarde et utilisera celle qui l'a précédée. D’où la séquence de commandes RMAN suivante :
$ rman
RMAN> connect target /
RMAN> startup mount ;
RMAN> run { set until time "to_date('16/02/2006 17:44:00', 'DD/MM/YYYY HH24:MI:SS')";
restore database ;
recover database ;
}
RMAN> alter database open resetlogs ;

Il est important de noter aussi que la place de la commande set until time "to_date('16/02/2006 17:44:00', 'DD/MM/YYYY HH24:MI:SS')"; est cruciale dans la séquence. Si cette commande était placée après la commande "restore database ; ", on aurait eu un superbe message d'erreur. En effet, n'ayant pas de "until time" pour la commande restore, RMAN aurait sélectionné la sauvegarde de 17h45 (l'optimale), mais quand il va aborder la commande "recover database ;", RMAN va se rendre compte qu'on lui demande l'impossible ou plus exactement, qu'on lui demande une récupération pas en cohérence avec la restauration qu'elle vient de faire. D'où le message d'erreur.

A SUIVRE ...

RESTAURATION D'UNE BD ORACLE A L'AIDE DE RMAN (1ERE PARTIE)

I - Introduction
En cas de panne sévère ou d'erreur grossière d'utilisateur (par exemple chargement de données de masse erronées dans une base de données, l'administrateur d'une base de données Oracle est souvent amené à faire une restauration-récupération incomplète de la base. Et RMAN (Oracle Recovery Manager) est un outil qui facilite les gestes techniques à faire dans le cadre de la gestion des sauvegardes et restaurations de ces bases de données.
Rappelons que RMAN permet de faire une récupération de la base de données entière avec les trois options suivantes :
- récupération jusqu'à un moment non-courant à spécifier (restauration-récupération basée sur le temps –time-based recovery);
- récupération jusqu'à un SCN (System Change Number) à spécifier (restauration-récupération basée sur un SCN – change-based recovery);
- récupération jusqu'à un numéro de log sequence à spécifier (restauration-récupération basée sur une séquence – sequence-based recovery).
Les développements que nous faisons dans cette série d'articles concernent en grande partie la première option c'est-à-dire la récupération jusqu'à un moment non-courant.
Après un bref rappel sur la restauration-récupération complète d'une base de données Oracle, nous analyserons les possibilités offertes à l'administrateur pour effectuer une restauration-récupération incomplète basée sur le temps.
Dans la rubrique "Restrictions et notes d'usage" de la commande restore, Oracle précise ceci :
"RMAN ne sauvegarde ni ne restaure les tablespaces temporaires gérés localement, bien qu'il puisse sauvegarder et restaurer les tablespaces temporaires gérés à l'aide du dictionnaire.
Par ailleurs, Oracle précise qu'après la restauration d'une sauvegarde de fichier de contrôle, les entrées pour les tempfiles dans les tablespaces temporaires gérés localement sont supprimées. De ce fait on doit ajouter de nouveaux tempfiles à ces tablespaces après ouverture avec l'option RESETLOGS. Sinon Oracle peut afficher l'erreur suivante lors de tentative de tri : ORA-25153: Temporary Tablespace is empty.


II - Restauration-récupération complète d'une base Oracle à l'aide de RMAN
Voici un exemple pratique avec une base de données dont le fichier de contrôle sert aussi de référentiel pour RMAN.
$ rman
RMAN> connect target /
RMAN> startup mount
RMAN run { restore database ;
recover database ;
}
RMAN> alter database open resetlogs ;

Il est à noter que dans le genre de restauration-récupération ci-dessus, RMAN choisit toujours le jeu de sauvegarde optimal qui est dans presque tous les cas le plus récent, ce qui peut ne pas être le souhait de l'administrateur. Nous verrons dans la 2ème partie qui va suivre comment l'administrateur peut choisir le jeu de sauvegarde qu'il souhaite restaurer et récupérer.

Je vous remercie d'avance pour tous vos commentaires.