bdrep.pdf

Bases de DonnéesRéparties

ArchitectureMise en œuvre

Duplication etRéplication

Michel Tuffery

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;


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


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


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


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


(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


(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


• 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


(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


(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


Fragmentation horizontale

ETUDIANT_L

ETUDIANT_M

ETUDIANT_D

ETUDIANT

Projection et Sélection

UNION


Fragmentation verticale

ETUDIANTSCOLARITE

STAGE

PROJECTION

JOINTURE

• Duplication de la clé primaire sur chaque fragment


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


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"


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


(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


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)


(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


É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


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’;


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)


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


(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é


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


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


Commit à deux phases

SITE 0 SITE 2SITE 1Prêt à commettre ?Prêt à commettre ?

Prêt Prêt

Commit Commit

OK

État ?

Commit

OK


Exemples de validation en deux étapes (1)

• Validation normale

S1 S0 S2

Prêt ? Prêt ?

Prêt Prêt

Commit Commit

OK OK


• Panne de S2 avant d’être prêt

S1 S0 S2

Prêt ? Prêt ?

Prêt

OK


TIMEOUT

Défaire Défaire

Reprise à chaud

(rollback)



• 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



• 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


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


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


(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


(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


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


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


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


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


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


Organisation de l’ensemble

base1 base2

OWNER 1 OWNER 2

Compte miroir bdr/bdr Compte miroir bdr/bdr

GRANT GRANT

DB LINK


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


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


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.


Indépendance à la localisationles SYNONYMS

• Création d’un synonyme

• Suppression d’un synonyme

CREATE SYNONYM etudiant FOR etudiant@db_ora;

DROP SYNONYM etudiant;


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;


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)


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


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;/

Duplication et Réplicationdes données réparties


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)


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


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


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;


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;


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


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 :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 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


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;



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



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'



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



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



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;



Package DBMS_JOB

• Ce package permet de manipuler des taches ou JOBS

• Il contient des procédures :– REMOVE– CHANGE– WHAT– RUN– SUBMIT



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');



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



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



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 ;



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



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



Propagation par PUSH

• La base maître pousse vers le répliqua


MaîtreCliché



(programmateur)

Ordre de MAJ


Propagation par PULL

• Le répliqua tire les modifications

Maître Cliché



(programmateur)

Ordre de MAJ



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 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


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



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


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;


Journal de vue matérialisée

• De nom MLOG$_nom_de_table_maître


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


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 ………;



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



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)



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



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



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



Rafraîchissement différentielmanuel avec deux clichés (1)

• Sur le site maître


INSERT INTO maitre VALUES(4,'ligne 4');INSERT INTO maitre VALUES(5,'ligne 5');COMMIT;



5 01/01/00 I N FE4 01/01/00 I N FE

Sinon, pas de propagation



• Sur le site de copie : on crée le second cliché

• On lance le rafraîchissement manuel


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);



• 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




• Sur le site maître


aucune ligne sélectionnée

INSERT INTO maitre VALUES(6,'ligne 6');COMMIT;



6 01/01/00 I N FE




• On ne rafraîchit que le premier cliché

• Journal du site maître


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



• Mise à jour de maître

INSERT INTO maitre VALUES (7,'ligne 7');

SQL> select * from mlog$_maitre;


7 01/01/00 I N FE6 03/10/04 I N FE




• 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




• 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



Rafraîchissement automatique

• Création du cliché


CREATE MATERIALIZED VIEW cliché3REFRESH FAST START WITH sysdate NEXT sysdate + 1WITH PRIMARY KEYFOR UPDATE AS SELECT * FROM maitre@db_tuf;


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


Réplication synchrone : le principe

• Deux fragments en miroir complet

ordres

déclenchés

Fragment 1 Fragment 2

locauxordreslocaux

ordres



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



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



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



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



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



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 Asynchrone

• La mise à jour des fragments se fait en différé comme pour la duplication mais dans les deux sens


MAJ MAJ

MAJ sur horloge

MAJ mis en attente


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 !



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 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


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 (?)]

bdrep.pdf

Documents