ORACLE 10G DISTRIBUTION ET REPLICATION Distribution de données avec Oracle G. Mopolo-Moké prof. Associé UNSA 2009/ 2010 1
Plan 12. Distribution de données 12.1 Génération des architectures C/S et Oracle 12.2 Les douze règles de Date et Oracle 12.3 Nommage des objets en environnement réparti 12.4 Liaison entre BD Oracle 12.5 Manipulation de données réparties 12.6 Le commit à deux phases 2
12.1 Génération des architectures C/S et Oracle Architecture fonctionnelle de développement d'application [MIR 94] Interface Application SGBD {GUI, Objets} {L3G, L4G, CASE,...} {SQL 1-2-3...} Base de données 3
12.1 Génération des architectures C/S et Oracle Générations d'architectures C/S [MIR 94] C L I E N T Interface Interface Interface Application Interface Application Interface Application SGBD Réseau : RPC, RDA, DRDA S E R V E U R Interface Application SGBD BD répartition du dialogue Application SGBD BD déport de dialogue Commit à 2 phases Moniteurs TP Application SGBD BD Application répartie SGBD BD déport gestion de données Interface Application SGBD BD SGBD repartie hétérogène 4
12.1 Génération des architectures C/S et Oracle Solution Oracle Interface Client 1 Interface Client N Application Oracle Application Oracle Driver SQL*NET Protocole de communication Driver SQL*NET Protocole de communication Protocole de communication Driver SQL*NET Noyau Oracle 5
12.1 Génération des architectures C/S et Oracle Solution Oracle (suite) Client Client Client Serveur SGBD ORACLE Serveur SGBD ORACLE SQL*NET SQL*NET Réseau Note :. SQL*Net : multiprocole Oracle gateways Client Serveur SGBD NON ORACLE 6
12.2 Les douze règles de Date et Oracle Les douze règles de Date et Oracle Règles de Date R1: Autonomie locale, gestion locale des données, contrôle local des contraintes et de la sécurité Oracle OK R2: Indépendance vis à vis d'un site central OK R3: Fonctionnement continue OK mais R4: Indépendance de la localisation Database link/ synonyme R5: Indépendance de la fragmentation OK mais R6: Indépendance de la duplication OK voir triggers R7: Traitement reparti des requêtes OK R8: Gestion répartie des transactions Commit à 2 phases R9: Indépendance vis à vis du matériel OK N plates-formes R10: Indépendance vis à vis de l'os OK R11: indépendance vis à vis du réseau Multi-protocôle R12:Indépendance vis à vis du SGBD gateways mais 7
12.3 Nommage des objets en environnement réparti Nommage des objets en environnement réparti BD Distribuée Base de données 1 Schéma 1 : SCOTT DEPT, EMP... dblink Base de données N Schéma 1 : SCOTT DEPT, EMP Schéma N Schéma N tables, vues, table 1, table 2, index,... index,... Niveau de désignation d'objets schéma Base de données locale Base de données distante Désignation nom_de_l'objet exemple : emp, dept,... dans le schéma SCOTT schéma.nom_objet exemple : SCOTT.emp, SCOTT.dept,... schéma.nom_objet@chaîne_connection exemple : (sqlnet) SCOTT.emp@dblink dblink : nom d'un lien 8
12.4 Liaison entre BD Oracle Les Database Links Oracle utilise la notion de DATABASE LINK pour faciliter la connexion à une base de données distante Un DATABASE LINK est un chemin unidirectionnel d une base locale vers une base distante Un DATABASE LINK peut être PRIVE, PUBLIC ou GLOBAL Un database link privé n est accessible que par l utilisateur qui l a créé. Il appartient au créateur Un database link public est accessible par tous les utilisateurs et les procédures stockées. Il appartient à l'utilisateur PUBLIC Un database link global est accessible par tous les utilisateurs via l annuaire LDAP Un database link peut être partagé (SHARED). Plusieurs utilisateurs peuvent partager la même connexion avec ledit database link 9
12.4 Liaison entre BD Oracle Les Database Links Il est existe trois types de database link. Ils sont désignés selon le mode d'authentification sur la base distante choisi : Connected user database link : Le compte et le mot de passe de l'utilisateur connecté doivent être les mêmes sur la base locale et distante Le paramètre d initialisation REMOTE_OS_AUTHENT doit être fixé à TRUE pour permettre aux utilisateurs authentifiés EXTERNALLY de se connecter Fixed user database link : L utilisateur qui se connecte utilise le nom d utilisateur et le mot de passe fixé lors de la création du database link derrière CONNECT TO CURRENT_USER database link : L utilisateur connecté doit avoir un compte sur la base locale et sur la base distante. S il s agit d une procédure stockée, l utilisateur propriétaire doit aussi être créé dans la base distante. L utilisateur doit être reconnu au niveau du serveur de sécurité d'oracle. Annuaire ldap 10
12.4 Liaison entre BD Oracle Nommage d un database link On peut attribuer à un database link le nom global de la base ou un nom quelconque Pour forcer l attribution d un nom global, le paramètre d initialisation GLOBAL_NAMES doit être posé à TRUE L attribution d un nom global a pour avantage de faciliter le fonctionnement de certaines options d Oracle telle que la réplication. Oracle recommande, d'utiliser le nom global de la base. Si GLOBAL_NAMES vaut TRUE Oracle contrôle le nom global en combinant les paramètres DB_NAME et DB_DOMAIN Exemple si DB_NAME=DBTEST et DB_DOMAIN=UNICE.FR, le nom global de la base sera DBTEST.UNICE.FR, ce sera aussi le nom du database link 11
12.4 Liaison entre BD Oracle Les Database Links Création d'un DATABASE LINK Syntaxe CREATE [SHARED] [ PUBLIC ] DATABASE LINK nom_lien [ {CONNECT TO {CURRENT_USER user IDENTIFIED BY password } } ] AUTHENTICATED BY user IDENTIFIED BY passwd [ USING 'chaîne_de_connexion' ] Notes : a) si CONNECT TO est absent c'est le mot de passe et le nom connecté qui sont utilisés b) Il faut avoir le privilège CREATE DATABASE LINK (lien privé) et CREATE PUBLIC DATABASE LINK (lien public) =>L'utilisateur de la base locale QUI ACCEDE AUX DONNEES D'UNE BASE DISTANTE A TRAVERS UN DB LINK doit exister sur la base distante 12
12.4 Liaison entre BD Oracle Les Database Links Création d'un DATABASE LINK Mots clés ou paramètre Description SHARED nom_lien Permet de partager entre plusieurs utilisateurs la connexion avec le même db link. Oblige d'utiliser la clause CONNECT TO et AUTHENTICATED Nom du lien CONNECT TO... Indique le nom et mot de passe de IDENTIFIED BY l'utilisateur sur la base distante Si cette clause n'est pas utilisée alors c'est le nom et le password de l'utilisateur connecté qui sont utilisés PUBLIC chaîne_de_connexion Lien utilisable par tout utilisateur Chaîne de connexion la base distante AUTHENTICATED BY Permet d'authentifier un utilisateur via le serveur de sécurité (annuaire) CURRENT_USER Permet de créer un db link authentifié avec l'utilisateur courant. Si l'objet utilisant le db link est une procédure stockée, il s'agit de l'utilisateur propriétaire de la procédure. Sinon il s'agit de l'utilisateur connecté. Cet utilisateur doit être reconnu au niveau du serveur de sécurité d'oracle. Ce doit être un utilisateur GLOBAL (LDAP) 13
12.4 Liaison entre BD Oracle Les Database Links Création d'un DATABASE LINK Exemple 1 : Public Connected user database link CREATE PUBLIC DATABASE LINK dbtest.unice.fr USING 'DBTEST'; Utilisation de ce DATABASE LINK sql> connect scott/tiger@orcl; sql> Select * from emp@dbtest.unice.fr ; L utilisateur scott doit exister sur la base locale ORCL et la base distante DBTEST avec le même mot de passe Scott de orcl peut consulter les tables de l'utilisateur scott de la base de données dbtest (y compris celles pour lesquelles il a des droits) Le user XXX de orcl ne peut accéder qu'aux objets accessibles par le user XXX de dbtest 14
12.4 Liaison entre BD Oracle Les Database Links Création d'un DATABASE LINK Exemple 2 : Public Fixed user database link CREATE PUBLIC DATABASE LINK dbtest.unice.fr CONNECT TO scott IDENTIFIED BY tiger USING 'dbtest'; Utilisation de ce DATABASE LINK sql> connect scott/tiger@orcl; sql> Select * from emp@dbtest.unice.fr ; L authentification est faite dans le lien. L'utilisateur scott doit exister dans les 2 bases y compris avec des password différents 15
12.4 Liaison entre BD Oracle Les Database Links Création d'un DATABASE LINK Exemple 3 : CURRENT_USER database link CREATE PUBLIC DATABASE LINK dbtest.unice.fr CONNECT TO CURRENT_USER USING 'dbtest'; Utilisation de ce DATABASE LINK sql> connect scott/tiger@orcl; sql> Select * from emp@dbtest.unice.fr ; =>L'utilisateur d'authentification du database link doit être défini dans l'annuaire LDAP 16
12.4 Liaison entre BD Oracle Les Database Links Création d'un DATABASE LINK Exemple 4 : Private Fixed user database link sql> connect system/manager@orcl; sql > grant create database link to scott; sql> connect scott/tiger@orcl; CREATE DATABASE LINK dbtest.unice.fr CONNECT TO scott IDENTIFIED BY tiger USING 'dbtest'; Utilisation de ce DATABASE LINK sql> connect scott/tiger@orcl; sql> Select * from emp@dbtest.unice.fr ; =>L authentification est faite avec le nom et mot de passe de l'utilisateur CONNECTE. Ici SCOTT. 17
12.4 Liaison entre BD Oracle Les Database Links Création d'un DATABASE LINK Exemple 5 : shared public fixed database link sql> connect system/oraclesysdba@orcl; CREATE shared public DATABASE LINK dbtest.unice.fr CONNECT TO scott IDENTIFIED BY tiger AUTHENTICATED BY system IDENTIFIED BY oraclesysdba USING 'dbtest'; Utilisation de ce DATABASE LINK sql>connect scott/tiger@orcl; sql> Select * from emp@dbtest.unice.fr ; Attention : L authentification est faite via la clause AUTHENTICATED BY. Toutefois les droits sur les objets seront ceux de scott et non system. Un shared database link permet de MULTIPLEXER LES CONNEXIONS La clause AUTHENTICATED BY est obligatoire 18
12.4 Liaison entre BD Oracle Les Database Links Suppression d'un DATABASE LINK Syntaxe DROP [PUBLIC] DATABASE LINK nom_lien; Exemple DROP PUBLIC DATABASE LINK dbtest.unice.fr; s il s agit d un Database link public. ou DROP DATABASE LINK dbtest.unice.fr; s il s agit d un Database link privé. 19
12.4 Liaison entre BD Oracle Transparence vis à vis de la localisation de données Mis en oeuvre sous Oracle grâce aux notions de VUE, SYNONYM et de DATABASE LINK règle 4 de DATE permet de réaliser des applications évolutives Exemple de Transparence de localisation via les Synonymes CREATE PUBLIC SYNONYM emp FOR emp@dbtest.unice.fr ; Utilisation du Synonyme sur des objets distants sql>select * FROM emp; au lieu de sql>select * FROM emp@dbtest.unice.fr ; Note : la transparence peut aussi être assurée via des vues et des procédures stockées 20
12.4 Liaison entre BD Oracle Transparence vis à vis de la localisation de données Exemple de Transparence de localisation via les vues CREATE view emp as select * from emp@dbtest.unice.fr ; Utilisation de la vue sur des objets distants sql>select * FROM emp; au lieu de sql>select * FROM emp@dbtest.unice.fr ; Note : la transparence peut aussi être assurée via des synonymes et des procédures stockées 21
12.4 Liaison entre BD Oracle Transparence vis à vis de la localisation de données Exemple de Transparence de localisation via les procédures stockées CREATE OR REPLACE PROCEDURE delete_emp (id number ) is BEGIN DELETE FROM emp@dbtest.unice.fr WHERE empno=id; END; / Utilisation de la procédure stockée sur des objets distants sql>execute delete_emp(7470); Note : la transparence peut aussi être aussi assurée via des synonymes et des vues 22
12.4 Liaison entre BD Oracle Limitation du nombre de databases link avec le paramètre OPEN_LINKS Le paramètre d initialisation OPEN_LINKS permet de contrôler le nombre de database link Par défaut OPEN_LINKS vaut 4 Si OPEN_LINKS=0 alors pas de connexion distribué à partir de cette base 23
12.4 Liaison entre BD Oracle Les informations sur les database link Les vues suivantes contiennent des informations sur les DB LINK : DBA_DB_LINKS,ALL_DB_LINKS, USER_DB_LINKS Contiennent les informations sur les Databases links V$DBLINK : Databases links ouverts Principales colonnes des vues *_DB_LINKS DB_LINK : nom du lien USERNAME : utilisateur si fixed user db link HOST : chaîne de connexion CREATED : date de création 24
12.5 Manipulation de données réparties Il est possible d'effectuer des consultations et des mises à jour en environnement réparti. Les actions possibles sont : Consultation d'une base distante Consultation répartie sur plusieurs bases distantes Mise à jour sur une base distance Mise à jour répartie sur plusieurs bases distantes Consultation et mise à jour sur une base distante Consultation et mise à jour répartie sur plusieurs bases distantes 25
12.5 Manipulation de données réparties Les commandes SQL autorisées SELECT SELECT... FOR UPDATE UPDATE INSERT DELETE LOCK TABLE SET TRANSACTION READ ONLY ANALYZE CREATE TABLE AS SELECT COMMIT, ROLLBACK, SAVEPOINT Les commandes interdites Commandes du LDD (CREATE TABLE, INDEX,..., DROP..., ALTER..., ) 26
12.5 Manipulation de données réparties Consultation et mise à jour sur un site distant Site 1 (Instance ORCL) Lien vers SCOTT : DBTEST.UNICE.FR ord schéma de SCOTT Ordre SQL Résultat Site 2 (Instance DBTEST) emp dept ord schéma de SCOTT Etapes de traitement de l'ordre 1. L'ordre SQL d'insertion ou de sélection est envoyé au SITE distant. 2. Un résultat est renvoyé au Site émetteur. Exemple sql>select * FROM SCOTT.emp@DBTEST.UNICE.FR ; sql> SELECT empno, ename FROM SCOTT.emp@DBTEST.UNICE.FR ; sql> UPDATE SCOTT.ord@DBTEST.UNICE.FR set...; 27
12.5 Manipulation de données réparties Consultation et mise à jour multi-sites Site 2 (instance DBTEST) ordre SQL Site 1 (Instance ORCL) Lien vers SCOTT : DBTEST.UNICE.FR Lien vers SCOTT : orcl11g Résultat emp ord schéma de SCOTT ord schéma de SCOTT... Client X ordre SQL Résultat SELECT empno, ename,dname FROM SCOTT.dept@orcl11g l, SCOTT.emp @DBTEST.UNICE.FR t WHERE l.deptno=t.deptno ; Site N (instance ORCL11G) dept schéma de SCOTT UPDATE SCOTT.emp@dbtest.unice.fr... ; UPDATE SCOTT.dept@orcl11g... ; INSERT INTO ord... ; COMMIT ; 28
12.5 Manipulation de données réparties Consultation et mise à jour multi-sites Etapes de traitement de l'ordre 1. Le client soumet ses ordres à son site local (exemple SITE 1) 2. Son site local éclate si nécessaire les requêtes et les dispatche à chaque site intéressé 3. chaque site distant traite (exécute) l'ordre et renvoi le résultat au site local initiateur 4. A la réception des résultats, le site local les fusionne si nécessaire 5. Un résultat est renvoyé à l'utilisateur. En cas d'erreur en mise à jour distribuée, l'utilisateur doit procéder à des annulations. 29
12.6 Le commit à deux phases Notion de transaction Une transaction est un ensemble d'ordres SQL (distante, répartie ou non) qui doivent s'exécuter en totalité ou jamais une transaction (répartie, distante ou non) se termine par un COMMIT ou un ROLLBACK une transaction (répartie, distante ou non) peut être découpée en points de sauvegarde SAVEPOINT et des ROLLBACK TO SAVEPOINT sont possibles Afin d'assurer la validation ou l'annulation correct d'une transaction répartie, Oracle implémente le mécanisme de COMMIT à deux phases (phase de préparation du COMMIT et phase de validation du COMMIT) Le mécanisme de COMMIT à deux phases est transparent pour les utilisateurs!!! 30
12.6 Le commit à deux phases Les différentes types de sites SELECT empno, ename,dname FROM SCOTT.dept@orcl11g l, SCOTT.emp @dbtest.unice.fr t WHERE l.deptno=t.deptno ; UPDATE SCOTT.emp@dbtest.unice.fr... ; UPDATE SCOTT.dept@orcl11g... ; INSERT INTO ord... ; Commit; -- commit à deux phase Site Coordinateur ORCL Site client Site coordinateur global Site de validation Site serveur de données Site Distant 1 DBTEST Site serveur de données Site Site distante 2 ORCL11G Site serveur de données 31
12.6 Le commit à deux phases Les différentes types de sites Site coordinateur global Site qui initialise la transaction distribuée Site coordinateur local Site forcé à référencer les données d autres sites pour compléter sa partie de transaction Site serveur de données Site qui reçoit une demande de données d un autre site Site de validation Site qui assure un commit ou un rollback à la demande du nœud coordinateur. Site client Site référençant des données existant dans d autres sites 32
12.6 Le commit à deux phases Le site de validation N attend pas la phase de préparation C est le site contenant les données les plus critiques Le commit est immédiat et les données ne peuvent rester en attente de validation en cas de panne Le paramètre COMMIT_POINT_STRENGTH permet de désigner le site de validation prioritaire. Le site ayant la valeur la plus grande doit commiter en premier 33
12.6 Le commit à deux phases Schéma fonctionnel Prêt à commiter/ Annuler? 2 OUI/NON Prêt à commiter/ 1 Annuler? 1 Site Coordinateur OUI/NON 2 3 3 Validation / Annulation Validation / Annulation Site distant 1 Site distant 2 34
12.6 Le commit à deux phases Traitement des pannes des pannes peuvent survenir lors d'une transaction répartie (en préparation ou validation) : panne logiciel, panne matériel, panne réseau Oracle résout automatiquement ces pannes grâce : au process background RECO (paramètre Distributed_Transaction) aux tables des transactions en attentes Les vues suivantes donnent des informations sur les transactions en suspend : DBA_2PC_PENDING : informations sur les transactions réparties DBA_2PC_NEIGHBORS : noeuds impliqués dans des transactions douteuses En cas de Problèmes insolubles dans les temps. La transaction doit être finie manuellement : chaque DBA récupère l'identité de la transaction (*_2pc*) et fait COMMIT ROLLBACK FORCE 'ID_TRANS' 35
12.6 Le commit à deux phases Simulation de pannes : Pour simuler une panne d'une transaction répartie, Oracle propose d'exploiter l'option COMMENT de l'ordre COMMIT. COMMIT COMMENT 'ORA-2PC-CRASH-TEST-N'; N est le numéro de la panne à simuler il faut pour cela désactiver la restauration distribuée sql>alter SYSTEM DISABLE DISTRIBUTED RECOVERY; Liste des Numéros de Pannes 1 panne d'un site en transaction (commit point site) après collecte 2 panne d'un site non en transaction après collecte 3 panne avant la phase de préparation 4 panne après la phase de préparation 5 panne du commit point site avant la phase de validation 6 panne d'un site en transaction après le Commit 7 panne d'une site non en transaction avant le Commit 8 panne d'un site non en transaction après la phase de validation 9 panne d'un site en transaction après la phase ignorer 10 panne d'un site non en transaction avant la phase ignorer 36