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
R
1
R
2

R
11
R
12
R
21
R
22

H
H
V
V V V
>< ><
R
11
R
12
R
21
R
22

U
Baze de date distribuite 6
BD
Problema alocarii
Fie:
F = {F
1
,F
2
,.F
n
} setul de fragmente
S = {S
1
,S
2
,.S
m
} setul de siteuri
Q = {Q
1
,Q
2
,.Q
p
} 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 F
i
la un
site S
k
, costul executiei unei cereri la siteul S
k
, costul unei operatii
de tip update la F
i
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: P
nume
(S
responsabil = 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><Lucr11
Ang21=Ang2><Lucr21
Lucr11= S
responsabil =Popescu
(Lucr1) Lucr21= S
responsabil =Popescu
(Lucr2)
Site 1
Site 2
Site 3
Site 4
Baze de date distribuite 8
BD

O alta varianta poate fi:
P
Nume
((Ang1 U Ang2) >< (S
responsabil = 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 = {F
1
,F
2
,.F
n
} obtinuta din
fragmentarea relatiei R
Completitudinea pentru fiecare atribut x R exista F
j
astfel incat
x F
j

Neredondanta oricare ar fi x F
j
nu exista F
k
astfel incat x F
k

pentru j#k.
Reconstructia exista o functie g astfel incat R = g(F
1
,F
2
,.F
n
)

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 R
1
, R
2
si R
3
, datele sunt pastrate pe site A si
site B cu R
1
replicat se obtine

R
1
R
3

R
1
R
2

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
<local_name, site_referinta>
<local_name, site_referinta, replica_id>
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 <500
Cererea
SELECT AVG(VARSTA)
FROM ANGAJAT
WHERE 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_t
ools.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.