Tuesday, March 21, 2006

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ègeBase de donnéesRequis pour
CREATE DATABASE LINKlocaleLa création d'un dblink privé
CREATE PUBLIC DATABASE LINKlocaleLa création d'un dblink public
CREATE SESSIONdistanteLa 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.


ColonneQuelles vues ?Description
OWNERToutes sauf USER_*L'utilisateur ayant créé le dblink. Si le lien est public, PUBLIC est indiqué.
DB_LINKToutesLe nom du dblink
USERNAMEToutesSi 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.
PASSWORDSeules USER_*Le mot de passe pour se loguer à la database distante.
HOSTToutesLe nom de service réseau utilisé pour se connecter à la database distante.
CREATEDToutesDate 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.

ColonneDescription
DB_LINKLe nom du dblink
OWNER_IDLe propriétaire du dblink
LOGGED_ONIndique si une connexion est en cours sur le dblink
HETEROGENEOUSIndique si le dblink est homohène (NO) ou hétérogène (YES).
PROTOCOLLe protocole de communication pour le dblink
OPEN_CURSORSIndique si des curseurs sont ouverts pour le dblink.
IN_TRANSACTIONIndique si le dblink est accédé dans une transaction qui n'a pas encore été validée ou annulée.
UPDATE_SENTIndique s'il y avait une mise à jour sur le dblink.
COMMIT_POINT_STRENGHTLa "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

1 Comments:

At 4:37 PM, Blogger SueIsFine said...

Merci pour vos explications :)

 

Post a Comment

<< Home