bdrep.pdf
TRANSCRIPT
BD réparties Michel Tuffery 2
BDR : Définition
• Ensemble de bases de données gérées par des sites différents et apparaissant à l’utilisateur comme une base unique
• Les 4 universités Toulousaines :
USS
UPS
INP
UTMSELECT * FROM etudiant
WHERE date_naissance=1994;
BD réparties Michel Tuffery 3
Architecture d’une BD répartie
donnéesGérant de
réparties
Gérant de
communication
Gérant d’applications
SGBD SGBD
Gérant de
communication donnéesGérant de
réparties
Gérant d’applications
Site 1
Base 1
Site 2
Base 2
Réseau
BD réparties Michel Tuffery 4
Fonctions d’un SGBD réparti
• Gestion d’un dictionnaire de données global– Dictionnaire centralisé, dupliqué ou réparti
• Définition des données réparties• Règles de localisation des données
réparties• Évaluation des requêtes réparties – optimisation
• Gestion des transactions réparties– COMMIT réparti – Graphe local des transactions réparties
BD réparties Michel Tuffery 5
Comparatif Client-Serveur et BD répartie
BD REPARTIECLIENT – SERVEUR
1 COMMIT généraliséPlusieurs COMMIT mono-base
Synchronisation automatique des n sous-transactions
Synchronisation des transactions dans l’application
1 transaction logiqueN transactions mono-base
1 ordre SQL plusieurs BD1 ordre SQL 1 seule BD
Règles de localisation dans le dictionnaire
Règles de localisation dans l’application
Indépendance à la localisationLocalisation explicite des bases (‘connect string’ ou DSN)
Une seule connexionPlusieurs connexions
Une base logique vue par le client
Plusieurs bases vues par le client
BD réparties Michel Tuffery 6
Les 12 règles d’un SGBD
• (1) Autonomie locale• (2) Pas de site fédérateur• (3) Exploitation en continue• (4) Indépendance à la localisation• (5) Règles de fragmentation• (6) Duplications multiples• (7) Requêtes distribuées• (8) Transactions distribuées• (9) Indépendance du matériel• (10) Indépendance des systèmes d’exploitation• (11) Indépendance du réseau• (12) Indépendance du SGBD
BD réparties Michel Tuffery 7
(1) Autonomie locale
• Les données locales sont gérées localement• Administration locale des données locales• Site autonome pour ses propres opérations• L’administration de la BDR est décentralisée
– Administrateurs locaux coordonnés– Pas d’administration globale– Possibilité d’autoriser ou non un accès réparti à une
base locale– Accès local possible simultanément aux accès répartis
BD réparties Michel Tuffery 8
(2) Pas de site fédérateur
• Pas de dépendance d’un site par rapport à un autre
• Avantages :– Architecture non vulnérable en cas de panne– Pas de goulot d’étranglement
• Inconvénients :– Pas de contrôle centralisé des accès concurrents– Pas de dictionnaire central– Pas de ‘recovery’ central– Pas d’exécution des requêtes centralisée
BD réparties Michel Tuffery 9
• Pas d’arrêt de la BDR pour la modification d’un site– Modification de la structure d’une BD locale (LDD)– Modification d’un SGBD (Release, Upgrade, …)
• Extensibilité– Ajout, suppression ou modification d’un site– Opération locale et non globale (règle 1)– Propriété importante : évolution permanente
(3) Exploitation en continue
BD réparties Michel Tuffery 10
(4) Indépendance à la localisation
• Objectif le plus important : changement de la localisation des données sans changer les programmes
• Nécessité d’un dictionnaire réparti• Avantages attendus :
– Illusion, pour l’utilisateur, de travailler sur un seul site avec BD centralisée
– Évolution des règles de localisation sans impact sur l’application
– Invisibilité du ou des réseaux (règle 11)• Inconvénient majeur :
– Attention aux performances après un changement de localisation de données
BD réparties Michel Tuffery 11
(5) Règles de fragmentation
• Découpage d’une relation pour des raisons fonctionnelles
• Mémorisation des règles de localisation (optimisation des requêtes)
• Transparent pour l’utilisateur• Trois types de fragmentation
– Horizontal, Vertical et Mixte• Opérateurs SQL utilisés
– projection et restriction pour fragmenter– UNION et JOINTURE pour reconstituer
BD réparties Michel Tuffery 12
Fragmentation horizontale
ETUDIANT_L
ETUDIANT_M
ETUDIANT_D
ETUDIANT
Projection et Sélection
UNION
BD réparties Michel Tuffery 13
Fragmentation verticale
ETUDIANTSCOLARITE
STAGE
PROJECTION
JOINTURE
• Duplication de la clé primaire sur chaque fragment
BD réparties Michel Tuffery 14
Fragmentation mixte
EMPLOYENOM AGE NO SAL DPT
E1 ( NO, SAL, DPT)
E2 (NOM, AGE, NO) AGE<=30
E3 (NOM , AGE, NO) AGE>30E1
E2
E3
• Prise en compte des règles de fragmentation pour optimiser les requêtes :
• SELECT …. FROM e3 WHERE …. AND age <28• SELECT e3.* FROM e2,e3 WHERE e2.no=e3.no
BD réparties Michel Tuffery 15
Fragmentation : construction de la BDR
• Construction descendante : la base centralisée est distribuée sur plusieurs sites (BDD)– C’est le cas le plus fréquent– La base centralisée devient trop importante : elle est
distribuée avec des règles• Construction ascendante : les diverses bases
locales sont restructurées et assemblées, la base est répartie sur plusieurs sites (BDR)– Cas du rachat ou du regroupement d’entreprises– Principe : "ne pas dupliquer les données"
BD réparties Michel Tuffery 16
Faire une bonne fragmentation
• Horizontale – Fragments (prédicats) disjoints– Fréquence d’accès uniforme (complétude) aux
fragments• Verticale
– Regroupement des attributs accédés souvent ensemble– Calcul de "l’affinité" entre deux attributs
BD réparties Michel Tuffery 17
(6) Duplications multiples(indépendance à la localisation)
• Duplication des données sur des sites distants
• Gain de temps pour les accès en lecture (interdit en modification) augmentation des performances
• Mises à jour par rafraîchissements périodiques à partir du site qui possède le fragment initial
• Inconvénient : pas de mise à jour immédiate • Intéressant pour les données stables
BD réparties Michel Tuffery 18
Duplication : le principe des clichés ou "snapshots"
• Duplication en "cohérence faible"• Rafraîchissements périodiques• Plusieurs solutions techniques
– "estampillage" des lignes modifiées avec la date et heure de sa dernière MAJ
– Utilisation d’une "table différentielle" contenant uniquement les lignes modifiées
• Oracle a choisi la deuxième technique avec un "journal" de transactions sur le fragment initial (voir plus loin)
BD réparties Michel Tuffery 19
(7) Requêtes distribuées
• Évaluation des requêtes distribuées ou réparties plan d’exécution réparti
• Le SGBD comprend que la requête traite avec des objets physiques distants
• La requête est reconstruite en tenant compte de la localisation des objets
• Les opérateurs de restriction (sélection, projection) qui réduisent la taille sont appliqués au plus tôt
• Utilisation du parallélisme
BD réparties Michel Tuffery 20
Évaluation d’une requête répartie
DECOMPOSITION SQL ALGEBRE
LOCALISATION
OPTIMISATION
EXECUTION
Reconstruction de la requête avec le dictionnaire réparti
Ordonnancement et algorithme d’accès :
règles de localisation
choix du site de transfert
semi - jointure
BD réparties Michel Tuffery 21
Optimisation d’une requête répartie :la semi - jointure
Site 3 : Ouvrage (IdOuv, titre, ….)
Site 2 : Emprunt (IdCli,IdOuv, ….)
Site 1 : Client (IdCli, nomcli, ….)
SELECT c.nomcli, o.titre FROM client c, emprunt e, ouvrage o WHERE c.idcli=e.idcli AND e.idouv=o.idouv AND c.adrcli=‘Tlse’ AND o.auteur=‘Michel’;
BD réparties Michel Tuffery 22
Requête répartie avec jointures
Client (Site 1)
Sélection adrcli=‘Tlse’ Emprunt (Site 2)
Ouvrage (Site 3)
Jointure (Site 2)
Sélection auteur=‘Michel’
Jointure (Site 3)
BD réparties Michel Tuffery 23
Requête répartie avec semi-jointures
Client (Site 1)
Sélection adrcli=‘Tlse’
Emprunt (Site 2) Projection IdCliC (idcli, nomcli)
Semi-Jointure (Site 2)
Ouvrage (Site 3)
Sélection auteur=‘Michel’
Projection Idouv
O (idouv, titre)
Semi-Jointure (Site 2)
Jointure (Site 1)
C
Jointure (Site 3)
O
BD réparties Michel Tuffery 24
(8) Transactions distribuées
• Sécurité , fiabilité et continuité quoi qu’il arrive• Différents types de pannes
– Panne d’une transaction en exécution– Panne simple d’un site– Panne catastrophique d’un site
• Notion de transaction– Atomicité
– Cohérence
– Isolation
– Durabilité
BD réparties Michel Tuffery 25
Panne d’une transaction ou panne simple
• Garantir l’atomicité des transactions en utilisant les mécanismes de journalisation et le protocole de validation en deux étapes
• Transactions réparties : commit généralisé• Commit normal
– Le site initiateur d’une transaction décide du commit– Les sites exécutants obéissent
SITE 1 SITE 0 SITE 2
COMMIT COMMITPANNE
Commit effectuéRollback effectué !!
Solution insuffisante
BD réparties Michel Tuffery 26
Commit à deux phases (2PC)
• Le site initiateur envoie, à tous les sites touchés par la transaction, un "prêt à commettre ? "
• Chaque site répond "prêt"• Le site initiateur envoie les commit à tous les
sites• Chaque site répond "ok"• La transaction est validée quand tous les sites
ont fait le commit• Tous les cas d’erreur sont traités grâce aux
journaux sur chaque site
BD réparties Michel Tuffery 27
Commit à deux phases
SITE 0 SITE 2SITE 1Prêt à commettre ?Prêt à commettre ?
Prêt Prêt
Commit Commit
OK
État ?
Commit
OK
BD réparties Michel Tuffery 28
Exemples de validation en deux étapes (1)
• Validation normale
S1 S0 S2
Prêt ? Prêt ?
Prêt Prêt
Commit Commit
OK OK
BD réparties Michel Tuffery 29
• Panne de S2 avant d’être prêt
S1 S0 S2
Prêt ? Prêt ?
Prêt
OK
Exemples de validation en deux étapes (2)
TIMEOUT
Défaire Défaire
Reprise à chaud
(rollback)
BD réparties Michel Tuffery 30
Exemples de validation en deux étapes (3)
• Panne de S2 après envoi de prêt
S1 S0 S2Prêt ? Prêt ?
Prêt Prêt
Commit Commit
OK Prêt
Commit
OK
Reprise
BD réparties Michel Tuffery 31
Exemples de validation en deux étapes (4)
• Panne du coordinateur
S1 S0 S2Prêt ? Prêt ?
Prêt Prêt
Commit Commit
OK OK
Prêt ?Prêt ?
Prêt Prêt
BD réparties Michel Tuffery 32
Reprise à froid après unepanne catastrophique
• Restauration de la base à partir de la sauvegarde et du journal ("Recovery de la base")
• Une reprise est toujours locale• Retour à un état stable de l’ensemble du système
réparti• Le site coordinateur décide :
– Le site en panne peut restaurer la transaction ("prêt") et la séquence se poursuit (processus "Reco")
– Le site en panne ne peut restaurer la transaction :• Demande à tous les sites de défaire les transactions• Risque d’effet domino
BD réparties Michel Tuffery 33
Problème des accès concurrentsverrou mortel global
• Pose de verrous sur des objets répartis• Gestion d’un graphe d’attente réparti
– Graphe Qui Attend Quoi (QAQ) réparti– Chaque site gère son propre graphe local et
communique l’information sur ses propres transactions bloquées
Site 1
T1
T2
T3
T4
Site 2
BD réparties Michel Tuffery 34
(9), (10), (11) Indépendance du matériel,des systèmes d’exploitation et du réseau
• Une base est "cliente" d’une autre base et vice –versa : architecture client - serveur
• C’est le "connect string" ou "chaîne hôte" qui permet cette indépendance
• Contenu du "connect string" – Protocole réseau– Serveur hôte (n° port)– Nom de l’instance de la base
BD réparties Michel Tuffery 35
(12) Indépendance du SGBD
• Très difficile d’arriver à cette indépendance• Interfaces communes minimum :
– Protocole d’échange– Lecture et traduction des dictionnaires, types de
données ….– Fonctions réciproques client – serveur– Système de mise à jour cohérent– Verrouillage cohérent, …..
• Noyau standard avec SQL ANSI
BD réparties Michel Tuffery 36
Création des fragments dansles bases distantes
• SQL-ANSI propose un ordre CREATE FRAGMENT permettant de créer les tables distantes
• Cet ordre permettra de conserver les règles de fragmentation dans le dictionnaire réparti
• Cet ordre n’est pas encore implémenté • Oracle propose l’ordre COPY• COPY est un ordre SQL+ permettant de Duplicationr un
fragment d’une base vers une autre en utilisant les ‘connect string’
• COPY possède 2 variables d’environnement configurables– COPYCOMMIT : intervalle du nombre de lignes transférées
entre 2 COMMIT (0 : COMMIT à la fin)– ARRAYSIZE : nombre de lignes transférées par chaque FETCH
BD réparties Michel Tuffery 37
Commande COPY
• Syntaxe de la commande
• APPEND : [CREATE] + INSERT• CREATE : CREATE + INSERT• REPLACE : [DROP] + CREATE + INSERT• INSERT : INSERT
COPY FROM spécification_base1 -TO spécification_base2 -
{APPEND|CREATE|REPLACE|INSERT} -fragment [(colonnes)] -USING SELECT …….
Caractère ligne suite
BD réparties Michel Tuffery 38
Exemples de COPY
• Création ou remplacement du fragment
• Création d’un fragment initial avec restriction verticale
COPY FROM michel/michel@vers_base1 -TO michel/michel@vers_base2 -REPLACE enseignants_info -USING SELECT * FROM enseignants -
WHERE ufr='info'
COPY FROM michel/michel@vers_base1 -TO michel/michel@vers_base2 -CREATE etudiant_scol(ine,nom,adr) -USING SELECT inet,nomet,adret -FROM etudiant
BD réparties Michel Tuffery 39
Contraintes des fragments
• La commande COPY n’exporte pas les contraintes (sauf NOT NULL)
• Il faut les recréer – Clés primaires – Clés étrangères– Contraintes autres
• Problème pour les clés étrangères distantes – Impossible d’utiliser les DB LINKS (voir plus loin)– Créer deux TRIGGERS :
• Sur le fragment fils : le père doit exister• Sur le fragment père : suppression impossible si des fils
sont présents
BD réparties Michel Tuffery 40
Bases réparties : travail de compte à compte
• Ne pas travailler avec les véritables comptes propriétaires des données
• Chaque site distant doit créer un compte ayant accès aux objets répartis locaux
• Ces comptes 'miroir' sont crées par le DBA et reçoivent les droits d’accès par les propriétaires des données réparties
• Chaque responsable local de la BDR ne connaît que le password des comptes 'miroir' distants
BD réparties Michel Tuffery 41
Organisation de l’ensemble
base1 base2
OWNER 1 OWNER 2
Compte miroir bdr/bdr Compte miroir bdr/bdr
GRANT GRANT
DB LINK
BD réparties Michel Tuffery 42
Lien inter-bases :Database Link
• Lien défini par un utilisateur pour relier deux bases
• Connaissance du user/password du compte miroir distant
• Utilisation du 'connect string' du serveur local pour accéder à l’instance distante
CREATE DATABASE LINK dbl_base2CONNECT TO bdr IDENTIFIED by bdrUSING 'vers_base2';
Nom du ‘connect string’ User/password
BD réparties Michel Tuffery 43
Manipulation des DataBase Link
• Suppression d’un lien
• Dictionnaire de données : USER_DB_LINKS
DROP DATABASE LINK dbl_base2;
SQL> col DB_LINK format a8SQL> col USERNAME format a8SQL> col PASSWORD format a8SQL> col HOST format a8SQL> col CREATED format a8SQL> select * from user_db_links;
DB_LINK USERNAME PASSWORD HOST CREATED-------- -------- -------- -------- --------DB_ORA MICHEL MICHEL oracle 14/01/03
BD réparties Michel Tuffery 44
Utilisation des DataBase Link
• Sélection d’un fragment distant
• Manipulation distante
SQL> select * from etudiant@DB_ORA;
INE NOM DIPLO CYCLE---------- -------------------- ----- ----------
100 étudiant 100 miag3 2200 étudiant 200 stri3 2300 étudiant 300 miag3 2400 étudiant 400 stri2 2
SQL> update etudiant@DB_ORA SET cycle=3;
4 ligne(s) mise(s) à jour.
BD réparties Michel Tuffery 45
Indépendance à la localisationles SYNONYMS
• Création d’un synonyme
• Suppression d’un synonyme
CREATE SYNONYM etudiant FOR etudiant@db_ora;
DROP SYNONYM etudiant;
BD réparties Michel Tuffery 46
Constructions des objets virtuels
• Reconstitution d’un objet fragmenté : VIEW
• Reconstitution d’un objet non éclaté : SYNONYM
CREATE VIEW etudiant (ine,nom,adr,cycle) ASSELECT inet,nomet,adret,’L’ FROM etud_licenceUNIONSELECT inet,nomet,adret,’M’ FROM etud_mastere;
CREATE SYNONYM sequence_client FOR sequence_client@db_link;
BD réparties Michel Tuffery 47
Manipulation d’une base répartieles Procédures stockées
• Les procédures stockées ou packages se comportent comme de véritables méthodes
• Les données réparties sont encapsulées et ne sont pas accessibles directement aux développeurs clients
• Les règles de fragmentation sont dans les procédures • La localisation des données est transparente aux
utilisateurs : appel des procédures sans connaissance de la base
• La transaction est traitée dans la procédure (COMMIT / ROLLBACK)
BD réparties Michel Tuffery 48
Manipulation d’une base répartieles Triggers INSTEAD OF
• Ces triggers s’appliquent sur des vues• Les développeurs clients connaissent les objets
virtuels et exécutent les ordres du LMD• Les triggers INSTEAD OF ‘prennent la main’ et
font les mises à jour sur les fragments distants• Les développeurs ‘serveur’ connaissent les
règles de distribution• Ces triggers ‘lèvent’ éventuellement des erreurs
applicatives (raise_application_error)• La transaction n’est pas dans le Trigger mais
dans le programme client
BD réparties Michel Tuffery 49
Exemple de Trigger INSTEAD OF
CREATE TRIGGER insert_etudiantINSTEAD OF INSERT ON etudiant FOR EACH ROWBEGINIF :NEW.cycle=’L’ THENINSERT INTO etudiant_licence@db_l VALUES(:NEW.ine,:NEW.nom,:NEW.adresse);INSERT INTO stage@db_s VALUES(:NEW.ine,:NEW.nomstage,:NEW.adstage);ELSIF :NEW.cycle=’M’ THEN....... Idem pour M et D ........
ELSE RAISE_APPLICATION_ERROR(-20455,’Entrer M, L ou D’); END IF;END;/
BD réparties Michel Tuffery 51
Distribution , Duplication et Réplication
• Distribution– BD distribuée ou répartie– Sans redondance
• Duplication– Duplication locale d’un fragment éloigné maître– Fragment local en lecture seule– Notion de cliché ou snapshot (materialized view)– Duplication synchrone (maj instantannée) ou asynchrone (maj
en différé)• Réplication
– Pas de fragment maître– Duplications en miroir– Réplication synchrone (emploi de jetons) ou asynchrone
(problèmes de cohérence)
BD réparties Michel Tuffery 52
Duplication de données : différentes possibilités
• Duplication d’une base entière– EXPORT – IMPORT programmé
• Duplication d’une table– Create ou Copy
• Duplication synchrone : trigger ou trigger insteadof
• Duplication asynchrone programmée par programmateur
• Duplication asynchrone assurée par Oracle : les snapshot ou vues matérialisées
BD réparties Michel Tuffery 53
Exportation et Importationd’une base
• Base maître
• Base dupliquée
• Automatisationpar shell OS
Fichier de paramètres
Log
EXPORT Fichierexport
IMPORT
LogFichier
de paramètres
BD réparties Michel Tuffery 54
Duplication d’une table distante
• Processus simple, rapide et fiable (PUSH ou PULL)
• Duplication complète (sans les contraintes)
• Duplication d’un fragment
CREATE TABLE copie AS SELECT * FROMmaître@dblink;
CREATE TABLE Duplication AS SELECT col1, col3, col5 FROM
maître@dblinkWHERE prédicat_de_resriction;
BD réparties Michel Tuffery 55
Duplication d’une table distante (2)
• Table locale existante
• Marquage des lignes transférées
DELETE FROM copie;INSERT INTO copie
SELECT * FROM maître@dblink;COMMIT;
INSERT INTO copie SELECT * FROM maître@dblinkWHERE jeton='pas transféré'
FOR UPDATE;UPDATE maître SET jeton='transféré'
WHERE jeton='pas transféré';COMMIT;
BD réparties Michel Tuffery 56
Duplication d’une table distante (3)COPY
• La Duplication peut être 'pilotée' à partir d’un site tiers
• Plusieurs cas de Duplication (page 37)• Duplication des données sans les contraintes• Fortement utilisé pour créer les fragments
répartis initiaux
BD réparties Michel Tuffery 57
Duplication Synchrone
• Mise à jour instantanée de la Duplication pour toute modification de la table maître
• La duplication synchrone fait partie de la transaction
Ordre de MAJ
Ordre de MAJdéclenché
instantanément
Maître Cliché
Duplication Synchrone
BD réparties Michel Tuffery 58
Duplication Synchrone :mise en œuvre avec les trigger
• Trigger de type 'before' qui répercute l’ordre exécuté sur la table maître dans la table cliché– La transaction est gérée par le client : exceptions possibles– Insertion, mise à jour et suppression de données– Plusieurs clichés possibles– Méthode 'PUSH'
Ordre de MAJ
Ordre desynchronisationTRIGGER
Maître
Cliché 1
Cliché 2
Duplication Synchrone
BD réparties Michel Tuffery 59
Duplication Asynchronepar programmateur
• La mise à jour du cliché est différée• Utilisation d’un programmateur et d’une file
d’attente
Ordre de MAJ
Maître ClichéTRIGGER
Mise de l’ordre en attente
File d’attente
Ordre déclenché sur horloge
(programmateur)
Duplication Asynchrone par programmateur
BD réparties Michel Tuffery 60
Exemple de mise en attente d’un ordre
• Un trigger de type 'before' est posé sur la table maître• Important de conserver la séquence des ordres de mise à
jour• Utilisation du dblink
CREATE TRIGGER mise_attente BEFORE INSERT ON maître FOR EACH ROWvordre VARCHAR(200);BEGIN
vordre:='INSERT INTO cliché@dblinkVALUES ………';
INSERT INTO attente(numéro,ordre)VALUES (seq_ordre.NEXTVAL,vordre);
END;
Duplication Asynchrone par programmateur
BD réparties Michel Tuffery 61
Exemple de mise en attente d’ordres
• Ordres de mise à jour dans maître
• Table Maître
INSERT INTO maitre VALUES('ligne1');INSERT INTO maitre VALUES('ligne2');INSERT INTO maitre VALUES('ligne3');DELETE FROM maitre WHERE nom='ligne2';UPDATE maitre SET nom='ligne33'WHERE nom='ligne3';
SQL> SELECT * FROM maitre;NOM----------ligne1ligne33
Duplication Asynchrone par programmateur
BD réparties Michel Tuffery 62
Exemple de mise en attente d’ordres (2)
• Table attente
SQL> select * from attente;
NUMERO ORDRE------ ----------------------------------------------
1 insert into cliché@db_ora values('ligne1')2 insert into cliché@db_ora values('ligne2')3 insert into cliché@db_ora values('ligne3')4 delete from cliché@db_ora where nom = 'ligne2'5 update cliché@db_ora set nom = 'ligne33'
where nom = 'ligne3'
Duplication Asynchrone par programmateur
BD réparties Michel Tuffery 63
Notion de Programmateur
• Service de déclenchement d’un processus par ordre d’une horloge
• Logiciel installé extérieur (OS) ou interne à la base de données
• La table d’attente peut être sur le site maître ou de Duplication
• Le programmateur peut être sur le site maître ou de Duplication
• Programmateur interne à la BD : JOBS
Duplication Asynchrone par programmateur
BD réparties Michel Tuffery 64
Programmateur avec Oracle
• Processus (Unix) ou Service de type SNP – Vérifier l’état du service sur NT (activé)
• Le processus ouvre une session dans la base à intervalle régulier (programmé) et consulte les tâches
• Exécution en tâche de fond• Utilisation multiple : sauvegarde, export,
duplication, MAJ d’attributs dérivés, ….• Exécution asynchrone
Duplication Asynchrone par programmateur
BD réparties Michel Tuffery 65
Mise en service du programmateur (DBA)
• Vérification du nombre de jobs autorisés
• Si = 0, modifier le paramètre (init.ora, pfile) ou la commande système :
• Droits d’exécution du package
SQL> SELECT name,value FROM v$parameter2 WHERE name LIKE '%job%';
NAME VALUE ------------------------------ ---------job_queue_processes 10
ALTER SYSTEM SET job_queue_processes=10;-- 1000 au maximum
CONNECT systemGRANT EXECUTE ON dbms_job TO user;
Duplication Asynchrone par programmateur
BD réparties Michel Tuffery 66
Package DBMS_JOB
• Ce package permet de manipuler des taches ou JOBS
• Il contient des procédures :– REMOVE– CHANGE– WHAT– RUN– SUBMIT
Duplication Asynchrone par programmateur
BD réparties Michel Tuffery 67
Procédure SUBMIT
• SpécificationPROCEDURE submit
( job OUT BINARY_INTEGER,what IN VARCHAR2,next_date IN DATE DEFAULT sysdate,interval IN VARCHAR2 DEFAULT 'null',no_parse IN BOOLEAN DEFAULT FALSE,instance IN BINARY_INTEGER DEFAULT 0,force IN BOOLEAN DEFAULT FALSE );
-- Submit a new job.Chooses JOB from the -- sequence sys.jobseq.
-- For example,-- variable x number;-- execute dbms_job.submit(:x,'pack.proc(''arg1'');'
-- ,sysdate,'sysdate+1');
Duplication Asynchrone par programmateur
BD réparties Michel Tuffery 68
Autres Procédures
• REMOVE
• WHAT
• NEXT_DATE
PROCEDURE remove( job IN BINARY_INTEGER );-- Remove an existing job from the job queue.-- This currently does not stop a running job.-- execute dbms_job.remove(14144);
PROCEDURE what( job IN BINARY_INTEGER,what IN VARCHAR2 );
-- Change what an existing job does, and --replace its environment
PROCEDURE next_date ( job IN BINARY_INTEGER,next_date IN DATE );
-- Change when an existing job will next execute
Duplication Asynchrone par programmateur
BD réparties Michel Tuffery 69
Exemple de manipulation de job
• Procédure d’insertion d’une ligne avec horaire
drop table testjob;create table testjob (t varchar(50));create or replace procedure test_job isheure varchar(20);beginheure:=to_char(sysdate,'HH24-MI-SS');insert into testjob values('ajout : '||heure) ;
end;/execute test_job;
SQL> select * from testjob;T-------------------------ajout : 14-23-51
Duplication Asynchrone par programmateur
BD réparties Michel Tuffery 70
Exemple de manipulation de job (2)
variable numjob number;execute dbms_job.submit(:numjob,'test_job;',
sysdate,'sysdate+1/1440');SQL>print numjob
NUMJOB----------
3SQL> select * from testjobT------------------ajout : 14-44-28ajout : 14-45-30ajout : 14-46-31
SQL>select job,what from user_jobs;JOB WHAT
---------- ------------3 test_job;
execute dbms_job.remove(3);
Attention au ;
Duplication Asynchrone par programmateur
BD réparties Michel Tuffery 71
Exemple de job d’extractionde la file d’attente
• Sans traiter les exceptions
• Le job qui lance le programmateur
CREATE PROCEDURE exeordres ISCURSOR c1 is SELECT ordre FROM attente
ORDER BY numero FOR UPDATE;BEGIN
FOR c1rec IN c1 LOOPEXECUTE IMMEDIATE c1rec.ordre;DELETE FROM attente WHERE CURRENT OF c1;END LOOP;COMMIT;
END;
variable numjob number;execute dbms_job.submit(:numjob,'exeordres;',
sysdate,'sysdate+1');print numjob
Duplication Asynchrone par programmateur
BD réparties Michel Tuffery 72
Placement du programmateur
• Gestion lourde pour la base (et l’OS)– Gestion des processus de fond
• Placé dans la base la moins chargée• Deux types de propagations possibles
– PUSH• Le programmateur "pousse" les ordres de MAJ
– PULL• Le programmateur "tire" les ordres de MAJ
Duplication Asynchrone par programmateur
BD réparties Michel Tuffery 73
Propagation par PUSH
• La base maître pousse vers le répliqua
Duplication Asynchrone par programmateur
MaîtreCliché
Mise de l’ordre en attente
Ordre déclenché sur horloge
(programmateur)
Ordre de MAJ
BD réparties Michel Tuffery 74
Propagation par PULL
• Le répliqua tire les modifications
Maître Cliché
Mise de l’ordre en attente
Ordre déclenché sur horloge
(programmateur)
Ordre de MAJ
Duplication Asynchrone par programmateur
BD réparties Michel Tuffery 75
Gestion des erreurs
• Obligation de gérer les erreurs de façon autonome
• Plusieurs types d’erreur– Erreur de connexion vers le site de répliqua– Violation de contraintes (?)– Panne du réplicateur– ……….
• Création d’un journal (log) des erreurs• Certaines erreurs sont irrattrapables
– Actions ponctuelles pour ramener à un état stable
Duplication Asynchrone par programmateur
BD réparties Michel Tuffery 76
Duplication par OracleLes vues matérialisées ou snapshots
• Technique d’Oracle pour la duplication asynchrone• Un cliché ou snapshot est un fragment de données en
lecture seule• Le cliché est rafraîchi à intervalles réguliers (refresh) ou à la
demande• Les rafraichissements sont complets (complete) ou
différentiels (fast)• Le cliché (fragment dupliqué) peut être le résultat de :
– Restriction verticale d’une table– Restriction horizontale– Une jointure de plusieurs tables
Duplication Asynchrone par Oracle
BD réparties Michel Tuffery 77
Principe général
• C’est le site du cliché qui tire les MAJ (pull)• On crée une vue matérialisée pour créer le cliché avec les
méthodes de rafraîchissement et le contenu choisis• Pour chaque table maître qui alimente un cliché, il faut
créer un journal de vue matérialisée• Ce journal contient les mises à jour différées gérées selon
deux techniques possibles– Par rowid (pas conseillé en cas de réorganisation de blocs)– Par clé primaire (utilisé par défaut) table maître avec une clé
primaire obligatoire• Une table maître (un même journal) peut alimenter plusieurs
fragments dupliqués
Duplication Asynchrone par Oracle
BD réparties Michel Tuffery 78
Mise en œuvre d’un rafraîchissementcomplet exécuté volontairement
• Création de la table maître sur le site maître
• Création du journal de vue matérialisée sur le site maître
Duplication Asynchrone par Oracle
DROP TABLE maitre;CREATE TABLE maitre (idm NUMBER PRIMARY KEY,
texte varchar(20));
DROP MATERIALIZED VIEW LOG ON maitre;CREATE MATERIALIZED VIEW LOG ON maitre;
BD réparties Michel Tuffery 79
Journal de vue matérialisée
• De nom MLOG$_nom_de_table_maître
Duplication Asynchrone par Oracle
SQL> DESC mlog$_maitre
Nom Type----------------------- ---------------IDM NUMBERSNAPTIME$$ DATEDMLTYPE$$ VARCHAR2(1)OLD_NEW$$ VARCHAR2(1)CHANGE_VECTOR$$ RAW(255)
Clé primaire
Pour les copies multiples
Ordre du LMD
Old ou New
BD réparties Michel Tuffery 80
Ordre de création de vue matérialisée (1)
• Création sans intervalles de rafraîchissements
• 4 méthodes de rafraîchissement– NEVER : jamais rafraîchie– COMPLETE : transfert complet– FAST : transferts différentiels– FORCE : FAST si possible, COMPLETE sinon
CREATE MATERIALIZED VIEW copieREFRESH [NEVER | COMPLETE | FAST | FORCE]AS SELECT …………FROM maître@dblink ………;
Duplication Asynchrone par Oracle
BD réparties Michel Tuffery 81
Ordre de création de vue matérialisée (2)
• Création avec intervalles de rafraîchissements
CREATE MATERIALIZED VIEW copieREFRESH FAST START WITH sysdate NEXT sysdate + 1WITH PRIMARY KEYAS SELECT …………FROM maître@dblink ………;
Début du transfert Intervalle de rafraîchissement
Duplication Asynchrone par Oracle
BD réparties Michel Tuffery 82
Mise en œuvre : cliché parrafraîchissement manuel
• Création du cliché
• On utilisera la procédure refresh du package dbms_mview pour rafraîchir
CREATE MATERIALIZED VIEW clichéREFRESH FAST AS SELECT * FROM maitre@db_tuf;
DBMS_MVIEW.REFRESH('nom_mv','F',NULL);
F (fast) ou C (complète)
Duplication Asynchrone par Oracle
BD réparties Michel Tuffery 83
Mises à jour sur la table maître
• Ordres de mise à jourINSERT INTO maitre VALUES(1,'ligne 1');INSERT INTO maitre VALUES(2,'ligne 2');INSERT INTO maitre VALUES(3,'ligne 3');UPDATE maitre SET texte = 'LIGNE 1' WHERE idm=1;UPDATE maitre SET texte = 'LIGNE 3' WHERE idm=3;DELETE FROM maitre WHERE idm=2;
SQL> SELECT * FROM maitre;
IDM TEXTE---------- --------------------
1 LIGNE 13 LIGNE 3
Duplication Asynchrone par Oracle
BD réparties Michel Tuffery 84
Contenu du journal de MV
• La date indique qu’aucun rafraîchissement n’a eu lieu à partir de ce journal (pour un éventuel autre cliché)
SQL> COL CHANGE_VECTOR$$ FORMAT a10SQL> SELECT * FROM mlog$_maitre;
IDM SNAPTIME D O CHANGE_VEC---------- -------- - - ----------
1 01/01/00 I N FE2 01/01/00 I N FE3 01/01/00 I N FE1 01/01/00 U U 043 01/01/00 U U 042 01/01/00 D O 00
Duplication Asynchrone par Oracle
BD réparties Michel Tuffery 85
Rafraîchissement manuel
• Rafraîchissement manuel complet
EXECUTE dbms_mview.refresh('cliché','C',null);
SQL> select * from cliché;
IDM TEXTE---------- --------------------
1 LIGNE 13 LIGNE 3
-- sur le site maître
SQL> SELECT * FROM mlog$_maitre;
aucune ligne sélectionnée Il n’y a pas d’autres clichés
Duplication Asynchrone par Oracle
BD réparties Michel Tuffery 86
Rafraîchissement différentielmanuel avec deux clichés (1)
• Sur le site maître
Duplication Asynchrone par Oracle
INSERT INTO maitre VALUES(4,'ligne 4');INSERT INTO maitre VALUES(5,'ligne 5');COMMIT;
SQL> SELECT * FROM mlog$_maitre;
IDM SNAPTIME D O CHANGE_VEC---------- -------- - - ----------
5 01/01/00 I N FE4 01/01/00 I N FE
Sinon, pas de propagation
BD réparties Michel Tuffery 87
Rafraîchissement différentielmanuel avec deux clichés (2)
• Sur le site de copie : on crée le second cliché
• On lance le rafraîchissement manuel
Duplication Asynchrone par Oracle
create materialized view cliché2refresh fast as SELECT * FROM maitre@db_tuf;
EXECUTE dbms_mview.refresh('cliché','F',null);
EXECUTE dbms_mview.refresh('cliché2','F',null);
BD réparties Michel Tuffery 88
Rafraîchissement différentielmanuel avec deux clichés (3)
• Vérification de la propagation des modifications SQL> SELECT * FROM cliché;
IDM TEXTE---------- --------------------
1 LIGNE 13 LIGNE 34 ligne 45 ligne 5
SQL> SELECT * FROM cliché2;IDM TEXTE
---------- --------------------1 LIGNE 13 LIGNE 34 ligne 45 ligne 5
Duplication Asynchrone par Oracle
BD réparties Michel Tuffery 89
Rafraîchissement différentielmanuel avec deux clichés (4)
• Sur le site maître
SQL> SELECT * FROM mlog$_maitre;
aucune ligne sélectionnée
INSERT INTO maitre VALUES(6,'ligne 6');COMMIT;
SQL> SELECT * FROM mlog$_maitre;
IDM SNAPTIME D O CHANGE_VEC---------- -------- - - ----------
6 01/01/00 I N FE
Duplication Asynchrone par Oracle
BD réparties Michel Tuffery 90
Rafraîchissement différentielmanuel avec deux clichés (5)
• On ne rafraîchit que le premier cliché
• Journal du site maître
Duplication Asynchrone par Oracle
EXECUTE dbms_mview.refresh(‘cliché','F',null);SQL> SELECT * FROM cliché;
IDM TEXTE---------- --------------------
1 LIGNE 13 LIGNE 34 ligne 45 ligne 56 ligne 6
SQL> SELECT * FROM mlog$_maitre;IDM SNAPTIME D O CHANGE_VEC
---------- -------- - - ----------6 03/10/04 I N FE
Il reste la ligne 6 pour cliché2
Voir la date - heure
BD réparties Michel Tuffery 91
Rafraîchissement différentielmanuel avec deux clichés (6)
• Mise à jour de maître
INSERT INTO maitre VALUES (7,'ligne 7');
SQL> select * from mlog$_maitre;
IDM SNAPTIME D O CHANGE_VEC---------- -------- - - ----------
7 01/01/00 I N FE6 03/10/04 I N FE
Duplication Asynchrone par Oracle
BD réparties Michel Tuffery 92
Rafraîchissement différentielmanuel avec deux clichés (7)
• Rafraîchissement de cliché2
EXECUTE dbms_mview.refresh(‘cliché2','F',null);
SQL> select * from esclave2;
IDM TEXTE---------- --------------------
1 LIGNE 13 LIGNE 34 ligne 45 ligne 56 ligne 67 ligne 7
Duplication Asynchrone par Oracle
BD réparties Michel Tuffery 93
Rafraîchissement différentielmanuel avec deux clichés (8)
• Le journal de maître
• Rafraîchissement de cliché
SQL> SELECT * FROM mlog$_maitre;IDM SNAPTIME D O CHANGE_VEC
---------- -------- - - ----------7 03/10/04 I N FE
EXECUTE dbms_mview.refresh(‘cliché','F',null);
-- sur le site maître
SQL> SELECT * FROM mlog$_maitre;aucune ligne sélectionnée
Duplication Asynchrone par Oracle
BD réparties Michel Tuffery 94
Rafraîchissement automatique
• Création du cliché
Duplication Asynchrone par Oracle
CREATE MATERIALIZED VIEW cliché3REFRESH FAST START WITH sysdate NEXT sysdate + 1WITH PRIMARY KEYFOR UPDATE AS SELECT * FROM maitre@db_tuf;
BD réparties Michel Tuffery 95
Réplication Synchrone des données
• Mêmes mécanismes que pour la duplication synchrone mais dans les deux sens
• La réplication synchrone fait partie de la transaction
• Mise en place de trigger (instead of) dans chaque site : problème de différentiation des ordres de mise à jour :– Ordres locaux de MAJ,– Ordres de MAJ déclenché par trigger
• Utilisation de JETONS pour différencier
Réplication Synchrone par jetons
BD réparties Michel Tuffery 96
Réplication synchrone : le principe
• Deux fragments en miroir complet
ordres
déclenchés
Fragment 1 Fragment 2
locauxordreslocaux
ordres
Réplication Synchrone par jetons
BD réparties Michel Tuffery 97
Principe des triggers avec jetons
• Jeton nul pour les ordres locaux
déclenchés
Fragment 1 Fragment 2
locauxordreslocaux
ordres
ordres
(sans jeton) (sans jeton)
(avec jeton)
Trigger déclenché
Trigger déclenché
sans jeton
sans jeton
Réplication Synchrone par jetons
BD réparties Michel Tuffery 98
Cohérence des données :séquence commune
• Pas de problème de clé primaire dans les fragments
• Utilisation d’une séquence commune pour alimenter les clés primaires des fragments répliqués
• Chaque site travaille sur la même séquence grâce à un synonyme
Réplication Synchrone par jetons
BD réparties Michel Tuffery 99
Technique de synchronisationFragment et vues
• Chaque fragment (F) possède sa vue (V)• Fragment et vue ont une colonne jeton (J)
– Soit valeur nulle– Soit une valeur permettant de savoir le site émetteur
J
J J
JF1 F2
V1 V2
J=NUL J=NUL
J=2
J=1
Réplication Synchrone par jetons
BD réparties Michel Tuffery 100
Synchronisation d’une insertion
• L’insertion locale se fait avec un jeton à nul• Le trigger instead of comprend si l’ordre est local
ou de synchronisation• La valeur finale du jeton dans le fragment permet
de savoir le site émetteur de l’insertion• Prévoir une exception avec l’erreur SQL
Réplication Synchrone par jetons
BD réparties Michel Tuffery 101
Synchronisation d’une suppression
• Le jeton permet de savoir quel type de suppression
• En cas de suppression avec un ordre local, il faut renseigner (modifier) le jeton distant (‘X’) et faire les suppressions
• Si le jeton a été modifié (‘X’), la suppression ne sera que locale
Réplication Synchrone par jetons
BD réparties Michel Tuffery 102
Synchronisation d’une modification
• Le jeton ‘nouveau’ d’une modification locale est nul
• Modification des 2 fragments avec un jeton non nul (connaissance du site qui modifie)
• Si le jeton ‘nouveau’ n’est pas nul , modification locale
Réplication Synchrone par jetons
BD réparties Michel Tuffery 103
Réplication Asynchrone
• La mise à jour des fragments se fait en différé comme pour la duplication mais dans les deux sens
Réplication Asynchrone
MAJ MAJ
MAJ sur horloge
MAJ mis en attente
BD réparties Michel Tuffery 104
Réplication Asynchronerisque d’incohérence des données
• La convergence des données est très difficile à assurer
• Les mises à jour risquent de s’exécuter dans un ordre différent sur une même donnée
• Le principe ACID des transactions peut ne plus être respecté
• On peut avoir des fragments différents :
divergence des copies !
Réplication Asynchrone
BD réparties Michel Tuffery 105
Divergence des copies
• En asynchrone, la transaction de MAJ ne pilote pas la réplication
• Impossible de défaire des transactions validées• Mettre en œuvre une technique pour détecter et
résoudre les conflits• Possible aussi de revenir en simple duplication
en choisissant un site maître• Choisir une solution SGBD :
vues matérialisées modifiables
Réplication Asynchrone
BD réparties Michel Tuffery 106
Réplication asynchrone avec Oracle
• Oracle propose une réplication asynchrone avec la technique des vues matérialisées modifiables (for update)
• Notion de groupes de vues matérialisées• Technique assez lourde et complexe à mettre en
oeuvre
Réplication Asynchrone avec Oracle
BD réparties Michel Tuffery 107
Travaux Pratiques
• (1) Création base centralisée et manipulation– Création des objets : tables, contraintes, séquences– Manipulation avec des procédures stockées
• (2) Création de la base répartie– Fragmentation des données– Reconstruction des contraintes– Création des objets virtuels (db_link)– Commit à deux phases
• (3) Manipulation de la base répartie– Procédures stockées– Trigger Instead Of
• (4) Duplication des données– Synchrone : trigger– Asynchrone : programmateur
• Jobs différés avec procédures– Asynchrone : vues matérialisées (snapshot)
• (5) Réplication des données– Synchrone : trigger ou trigger instead of (avec jeton)– [Asynchrone : programmateur (?)]– [Asynchrone : vues matérialisées en modification (?)]