bd9_baze de date distribuite
Post on 10-Oct-2015
45 Views
Preview:
DESCRIPTION
TRANSCRIPT
-
BD Baze de date distribuite 1
Baze de date distribuite
-
Baze de date distribuite 2 BD
Caracteristici BD distribuite
Beneficiaza de spatii de stocare si procesoare multiple, dar si
memorie extinsa
Inglobeaza componente eterogene si in acelasi timp autonome
Datele stocate in locatii diverse fiecare locatie fiind gestionata de
un DBMS ce poate rula independent
Utilizatorii nu cunosc locul in care datele sunt pastrate (extinde
conceptul independentei fizice si logice a datelor)
Utilizatorii pot scrie tranzactii accesand multiple siteuri similar cu
tranzactiile locale.
Tipuri de BD distribuite
Omogene acelasi DBMS la fiecare site
Eterogene diverse DBMS pe siteuri
Geteway Geteway Geteway
DBMS1 DBMS2 DBMS3
infrastructura
-
Baze de date distribuite 3 BD
Gateway piesa software utilizata pentru compatibilizarea datelor pentru SGBD eterogene ce accepta cereri pe care le trimite la DBMS
local si returneaza raspunsul celui care a furnizat cererea
Probleme specifice ce trebuie rezolvate
Ce date si unde se pastreaza
Accesul aplicatiilor la date
Fragmentare si alocare
Optimizarea interogarilor, la baze centralizate minimizarea
numarului operatiilor de intrare/iesire
Adaugarea costului comunicatiilor
Oportunitatea paralelizarii prelucrarilor
Concurenta accesului la date duce la multiplicarea nodurilor
Copiile multiple ale datelor creaza probleme de sincronizare la
update
Functionalitate partiala cand un site este nefunctional
Impactul pierderi conexiunii sistemelor de comunicatii
-
Baze de date distribuite 4 BD
Implementari
1. Servere colaborative
2. Middleware system
Client Server
Server
Server
query
Client Middleware
Server
Server
Server
query
-
Baze de date distribuite 5 BD
2. Fragmentarea si stocarea datelor
Fragmentarea descompunerea unei relatii in relatii mai mici sau fragmente si pastrarea fragmentelor ca o singura relatie
Orizontala - separarea n-uplurilor relatiei
Primara functie de atribute locale
Derivata functie de atribute din relatii straine
Verticala descompunere join, cu posibilitatea refacerii relatiei
Hibrida combinatie fragmentare orizontala, verticala
R
R1 R2
R11 R12 R21 R22
H H
V V V V
>< ><
R11 R12 R21 R22
U
-
Baze de date distribuite 6 BD
Problema alocarii
Fie:
F = {F1,F2,.Fn} setul de fragmente
S = {S1,S2,.Sm} setul de siteuri
Q = {Q1,Q2,.Qp} setul posibil de cereri
Problema alocarii cere determinarea distributiei optime a setului de
fragmente F la setul de locatii S.
Criterii:
Cost minim agregat ca fiind costul stocarii fiecarui fragment Fi la un
site Sk, costul executiei unei cereri la siteul Sk, costul unei operatii
de tip update la Fi acolo unde este stocat si costul comunicatiei.
Performanta determinata de minimizarea timpului de raspuns si de
maximizarea fiabilitatii
Fie pentru exemplificare urmatoarea structura a tabelelor in baza de
date:
Angajat(nume, ) Lucreaza(responsabil, nume,..)
-
Baze de date distribuite 7 BD
Sa consideram cererea:
SELECT A.Nume
FROM Angajat A, Lucreaza L
WHERE A.Nume = L.Nume and L.Responsabil =Popescu
Adica: Pnume (Sresponsabil = Popescu (Lucreaza >< Angajat)
Daca vom considera baza fragmentata orizontal in fragmentele Ang1,
Ang2, Lucr1, Lucr2 ce sunt stocate pe locatiile 1, 2, 3, 4 si cererea
este furnizata de locatia 5 se obtine urmatoarea schema de
executie:
Site 5 Ang11 U Ang21
Ang11=Ang1>
-
Baze de date distribuite 8 BD
O alta varianta poate fi:
P Nume ((Ang1 U Ang2) >< (Sresponsabil = Popescu (Lucr1 U Lucr2)))
In general o procesare a cererii urmeaza schema:
Decompozitie cerere
Realizare cerere in alg. relationala pentru relatii dustribuite
Localizarea datelor
Cerere pe fragment
Otimizare globala
Cerere optimizata pe fragmente
Otimizare locala
Cerere optimizata local
Schema globala
Schema fragmente
Schema locala
Statistica fragmentelor
-
Baze de date distribuite 9 BD
Decompozitia:
Scrierea in forma normalizata (forma conjunctiva)
Analiza sintactica
Simplificarea (eliminarea predicatelor redondante)
Restructurare in forma algebrica
Proprietati dorite pentru fragmentare:
Fie o relatie R si colectia de fragmente F = {F1,F2,.Fn} obtinuta din fragmentarea relatiei R
Completitudinea pentru fiecare atribut x R exista Fj astfel incat x Fj
Neredondanta oricare ar fi x Fj nu exista Fk astfel incat x Fk pentru j#k.
Reconstructia exista o functie g astfel incat R = g(F1,F2,.Fn)
-
Baze de date distribuite 10 BD
3. Replicarea
Stocarea copiilor unei relatii sau fragmente ale relatiei. O intreaga
relatie poate fi replicata la unul sau mai multe siteuri. In acest mod
se asigura o disponibilitate mai mare a datelor daca un server nu
poate beneficia de serviciile unui alt server. In plus poate fi evaluata
rapid o cerere prin utilizarea datelor locale.
Daca R este fragmentat in R1, R2 si R3, datele sunt pastrate pe site A si
site B cu R1 replicat se obtine
R1 R3
R1 R2
Site A
Site B
-
Baze de date distribuite 11 BD
Gestiunea catalogului distribuit
Trebuie sa pastreze traiectoria distributiei datelor la siteuri
Trebuie sa fie capabil sa numeasca fiecare replica a fiecarui
fragment
Site catalog descrie toate obiectele (fragmente, replici) ale siteului si pastreaza traseele replicilor relatiilor create pe acest
site (pentru a gasi o relatie cu site_referinta, catalogul nu se
modifica daca relatia este mutata)
Tipuri de replicare
Replicare sincrona toate copiile relatiilor sau fragmentelor modificate trebuiesc updatate sincron la COMMIT
Replicare asincrona copiile sunt periodic updatate, exista diferente intre date la anumite momente.
-
Baze de date distribuite 12 BD
Tehnici de replicare sincrona
Votarea tranzactia trebuie sa scrie majoritatea copiilor la modificarea unui obiect si trebuie citite mai multe copii pentru a fi
sigur ca utilizeaza o copie recenta. Ex: 10 copii, 7 scrise pentru
update, 4 copii citite.
Read any Write all citirea de oriunde scrierea la toate pentru a pastra consistenta.
Obs:
Inainte de update trebuie sa se obtina blocarea tuturor copiilor
modificate
Transmite cerere lock la siteuri si asteapta raspunsul ce poate fi
intarziat de alte blocari.
Daca se pierde legatura cererea nu poate fi comisa
Chiar si la succes este necesar un protocol COMMIT expansiv
-
Baze de date distribuite 13 BD
Caracteristici replicare asincrona
Permite comiterea modificarii inainte ca toate copiile sa fi fost
modificate, utilizatorii trebuie sa cunoasca ce copie utilizeaza, unele
fiind out-of-sync
Metode
Primary site o singura locatie reprezinta copia master
Replicile nu sunt direct updatate. Schimbarile in master copy se
executa in doi pasi: captura si aplicare.
Peer to peer mai mult de o copie a unui obiect poate fi master
Schimbarile la master copy trebuiesc propagate la toate copiile. Daca
doua master copy sunt schimbate intr-o maniera conflictuala este
nevoie de un mecanism de rezolvarea conflictului. Metoda este
buna daca nu sunt conflicte - un singur master la un moment de
timp.
-
Baze de date distribuite 14 BD
Exemple cereri distribuite
Fragmentare orizontala
Fie fragmentarea tabelei angajat pastrand la Bucuresti angajatii cu salariu >500 si la Iasi angajatii cu salariu 300 AND SALARIU < 700
Necesita pentru executie SUM(VARSTA) si COUNT(VARSTA) la ambele siteuri dupa care se va agrega pentru a obtine informatia dorita. Descompunerea in cele doua subcereri este dificila.
Daca cererea doreste media varstei angajatilor cu salariu mai mare de 600 executia cererii se face la un singur site.
Fragmentare verticala
La Bucuresti: titlu, salariu, id, la Iasi: nume, varsta, id.
Join dupa id reconstruieste relatia
-
Baze de date distribuite 15 BD
Join distribuit
Consideram doua tabele Angajat avand 80 inregistrari pe pagina si 500 pagini si Lucreaza avind 100 inregistrari pe pagina si 1000 pagini.
Angajat 80*500 = 40000 inregistrari stocate la Bucuresti
Lucreaza 100*1000 = 100000 inregistrari stocate la Iasi.
Vom nota costul operatiei de citire/scriere pe pagina cu D si costul transportului unei pagini cu S
Operatia de join facuta de la Bucuresti
Cost = 500*D+500*1000*(D+S)
Transport Lucreaza la Bucuresti
Cost = 1000*S+1500*D
Transport Angajat la Iasi
Cost = 500*S+1500*D
Alte posibilitati
Semijoin - la Bucuresti se efectueaza o operatie Project pentru a pastra coloanele de interes si transport rezultat la Iasi pentru JOIN (sau invers).
-
Baze de date distribuite 16 BD
Blommjoin
La Bucuresti se produce un vector de biti de dimensiune k, initializat cu
0. Se aplica o functie hash la coloana dupa care se face join,
functie ce intoarce valori in gama [0, k-1]. Daca rezultatul aplicarii
functiei hash este i se seteaza bitul i al vectorului. In vectorul
rezultat avem bitul i cu valoarea 1 daca exista cel putin o valoare
a campului de join pentru care functia hash a intors rezultatul i.
Vectorul rezultat se transmite la Iasi.
La Iasi se utilizeaza aceeasi functie hash pe campul de join al tabelei
Lucreaza. Se creaza o tabela Lucreaza redusa in care se tin doar
inregistrarile la care rezultatul functiei hash este i si in bit vector la
pozitia i avem valoarea setata. Tabela redusa se trimite la
Bucuresti pentru join.
Obs:
Metoda se aplica doar pentru join cu conditie de egalitate
Eficienta depinde de gradul de reducere al tabelei.
-
Curs 10 17 SBDD
BD Distribuite Oracle Pot fi: omogene sau eterogene
Un sistem omogen este format din doua sau mai multe baze de date ORACLE
instalate pe una sau mai multe masini. In fig. trei baze : hq, mfg si sales.
-
Curs 10 18 SBDD
Definire: Baze de date distribuite
procesare distribuita
Termenii de baze de date distribuite si procesare distribuita sunt strans legati intre ei, chiar daca au semnificatii diferite. Pentru fiecare dintre termeni exista o definitie generala:
Baze de date distribuite un set de baze de date intr-un sistem distribuit ce poate fi vazut ca aplicatii ale unei singure surse de date.
Procesare distribuita operatii ce se executa cand o aplicatie distribuie task-uri catre diferite calculatoare aflate in retea. De exemplu, o baza de date distribuie taskuri de prezentare front-end catre client si permite serverului de baze de date din spate sa gestioneze accesul la bazele de date. In consecinta, un sistem de procesare al aplicatiei de baze de date distribuite mai este numit si un sistem de baze de date client/server.
-
Curs 10 19 SBDD
Arhitectura BD distribuita Oracle
Fiecare masina dintr-
o retea poate
gazdui una sau
mai multe baze
de date. Intr-un
sistem de baze
de date
distribuite, fiecare
nod poate fi
client, server sau
ambele, in functie
de situatie.
-
Curs 10 20 SBDD
Database link
O conexiune intre baze de date este un pointer care defineste o cale de comunicatie unidirectionala de la un server de baze de date Oracle la un alt server de baze de date. Pointer-ul conexiunii este definit ca un camp intr-o tabela dictionar de date.
O conexiune intre baze de date permite utilizatorilor locali sa acceseze date aflate intr-o baza de date remote. Pentru initierea acestei conexiuni, fiecare baza de date din sistemul distribuit trebuie sa aiba un nume global unic de baza de date in domeniul respectiv de retea.
-
Curs 10 21 SBDD
Tipuri conexiuni
Connected user link. Utilizatorii se conecteaza la baza de date remote in acelasi mod in care s-ar conecta local, ceea ce presupune ca acestia sa aiba un cont de utilizator pentru baza de date remote cu nume de utilizator si parola identice cu cele din contul aflat pe baza de data locala.
Fixed user link. Utilizatorii se conecteaza folosind numele de utilizator si parola referentiate prin conexiune. De exemplu, daca Ioana utilizeaza o conexiune fixed user link care presupune conectarea la baza de date hq cu numele de utilizator si parola mihai/adcm1, ea conectandu-se ca mihai, va avea toate privilegiile la hq atribuite lui mihai in mod direct si toate facilitatile care i-au fost acordate lui mihai la baza de date hq.
Current user link. Un utilizator se conecteaza ca un utilizator global. Un utilizator local se poate conecta ca utilizator global in contextul unei proceduri stocate, fara a salva parola globala de utilizator in definirea conexiunii. De exemplu, Ioana poate accesa o procedura scrisa de Mihai, accesand contul de utilizator si schema lui Mihai in cadrul bazei de date hq.
-
Curs 10 22 SBDD
Conexiuni shared intre baze de date O conexiune shared intre baze de date reprezinta o legatura intre un
proces al serverului local si o baza de date remote. Conexiunea este impartita (shared) pentru ca multiple procese client pot utiliza aceeasi conexiune simultan.
Un dblink shared difera de un dblink standard prin:
Utilizatorii diferiti ce acceseaza acelasi obiect al unei scheme prin intermediul unui dblink pot face parte din aceeasi retea;
Cand un utilizator trebuie sa realizeze o conexiune intre un server remote si un proces al unui server particular, procesul poate refolosi conexiunea deja existenta cu serverul remote. Aceasta reutilizare a conexiunii poate fi posibila daca a fost stabilita pe acelasi proces al serverului, cu acelasi dblink, dar intr-o alta sesiune. Pentru un dblink standard, conexiunea nu poate fi folosita pentru sesiuni multiple.
Cand se foloseste un dblink shared intr-o configurare de tip shared a serverului, o conexiune poate fi stabilita direct in afara procesului serverului shared, in serverul local. Pentru un dblink standard, acest tip de conexiune trebuie stabilita cu ajutorul unui dispecer local, prin care vor trece toate datele.
-
Curs 10 23 SBDD
DB link
Fiecare baza de date intr-un sistem distribuit este identificat unic prin acest nume global. Baza de date formeaza numele global prin prefixarea domeniului retelei bazei de date respective, specificat de parametrul de initializare DB_DOMAIN la crearea bazei de date, cu numele individual al bazei de date, specificat de parametrul de initializare DB_NAME.
Ex: mfg.division3.acme_tools.com
-
Curs 10 24 SBDD
Nume dblink-uri
Uzual, un dblink are acelasi nume ca numele global al bazei de date remote care este referita. De exemplu, la sales.us.oracle.com, dblink-ul va fi sales.us.oracle.com.
Atunci cand parametrul de initializare GLOBAL_NAMES este setat TRUE, baza de date asigura ca numele dblink-ului este acelasi cu al bazei de date remote. De exemplu, daca numele global al unei baze de date hq este hq.acme.com si GLOBAL_NAMES este TRUE, atunci link-ul este hq.acme.com. A se retine faptul ca baza de date verifica partea domeniu a numelui global asa cum este stocat in dictionar, nu si setarea DB_DOMAIN din fisierul de initializare al parametrilor.
Daca parametrul GLOBAL_NAMES este setat FALSE, atunci nu este necesara utilizarea denumirii globale. Astfel, dblink-ul poate avea orice nume. O recomandare Oracle este de a utiliza numele global, deoarece multe optiuni, incuzand replicarea, necesita nume globale.
Dupa activarea numelor globale, dblink-urile sunt transparente utilizatorilor unui sistem de baze de date distribuite.
De exemplu, urmatorul query creaza un dblink intr-o baza de date locala pentru baza de date remote sales:
CREATE PUBLIC DATABASE LINK sales.divisional3.acme.com USING SALES;
-
Curs 10 25 SBDD
Tipuri de conexiuni intre baze de date Private. Utilizatorul care a creat conexiunea vede datele detinute prin:
DBA_DB_LINKS, ALL_DB_LINKS, USER_DB_LINKS. Creaza o conexiune intr-o anumita schema a bazei de date locale. Doar administratorul unui dblink privat sau al unui subprogram PL/SQL din schema poate utiliza aceasta conexiune pentru a accesa obiectele corespunzatoare bazei de date remote.
Public. Utilizator numit PUBLIC. Conexiune database-wide.Toti utilizatorii si subprogramele PL/SQL din baza de date pot utiliza conexiunea pentru a accesa obiectele din baza de date remote corespunzatoare.
Global. Utilizator numit PUBLIC. Conexiune network-wide. Cand o retea Oracle utilizeaza un server director, acesta creaza automat si intretine dblink-urile globale. Utilizatorii si subprogramele PL/SQL din orice baza de date pot utiliza o conexiune globala pentru a accesa obiectele din baza de date remote corespunzatoare.
-
Curs 10 26 SBDD
Tipuri de utilizatori - conexiuni
Connected user. Un utilizator local ce acceseaza un dblink in care nu a fost specificat nici un user sau parola fixata. Daca SYSTEM acceseaza o conexiune publica intr-un query, atunci uilizatorul la baza de date remote va fi SYSTEM. Ex: CREATE PUBLIC DATABASE LINK hq USING 'hq';
Current user. Un utilizator global intr-un dblink CURRENT_USER. Utilizatorul global trebuie autentificat de un certificat SSL sau o parola si trebuie sa fie utilizator al ambelor baze de date ale conexiunii. Acesta este un aspect al optiunii de securitate avansata ORACLE. Ex: CREATE PUBLIC DATABASE LINK hq CONNECT TO CURRENT_USER using 'hq';
Fixed user. Un utilizator ale carui nume si parola sunt precizate in definitia conexiunii. Daca o conexiune include un fixed user, atunci numele utilizatorului si parola vor fi folosite pentru conectarea la baza de date remote. Ex: CREATE PUBLIC DATABASE LINK hq CONNECT TO ioana IDENTIFIED BY acm1 USING 'hq';
-
Curs 10 27 SBDD
Denumirea obiectelor unei scheme
utilizand dblink-uri
Oracle utilizeaza numele global pentru a denumi global obiecte ale unei scheme utilizand urmatorul tipar:
schema.schema_object@global_database_name
Unde:
schema colectie de structuri de date logice, sau obiecte ale schemei. O schema este detinuta de un utilizator al bazei de date si are acelasi nume ca acel utilizator. Fiecare utilizator detine o singura schema.
schema_object o structura de date logica, precum tabel, index, view, sinonim, procedura, pachet sau dblink
global_database_name numele care identifica in mod unic o baza de date remote. Acest nume trebuie sa fie la fel ca si concatenarea intre parametrul de initializare al bazei de date remote DB_NAME si DB_DOMAIN.
-
Curs 10 28 SBDD
Ex:
SELECT * FROM mihai.emp@sales.division3.acme.com; SELECT loc FROM mihai.dept@sales.division3.acme.com;
Autorizarea pentru accesarea obiectelor unei scheme remote
Pentru a accesa obiectele unei scheme remote, utilizatorul trebuie sa aiba acces la obiectele remote.
Pentru operatii update, insert sau delete la un obiect remote, utilizatorul trebuie sa aiba privilegiile: SELECT si UPDATE, INSERT sau DELETE pe obiectul respectiv.
Spre deosebire de accesarea obiectelor locale, privilegiul de SELECT este necesar pentru accesarea obiectelor remote intrucat baza de date nu are capabilitatea de descriere remote.
Obs: Trebuie facut SELECT * pe obiectul remote pentru a determina structura acestuia.
-
Curs 10 29 SBDD
Restrictii dblink
Nu se pot efectua urmatoarele operatii utilizand dblink: Acordarea privilegiilor pentru obiecte remote Executarea operatiilor DESCRIBE pe anumite obiecte remote. Urmatoarele
obiecte remote suporta insa operatii DESCRIBE: Tabele View-uri Proceduri Functii
Analiza obiectelor remote Definirea sau fortarea integritatii referentiale Acordarea de roluri utilizatorilor intr-o baza de date remote Obtinerea de roluri non-default intr-o baza de date remote (nu se poate
folosi SET ROLE pentru obtinerea rolurilor non-default) Executarea de cereri ce utilizeaza conexiuni shared ale serverului Folosirea unui utilizator curent fara autentificare prin SSL sau macar parola.
-
Curs 10 30 SBDD
Caracteristici aplicatii distribuite Oracle
Transparenta in sistemele de baze de date distribuite Oracle
Prin transparenta un sistem distribuit apare ca si cand ar fi o singura baza de date Oracle.
Transparenta localizarii, adica ascunderea localizarii fizice a obiectelor bazei de date fata de aplicatie si utilizatori.
Accesul la datele remote este simplu, deoarece utilizatorii nu au nevoie sa stie locatia fizica a obiectelor bazei de date;
Administratorii pot muta obiectele fara a afecta utilizatorii sau aplicatiile existente.
Adiministratorii si programatorii utilizeaza sinonime pentru a asigura transparenta locatiei pentru tabele si obiectele din schema aplicatiei. Ex:
CREATE PUBLIC SYNONYM emp FOR scott.emp@sales.us.americas.acme_auto.com;
CREATE PUBLIC SYNONYM dept FOR scott.dept@sales.us.americas.acme_auto.com;
-
Curs 10 31 SBDD
Exemple cereri
Query fara sinonim:
SELECT ename, dname
FROM scott.emp@sales.us.americas.acme_auto.com e, scott.dept@sales.us.americas.acme_auto.com d
WHERE e.deptno = d.deptno;
Query cu sinonim:
SELECT ename, dname
FROM emp e, dept d
WHERE e.deptno = d.deptno;
-
Curs 10 32 SBDD
Transparenta pentru cereri si tranzactii
Instructiunile SQL standart precum SELECT, INSERT, UPDATE si DELETE functioneaza la fel ca intr-un sistem centralizat.
Acelasi lucru este valabil si pentru tranzactii: COMMIT, SAVEPOINT si ROLLBACK. Nu este nevoie de operatii speciale pentru a asigura controlul tranzactiilor in medii distribuite.
O tranzactie poate referi oricate tabele locale sau remote
Oracle asigura ca la toate nodurile implicate intr-o tranzactie distribuita se realizeaza acceasi actiune
Daca apare o eroare de retea sau de sistem in timpul unei operatii commit intr-o tranzactie distribuita exista un mod de rezolvare automata. La repornire, toate nodurile ori realizeaza operatia de commit ori pe cea de rollback a tranzactiei.
Fiecare tranzactie de commit are asociat intern un SCN (system change number) ce indentifica in mod unic modificarile realizate prin tranzactie.
-
Curs 10 33 SBDD
SCN-urile nodurilor ce comunica sunt coordonate cand: Este realizata o conexiune folosind calea descrisa de unul sau mai multe dblink-uri
Este executata o operatie SQL distribuita Este comisa o tranzactie distribuita
Programatorii pot utiliza pachete PL/SQL sau proceduri pentru aplicatii ce folosesc baze de date distribuite. Aplicatiile pot accesa local procedurile pentru a lucra cu baza de date locala si RPC pentru a lucra cu baza de date remote.
Cand un program apeleaza o procedura remote, serverul local paseaza toti parametrii procedurii catre serverul remote.
Exemplu, in urmatorul program PL/SQL se transmite parametrul 1257: BEGIN emp_mgmt.del_emp@sales.us.americas.acme_auto.com(1257); END; Pentru un RPC, procedura apelata trebuie sa existe pe serverul
remote, iar utilizatorii sa aiba privilegiile de a executa acea procedura
-
Curs 10 34 SBDD
Optimizarea cererilor distribuite
Optimizarea cererilor distribuite este o facilitate oferita de Oracle
pentru a reduce cantitatea de date transferata intre servere, atunci
cand o tranzactie aduce date dintr-o tabela remote referita intr-o
instructiune distribuita SQL.
Pentru optimizare se utilizeaza DRIVING_SITE, NO_MERGE si
INDEX, pentru a controla unde se proceseaza datele si cum sunt
accesate intr-un sistem distribuit Oracle.
DRIVING_SITE, forteaza executia cererii la un site selectat de
utilizator nu selectat de baza de date.
NO_MERGE, spune optimizatorului sa nu combine alte cereri si alte
vederi intr-o singura cerere.
-
Curs 10 35 SBDD
Tranzactii distribuite O tranzactie distribuita include una sau mai multe instructiuni care, individual sau
grupate, modifica date in doua sau mai multe noduri distincte ale unei baze de date distribuite
-
Curs 10 36 SBDD
Ex: tranzactie distribuita executata de utilizatorul scott modifica baza de date
locala sales, baza de date remote hq si baza de date remote maint:
UPDATE scott.dept@hq.us.acme.com
SET loc = REDWOOD SHORES WHERE deptno = 10;
UPDATE scott.emp
SET deptno = 11
WHERE deptno = 10;
UPDATE scott.bldg@maint.us.acme.com
SET room = 1225
WHERE room = 1163;
COMMIT;
Daca toate instructiunile unei tranzactii sunt adresate unui singur nod remote, tranzactia se numeste tranzactie remote nu distribuita.
Exista doua tipuri de operatii premise in tranzactiile distribuite:
Tranzactii DML si DDL
Instructiuni de control al tranzactiilor
-
Curs 10 37 SBDD
Operatii DML si DDL permise intr-o tranzactie distribuita:
CREATE TABLE AS SELECT
DELETE
INSERT
LOCK TABLE
SELECT
SELECT FOR UPDATE
Se pot executa instructiuni DML si DDL in parallel cu urmatoarele restrictii:
Toate operatiile remote trebuie sa fie instructiuni SELECT.
Aceste instructiuni nu trebuie sa fie clauze in alta tranzactie distribuita.
Daca tabela referentiata in table_expression_clause al unui INSERT, UPDATE sau DELETE este remote, executia este mai degraba seriala decat paralela.
Nu se pot efectua operatii remote dupa initierea operatiilor paralele DML/DDL sau INSERT
Nu se poate efectua nici o operatie recursiva pe tranzactia initiata de operatia paralela. De exemplu, nu se poate referi un obiect remote care este de fapt sinonimul unui obiect local.
Daca se efectueaza o operatie distribuita alta decat un SELECT in tranzactie, nici un DML nu este paralelizat.
-
Curs 10 38 SBDD
Control tranzactii
Pentru controlul tranzactiilor sunt utilizate:
COMMIT
ROLLBACK
SAVEPOINT
Arbori de sesiune pentru tranzactiile distribuite
Pe masura ce sunt executate instructiunile dintr-o tranzactie distribuita, baza de date isi defineste un arbore de sesiune al tuturor nodurilor participante la tranzactie. Un arbore de sesiune este un model ierarhic care descrie relatia dintre sesiuni si rolul acestora.
Toate nodurile participante in arborele de sesiune al unei tranzactii distribuite indeplinesc unul sau mai multe dintre urmatoarele roluri:
Client. Un nod care referentiaza informatia dintr-o baza de date apartinand altui nod.
Server. Un nod care primeste cereri de informatii de la un alt nod.
Coordonator global. Nodul care initiaza tranzactia distribuita.
Coordonator local. Un nod care este obligat sa referentieze date situate in alte noduri pentru a-si completa partea sa din tranzactie.
Commit point site. Nodul care face commit sau rollback pe tranzactie in functie de cerintele coordonatorului global.
-
Curs 10 39 SBDD
Client un nod actioneaza ca un client Database Servers. Nod ce gazduieste baza referita de client
Coordonator local. Nod care trebuie sa refere date de la alte noduri ca parte a unei tranzactii distribuite. Este responsabil de coordonarea tranzactiei cu nodurile cu care comunica: Receptia starii tranzactiei de la acele noduri
Transmiterea cererilor la aceste noduri
Receptia cererilor de la noduri si inaintarea lor la alte noduri
Returnarea rezultatelor la nodurile initiatoare
Coordonator global. Nodul care initiaza tranzactia distribuita. Coordonatorul global devine radacina arborelui sesiune si efectueaza urmatoarele operatii: Trimite RPC la nodurile referite
Instruieste toate nodurile referite in afara de commit point site sa faca prepararea tranzactiei
Instruieste commit point site sa initieze commit global daca toate nodurile raspund cu succes la preparare
Instruieste toate nodurile sa faca rollback global la tranzactie daca exista un raspuns de abort
-
Curs 10 40 SBDD
Commit Point Site. Rol de a initia commit sau rollback dupa
instructiunile coordonatorului global. Administratorul asociaza o
pondere astfel ca nodul cu date critice sa fie selectat commit point
site. Un astfel de nod nu intra in prepare si este realizata inaintea
altor noduri pentru a putea fi usor revocata.
O tranzactie este distribuita daca include una sau mai multe instructiuni
care individual sau in grup actualizeaza date la doua sau mai multe
locatii. De exemplu tranzactia:
UPDATE scott.dept@sales.us.americas.acme_auto.com
SET loc = 'NEW YORK'
WHERE deptno = 10;
UPDATE scott.emp
SET deptno = 11
WHERE deptno = 10;
COMMIT;
-
Curs 10 41 SBDD
Tranzactii in doua faze Spre deosebire de tranzactiile din baze de date locale tranzactiile
distribuite sunt mult mai complexe. Fie intreaga tranzactie este commit fie rollback.
Asigurarea integritatii datelor utilizand mecanismul two-phase commit.
Faza prepare, nodul initiator cere altor noduri sa asigure commit sau rollbacl la tranzactie
In faza commit, modul initiator cere tuturor participantilor sa comita tranzactia. Daca nu este posibil la toate nodurile se cere rollback.
Monitorizare automata a efectuarii tranzactiilor distribuite pentru a mentine integritatea datelor, mecanism cvomplet transparent fara sa ceara programare de catre utilizator.
Mecanismul commit:
Faza preparare coordonatorul global cere tuturor participantilor in afara de commit point site sa asigure commit sau rollback
Faza commit daca toti participantii raspund la preparare va cere la commit point site operatia de commit. Dupa ce acesta face commit cere la toate celelalte noduri sa commita tranzactia.
Faza forget coordonatorul global uita de tranzactie.
-
Curs 10 42 SBDD
Raspuns prepare
Cand un nod primeste prepare el poate raspunde:
Mesaj prepared. Nodul a inregistrat schimbarea in online log asa ca este pregatit pentru commit sau rollback.
Raspuns Read-Only. Daca nodul solicitat nu necesita afectarea datelor stocate ci doar selectii SQL. Ca urmare nodul nu participa la faza de commit.
Raspuns Abort. Atunci cand nodul nu poate face prepared cu succes va executa actiunile: Elibereaza resursele pastrate pentru tranzactie si face rollback pentru
portiunea locala a tranzactiei.
Raspunde la nodul care la referit intr-o tranzactie distribuita cu un mesaj abort.
Aceste actiuni se propaga la alte noduri pentru a face rollback la tranzactii in scopul pastrarii integritatii globale. Ca urmare fie toate nodurile commit, fie toate rollback la acelasi moment de timp logic.
-
Curs 10 43 SBDD
Pasi in faza prepare Toate nodurile in afar de commit point site realizeaza urmatorii pasi:
Cere nodurilor descendente prepare to commit.
Nodul verifica daca afecteaza date ce ii apartin sau nu (raspunde cu read-only).
Daca afecteaza datele detinute aloca resursele pentru commit tranzactie.
Salveaza redo records corespunzand modificarilor facute de tranzactie in redo log.
Nodul garanteaza ca blocarile pentru tranzactie sunt capabile sa preintampine defectarile.
Nodul raspunde initiatorului cu prepared response daca s-a produs, sau cu abort daca unul din descendentii sai nu poate face prepare cu succes.
Actiunile garanteaza commit sau rollback la nod si asteapta pana primeste COMMIT sau ROLLBACK de la coordonatorul global.
top related