BD9_baze de Date Distribuite

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


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


Implementari

1. Servere colaborative

2. Middleware system

Client Server

Server

Server

query

Client Middleware

Server

Server

Server

query


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


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,..)


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>


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


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)


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


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.


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


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.


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


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


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 [email protected]; SELECT loc FROM [email protected];

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 [email protected]_auto.com;

CREATE PUBLIC SYNONYM dept FOR [email protected]_auto.com;

Curs 10 31 SBDD

Exemple cereri

Query fara sinonim:

SELECT ename, dname

FROM [email protected]_auto.com e, [email protected]_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 [email protected]_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 [email protected]

SET loc = REDWOOD SHORES WHERE deptno = 10;

UPDATE scott.emp

SET deptno = 11

WHERE deptno = 10;

UPDATE [email protected]

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 [email protected]_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.

BD9_baze de Date Distribuite

Documents

Transcript of BD9_baze de Date Distribuite