UNIVERSITATEA POLITEHNICA BUCURETI

Facultatea de Electronic Telecomunicaii !i In"ineria In#ormaiei

Catedra de Electronic A$licat !i In"ineria In#ormaiei
Metode concureniale de acces la baze de date distribuite.
Protocoalele 2-PL, Send-on-Demand.
Platformele SQL i Oracle.
Conductor tiini#ic U%P%B%&
Con#% 'r% In"% TEFAN ST(NCESCU
)a*terand&
Ba*tea +ABRIEL
BUCURESTI
,--.
1
Cuprins
1. Prezentare generala. Definitii......................................................................................3
1.1 Prezentare generala..............................................................................................3
2. FACILITATILE SI ARHITECTURA SISTEMULUI ORACLE....................................6
3. . FACILITATILE SI ARHITECTURA SISTEMULUI SL...........................................!
3.1 Tr"#"t$ri %ara%teri#ti%e ale li&'a($l$i SL...............................................................!
3.2 Set$l )e %*&enzi SL.............................................................................................1+
3.3 Ar,ite%t$ra SL-......................................................................................................1+
.. Pr*/riet"0i ale 'azel*r )e )ate rela0i*nale......................................................................11
..1 Pr*/riet"0ile rela0iil*r ta'elare.................................................................................12
..2 Definitii........................................................................................................................12
1. C*n%$renta #i %*n#i#tenta )atel*r..................................................................................13
1.1 Citirea %*n#i#tenta....................................................................................................13
1.2 Citirea %*n#i#tenta2 #eg&entele r*ll'a%3 #i tranza%tiile...........................................1.
1.3 Tranza%tii rea)4*nl5.................................................................................................1.
1.. Me%ani#&$l )e 'l*%are............................................................................................11
1.1 6l*%area a$t*&ata...................................................................................................11
1.6 6l*%area &an$ala....................................................................................................11
6. Pr*%e#are )i#tri'$ita #i 'aze )e )ate )i#tri'$ite.............................................................16
6.1 Ar,ite%t$ra %lient 7 #er8er- Pr*%e#are )i#tri'$ita......................................................16
9. Tranza%0ii.......................................................................................................................19
9.1 A:OMALII DE E;ECU<IE CO:CURE:TA A TRA:=AC<IILOR..................1>
9.2 PROPRIET?<ILE TRA:=AC<IILOR..................................................................21
9.3 ST?RILE TRA:=AC<IILOR................................................................................21
>. TEH:ICI DE CO:TROL AL CO:CURE:<EI..........................................................2.
>.1 CO:TROLUL CO:CURE:<EI............................................................................2.
>.2 A:ALI=A CO:TROLULUI CO:CURE:<EI.....................................................26
>.3 Te,ni%i */ti&i#te......................................................................................................33
>.. TEH:ICI DE REFACERE A 6A=ELOR DE DATE.............................................3.
!. CO:TROLUL TRA:=AC<IILOR..............................................................................3.
1+. 6l*%ari..........................................................................................................................39
1+.1 Dea)l*%3.................................................................................................................1
1+.2 Serializare...............................................................................................................2
1+.3 6l*%are ierar,i%@.....................................................................................................1
11. Pr*t*%*l$l An )*$" faze 24PL........................................................................................6
12. 2PL #tri%t.......................................................................................................................!
13. Pr*t*t*%*l$l #en)4*n4)e&an)......................................................................................1+
A/li%a'ilitate......................................................................................................................1.
C*n%l$zii............................................................................................................................1.
6i'li*grafie........................................................................................................................1.
2
1. Prezentare generala. Definitii.
1.1 Prezentare generala.
Modelul relaional a fost propus de ctre BM i a revoluionat
reprezentarea datelor fcnd trecerea la generaia a doua de baze de date.
Modelul este simplu, are o solid fundamentare teoretic fiind bazat pe
teoria seturilor (ansamblurilor) i pe logica matematic. Pot fi reprezentate toate
tipurile de structuri de date de mare complexitate, din diferite domenii de
activitate.
Modelul relaional este definit prin: structura de date, operatorii care
acioneaz asupra structurii i restriciile de integritate.
1) Conceptele utilizate pentru definirea structurii de date sunt:
domeniul, tabela (relaia), atributul, tuplul, cheia i schema tabelei.
Domeniu este un ansamblu de valori caracterizat printr-un nume. El poate
fi explicit sau implicit.
Tabela/relaia este un subansamblu al produsului cartezian al mai multor
domenii, caracterizat printr-un nume, prin care se definesc atributele ce aparin
aceleai clase de entiti.
Atributul este coloana unei tabele, caracterizat printr-un nume.
Cheia este un atribut sau un ansamblu de atribute care au rolul de a
identifica un tuplu dintr-o tabel. Tipuri de chei: primare/alternate,
simple/comune, externe.
Tuplul este linia dintr-o tabel i nu are nume. Ordinea liniilor (tupluri) i
coloanelor (atribute) dintr-o tabel nu trebuie s prezinte nici-o importan.
Schema tabelei este format din numele tabelei, urmat ntre paranteze
rotunde de lista atributelor, iar pentru fiecare atribut se precizeaz domeniul
asociat.
Schema bazei de date poate fi reprezentat printr-o diagram de structur
n care sunt puse n eviden i legturile dintre tabele. Definirea legturilor dintre
tabele se face logic construind asocieri ntre tabele cu ajutorul unor atribute de
legtur. Atributele implicate n realizarea legturilor se gsesc fie n tabelele
asociate, fie n tabele distincte construite special pentru legturi. Atributul din
tabela iniial se numete cheie extern iar cel din tabela final este cheie
primar. Legturile posibile sunt 1:1 1:m m:n. Potenial, orice tabel se poate
lega cu orice tabel, dup orice atribute.
Legturile se stabilesc la momentul descrierii datelor prin limbaje de descriere a
datelor (LDD), cu ajutorul restriciilor de integritate. Practic, se stabilesc i
legturi dinamice la momentul execuiei.
2) Operatorii modelului relaional sunt operatorii din algebra relaional
i operatorii din calculul relaional.
3
Algebra relaional este o colecie de operaii formale aplicate asupra
tabelelor (relaiilor), i a fost conceput de E.F.Codd. Operaiile sunt aplicate n
expresiile algebrice relaionale care sunt cereri de regsire. Acestea sunt
compuse din operatorii relaionali i operanzi.
!peranzii sunt ntotdeauna tabele (una sau mai multe). "ezultatul
evalurii unei expresii relaionale este format dintr-o singur tabel. Algebra
relaional are cel puin puterea de regsire a calcului relaional. O expresie din
calculul relaional se poate transforma ntr-una echi#alent din algebra
relaional i invers. Codd a introdus ase operatori de baz (reuniunea,
diferena, produsul cartezian, selecia, proiecia, jonciunea) i doi operatori
deri#ai (intersecia i diviziunea).
Ulterior au fost introdui i ali operatori derivai (speciali). n acest context,
operatorii din algebra relaional pot fi grupai n dou categorii: pe mulimi i
speciali. !peratori pe mulimi (R1, R2, R3 sunt relaii (tabele)) sunt:
"euniunea. R3 = R1 R2, unde R3 va conine tupluri din R1 sau R2
luate o singur dat;
Diferena$ R3 = R1 \ R2, unde R3 va conine tupluri din R1 care nu se
regsesc n R2;
%rodusul cartezian$ R3 = R1 R2, unde R3 va conine tupluri construite
din perechi (x1x2), cu x1R1 i x2R2;
&ntersecia$ R3 = R1 i R2, unde R3 va conine tupluri care se gsesc n
R1 i R2 n acelai timp, etc.
!peratori relaionali speciali sunt:
Selecia. Din R1 se obine o subtabel R2, care va conine o submulime
din tuplurile iniiale din R1 ce satisfac un predicat (o condiie). Numrul de
atribute din R2 este egal cu numrul de atribute din R1. Numrul de tupluri din
R2 este mai mic dect numrul de tupluri din R1.
%roiecia$ Din R1 se obine o subtabel R2, care va conine o
submulime din atributele iniiale din R1 i fr tupluri duplicate. Numrul de
atribute din R2 este mai mic dect numrul de atribute din R1.
'onciunea este o derivaie a produsului cartezian, ce presupune
utilizarea unui calificator care s permit compararea valorilor
unor atribute din R1 i R2, iar rezultatul n R3. R1 i R2 trebuie s aib unul sau
mai multe atribute comune care au valori comune. Algebra relaional este prin
definiie neprocedural (descriptiv), iar calculul relaional permite o manier de
cutare mixt (procedural/neprocedural).
Calculul relaional se bazeaz pe calculul predicatelor de ordinul nti
(domeniu al logicii) i a fost propus de E.F. Codd. %redicatul este o relaie care
se stabilete ntre anumite elemente i care poate fi confirmat sau nu.
%redicatul de ordinul 1 este o relaie care are drept argumente variabile
care nu sunt predicate. (ariabila poate fi de tip tuplu (valorile sunt dintr-un tuplu
al unei tabele) sau domeniu (valorile sunt dintr-un domeniu al unei tabele).
Construcia de baz n calculul relaional este expresia relaional de
calcul tuplu sau domeniu (funcie de tipul variabilei utilizate).
Expresia relaional de calcul este format din: operaia de efectuat,
variabile (tuplu respectiv domeniu), condiii (de comparaie, de existen),
.
formule bine definite (operanzi-constante, variabile, funcii, predicate; operatori),
cuantificatori. Pentru implementarea acestor operatori exist comenzi specifice n
limbajele de manipulare a datelor (LMD) din sistemele de gestiune a bazelor de
date relaionale (SGBDR). Aceste comenzi sunt utilizate n operaii de regsire
(interogare).
Dup tehnica folosit la manipulare, LMD sunt bazate pe:
calculul relaional (QUEL n ngres, ALPHA propus de Codd);
algebra relaional (SBL, RDMS);
transformare (SQL, SQUARE);
grafic (QBE, QBF).
Transformarea ofer o putere de regsire echi#alent cu cea din calculul
i algebra relaional. Se bazeaz pe transformarea (mapping) unui atribut sau
grup de atribute ntr-un atribut dorit prin intermediul unor relaii.
"ezultatul este o relaie (tabel) care se poate utiliza ntr-o alt
transformare. )rafica ofer interacti#itate mare pentru constrirea cererilor de
regsire. Utilizatorul specific cerea aleg*nd sau completnd un ecran structurat
grafic. Poate fi folosit de ctre toate categoriile de utilizatori n informatic.
3) estriciile de integritate ale modelului relaional sunt structurale +i
comportamentale.
"estriciile structurale sunt:
1 "estricia de unicitate a cheii. ntr-o tabel nu trebuie s existe mai
multe tupluri cu aceeai valoare pentru ansamblul cheie;
2 "estricia referenial. ntr-o tabel t1 care refer o tabel t2, valorile
cheii externe trebuie s figureze printre valorile cheii primare din t2 sau
s ia valoarea null (neprecizat);
3 "estricia entitii$ ntr-o tabel, atributele din cheia primar nu trebuie
s ia valoarea NULL.
Cele trei restricii de mai sus sunt minimale.
Pe lng acestea, exist o serie de alte restricii structurale care se refer
la dependenele dintre date: funcionale, multivaloare, jonciune etc. (sunt luate n
considerare la tehnicile de proiectare a bazelor de date relaionale - BDR).
"estriciile de comportament sunt cele care se definesc prin
comportamentul datelor i in cont de valorile din BDR:
1 Restricia de domeniu$ Domeniul corespunztor unui atribut dintr-o
tabel trebuie s se ncadreze ntre anumite valori;
2 Restricii temporare. Valorile anumitor atribute se compar cu nite
valori temporare (rezultate din calcule etc.).
1
Restriciile de comportament fiind foarte generale se gestioneaz fie la
momentul descrierii datelor (de exemplu prin clauza CHECK), fie n afara
modelului la momentul execuiei.
Restriciile de integritate suportate de Oracle sunt:
1 NOT NULL nu permite valori NULL n coloanele unei tabele;
2 UNQUE nu sunt permise valori duplicat n coloanele unei tabele;
3 PRMARY KEY nu permite valori duplicate sau NULL n coloana sau
coloanele definite astfel;
4 FOREGN KEY presupune ca fiecare valoare din coloana sau setul de
coloane defini astfel s aib o valoare corespondent identic n tabela
de legtur, tabel n care coloana corespondent este definit cu
restricia UNQUE sau PRMARY KEY;
5 CHECK elimin valorile care nu satisfac anumite cerine (condiii)
logice.
Termenul de chei (keys) este folosit pentru definirea ctorva categorii de
constrngeri i sunt: primar, -e, uni.ue -e, foreign -e, referenced -e,$
Se consider c modelul relaional are o serie de limite cum ar fi:
1 Simplitatea modelului l face dificil de aplicat pentru noile tipuri
de aplicaii (multimedia, internet etc.);
Nu asigur o independen logic total a datelor de aplicaie; Poate crete
redundana datelor.
EXEMPLE DE SSTEME DE GESTUNE A BAZELOR DE DATE RELA|ONALE
Oracle. Este realizat de firma Oracle Corporation USA. Sistemul este complet
relaional, robust, se bazeaz pe SQL standard extins. Arhitectura sistemului este
client / server, permnd lucrul, cu obiecte i distribuit. Are BD nternet i modul
de optimizare a regsirii. Ultima versiune este Oracle 11g.
SQL Server$ Este realizat de firma Microsoft. Se bazeaz pe SQL i ruleaz n
arhitectura client/server. Ultima versiune este SQL Server 2005.
!. "AC#$#%A%#$& '# A(#%&C%)A '#'%&M)$)# OAC$&
Componentele care formeaz arhitectura de baz Oracle sunt dispuse
ntr-o configuraie client/server. Aceste componente sunt plasate pe calculatoare
diferite ntr-o reea asigurnd funcionaliti specifice, astfel: ser#erul asigur
memorarea i manipularea datelor, precum i administrarea bazei de date iar
clientul asigur interfaa cu utilizatorul i lanseaz aplicaia care acceseaz
datele din baza de date.
6
Fig 2.1 Arhitectura sistemului Oracle
Arhitectura Oracle se ncadreaz n tendinele actuale i anume este
structurat pe trei niveluri: nucleul, interfeele i instrumentele de ntreinere.
/ucleul !racle conine componentele care dau tipul relaional pentru
SGBD Oracle: limbajul relaional de regsire SQL i limbajul procedural propriu
PL/SQL.
Sistemul Oracle creeaz i ntreine automat dicionarul de date$ Acesta
face parte din baza de date Oracle i conine un set de tabele i viziuni (vederi)
accesibile utilizatorilor doar n consultare. Dicionarul conine informaii de tipul:
numele utilizatorilor autorizai, drepturile de acces, numele obiectelor din baza de
date, structurile de date, spaiul ocupat de date, chei de acces etc.
&nterfeele sunt componentele care permit dezvoltarea aplicaiilor cu BD,
astfel:
1 DEVELOPER SUTE este componenta destinat dez#oltatorilor
0programatorilor1 de aplicaii. Conine generatoarele FORMS (meniuri
i videoformate), REPORTS (rapoarte i grafice), JDEVELOPER;
2 DESGNER este component destinat anali+tilor/proiectanilor de
aplicaii. Ofer elemente de CASE pentru proiectarea aplicaiilor cu
BD;
3 PRO*C este componenta destinat programatorilor 2n limba3ele de
programare uni#ersale (FORTRAN, COBOL, Pascal, C, ADA, PL1);
4 DATAWAREHOUSE BULDER este destinat analizei datelor
multidimensionale, folosind tehnologia de tip OLAP (On Line Analitical
Processing);
5 ORACLE APPLCATONS permite dezvoltarea unor aplicaii de
ntreprindere (Financials, Manufacturing, Projects etc.);
9
&nstrumentele sunt componente destinate ntreinerii i bunei funcionri a
unei BD Oracle. ENTERPRSE MANAGER CONSOLE conine mai multe utilitare
destinate administratorului BD (deschidere/nchidere BD, autorizarea accesului,
refacerea BD, conversii de date, etc.).
%rocesele bac-ground 04ac-ground processes1 sunt create pentru fiecare
instan Oracle pentru a executa asincron anumite funcii.
Acestea sunt:
1 Database 5riter 0D45"1 scrie datele modificate n baza de date;
2 6og 5riter 06)5"1 scrie nregistrrile redo log pe disc;
3 Chec-point 0C7%T1 scrie nregistrrile checkpoint la timpul potrivit ;
4 S,stem 8onitor 0S8!/1 execut recuperarea unei instane la
momentul pornirii, colecteaz spaiul liber etc;
5 %rocess 8onitor 0%8!/1 recupereaz procesele utilizator dac
acestea cad accidental;
6 Archi#er 0A"C91 copiaz n mod online fiierele Redo Log n fiiere de
arhiv atunci cnd acestea se umplu cu datei;
7 "eco#erer 0":C!1 rezolv tranzaciile suspendate n sistemul cu baze
de date distribuite;
8 Dispacher 0Dnnn1 folosit n sistemul multithreaded;
1 Lock (LCKn) blochez procesele n sistemul Parallel server.
Legtura dintre procesele utilizator i procesele Oracle este prezentat n
figura de mai jos :
>
Fig 2.2 Legtura dintre procesele utilizator i procesele Oracle .
3. . "AC#$#%A%#$& '# A(#%&C%)A '#'%&M)$)# '*$
SQL poate fi folosit astfel:
direct la terminal, adic n mod comand (interactiv, sau batch)
Cu ajutorul tools-urilor SQL (Query Analyzer , Enterprize
Manager,Business nteligence etc in functie de versiunea utilizata ).
n cadrul unor programe scrise ntr-un limbaj de programare, precum C++,
C# , Visual Basic etc.
n concluzie: Un sistem de management al bazei de date necesit un limbaj de
interogare pentru a permite utilizatorului s acceseze datele. SQL (iniial numit
SEQUEL, ca limbaj de interogare structurat) este limbajul standardizat ANS i
SO, utilizat de majoritatea sistemelor ce manevreaz baze de date relaionale.
3.1 Trsturi caracteristice ale limbajului SQL
SQL, folosete cuvinte din limba englez. n mod special cuvintele select+
update+ insert+ delete ca elemente ale setului de comenzi.
SQL este un limbaj neprocedural: specific care sunt informaiile dorite, nu
cum se obin acestea. Cu alte cuvinte, SQL nu cere s fie specificat
metoda de acces la date.
Execuia comenzilor SQL asupra nregistrrilor nu se poate face dect
secvenial, asupra cte unei singure nregistrri. Setul de nregistrri fiind
vzut ca set de linii ale unui tabel.
SQL poate fi folosit de un ir de utilizatori, incluznd administratorul bazei
de date, programatorii de aplicaii, personalul de management i multe
alte tipuri de utilizatori.
SQL include comenzi pentru o varietate de sarcini, incluznd:
o selecia unor date
o inserarea, extragerea i tergerea rndurilor dintr-un tabel
o crearea, modificarea i tergerea obiectelor de tip baz de date
o controlul accesului la baza de date i la obiectele de tip baz de
date
o verificarea - garantarea consistenei bazei de date
La nceput, sistemele de management a bazelor de date au utilizat un limbaj
separat pentru fiecare categorie de sarcini n parte. SQL le-a unificat pe toate
acestea ntr-un singur limbaj.
Logic, comenzile limbajului SQL sunt mprite n trei componente:
!
limbajul de definire a datelor (Data Definition 6anguage)- DDL,
limbajul de manipulare a datelor (Data 8anipulation 6anguage)- DML,
limbajul de control al datelor (Data Control 6anguage)-DCL.
Primul pentru crearea structurii de baz de date, al doilea, dup ce structura
exist, pentru a aduga date n tabele i pentru a le manipula. A treia
component ofer posibilitatea de a proteja (securiza) datele.
3.2 Setul de cmenzi SQL
Comenzile de definire a datelor (DD$): CREATE, ALTER, DROP
aceste trei comenzi sunt utilizate dinamic pentru a crea, utiliza i terge orice
structur de date, n particular tabele.
Comenzile de manipulare a datelor (DM$): NSERT, UPDATE, DELETE i
SELECT
utilizate pentru a introduce noi rnduri, pentru a schimba (actualiza) rndurile
existente, pentru a terge rndurile nedorite din baza de date respectiv, i, n
fine, SELECT - comanda cea mai utilizat, folosit pentru a cuta, a selecta
nregistrri din tabel sau dintr-o combinaie de tabele ale bazei de date.
Comenzile de control (grupul DC$), la dispoziia administratorului(DBA): GRANT,
REVOKE utilizate pentru a da sau a lua drepturi de acces (la comenzi DML, deci
la operarea unor modificri a bazei de date).
Sintaxa comenzilor difer de la un grup la altul. Ne limitm acum doar la un
exemplu:
CREATE TABLE [dbo].[IC] (
[Institutie] [char] (10) COLLATE RomanianCIA!
"#LL $
[%unctia] [char] (100) COLLATE RomanianCIA! "#LL $
[te&e%on] [char] (10) COLLATE RomanianCIA! "#LL
3.3 !r"itectura SQL#
1+
Fig . 3.1 Ar,ite%t$ra Si#te&$l$i SL
,. Proprieti ale bazelor de date relaionale
O baz de date relaional apare ca o colecie de relaii (tabele)
Exist o mulime de operatori pentru transformarea i combinarea
relaiilor:
o selecia,
o proiecia,
o produsul,
o 3oin-ul,
o reuniunea,
o intersecia,
o diferena.
Nu apar pointeri; conexiunile sunt fcute numai pe baza datelor.
Exist o independen total a datelor.
Limbajul utilizat pentru interogarea bazei de date este non-procedural i
similar limbii engleze.
Utilizatorul nu specific calea de acces i nu are nevoie s tie cum este
aranjat fizic informaia.
11
Comenzile pentru selecia sau refacerea datelor, ct i acelea pentru
realizarea schimbrilor n baza de date sunt incluse ntr-un singur limbaj,
standardizat acum ca '*$.
$.1 Pr%riet&ile rela&iilr tabelare
Fiecare tabel, individual, are urmtoarele proprieti:
Nu exist rnduri duplicate
Nu exist nume de coloane identice (duplicate)
Ordinea rndurilor este neimportant
Ordinea coloanelor este neimportant
Valorile (cmpurile) sunt atomice (nedecompozabile).
,.! Definitii.
Tabela sau relaia este un ansamblu format din n coloane
(atribute/subansambluri) i m rnduri (tupluri/linii) care respect urmtoarele
condiii minime: nu conine date la nivel agregat (valorile aflate la intersecia
liniilor cu coloanele s fie la un nivel elementar); liniile sunt distincte unele fa de
altele; nu conine coloane repetitive n descriere.
Cheia primar este un atribut care are valori distincte. Deci, fiecare linie
se identific printr-o valoare distinct. Dou sau mai multe atribute care pot fi
chei primare se numesc chei candidate.
Cheile sunt de trei tipuri : cheie candidat, cheie primar i cheie surogat.
Orice atribut sau combinaie de atribute care identific n mod unic o
instan a unui tip de entitate se numete cheie candidat. Cheia candidat care a
fost aleas ca identificator pentru un tip de entitate se numete cheie primar.
Cheia surogat este atributul introdus artificial la o entitate pe post de
cheie primar.
n general, cheile sunt chei simple atunci cnd sunt formate dintr-un singur
atribut i chei compuse cnd sunt formate din mai multe atribute, caz n care
conteaz i ordinea n care sunt precizate atributele (cheile compuse sunt
poziio-nale).
Coloana tabelei este format din valorile pe care le ia atributul n liniile
tabelei respective.
Rndul / tuplul / linia este format din valorile coloanelor ce se refer la o
entitate a tabelei.
-aza de date relaional este un ansamblu de tabele normalizate,
grupate n jurul unui subiect, n principiu, bine definit. ntr-o baz de date
relaional, entitile i legturile sunt transpuse n tabele.
Viziunea este o tabela logic i reprezint o fereastr la date, dintr-una
sau mai multe tabele.
Pentru ca accesul la date sa se fac mai rapid, se utilizeaz indexarea.
12
Un inde. reprezint o cheie pe una sau mai multe coloane. ndexarea
este dinamic deoarece se pot adaug sau terge indeci oricnd, fr ca datele
memorate sau aplicaiile scrise s fie afectate.
Pentru realizarea unor operaii sau pentru a utiliza n cereri nume mai
scurte, se pot defini sinonime ale unor nume de tabele sau viziuni.
Un cluster reprezint o anumit modalitate de grupare a rndurilor uneia
sau mai multor tabele. Aceast grupare mrete viteza de execuie a unor
operaii consumatoare de timp.
Comanda este o instruciune emis din SQL ctre o baz de date Oracle
respectiv SQL.
-locul reprezint un grup de instruciuni SQL.
Cererea este o comanda SQL (SELECT) care regsete date din baza de
date. Rezultatul cererii l formeaz datele regsite din baza de date.
aportul este rezultatul cererii formatat cu ajutorul comenzilor si poate fi
afisat in format .csv, importat in .xls din format csv, sau afisat cu ajutorul aplicatiei
Crystal Reports.
/. Concurenta si consistenta datelor
Principala grija a unui sistem de gestiune a bazelor de date multiuser este
modul cum controleaza concurenta sau accesul simultan la aceeasi data de
catre mai multi utilizatori. Fara un control adecvat al concurentei, datele pot fi
actualizate si schimbate necorespunzator compromitind integritatea datelor.
Daca mai mulit utilizatori acceseaza aceeasi data, o cale de a gestiona
concurenta este de a face ca fiecare sa-si astepte rindul.
Scopul sistemului de gestiune a bazelor de date este de a face aceasta
asteptare inexistenta sau neglijabila pentru fiecare utilizator. Toate comenzile de
manipulare a datelor (DML) vor trebui efectuate astfel incit sa fie prevenita
interactiunea distructiva intre tranzactiile concurente.
nteractiunea distructiva este oricare interactiune care actualizeaza
incorect date sau modifica incorect structura datelor.
Oracle rezolva aceste probleme folosind un tip variat de blocari si un
modul de consistenta multiversiune. Aceste caracteristici sint bazate pe
conceptul de tranzactie.
5.1 'itirea cnsistenta
Citirea consistenta, suportata de Oracle, face urmatoarele:
- garanteaza ca setul de date consultate de o comanda este consistent cu
respectarea unui singur moment de timp si nu se schimba in cursul executiei
comenzii (citire consistenta la nivel de comanda) ;
1- asigura ca cititorii datelor nu asteapta pentru scriere sau dupa alti cititori ai
aceleasi date ;
13
2- asigura ca cei care scriu in baza de date nu asteapta numai dupa altii care
scriu daca acestia incearca sa actualizeze rinduri identice in tranzactii
concurente.
Modul simplu in care se intelege implementarea Oracle a citirii consistente este
de a se imagina ca fiecare utilizator opereaza o copie privata a bazei de date, de
aici modelul de consistenta multi0ersiune.
5.2 'itirea cnsistenta( segmentele rllbac) si tranzactiile
Pentru a gestiona modelul consistenta multiversiune, Oracle trebuie sa
creeze un set de date citire consistenta cind o tabela este interogata (citita) sau
actualizata (scrisa) simultan.
Cind se intilneste o actualizare, valorile originale ale datelor schimbate prin
actualizare sint scrise in segmentul rollback al bazei de date.
Atita timp cit aceste actualizari ramin parte a unei tranzactii nerealizate,
oricare utilizator care mai tirziu interogheaza datele modificate vede valorile
originale ale datelor.
Oracle foloseste informatia curenta din SGA si informatia din segmentul
rollback pentru a construi o vizualizare consistenta ( "read-consistent view)
pentru datele tabelei interogate.
Numai cind o tranzactie este comisa schimbarile tranzactiei sint facute
permanente. Comenzile lansate dupa ce tranzactia utilizatorului este realizata
vad numai schimbarile facute prin intermediul tranzactiei realizate.
De notat ca tranzactia este cheia strategiei Oracle pentru a furniza citirea
consistenta.
Aceasta unitate a comenzilor SQL de realizare (sau nerealizare)
1 dicteaza punctul de start pentru view-urile de citire consistenta generate in
beneficiul cititorilor
2 controleaza cind datele modificate pot fi vazute de alte tranzactii ale bazei de
date pentru citire sau actualizare
5.3 Tranzactii read*nl+
mplicit, Oracle garanteaza citire consistenta la nivel de comanda. Aceasta
stabileste ca setul de date returnat de o singura cerere este consistent cu
respectarea unui moment de tip.
Totusi, in anumite situatii, se poate cere citire consistenta la nivel de
tranzactie - capacitatea de a rula mai multe cereri intr-o singura tranzactie, toate
fiind citiri consistente cu respectarea aceluiasi moment de timp astfel incit
cererile acestei tranzactii sa nu vada efectele intervenite prin tranzactiile
efectuate.
Daca se doreste rularea unui numar de cereri intre tabele multiple si nu se
doreste actualizarea se prefera tranzactiile read-only. Dupa indicarea ca
tranzactia este read-only, se pot executa mai multe cereri intre orice tabele,
1.
cunoscind ca rezultatul oricarei cereri este consistent cu respectarea aceluiasi
moment de timp.
5.$ ,ecanismul de blcare
Oracle foloseste blocarea pentru a controla accesul concurent la date.
Blocarea este un mecanism cu intentia de a preveni interactiunile
distructive intre utilizatorii care acceseaza date Oracle respectiv SQL.
Blocarea este utilizata pentru a realiza doua scopuri importante ale bazei de
date:
14 consistenta - asigura ca, datele unui utilizator sau schimbarile nu sint efectuate
(de alti utilizatori) pina cind utilizatorul nu termina cu datele.
24 integritatea - asigura ca datele bazei de date si structurile reflecta toate
schimbarile facute in acestea in secventa corecta.
Blocarea garanteaza integritatea datelor prin furnizarea accesului concurent
maxim la date pentru un numar nelimitat de utilizatori.
5.5 -lcarea autmata
Oracle executa blocarea automata si nu cere actiunea utilizatorului.
Blocarea implicita intilnita pentru comenzi SQL la nevoie, depinde de
actiunea ceruta.
Managerul de blocare Oracle automat blocheaza datele tabelei la nivel de
rind. Prin blocarea datelor la nivel de rind, conflictele pentru aceleasi date sint
minimizate.
Managerul Oracle mentine citeva tipuri de blocare a rindurilor, depinzind de tipul
operatiei care stabileste blocarea. n general sint doua tipuri de blocare: blocare
e.clusi0a si blocare parta1ata.
:$&ai * 'l*%are eB%l$#i8a /*ate *'tine * re#$r#a C%$& ar fi $n rin) #a$ * ta'elaDE
t*t$#i2 &ai &$lte 'l*%ari /arta(ate /*t *'tine * #ing$ra re#$r#a. A&'ele 'l*%ari /er&it
inter*garea re#$r#ei 'l*%ate )ar interzi% alte a%ti8itati a#$/ra re#$r#ei C%a a%t$alizare #a$
#tergereD.
5.. -lcarea manuala
n anumite circumstante, utilizatorul poate modifica blocarea implicita.
Oracle permite modificarea manuala a caracteristicilor blocarii automate la nivel
de rind (prin prima cerere pentru rindurile care vor fi actualizate in comanda
urmatoare) si la nivel de tabela.
11
2. Procesare distribuita si baze de date distribuite
Lucrul calculatoarelor in retea devine din ce in ce mai obisnuit in mediile
de calcul de zi cu zi de aceea sistemele de gestiune a bazelor de date trebuie sa
fie capabile sa ia avantajele proceselor si capacitatilor de memorare distribuite.
..1 !r"itectura client / server# Prcesare distribuita
Procesarea distribuita foloseste mai mult de un procesor pentru a imparti
procesarea unui set stabilit de lucrari. Procesarea distribuita reduce incarcarea
procesului la un singur procesor permitind diferitelor procesoare sa se
concentreze la un subset de sarcini (taskuri), prin aceasta crescind capacitatile si
performanta sistemului.
O baza de date Oracle poate lua usor avantajele procesarii distribuite
folosind arhitectura client/server. n aceasta arhitectura baza de date sistem este
impartita in doua parti: front3end sau portiunea client si bac43end sau portiunea
server.
Portiunea client - este partea aplicatiei bazei de date care interactioneaza
cu tastatura, monitorul si mousele; Nu are responsabilitati de accesare a datelor;
concentreaza cererea, procesarea si prezentarea datelor gestionate de portiunea
server. Statiile de lucru client pot fi optimizate pentru aceste lucrari. Ele nu
necesita discuri de capacitati mari dar beneficiaza de capacitati grafice sporite.
Portiunea server - ruleaza softul Oracle si manipuleaza functiunile cerute
pentru accesul concurent si partajat la date. Portiunea server receptioneaza si
proceseaza comenzile SQL si PL/SQL generate de aplicatia client. Calculatorul
care gestioneaza partea server poate fi optimizat pentru realizarea acestuia:
discuri de capacitate mare si procesoare rapide.
Realizarea in doua faze
Oracle furnizeaza aceeasi siguranta a consistentei in mediu distribuit ca si
in mediu nedistribuit. Oracle furnizeaza aceasta siguranta folosind modelul
tranzactional si mecanismul de realizare in doua faze.
Ca si intr-un sistem nedistribuit, tranzactiile vor fi planificate exact sa
includa un set logic de comenzi SQL care se vor succede.
Mecanismul Oracle de realizare in doua faze garanteaza ca indiferent de tipul
defectiunii intilnite, sistem sau retea, se realizeaza o tranzactie distribuita sau o
anuleaza in toate nodurile implicate pentru mentinerea consistentei datelor intre
baza de date distribuita globala.
16
5. %ranzacii
n mod obinuit, un sistem SGBD deservete mai muli utilizatori, care
acceseaz concurent datele din tabele. Accesul concurent al utilizatorilor este
asigurat prin capacitatea de multiprogramare a sistemului de operare al
calculatorului gazd, care permite execuia concurent a mai multor procese.
Execuia concurent a mai multor procese poate avea loc att ntr-un sistem
uniprocesor, prin partajarea (mprirea) timpului de execuie al procesorului ntre
mai multe procese, ct i ntr-un sistem multiprocesor n care mai multe procese
pot fi executate n mod real simultan, pe mai multe procesoare ale sistemului.
ndiferent de numrul de procesoare ale sistemului, accesul concurent al mai
multor utilizatori la datele memorate n tabelele unei baze de date necesit
tehnici de meninere a consistenei (corectitudinii) i a siguranei datelor
memorate.
Meninerea consistenei i a siguranei bazelor de date n situaia n care
mai muli utilizatori le acceseaz concurent i n condiiile n care pot s apar
erori de funcionare (defecte) ale sistemului de calcul se bazeaz pe conceptul
de tranzacie care va fi prezentat n seciunea urmtoare.
! tranzacie (transaction) este o unitate logic de prelucrare indi#izibil
(atomic) a datelor unei baze de date prin care se asigur consistena acesteia$
n principiu, orice execuie a unui program care acceseaz o baz de date
poate fi considerat o tranzacie, dac baza de date este ntr-o stare consistent
att nainte ct i dup execuie. O tranzacie trebuie s asigure consistena
bazei de date indiferent dac a fost executat individual sau concurent cu alte
tranzacii precum i n condiiile n care au aprut defecte ale sistemului
hardware n cursul execuiei tranzaciei.
Se va studia problema consistenei bazelor de date pe exemplul unui
sistem de rezervare a locurilor la curse aeriene. Un numr mare de ageni de
vnzri vor accesa relaiile care memoreaz datele de rezervare i vnzare a
biletelor de avion. De exemplu, vor exista relaiile:
C#R!E(IdCursa$Aero'ort(&ecare$Aero'ort!osire$)ata$
"rLocuriLibere)
(A!A*ERI(Id(asa+er$"ume$(renume$Adresa$ "rCreditCard)
RE,ER-ARI(IdRe.er/are$IdPasager$IdCursa)
0ACT#RI(Id0actura$IdPasager$)ata0acturarii$(ret)
Cheile primare i strine au fost marcate conform conveniilor care au mai
fost folosite i n seciunile precedente, iar semnificaia atributelor acestor relaii
este destul de clar exprimat chiar prin numele lor. Detalii ca: tipul locului
rezervat (turist, business, etc), reduceri de plat a biletului (bilet copil, etc.), mai
multe rezervri fcute de acelai client, intervalul de timp dintre rezervare i
cumprarea biletului, posibilitatea ca o rezervare s fie anulat, etc., au fost
ignorate, dat fiind c nu modific fondul problemei de consisten a bazei de
date.
19
Atunci cnd un agent de vnzri rezerv un loc la o curs i vinde biletul
corespunztor, se efectueaz mai multe operaii:
11. Se insereaz o linie nou n tabelul PASAGER, care conine datele
pasagerului.
22. Dac exist locuri libere la cursa dorit, atunci se face propriu-zis
rezervarea, prin inserarea unei linii noi n tabelul REZERVAR, linie
care conine numrul de identificare al pasagerului, numrul de
identificare al cursei i (eventual) numrul locului rezervat; altfel,
rezervarea este imposibil.
33. La achitarea biletului se insereaz o linie n tabelul FACTUR. Acest
nregistrare este folosit pentru a tipri o factur, care va fi folosit
pentru plata n numerar sau va fi trimis companiei de cri de credit.
44. Se emite (tiprete) biletul (pornind de la datele din rezervare i
factura corespunztoare).
Dac sistemul se defecteaz dup ce s-a executat pasul 2, s-a fcut o
rezervare, dar biletul nu a fost facturat i nici emis. Mai ru, dac defeciunea are
loc dup ce s-a executat pasul 3, atunci clientului i se trimite factura, dar el nu a
primit biletul. Astfel de situaii sunt, bineneles, inacceptabile.
Chiar dac nu se defecteaz sistemul, pot s apar probleme dac baza
de date este accesat concurent de mai muli utilizatori. De exemplu, dac doi
ageni de vnzri atribuie acelai loc la doi pasageri diferii, atunci vor fi probleme
la mbarcarea pasagerilor.
Dac toate aciunile aferente unei rezervri ar fi grupate ca o operaie
indivizibil (atomic), o parte din problemele artate mai sus ar disprea.
O operaie indivizibil de acces la baza de date este numit tranzacie i
ea fie execut cu succes toate aciunile i se termin cu o validare a modificrilor
efectuate asupra bazei de date (commit), fie nu poate efectua (din diferite
motive) toate aciunile i este abandonat i anulat (abort, rollbac-).
n cazul n care o tranzacie a efectuat cu succes toate aciunile i este
validat, n momentul validrii toate modificrile efectute asupra bazei de date
devin permanente (durabile), vor fi vizibile altor tranzacii i nu mai pot fi anulate.
Pn n momentul validrii, modificrile efectuate de tranzacie au un caracter
provizoriu, nu sunt vizibile altor tranzacii i pot fi oricnd revocate (anulate).
n cazul abandonrii unei tranzacii, execuia acesteia este oprit i
efectele tuturor aciunilor executate pn n momentul abandonrii sunt anulate,
astfel nct baza de date este adus n starea de dinaintea lansrii tranzaciei.
0.1 !1O,!L22 34 454'6724 'O1'6841T! ! T8!19!'722LO8
Pentru studierea controlului concurenei i al refacerii datelor se vor
aborda operaiile asupra bazei de date la nivel de articol de date (data item) i
1>
bloc de memorare pe disc. La acest nivel, operaiile de acces la baza de date
care pot s apar n cursul unei tranzacii sunt:
1 read(X): citete articolul X din baza de date ntr-o variabil a
programului; pentru simplificarea notaiilor se va considera c variabila
n care se citete articolul X este notat, de asemenea, cu X.
2 write(X): scrie variabila de program X n articolul X al bazei de date.
Unitatea de transfer a datelor ntre discul magnetic i memoria principal a
sistemului este un bloc, care corespunde unui sector de pe disc. n general, un
articol de date este un cmp care memoreaz valoarea unui atribut dintr-o
nregistrare (tuplu), dar poate fi o ntreag nregistrare sau chiar un bloc ntreg.
Tranzaciile lansate de diferii utilizatori se pot executa concurent i este
posibil s actualizeze aceleai articole ale bazei de date. Dac execuia
concurent a tranzaciilor este necontrolat, este posibil ca baza de date s
ajung ntr-o stare inconsistent (incorect), chiar dac fiecare tranzacie n parte
este un program corect, a fost executat corect i nu au aprut defecte de
funcionare ale sistemului.
Actualizare pierdut (lost update). n figura de mai jos, este prezentat
una din cele cteva situaii posibile de inconsisten a datelor memorate atunci
cnd dou sau mai multe tranzacii sunt executate concurent, dar ntr-un mod
necontrolat. Cele dou tranzacii T
1
i T
2
actualizeaz acelai articol (X) al bazei
de date i se execut concurent prin partajarea (i ntreeserea) timpului de
execuie al procesorului.
nconsistena datelor provenit din execuia concurent necontrolat a dou
tranzacii: a - actualizare pierdut; b - citire improprie.
Pentru modul de ntreesere n timp a celor dou tranzacii prezentate n
figura de mai sus, a valoarea memorat n articolul X n baza de date este X+M,
1!
n locul valorii corecte X~N+M (X fiind valoarea iniial a articolului, nainte de
lansarea tranzaciilor). Actualizarea efectuat de tranzacia T
1
a fost pierdut, dat
fiind c tranzacia T
2
folosete valoarea iniial a articolului X, nainte ca valoarea
calculat de T
1
(X~N) s fie memorat n baza de date. Acest tip de funcionare
concurent incorect se numete actualizare pierdut.
'itire im%r%rie (dirt, read). n figura de mai sus unde in cazul b este
exemplificat o alt situaie de inconsisten a datelor, cunoscut sub denumirea
de citire improprie ; dirt, read, sau dependen ne#alidat ; uncommited
dependence sau actualizare temporar ; temporar, update. Aceast anomalie
poate s apar atunci cnd una din tranzacii este abandonat, iar alt tranzacie
concurent a utilizat articolele modificate, nainte de readucerea acestora la
valoarea iniial. n acest exemplu tranzacia T
1
a modificat articolul X, dup care
a fost abandonat dintr-o cauz oarecare, dar tranzacia T
2
a citit i a utilizat
articolul modificat X, nainte ca acesta s fie readus la valoarea sa iniial.
Rezultatul celor dou tranzacii este valoarea X N + M, n locul valorii corecte,
X + M.
'itire ire%etabil (nonrepetable read). O alt problem de inconsisten a
datelor, cunoscut sub numele de citire irepetabil (nonrepetable read, sau
analiz inconsistent - inconsistent anal,sis), poate s apar dac o tranzacie T
citete un articol de dou ori, iar ntre cele dou citiri, o alt tranzacie (T') a
modificat chiar acel articol. n aceast situaie tranzacia T primete dou valori
diferite ale aceluiai articol.
'itire :antm (phantom read). Asemntoare problemei citirii irepetabile
este problema citirii fantom, care apare atunci cnd o tranzacie prelucreaz un
set de linii rezultat al unei interogri; dac n timpul acestei prelucrri o alt
tranzacie a inserat sau a ters o linie care satisface condiia interogrii
respective, atunci pot s apar sau s dispar linii din mulimea de linii rezultat,
comportare asemntoare cu aparia sau dispariia fantomelor.
Diferena dintre citirea fantom i citirea irepetabil este aceea c citirea
fantom apare dac tranzaciile concurente modific numrul de linii utilizate de
tranzacia curent (prin instruciuni NSERT sau DELETE), pe ct vreme citirea
irepetabil apare dac tranzaciile concurente modific valorile din liniile
existente i prelucrate de tranzacia curent (prin instruciuni UPDATE).
Astfel de anomalii, care pot s apar la execuia concurent necontrolat
a dou sau mai mai multor tranzacii, evideniaz necesitatea controlului
concurenei n bazele de date.
Consistena datelor memorate n baza de date trebuie s fie asigurat
chiar n condiiile n care o tranzacie nu poate fi terminat cu succes, datorit
apariiei unei erori de funcionare.
0.2 P8OP824T;72L4 T8!19!'722LO8
Cele mai importante proprieti ale tranzaciilor sunt identificate n
literatur prin acronimul ACD: atomicitate, consisten, izolare, durabilitate.
2+
Atomicitatea (atomicit,) este proprietatea unei tranzacii de a reprezenta
o unitate de execuie indi#izibil adic de a executa <totul sau nimic=$ Dac o
tranzacie este ntrerupt dintr-o cauz oarecare, atunci sistemul SGBD va
asigura, dup eliminarea cauzei care a ntrerupt executarea tranzaciei, fie
completarea i validarea tranzaciei, fie abandonarea tranzaciei i anularea
tuturor efectelor aciunilor efectuate de tranzacie pn n momentul ntreruperii.
Consistena (consistenc,) unei tranzacii 2nseamn proprietatea acesteia
de a efectua modificri corecte ale bazei de date. Cu alte cu#inte o tranzacie
transform baza de date dintr;o stare consistent 2n alt stare consistent$ n
strile intermediare prin care trece o baz de date n cursul unei tranzacii, este
posibil s existe unele inconsistene, dar starea final n care ajunge baza de
date dup execuia unei tranzacii trebuie s fie consistent. Starea unei baze de
date este consistent dac respect toate constrngerile de integritate implicite
sau explicite. Sistemul SGBD nu verific consistena bazei de date dup fiecare
operaie (tranzacie), ci este sarcina proiectanilor aplicaiilor de baze de date ca
operaiile prevzute n tranzacii s produc o stare consistent a bazei de date.
#zolarea (isolation) este proprietatea unei tranzacii de a face #izibile
modificrile efectuate numai dup ce a fost #alidat (committed). Dac n acest
timp sunt executate alte tranzacii concurente, acestea nu "vd modificrile
pariale efectuate de tranzacia respectiv pn n momentul validrii tranzaciei.
Proprietatea de izolare a tranzaciilor este important deoarece elimin
fenomenul de abandonare n cascad a tranzaciilor. Dac rezultatele pariale ale
unei tranzacii sunt vizibile altor tranzacii nainte de validarea acesteia i dac se
ntmpl ca aceast tranzacie s fie abandonat i anulat (rollbac-), atunci
toate tranzaciile care au accesat rezultatele pariale ale acesteia vor trebui s fie
anulate; aceste operaii de anulare pot produce, la rndul lor alte anulri, .a.m.d.
Acest fenomen de anulare n cascad creeaz un efect de "domino. zolarea
este impus prin metode de control al concurenei, pe diferite niveluri de izolare.
Durabilitarea (durabilit,, sau permanena - permanenc,) este
proprietatea prin care, dup validarea unei tranzacii, modificrile efectuate de
aceasta n baza de date nu vor mai fi pierdute datorit unor defectri ulterioare a
sistemului. Proprietatea de durabilitate este asigurat prin metode de refacere
(reco#er,) ale sistemului SGBD.
0.3 ST;82L4 T8!19!'722LO8
Dac operaiile de acces la baza de date ale unei tranzacii sunt numai
operaii de citire, acea tranzacie se numete tranzacie de citire (read;onl,
transaction) i controlul concurenei unor astfel de tranzacii este mult mai
simplu. n cele ce urmeaz se va studia cazul general, al tranzaciilor de citire i
scriere (read;>rite transactions) care efectueaz att regsiri de date (prin
21
operaii de citire) ct i actualizri (prin operaii de scriere), i care necesit
tehnici de control al concurenei mult mai complexe.
Operaiile efectuate de o tranzacie i nregistrate de administratorul de
refacere (reco#er, manager), pentru a asigura cele patru proprieti importante
ale tranzaciilor (ACD), sunt urmtoarele:
0 1. begin: aceast operaie marcheaz nceputul execuiei unei
tranzacii.
1 2. read sau write: sunt operaii de citire sau scriere a articolelor n baza
de date, executate n cadrul unei tranzacii.
2 3. end: aceast operaie marcheaz terminarea operaiilor de scriere
sau citire din baza de date, ceea ce nseamn c tranzacia se poate
termina; totui, este posibil s fie necesare unele operaii de verificare
nainte de validarea (commit) tranzaciei.
3 4. commit: aceast operaie semnaleaz terminarea cu succes a
tranzaciei, validarea tuturor modificrilor efectuate n baza de date i
vizibilitatea modificrilor efectuate pentru alte tranzacii; din acest
moment, modificrile efectuate nu mai pot fi anulate, nici pierdute
printr-o defectare ulterioar a sistemului (bineneles, dac mecanismul
de refacere al SGBD-ului funcioneaz corect).
4 5. rollback (sau abort): aceast operaie semnaleaz faptul c
tranzacia a fost abandonat i c orice efect pe care tranzacia l-a
avut asupra bazei de date trebuie s fie anulat (printr-o "rulare napoi
a operaiilor).
5 6. undo: aceast operaie este similar operaiei rollback, dar se aplic
unei singure operaii, nu unei ntregi tranzacii.
6 7. redo: aceast operaie specific faptul c unele operaii ale unei
tranzacii trebuie s fie executate din nou pentru a se putea valida
ntreaga tranzacie.
Ultimele dou operaii sunt necesare numai n anumite tehnici de refacere.
n figura de mai jos este reprezentat diagrama de stare a unei tranzacii
folosind limbajul UML, unde fiecare stare are o denumire i fiecare operaie
provoac o anumit tranziie ntre stri.
n starea ACTVA se ajunge ca urmare a lansrii unei tranzacii prin
operaia begin, iar execuia corect a operaiilor read sau write nu modific
aceast stare. Atunci cnd o tranzacie se termin, ea trece n starea PARTAL
VALDATA n care se efectueaz operaii de verificare impuse de tehnicile
(protocoalele) de control al concurenei i de refacere. Dac ambele verificri
sunt ndeplinite cu succes, atunci tranzacia este validat (prin execuia unei
operaii commit) i trecut n starea VALDATA; dac una sau ambele condiii nu
sunt ndeplinite, tranzacia este trecut n starea ABANDONAT prin execuia
operaiei abort. Starea TERMNAT este consecina imediat a atingerii uneia
din strile VALDAT sau ABANDONAT i nu necesit nici o alt operaie
22
pentru efectuarea acestei tranziii. n cursul strii ACTV, orice tranzacie poate
fi abandonat (i trecut n starea ABANDONAT prin execuia unei operaii
abort), dac diferite verificri efectuate nu sunt ndeplinite.
Fig. 7.1 Diagrama de stare a unei tranzacii.
Pentru refacerea bazei de date n condiiile n care unele tranzacii sunt
abandonate sau n care pot aprea defecte de funcionare, sistemul SGBD
menine un fi+ier 3urnal, n care memoreaz operaiile efectuate de tranzacii.
Fiierul jurnal este memorat pe disc i nu este afectat de diferite erori de
execuie, cu excepia unei defectri catastrofice a discului. n plus, fiierul jurnal
este salvat periodic pe un suport auxiliar (band magnetic), ca o msur de
prevedere pentru astfel de defecte catastrofice.
<n :i=ierul jurnal (log file -> .LDF) se nregistreaz operaiile efectuate de
fiecare tranzacie (cu exceptia tranzactiilor de tip bcp respectiv insert into),
identificat printr-un identificator unic (T) generat de sistem.
Prima nregistrare referitoare la o tranzacie cu identificatorul T este
nregistrarea de start a tranzaciei: [begin,T]. La fiecare operaie write(X)
executat de o tranzacie T, n fiierul jurnal se memoreaz o nregistrare de tipul
[write,T,X,vechea_valoare,noua_valoare], dac pentru refacerea datelor se
folosesc operaii undo, sau o nregistrare de tipul [write,T,X,noua_ valoare], dac
se folosesc operaii redo. Sistemele care nu evit abandonarea n cascad a
tranzaciilor nregistreaz n fiierul jurnal i operaiile de citire read(X), printr-o
nregistrare de tipul [read,T,X,valoare].
Pentru fiecare tranzacie T, n fiierul jurnal se mai memoreaz starea de
terminare: validat (printr-o nregistrare [commit,T] ) sau anulat (printr-o
nregistrare[rollback,T]). Dup executarea validrii i nregistrarea ei n fiierul
jurnal, efectul tranzaciei este permanent memorat n baza de date.
Dac sistemul se defecteaz, la reluarea execuiei dup ndeprtarea
defectului, sistemul SGBD va aduce baza de date ntr-o stare consistent prin
examinarea fiierului jurnal. Dat fiind c fiierul jurnal conine o nregistrare
23
pentru fiecare operaie de scriere care a modificat valoarea unui articol al bazei
de date, este posibil de a anula efectul tuturor operaiilor de scriere efectuate de
o tranzacie care a fost lansat dar nu a fost validat, parcurgnd napoi fiierul
jurnal i nlocuind valoarea existent a articolului modificat cu vechea valoare,
memorat n fiierul jurnal. n cazul abandonrii n cascad, trebuie s fie
abandonate i tranzaciile care au citit valori modificate de tranzaciile
abandonate.
6. %&(7#C# D& CO7%O$ A$ CO7C)&78&#
Controlul execuiei concurente a mai multor tranzacii este necesar pentru
a asigura proprietile de atomicitate, izolare i durabilitate a tranzaciilor i, prin
aceasta, consistena datelor memorate. Controlul concurenei se poate realiza
prin protocoale (set de reguli) impuse tranzaciilor astfel nct, dac acestea sunt
respectate de fiecare tranzacie, orice planificare n care astfel de tranzacii
particip este serializabil i, deci, corect. Cele mai utilizate tehnici de control al
concurenei sunt cele bazate pe blocarea datelor prin intermediul zvoarelor
(loc-s) i cele bazate pe mrci de timp (timestamps). Protocoalele de control al
concurenei sunt implementate de sistemele de gestiune a bazelor de date astfel
nct programatorii de aplicaii nu opereaz n mod explicit cu zvoare sau mrci
de timp, ci stabilesc opiunile prin care sistemul SGBD adopt anumite tehnici de
control al concurenei. Descrierea n continuare a algoritmilor i a operaiilor de
execuie a tranzaciilor este o descriere de principiu, prezentat cu scopul
nelegerii mecanismelor de baz ale controlului concurenei.
>.1 'O1T8OL6L 'O1'6841742
Controlul concurenei tranzaciilor prin blocare (concurrenc, control using
loc-ing techni.ue) se realizeaz folosind zvoare. Un zvor (loc-) este o
variabil asociat cu un articol al unei baze de date care descrie starea acelui
articol n raport cu operaiile care se pot aplica acelui articol. Pentru un articol X,
zvorul care controleaz accesul la acel articol va fi notat L(X). n sistemele de
gestiune a bazelor de date se pot utiliza dou tipuri de zvoare, zvoare binare i
zvoare cu stri multiple. 6n zvr binar (binar, loc-) poate avea dou stri:
liber (sau neblocat - free, unloc-ed) i ocupat (sau blocat ; bus,, loc-ed) sau, mai
simplu, strile 1 i 0. Asupra unui zvor L(X)se pot executa dou operaii:
operaia de blocare, lock(X) i operaia de eliberare, unlock(X).
Dac zvorul articolului X este deja blocat (L(X)=0), atunci operaia de
blocare lock pune n ateptare tranzacia pn cnd zvorul se elibereaz. Dac
zvorul este liber (L(X)=1), atunci tranzacia achiziioneaz zvorul, trecndu-l n
starea ocupat, dup care execut operaiile necesare asupra articolului X. Dup
2.
terminarea operaiilor asupra acelui articol, tranzacia elibereaz zvorul, prin
execuia operaiei unlock.
Dac zvorul a fost ocupat, tranzacia ateapt pn ce acesta este
eliberat (de o alt tranzacie, care i-a terminat operaiile de acces la acel articol),
dup care execut aceeai secven de operaii: blocarea zvorului, execuia
operaiilor care acceseaz articolul respectiv i eliberarea zvorului. Pentru ca, n
orice moment de timp, cel mult o tranzacie s dein un anumit zvor, trebuie ca
operaia de blocare s fie executat ca operaie indivizibil. Acest cerin este
implementat prin instruciuni speciale ale procesorului (de tip TestAndSet(TS)).
Se pot preciza urmtoarele reguli (protocolul) pe care trebuie s le urmeze
fiecare tranzacie care folosete zvoare binare:
1. O tranzacie T trebuie s lanseze o operaie de blocare a zvorului asignat
articolului X (lock(X)), nainte de a efectua orice operaie de citire (read(X)) sau
de scriere (write(X)) a articolului X.
2. O tranzacie T trebuie s elibereze zvorul unui articol X (prin operaia
unlock(X)) dup ce a efectuat toate operaiile de citire (read(X)) sau de scriere
(write(X)) a articolului X.
3. O tranzacie T nu poate cere un zvor pe care l deine deja.
4. O tranzacie T nu poate elibera un zvor pe care nu l deine.
1ntre operaia de blocare (lock(X)) lansat de o tranzacie T i operaia de
eliberare (unlock(X)) a unui zvor L(X), tranzacia T deine zvorul respectiv. n
cazul zvoarelor binare, cel mult o tranzacie poate deine un zvor la un
moment dat, i nici o alt tranzacie nu poate accesa articolul respectiv. Se poate
spune c zvoarele binare realizeaz un mecanism de excludere mutual, prin
care accesul unei tranzacii la un articol (tranzacia care deine zvorul acelui
articol) exclude accesul altor tranzacii la acel articol.
Dei este foarte general i relativ simplu de utilizat, tehnica zvoarelor
binare este prea restrictiv i limiteaz n mod nejustificat concurena n execuia
tranzaciilor. De exemplu, mai multe tranzacii pot efectua operaii de citire n
mod concurent, fr ca acest lucru s afecteze consistena bazei de date, dar
acest lucru este interzis n tehnica zvoarelor binare. De aceea, multe sisteme
de gestiune a bazelor de date utilizeaz zvoare cu stri multiple.
>.2 !1!L29! 'O1T8OL6L62 'O1'6841742
21
Dac fiecare tranzacie lucreaz pe rnd, se pierde timp cnd calculatorul st
s atepte terminarea unei operaii de intrare/ieire, sau n timpul altei
ntreruperi. Pe de alt parte, dac lsm s lucreze deodat, fiecare n timpul
lsat liber de cel din nainte, zicem c avem tranzacii concurente.
Concurena va mri randamentul timpului de lucru al calculatorului dar ea
trebuie controlat pentru c altfel poate da natere la inconsisten.
Prezint n continuare, trei exemple n care art cum se poate pierde
cinsistena.
n primul exemplu tranzacia T
1
citete contul lui x (bal
x
) i scade 10 din
cont.
Tranzacia T
2
citete contul lui x (bal
x
) i adun 100 la cont. Pornind cu un
cont de 100, evident c dac se executa mai nti prima tranzacie i apoi a
doua contul lui x ar fi fost 100-10+100=190. n cealalt ordine am fi avut
100+100-10=190 aceeai valoare. S considerm urmtorul plan de
tranzacii.
Un plan de tranzacii este o secven posibil n timp a modului de execuie
a tranzaciilor. Putem observa, n timpii nscrii n stnga cum evolueaz
contul din ultima coloan.
Ti&e T1 T2 'alB
A t1 'eginFtran#a%ti*n 1++
A t2 'eginFtran#a%ti*n %itC'alBD 1++
A t3 %itC'alBD 'alB G 'alB H 1+ 1++
A t. 'alB G 'alB 4 1+ #%rieC'alBD 2++
A t1 #%rieC'alBD %*&&it !+
A t6 %*&&it !+
Problema se numete problema pierderii actualizrii.
Problema dependenei de o tranzacie neterminat apare cnd o
tranzacie este lsats 'vad' rezultatele intermediare alei alte tranzacii
nainte ca ea s fac 'commit'. Aceleai tranzacii ca n figura precedent se
desfoar acum dup un alt plan.
Ti&e T3 T. 'alB
A t1 'eginFtran#a%ti*n 1++
A t2 %itC'alBD 1++
A t3 'alB G 'alB H 1+ 1++
A t. 'eginFtran#a%ti*n #%rieC'alBD 2++
A t1 %itC'alBD 2++
A t6 'alB G 'alB 4 1+ roll/ac0 1++
26
A t9 #%rieC'alBD 1!+
A t> %*&&it 1!+
Rezultatul este 190, ai putea spune c este bun, dar inei cont c tranzacia
4 a fost ntrerupt i, cnd se va relua, va mai mri cu 100 contul ceea ce va
deveni incorect.
Chiar i cnd unele tranzacii numai citesc baza de date se pot ntmpla
neplceri. Aceast problem este problema analizei inconsistente sau
problema 'citirii murdare'.
De exemplu tranzaciile T
5
i T
6
executate serial, adic una dup alta, ar
trebui s dea rezultatele:
T
5
T
6
bal
x
=100-10=90, bal
z
=25+10=35, sum=90+50+35+175
sau T
6
T
5
sum=100+50+25=175, bal
x
=100-10=90, bal
z
=25+10=35
i putem vedea n figura urmtoare ce se poate ntmpla ncazul concurenei
libere, necontrolate:
Ti&e T1 T6 'alB 'al5 'alz #$&
A t1 'eginFtran#a%ti*n 1++ 1+ 21
A t2 'eginFtran#a%ti*n #$& G + 1++ 1+ 21 +
A t3 %itC'alBD %itC'alBD 1++ 1+ 21 +
A t. 'alB G 'alB
41+
#$& G #$& H
'alB
1++ 1+ 21 1++
A t1 #%rieC'alBD %itC'al5D !+ 1+ 21 1++
A t6 %itC'alzD #$& G #$& H
'al5
!+ 1+ 21 11+
A t9 'alz G 'alz H
1+
!+ 1+ 21 11+
A t> #%rieC'alzD !+ 1+ 31 11+
A t! %*&&it %itC'alzD !+ 1+ 31 11+
A t1+ #$& G #$& H
'alz
!+ 1+ 31 1>1
A t11 %*&&it !+ 1+ 31 1>1
Nu putem, deci, lsa concurena necontrolat, dar nici nu este profitabil s
o desfiinm de tot. Spunem c un plan de tranzacii este serial cnd tranzaciile
se execut una dup alta fr a intercala operaii din alt tranzacie. Spunem c
un plan de tranzacii este neserial cnd tranzaciile snt concurente , adic ntre
operaiile unei tranzacii se intercaleaz operaiile alteia. Vom spune c un plan
de tranzacii este corect atunci cnd el are ca rezultat acelai cu unul executat
serial; acesta se va numi serializabil. Avei deja exemple de planuri
neserializabile.
Am vzut c problemele apar atunci cnd o tranzacie 'vede' (citete) sau
scrie ntr-un moment nepotrivit. deile de a controla concurena snt legate de a
29
nu lsa pe cellalt (de a bloca) sau de a ine cont de momente (de a marca
timpul).
Ce nseamn s blocm : Cnd o tranzacie blocheaz parta1at
(part_bloc) o anumit unitate de memorie, o alt tranzacie nu mai poate s
rescrie tot acolo, iar cnd o tranzacie blocheaz e.clusi0 (ex_bloc) o alta nu
mai poate nici s o citeasc.
Despre ce unitate de memorie este vorba? Aceasta este problema
granularitii la care se face blocajul. Blocajul se poate face la nivel de:
4 ntreaga baz de date
4 tabela(fiier)
4 nregistrare (cel mai des)
4 cmp din nregistrare
Mai spunem c avem granularitate dinamic atunci cnd SGBD-ul poate
s schimbe granularitatea n timpul unei tranzacii.
Cititorul poate s demonstreze singur pe un exemplu (vezi problema ) c
numai simpla blocare urmat cndva de deblocare (debloc) nu asigur
serializabilitatea.
Serializabilitatea este asigurat dac se respect protocolul de blocare
9n dou faze. Acesta const din mprirea tranzaciei n dou faze una de
blocri i creteri de blocaje i a doua de descreteri i deblocaje. Aceasta
nseamn c dup ce s-a fcut prima deblocare nu se mai pot face blocri.
Urmtoarele trei exemple reiau tranzaciile T
1
,T
2
respectiv T
3
, T
4
, T
5
, T
6

cu protocolul n dou faze i realizeaz planuri serializabile.
Ti&e T1 T2 'alB
A t1 'eginFtran#a%ti*n 1++
A t2 'eginFtran#a%ti*n eBF'l*%C'alBD 1++
A t3 eBF'l*%C'alBD %itC'alBD 1++
A t. ATEAPT( 'alB G 'alB H1++ 1++
A t1 ATEAPT( #%rieC'alBD 2++
A t6 ATEAPT( )e'l*%C'alBD 2++
A t9 %itC'alBD %*&&it 2++
A t> 'alB G 'alB 41+ 2++
A t! #%rieC'alBD 1!+
A t1+ )e'l*%C'alBD 1!+
A t11 %*&&it 1!+
Ti&e T3 T. 'alB
A t1 'eginFtran#a%ti*n 1++
A t2 eBF'l*%C'alBD 1++
A t3 %itC'alBD 1++
2>
A t. 'eginFtran#a%ti*n 'alB G 'alB H1++ 1++
A t1 eBF'l*%C'alBD #%rieC'alBD 2++
A t6 ATEAPT( )e'l*%C'alBD 1++
A t9 ATEAPT( roll/ac0 1++
A t> %itC'alBD 1++
A t! 'alB G 'alB 41+ 1++
A t1+ #%rieC'alBD !+
A t11 )e'l*%C'alBD !+
A t12 %*&&it !+
Ti&e T1 T6 'alB 'al5 'alz #$&
A t1 'eginFtran#a%ti*n 1++ 1+ 21
A t2 'eginFtran#a%ti*n #$& G + 1++ 1+ 21 +
A t3
eBF'l*%C'alBD
1++ 1+ 21 +
A t. %itC'alBD /artF'l*%C'alBD 1++ 1+ 21 +
A t1 'alB G 'alB
41+
AITEAPT? 1++ 1+ 21 +
A t6 #%rieC'alBD AITEAPT? !+ 1+ 21 +
A t9
eBF'l*%C'alzD
AITEAPT? !+ 1+ 21 +
A t> %itC'alzD AITEAPT? !+ 1+ 21 +
A t! 'alz G 'alz H
1+
AITEAPT? !+ 1+ 21 +
A t1+ #%rieC'alzD AITEAPT? !+ 1+ 31 +
A t11 )e'l*%C'alB 2
'alzD
AITEAPT? !+ 1+ 31 +
A t12 %*&&it AITEAPT? !+ 1+ 31 +
A t13 %itC'alBD !+ 1+ 31 +
A t1. #$& G #$& H 'alB !+ 1+ 31 !+
A t11 /artF'l*%C'al5D !+ 1+ 31 !+
A t16 %itC'al5D !+ 1+ 31 !+
A t19 #$& G #$& H 'al5 !+ 1+ 31 1.+
A t1> /artF'l*%C'alzD !+ 1+ 31 1.+
A t1! %itC'alzD !+ 1+ 31 1.+
A t2+ #$& G #$& H 'alz !+ 1+ 31 191
A t21
)e'l*%C'alB2'al52'alzD
!+ 1+ 31 191
A t22 %*&&it !+ 1+ 31 191
2!
Protocolul de blocare n dou faze asigur serializanilitatea dar nu ne
scutete de probleme. Pezentm n cele dou exemple urmtoare rollbac43ul
9n cascad i bloca1ul ciclic.
La momentul t14 tranzacia T
7
face rollback (dintr-un motiv extern) i,
pentru c T
8
este dependent de T
7
care a citit o nregistrare care a fost
actualizat de T
7
, trebuie s fac i T
8
rollback, ceea ce pe urm se ntmpl
i cu T
9
.
Ti&e T9 T> T!
A t1 'eginFtran#a%ti*n
A t2 eBF'l*%C'alBD
A t3 %itC'alBD
A t. /artF'l*%C'al5D
A t1 'alB G 'al5 H
'alB
A t6 #%rieC'alBD
A t9 )e'l*%C'alBD 'eginFtran#a%ti*n
A t> J eBF'l*%C'alBD
A t! J %itC'alBD
A t1+ J 'alB G 'alB H1++
A t11 J #%rieC'alBD
A t12 J )e'l*%C'alBD
A t13 J J
A t1. roll/ac0 J
A t11 roll/ac0 'eginFtran#a%ti*n
A t16
/artF'l*%C'alBD
A t19 J
A t1> roll/ac0
O alt problem este blocarea ciclic prezentat n exemplul urmtor. Cele
dou trnzacii T
10
i T
11
se blocheaz reciproc.
3+
Ti&e T1+ T11
A t1 'eginFtran#a%ti*n
A t2 eBF'l*%C'alBD 'eginFtran#a%ti*n
A t3 %itC'alBD eBF'l*%C'al5D
A t. 'alB G 'alB 41+ %itC'al5D
A t1 #%rieC'alBD 'al5 G 'al5 H1++
A t6 eBF'l*%C'al5D #%rieC'al5D
A t9 AITEAPT? eBF'l*%C'alBD
A t> AITEAPT? AITEAPT?
A t! AITEAPT? AITEAPT?
A t1+ J AITEAPT?
A t11 J J
Blocajul ciclic este detectat , de obicei, prin constuirea unui graf de
preceden care arat dependena ntre tranzacii n felul urmtor:
4 se creaz un nod pentru fiecare tranzacie
4 se creaz o muchie direcionat Ti Tj dac tranzacia Ti ateapt
s blocheze o nregistrare care este deja blocat de Tj.
Pe acest graf se detecteaz un blocaj ciclic dac exist un circuit. Graful
tranzactiilor:
O alt metod de a evita blocajul ciclic pstrnd serializabilitatea este
protocolul cu marcarea timpului (time stamp). Acest protocol ataeaz un timp
(timpul real din calculator sau un numr care se mrete autmat de cte ori este
solicitat) fiecrei tranzacii (marc(T)) i timpul tranzaciei care realizeaz operaia
fiecrei citiri sau scrieri a unei nregistrri. Deci fiecare tranzacie va avea o
valoare de marcj i fiecare nregiistrare prelucrat va avea dou marcaje; unul
care spune ce marcaj a avut tranzacia care a citit-o (cit_marc) i cellalt care
spune ce marcaj a avut tranzacia care a scris-o (scri_marc).
Numai n urmtoarele trei situaii se pun probleme deosebite:
1. Tranzacia T cere s citeasc o nregistrare x care a fost deja actualizat
de o tranzacie cu scri_marc(x) > marc(T), adic o nregistrare scris de o
tranzacie care a nceput mai trziu. Ce ar rescrie ea ar putea da natere
la inconsisten deci trnzacia respectiv trebuie ntrerupt.
31
T
1+
T
11
2. Tranzacia cere s scrie nregistrarea x a crei valoare a fost deja citit de
o tranzacie care a nceput mai trziu marc(T) < cit_marc(x). Aceasta
nseamn c tranzacia vrea s rescrie o nregistrare, pe care o alt
tranzacie nceput mai trziu, a citit-o i o folosete. Si n acest caz
tranzacia trebuie ntrerupt.
3. Tranzacia cere s scrie o nregistrare x a crei valoare a fost deja scris
de o tranzacie care a nceput mai trziu, adic marc(T) < scri_marc(x).
Este o ncercare de a scrie o valoare perimat i n acest caz se ignor
aceast scriere.
n figura urmtoare se poate observa cum funcioneaz acest protocol.
Ti&e O/ T9 T> T!
A t1 'eginFtran#a%ti*n
A t2 %itC'alBD %itC'alBD
A t3 'alB G 'alB H1+ 'alB G 'alB H1++
A t. #%rieC'alBD #%rieC'alBD 'eginFtran#a%ti*n
A t1 %itC'al5D %itC'al5D
A t6 'al5 G 'al5 H2+ 'al5 G 'al5 H2+ 'eginFtran#a%ti*n
A t9 %itC'al5D %itC'al5D
A t> #%rieC'al5D #%rieC'al5D
KK

A t! 'al5 G 'al5 H3+ 'al5 G 'al5 H3+
A t1+ #%rieC'al5D #%rieC'al5D
A t11 'alzG1++ 'alzG1++
A t12 #%rieC'alzD #%rieC'alzD
A t13 'alzG1+ 'alzG1+ %*&&it
A t1. #%rieC'alzD #%rieC'alzD
K
'eginFtran#a%ti*n
A t11 %itC'al5D %*&&it %itC'al5D
A t16 'al5 G 'al5 H2+ 'al5 G 'al5 H2+
A t19 #%rieC'al5D #%rieC'al5D
A t1> %*&&it
* la timpul t
8
scrierea de ctre tranzacia T
13
violeaz regula 2 i de aceea
este ntrerupt i reluat la momentul t
14
** la timpul t
14
scrierea de ctre tranzacia T
12
poate fi ignorat conform celei
de a treia reguli
>.3 Te"nici %timiste.
Nu ntotdeuna este necesar s pierdem timp n calculator controlnd
concurena. Atunci cnd conflictele ntre tranzacii snt rare putem adopta aa-
32
numitele tehnici optimiste. Asta nseamn s lsm tranzaciile s ruleze fr s
impunem ntrzieri care s asigure serializabilitatea, iar cnd o tranzacie vrea s
fac 'commit' s efectum un control care s determine dac a avut loc un
conflict. Dac a avut loc un conflict, tranzacia trebuie ntrerupt i restartat.
Pentru c am spus c aceeste conflicte snt rare, aceste nteruperi i restartri
vor fi, i ele, rare.
Distingem trei faze ale unui control optimist al concurenei.
?aza de citire$ Aceast faz dureaz de la nceputul tranzaciei pn
nainte de 'commit'. Tranzacia citete valorile de care are nevoie din baza
de date i le stocheaz in variabile locale. Actualizrile nu snt fcute
direct n baza de date ci ntr-o copie local.
?aza de #alidare$ Urmeaz dup faza de citire i controleaz dac nu sar
nclca serializabilitatea n cazul c s-ar aplica actulizarea n baza de
date. Dac avem o tranzacie care numai citete baza (adic nu scrie),
controlul const n a verifica dac datele citite snt nc datele curente n
baz i, dac este aa, atunci se face 'commit', altfel se ntrerupe i se
reia mai trziu. Dac trnzacia face i rescrieri n baz, atunci se verific
dac se pstreaz serializabilitatea i dac baza de date rmne ntr-o
stare consistent; dac acest lucru nu se ntmpl, atunci se ntrerupe.
?aza de scriere$ Este o faz care este necesar numai la tranzaciile care
fac rescrieri. Dac faza anterioar s-a terminat cu succes, atunci
actualizrile efectuate n copia local, snt nregistrate definitiv n baza de
date.
at cum se desfoar acest tip de control:
Fiecrei tranzacii i este ataat, la nceputul primei faze, un marcaj start(T), la
nceputul celei de a doua faze, valid(T) i la sfrit fin(T), dup scriere n copia
local, daceste cazul. Ca s treac faza de validare trebuie s avem una din
urmtoarele situaii:
1) Toate tranzaciile cu un marcaj mai mic, trebuie s se fi terminat
nainte ca tranzacia T s fi nceput; adic fin(S) < start(T).
2) Dac tranzacia start(S) < start(T) (S a nceput naintea lui T) i nu
s-a terminat adic fin(S) < fin(T) atunci:
a. Datele scrise de tranzacia anterioar S nu snt cele citite de
cea curent T i
b. Tranzacia anterioar S i completeaz faza de scriere
nainte ca tranzacia curent T s intre n faza de validare
adic start(T) < fin(S) < valid(T).
Dei tehnicile optimiste snt eficiente cnd conflictele snt rare totui pot
aprea multe reluri (rollback); s reinem c aceste reluri nu snt n cascad
pentru c se lucreaz pe o coppie local.
Ce ne facem dac apar totii inconsistene? Trebuie s{ [putem recupera
baza de date ntr-o stare anterioar consistent.
33
>.$ T4?12'2 34 84@!'484 ! -!94LO8 34 3!T4
"efacerea unei baze de date dup producerea unui defect 0database
reco#er,1 2nseamn aducerea bazei de date 2ntr;o stare precedent corect din
care e#entual se poate reconstrui o nou stare corect +i c*t mai apropiat de
momentul apariiei defectului$ Pentru operaiile de refacere se folosete fiierul
jurnal, i (sau) o copie de rezerv a bazei de date (database backup) stocat n
general pe band magnetic. Dac baza de date nu este distrus fizic, dar a
devenit inconsistent datorit unui defect necatastrofic, atunci strategia de
refacere const n a anula modificrile care au produs inconsistena (prin operaii
undo) sau, uneori, de a executa din nou anumite modificri care s-au pierdut
(prin operaii redo). n acest caz nu este necesar copia de rezerv, ci se
folosete starea actual a bazei de date i fiierul jurnal.
Dac baza de date a fost puternic distrus, datorit unei defectri
serioase a discului, atunci se restaureaz starea bazei de date din copia de
rezerv, dup care se reconstruiete o stare ct mai actual prin reaplicarea
tuturor tranzaciilor validate existente n fiierul jurnal, dac acesta nu a fost
deteriorat, sau din ultima copie salvat a fiierului jurnal.
:. CO7%O$)$ %A7;AC8##$O
Tehnicile de gestiune a tranzaciilor i de refacere a datelor prezentate n
seciunile precedente sunt incluse n componentele sistemelor de gestiune a
bazelor de date (administratorul de tranzacii i administratorul de refacere) ntr-o
form specific fiecrui SGBD, cu diferite grade de complexitate.
Aplicaiile de baze de date au un control destul de limitat asupra opiunilor
de gestiune a tranzaciilor prin intermediul unor comenzi care se bazeaz pe
standardul SQL2.
n standardul SQL2 sunt prevzute urmtoarele comenzi de specificare a
tranzaciilor:
SET TRANSACTON optiuni
COMMT [WORK] ROLLBACK [WORK]
Comanda SET TRANSACTON stabilete proprietile tranzaciilor i
admite urmtoarele opiuni de setare a modului de gestiune a tranzaciilor:
0 Nivelul de izolare a tranzaciilor (SOLATON LEVEL) cu valorile
posibile: READ UNCOMMTTED, READ COMMTTED, REPETABLE
READS, SERALZABLE.
1 Modul de acces la articole - cu valorile posibile READ ONLY, READ
WRTE.
2 Modul de refacere a datelor (SET CONSTRANTS), cu valorile
posibile DEFERRED (refacere amnat) i MMEDATE (refacere
imediat).
3.
1Nivelul de izolare reprezint gradul pn la care o tranzacie trebuie s
fie izolat de celelalte tranzacii. zolarea total a tranzaciilor, n care starea
bazei de date este consistent n permanen, iar n tranzacii nu apar nici un fel
de anomalii, este obinut pe nivelul cel mai nalt de izolare, denumit
SERALZABLE, care corespunde planificrilor serializabile (echivalente cu
planificri seriale ale tranzaciilor). Acest nivel de izolare total micoreaz gradul
de concuren a tranzaciilor, i, ori de cte ori este posibil, se admit niveluri de
izolare mai sczute, care admit unele anomalii (controlabile) de execuie a
tranzaciilor i asigur un grad de concuren mai ridicat. Nivelurile de izolare
determin modul n care sistemul de gestiune a bazei de date introduce diferitele
mecanisme de control al concurenei (cel mai frecvent zvoare cu stri multiple).
De exemplu, pe nivelul READ COMMTTED, sunt prevzute zvoare partajate
pentru toate articolele citite, ceea ce mpiedic apariia citirilor improprii, dar
aceste zvoare sunt eliberate nainte de terminarea tranzaciei i, de aceea, pot
rezulta citiri nerepetabile i citiri fantom (tabelul de mai jos)
Nivelurile de izolare a tranzaciilor .
Pe orice nivel de izolare, inclusiv pe cel mai slab (READ
UNCOMMTTED), se folosesc mecanisme de control al concurenei tranzaciilor
care previn pierderea actualizrilor. Astfel de anomalii sunt foarte grave, baza de
date nu reflect operaiile care s-au efectuat asupra datelor i nici nu exist vreo
posibilitate de refacere a acestor pierderi. De aceea nu este prevzut nici un
nivel de izolare care s permit pierderea actualizrii datelor. Pe toate nivelurile
de izolare, cu excepia nivelului SERALZABLE, pot s apar diferite anomalii,
dar aceste anomalii sunt anomalii de citire, care pot fi gestionate de tranzacii, i
nu anomalii memorate permanent n baza de date.
De exemplu, dac se tie c o tranzacie va fi executat pe nivelul de
izolare READ COMMTTED, atunci se poate scrie codul tranzaciei astfel nct
aceasta s nu citeasc datele din tabele dect o singur dat i s le memoreze
local pentru o alt utilizare, n loc s citeasc de mai multe ori din tabele. Cu ct
nivelul de izolare a tranzaciilor este mai sczut, cu att pot s apar mai multe
anomalii de actualizare, dar crete gradul de concuren a execuiei i scade
probabilitatea de apariie a impasului. De aceea, pentru proiectarea unor
tranzacii eficiente se recomand utilizarea unor niveluri de izolare ct mai
sczute, att ct este posibil pentru ca tranzaciile respective s se execute
totui corect. O tranzacie se poate termina fie prin validare (cu comanda
31
COMMT), fie prin anulare (cu comanda ROLLBACK). Comanda COMMT
garanteaz c toate modificrile efectuate de tranzacia respectiv au devenit
permanente.
Comanda ROLLBACK termin o tranzacie i anuleaz (ruleaz napoi)
toate modificrile executate pn n acel punct de acea tranzacie; aceast
comand se trimite atunci cnd apare o anumit condiie (posibil o eroare), care
face imposibil continuarea cu succes a tuturor operaiilor tranzaciei.
nstruciunile COMMT i ROLLBACK elibereaz resursele ocupate de tranzacie,
cum ar fi zvoarele articolelor.
n general, sistemele SGBD implementeaz protocoalele i funciile de
control al concurenei i gestioneaz automat execuia tranzaciilor i refacerea
datelor, pentru a asigura consistena i integritatea datelor memorate.
Tranzaciile sunt administrate la nivelul conexiunii unei aplicaii client cu serverul
bazei de date: atunci cnd o tranzacie a fost nceput pe o conexiune, toate
instruciunile urmtoare executate pe acea conexiune fac parte din acea
tranzacie, pn ce aceasta se termin. Programatorii de aplicaii au
responsabilitatea s stabileasc punctele de nceput i de sfrit ale tranzaciilor
i s prevad n fiecare tranzacie secvenele de modificri ale datelor astfel
nct acestea s lase baza de date ntr-o stare consistent, care s respecte
toate constrngerile, implicite i explicite.
De asemenea, se pot selecta prin program diferite opiuni de control (nivel
de izolare, mod de acces, etc.). Aceste operaii se pot realiza prin intermediul
unor comenzi care sunt variante ale comenzilor SQL de baz i care se transmit
SGBD-ului, fie prin instruciuni ale unui limbaj procedural de extensie a limbajului
SQL, fie prin funcii ale interfeelor de programare (cum sunt interfeele ODBC,
JDBC) (exemple in manual).
Tranzaciile sunt corecte dac las baza de date ntr-o stare consistent i
sunt cu att mai eficiente cu ct sunt mai scurte (ca timp de execuie i ca numr
de articole ale bazei de date accesate). Respectarea acestor cerine are o
influen pozitiv asupra performanelor bazelor de date att prin limitarea
frecvenei de apariie a impasului (n cazul folosirii zvoarelor), ct i din punct de
vedere al eficienei operaiilor de anulare i de blocare a resurselor.
Ori de cte ori se poate nlocui o tranzacie complex, cu numr de
operaii i timp de execuie ridicate, cu mai multe tranzacii scurte, este indicat s
se fac aceast transformare.
De asemenea, pentru meninerea tranzaciilor ct mai scurte posibil, se
recomand ca o tranzacie s nu fie pornit pn ce nu au fost pregtite toate
datele (citirea datelor de intrare, parcurgerea, analiza i prelucrarea acestora).
1<. -locari
n absena unor mecanisme de control al concurenei pot aprea
fenomene nedorite, care pot conduce la rezultate eronate sau la coruperea
consistenei bazei de date. Literatura de specialitate menioneaz n general trei
anomalii tipice care pot s apar [DATE95]. Pentru exemplificare vom considera
36
o aplicaie de rezervare de locuri pentru o companie de transporturi aeriene (vezi
caseta "Exemplu aplicativ").
S considerm dou tranzacii de tip "Rezervare", R1 i R2, care se
execut n mod concurent i care, ntmpltor, se refer la acelai zbor Z. Vom
face abstracie de operatia de inserare (care nu este important n acest context)
i vom folosi o notaie simplificat: deoarece selecia este - n esent - o citire, o
vom nota cu Read. Modificarea, fiind o scriere, o vom nota cu Write. O posibil
succesiune temporal a evenimentelor ar putea fi urmtoarea:
t1 - R1: Read Z
t2 - R2: Read Z
t3 - R1: Write Z
t4 - R2: Write Z
...
Citirile efectuate de cele dou tranzacii vor gsi linia n aceeai stare. S
presupunem c valoarea cmpului VNDUT este 25. Ambele tranzacii vor seta
variabilele lor locale vndut la valoarea 25. Actualizarea efectuat de tranzacia
R1 la momentul t3 va modifica valoarea cmpului la 26. La momentul t4,
tranzacia R2 actualizeaz i ea linia Z, plasnd ns n cmpul VNDUT aceeai
valoare. Se realizeaz dou rezervri, dar numrul locurilor vndute crete doar
cu o unitate. Dac numrul solicitrilor este mare, este foarte probabil c va fi
vndut un loc n plus la cursa respectiv.
Anomalia, numit "modificarea pierdut" (the lost update) a survenit
datorit faptului c tranzacia R2 i-a bazat actualizarea de la momentul t4 pe o
valoare citit la momentul t2, care ns a fost ntre timp (la momentul t3)
modificat de tranzacia R1. Practic, efectul actualizrii realizate de tranzacia R1
la momentul t3 s-a pierdut. Dac tranzacia R2 ar fi citit linia Z dup ce ea a fost
modificat de R1, atunci R2 ar fi plasat n cmpul VNDUT valoarea 27, ceea ce
ar fi fost corect.
O alt situatie posibil este cea n care una dintre tranzacii este anulat. S
considerm scenariul urmtor:
t1 - R2: Read Z
t2 - R2: Write Z
t3 - R1: Read Z
t4 - R2: ROLLBACK
t5 - R1: Write Z
...
n aceast situaie, tranzacia R1 va avea n variabilele locale rezultatul scris de
tranzacia R2 la momentul t2. Anularea tranzaciei R2 poate surveni din motive
diverse (s presupunem c adugarea liniei corespunztoare rezervrii n tabela
39
REZ eueaz din lips de spaiu pe disc) i va provoca revenirea liniei Z la
valorile dinainte de momentul t2. n acest caz, tranzacia R1 i va baza aciunile
viitoare pe nite valori care, practic, nu au existat niciodat n baza de date! S
presupunem c la momentul t1 cmpul VNDUT al liniei Z coninea valoarea 25.
La momentul t2 aceast valoare este incrementat, astfel nct tranzacia R1 va
citi la momentul t3 valoarea 26. La momentul t4, tranzacia R2 este anulat i, n
consecint, valoarea cmpului VNDUT al liniei Z va fi adus la valoarea pe care-
o avea nainte de nceperea tranzaciei R2, deci 25. La momentul t5, tranzacia
va scrie n linia Z valoarea 27. Ceea ce este, evident, greit. Anomalia (numit
uncommitted dependenc,) provine din faptul c tranzacia R1 a citit rezultate
intermediare ale tranzaciei R2.
Pentru a exemplifica o a treia anomalie, numit "analiza inconsistent"
(inconsistent anal,sis) vom considera tabela CLENT, asupra creia se execut
n mod concurent dou tranzacii. Tranzacia T1 calculeaz suma total ncasat
de la pasagerii cursei Z, n timp ce tranzacia T2 transfer o anumit sum x din
contul unui client C3 n contul unui client C1 (care s-a ntmplat c au zburat
mpreun). n mod normal suma total ar trebui s fie aceeai indiferent n care
cont se afla suma x. S presupunem c soldurile clientilor C1, C2 i C3 sunt 200,
100 i respectiv 300, iar x este 20.
Dar iat ce se poate ntmpla:
t1 - T1: Read C1 (sold = 200, total = 200)
t2 - T1: Read C2 (sold = 100, total = 300)
t3 - T2: Read C3 (sold = 300)
t4 - T2: Write C3 (sold = 280)
t5 - T2: Read C1 (sold = 200)
t6 - T2: Write C1 (sold = 220)
t7 - T2: Commit
t8 - T1: Read C3 (sold = 280, total = 580)
...
Pentru clientii C1, C2 i C3 totalul ar fi trebuit s fie, desigur, 600. Este
evident c suma total va fi greit. Spre deosebire de celelalte dou cazuri
prezentate, nu mai este vorba despre citirea unor valori actualizate de o
tranzacie nainte de comiterea acesteia. T1 nu citete nimic n timpul dintre
momentul nceperii tranzaciei T2 i pn la comiterea acesteia. Problema
provine din faptul c T1 a citit unul dintre conturi nainte de transfer iar pe cellalt
dup transfer.
n toate cele trei cazuri, anomaliile sunt provocate de interferenele dintre
tranzacii care se execut n mod concurent. O metod simpl (ba chiar
simplist...) de evitare a acestor interferene ar fi executarea complet a
tranzaciilor n ordinea nceperii lor. n acest caz ns performanele serverului de
date ar fi afectate n mod inacceptabil. Ar fi ca i cum ntr-un mare magazin cu
3>
autoservire clienii ar fi lsai nuntru unul cte unul, fiecare dup ce clientul
precedent i-a terminat toate cumprturile.
Pentru a echilibra ct mai bine performana i sigurana, constructorii de
sisteme de gestiune a bazelor de date au dezvoltat mai multe procedee prin care
interferenele ntre tranzaciile concurente s poat fi controlate. Cel mai
rspndit este mecanismul bazat pe blocarea (loc-ing) unor poriuni ale bazei de
date pentru a interzice altor tranzacii accesul la datele respective pe durat unor
operaiuni critice efectuate de o tranzacie. O alt metod este cea bazat pe
aplicarea unor "mrci de timp" (timestamping) asupra tranzaciilor i a obiectelor
implicate n tranzacii. Ambele procedee (precum i procedeele "hibride")
pornesc de la premisa pesimist c interferenele nedorite sunt oricnd posibile
i chiar probabile, deci se bazeaz pe prevenirea lor. Exist ns i o abordare
optimist, care pleac de "prezumia de nevinovie" i care ncearc doar s
depisteze i s rezolve conflictele n cazul n care acestea apar. Toate metodele
au avantaje i dezavantaje, fiecare dintre ele se preteaz la anumite aplicaii i
sunt inacceptabile n cazul altora.
dea pe care se bazeaz tehnica blocrii este foarte simpl: o tranzacie
care a nceput s opereze asupra unor date trebuie s interzic accesul altor
tranzacii la datele respective pn n momentul n care operaia se ncheie. n
acest timp, datele sunt "inute sub cheie" (to loc- - a ncuia, a zvor). Controlul
blocrii datelor este asigurat de o component a SGBD-ului numit 6oc-
8anager (LM). n momentul n care o tranzacie T dorete s acceseze un
anumit obiect al bazei de date (pies de date), va cere componentei LM blocarea
obiectului. Dac obiectul este blocat de o alt tranzacie, tranzacia T va fi pus
n stare de ateptare (>ait) pn cnd obiectul este eliberat.
S re-analizm a doua anomalie prezentat n seciunea precedent
(uncommitted dependenc,). La momentul t1 tranzacia R2 blocheaz linia Z. La
momentul t3, tranzacia R1 cere la rndul ei blocarea liniei Z dar, linia fiind deja
blocat de R2, este pus n stare de ateptare. La momentul t4, tranzacia R2 se
termin (prin ROLLBACK) i elibereaz linia Z. Abia acum R1 obine blocarea
liniei Z i poate s o acceseze. Datele asupra crora acioneaz acum R1 sunt
"curate" (efectele tranzaciei R2 au fost anulate), deci anomalia a fost evitat.
Se poate observa cu uurin c aceast modalitate de blocare este prea
restrictiv. Anomaliile apar doar n cazul actualizrilor datelor, ceea ce sugereaz
c o rafinare a tehnicii implic folosirea a dou tipuri de blocri:
-locare parta1at (share loc- sau S loc-) - Permite citirea obiectului dar
interzice modificarea acestuia, motiv pentru care mai este numit "blocare
pentru citire" (read loc-). Mai multe tranzacii pot bloca simultan pentru
citire un anumit obiect.
-locare e.clusi0 (exclusi#e loc- sau @ loc-) - nterzice accesul altor
tranzacii la obiectul blocat, fie pentru citire, fie pentru modificare. Blocarea
3!
exclusiv este mai "tare" dect blocarea partajat, fiind folosit doar
pentru actualizri, motiv pentru care mai este numit "blocare pentru
scriere" (>rite loc-).
Se poate observa c anumite cereri de blocare asupra unui obiect pot fi
compatibile sau nu, n functie de tipul blocrii. Compatibilitatea cererilor de
blocare poate fi exprimat sintetic printr-o matrice de compatibilitate (vezi caseta
"Focus: Blocri").
O situaie special este cea n care o tranzacie blocheaz pentru citire un obiect
i dorete s obin o blocare exclusiv. Dac obiectul respectiv nu este blocat
partajat i de ctre alte tranzacii, blocarea exclusiv este obinut de tranzacia
n cauz. Procedeul de numete "promovarea blocrii" (loc- promotion).
S ne oprim puin pentru cteva observaii:
a. n cazul celor mai multe SGBD-uri, blocarea este implicit: orice operaie
asupra datelor este automat precedat de cererea pentru obinerea blocrii
datelor respective (S loc- pentru citire, @ loc- pentru actualizare - ntelegnd prin
"actualizare" operaiile UPDATE, NSERT i DELETE). ncheierea tranzaciei (cu
sau fr succes) elibereaz n mod automat blocrile pe care aceasta le deinea.
Anumite sisteme (de pild Adabas D) permit "nlnuirea tranzaciilor"
(transaction chaining) cu pstrarea anumitor blocri (prin clauza KEEP LOCK a
instruciunii COMMT).
b. Standardul SQL nu face nici o prezumie legat de modul de implementare a
mecanismelor de control al accesului concurent (prin blocare, prin mrci de timp
sau alte metode) i, n consecin, nu prevede instruciuni explicite de blocare.
Cu toate acestea, majoritatea SGBD-urilor relaionale ofer n propriile dialecte
SQL instruciuni de blocare explicit (LOCK). Anumite sisteme non-relaionale
(Raima, de exemplu) folosesc doar blocri explicite. De obicei, aceste sisteme
prevd i instruciuni de deblocare explicit (UNLOCK).
c. Dei sunt cele mai uzuale, blocrile partajate i exclusive nu sunt singurele
posibile. Unele SGBD-uri (BM DB2, Sybase SQL Server, Raima db_VSTA)
folosesc o aa-numit "blocare pentru actualizare" (update loc-), care este un
nivel intermediar ntre blocarea partajat i cea exclusiv.
Dac mai multe tranzacii blocheaz partajat (pentru citire) un anumit obiect, una
dintre ele (doar una) poate obine o blocare pentru actualizare (remarcai c o
blocare exclusiv nu poate fi obinut n aceste conditii). De obicei utilizarea
blocrii pentru actualizare este posibil doar n situaia unui mecanism de control
special (bazat n general pe versiuni multiple ale datelor) care s avertizeze o
alt tranzacie care solicit o blocare pentru actualizare c datele au fost
modificate.
.+
10.1 3eadlc)
S revedem acum problema "actualizrii pierdute", folosind blocrile
partajate i exclusive. La momentul t1 tranzacia R1 solicit o blocare partajat a
liniei Z i (presupunnd c linia nu era blocat pentru scriere de o alt tranzacie)
o obine. La momentul t2, tranzacia R2 solicit i ea o blocare partajat a liniei Z
i o obine la rndul ei. Ambele tranzacii blocheaz n acest moment pentru citire
linia Z. La momentul t3, tranzacia R1 solicit blocarea exclusiv a liniei Z, pentru
a face o actualizare.
Nu obine blocarea, deoarece linia este blocat pentru citire de tranzacia
R2, deci este pus n stare de ateptare. Tranzacia R2 cere i ea blocarea
exclusiv i, evident, nu o obine din motive similare. Nici una dintre tranzacii nu
poate continua, deoarece fiecare ateapt ca cealalt s elibereze linia Z.
Aceast situatie se numeste deadloc- sau "interblocare". Este uor de verificat
c i n situaia "analizei inconsistente" se va ajunge la o interblocare. Rezultatul
este c am rezolvat problema anomaliilor (ntr-adevr, acestea nu mai apar) dar
am obinut o alt problem, cea a interblocrilor. Rezolvarea noii probleme
cuprinde dou aspecte:
1. Pre0enirea interblocrii. mplic stabilirea unui protocol de acces la date
care s fac imposibil apariia situaiilor de deadloc-. O variant posibil este ca
fiecare tranzacie s blocheze "n bloc" toate liniile de care are nevoie. Alta
variant este stabilirea unei ordini a obiectelor iar cererile de blocare s fie
rezolvate n conformitate cu aceast ordine. Ambele metode au dezavantajul c
limiteaz semnificativ performanele prin blocarea resurselor pe durate mai lungi
dect cele strict necesare. Pe de alt parte, prima metod nu este aplicabil
ntotdeauna, deoarece este posibil ca o tranzacie s nu cunoasc de la nceput
toate datele de care are nevoie.
2. Detectarea interblocrii. Cea mai simpl metod de detectare a unei situaii
de deadloc- este cea bazat pe un mecanism de time;out: dac durata execuiei
unei tranzacii depete o valoare prestabilit, sistemul deduce c a aprut o
interblocare. O alt metod se bazeaz pe construirea i meninerea dinamic a
unui "graf de ateptare" (5ait;?or )raph). Nodurile acestui graf reprezint
tranzaciile care se execut (T1, T2, ..., Tn) iar arcele reprezint relaia de
dependen (ateptare): existena unui arc de la Ti la Tj semnific faptul c
tranzacia Ti ateapt ca tranzacia Tj s elibereze anumite resurse. Detectarea
unei interblocri revine la detectarea existenei unui ciclu n graful de ateptare.
n practic, cel mai adesea se utilizeaz o mixtur de tehnici: se impune
un protocol de acces care s reduc posibilitatea interblocrii (fr s o previn
total, dar i fr s inhibeze semnificativ concuren), se implementeaz un
mecanism care s detecteze interblocrile cele mai uzuale, lsndu-le pe
celelalte pe seama unui mecanism de time-out.
.1
Rezolvarea efectiv a unei interblocri revine la stabilirea unei "victime" dintre
tranzaciile implicate n deadlock i anularea ei (ROLLBACK). Dup ce
interblocarea a fost nlturat, tranzacia poate fi lansat din nou n execuie.
Observaii:
a. Desigur, ntr-o interblocare pot s intervin mai mult de dou tranzacii (dei
experimentele cu System R au demonstrat c n realitate astfel de situaii sunt
extrem de rare). n acest caz este posibil ca mai multe tranzacii s trebuiasc
anulate pentru a debloca execuia.
b. Cele mai multe sisteme reprogrameaz automat pentru execuie tranzaciile
anulate. Exist ns i sisteme care returneaz doar un cod de eroare aplicaiei,
acesteia revenindu-i sarcina s se ocupe de rezolvarea problemei.
10.2 Serializare
Problema care se pune este: cum putem s tim dac execuia
concurent a unui grup de tranzacii este corect sau nu?
S ncepem cu o definiie: Se numete planificare (schedule) oricare ordine
posibil de executare a operaiilor grupului de tranzacii considerat.
O prim constatare este c, dac presupunem c fiecare tranzacie n
parte din grup este corect, atunci orice planificare serial a tranzaciilor (una
dup alta, indiferent de ordine) este corect. Dei afirmaia este intuitiv, se
poate justifica uor prin faptul c orice program execut o secven de tranzacii
(deci niciodat dou tranzacii simultan). Aadar, tranzaciile din grupul
considerat sunt executate de programe diferite (sunt deci independente), ordinea
execuiei lor fiind irelevant (de regul FFO: first in, first out).
n cazul n care se execut operaii ale unei tranzacii n timp ce execuia altor
tranzacii nu a fost nc ncheiat avem de-a face cu o planificare intercalat
(interlea#ed), caz n care este posibil ca execuia s nu fie corect (cum a fost
cazul celor trei exemple prezentate la nceput).
Dou planificri ale unui grup de tranzacii sunt echivalente dac vor produce
mereu acelai rezultat, oricare ar fi starea iniial a bazei de date (aceasta
nseamn, de fapt, c operaiile conflictuale sunt n aceeasi ordine).
O planificare este serializabil dac este echivalent cu o planificare serial.
Orice planificare serial fiind corect, nseamn c am gsit criteriul de
corectitudine cutat. Execuia unui grup de tranzacii este corect dac s-a fcut
conform unei planificri serializabile. S remarcm c nici una dintre planificrile
utilizate ca exemple pentru cele trei anomalii nu este serializabil.
.2
O caracterizare mai puin riguroas, dar mult mai intuitiv a caracterului
serializabil este urmtoarea: Oricare ar fi dou tranzacii A i B dintr-o planificare
a unui grup de tranzacii concurente, fie A precede logic pe B, fie B precede logic
pe A. Faptul c "A precede logic pe B" nseamn c B poate vedea rezultatele
execuiei tranzaciei A. Deci, dac considerm toate obiectele vzute de
tranzacia A, atunci B vede toate aceste obiecte fie modificate deja de A, fie n
forma n care erau nainte ca modificrile s se produc, dar niciodat ca un
amestec de obiecte modificate i obiecte nemodificate.
Teoria este, desigur, mult mai bogat (vezi de pild [OSZU91]) i specific mai
multi algoritmi de verificare a criteriului pe care l-am enunat. Rezultatul cel mai
important din perspectiv practic a acestei teorii este aa-numita "teorem a
seriabilittii" (sau "a blocrii n dou faze"):
Dac toate tranzaciile unui grup de tranzacii concurente sunt bine formate +i
respect protocolul de blocare 2n dou faze atunci orice planificare legal este
serializabil$
Demonstraia nu este dificil (o variant se bazeaz pe graful de precedent al
planificrii i se desfsoar prin reducere la absurd). mportante sunt ns
condiiile:
O tranzacie este "bine format" dac orice operaie a tranzaciei este acoperit
de o blocare i toate blocrile sunt eliberate. O operaie (citire sau scriere) este
"acoperit de o blocare" dac tranzacia deine o blocare suficient de puternic a
obiectului asupra cruia se desfsoar operaia.
O planificare este "legal" dac nu se desfsoar n condiiile unor blocri
conflictuale.
Un "protocol de blocare" const dintr-un set de restricii impuse ordinii n care
tranzaciile concurente blocheaz i deblocheaz obiectele bazei de date.
Protocolul de blocare n dou faze (t>o;phase loc-ing) impune urmtoarele dou
restricii:
1. nainte de a opera asupra oricrui obiect al bazei de date, o tranzacie trebuie
s obin blocarea respectivului obiect.
2. Dup ce a eliberat o blocare, o tranzacie nu va mai ncerca niciodat s
obtin noi blocri.
Se observ cu usurin explicaia denumirii "n dou faze" (care n-are nimic n
comun cu comiterea n dou faze): conform acestui protocol orice tranzacie
trece mai nti printr-o faz de obinere a blocrilor, dup care trece ntr-o faz de
eliberare a blocrilor.
.3
O scurt discuie asupra acestui protocol se impune. n primul rnd trebuie
spus c sarcina asigurrii respectrii acestui protocol revine Lock Manager-ului
(desigur, dac sistemul lucreaz pe baza acestui protocol). Mai observm c
protocolul prevede "eliberarea blocrilor". O regul de "bun sim" spune c un
obiect trebuie blocat ct mai puin timp cu putin, pentru a permite i accesul
altor tranzacii la acesta.
Din pcate, implementarea acestui protocol n forma sa cea mai eficient
din acest punct de vedere este extrem de dificil: LM trebuie s "tie" cnd o
tranzacie a obinut toate blocrile i nu va mai avea nevoie de altele (pentru a
identifica faza n care se afl); LM trebuie s tie dac tranzacia va mai avea
nevoie de un obiect asupra cruia a efectuat o operaie, deci dac poate sau nu
s-l elibereze (din acelai motiv al identificrii fazelor); n fine, apare problema
extrem de dificil a "anulrii n cascad" a tranzaciilor: n cazul n care o
tranzacie a fost anulat n faza a doua, este posibil ca unele date eliberate de
aceasta au fost apoi blocate de alte tranzacii, caz n care aceste tranzacii
trebuie la rndul lor anulate.
Din cauza acestor dificulti, majoritatea sistemelor implementeaz o
variant mai restrictiv a protocolului, n care toate eliberrile blocrilor unei
tranzacii sunt amnate pn la terminarea tranzaciei (fie prin COMMT fie prin
ROLLBACK).
Este deci rezonabil s considerm c blocrile obinute de o tranzacie
sunt pstrate pn la terminarea acesteia, cu toate c n felul acesta intervalul de
timp n care un obiect este blocat este de regul mai lung dect minimul necesar.
Compromisul este i aici prezent: simplificarea mecanismelor implementate n
Lock Manager compenseaz scderea nivelului de concuren prin blocri de
mai lung durat. Exist ns situaii n care se poate admite un grad oarecare
de interferen, caz n care nivelul concurentei poate fi crescut prin "relaxarea"
protocolului de blocare (n spet prin admiterea unor condiii n care anumite
blocri pot fi eliberate naintea terminrii tranzaciei).
Observaie: Din cte tiu, toate sistemele relaionale majore implementeaz
diverse forme ale protocolului de blocare n dou faze. Sistemele care utilizeaz
doar blocri i deblocri explicite las implementarea acestui mecanism n
seama proiectanilor de aplicaie. n oricare situaie, proiectanii sunt sftuii s nu
lase controlul blocrii nici o clip n seama utilizatorilor finali, din motive lesne de
nteles (sindromul "blocrii peste pauza de mas").
10.3 -lcare ierar"icA
Dac pn acum am folosit n exemple doar blocri la nivel de articol, n cele ce
urmeaz vom considera i blocri aplicate unor portiuni mai mari (pentru a nu
complica expunerea, ne putem limita la nivel de tabel). Tehnica blocrii ierarhice
se refer la sistemele care admit mai multe granulaii ale blocrii (vezi caseta
..
"Focus: Granulaie") i a fost introdus de Jim Gray i colaboratorii si nc din
1975. O descriere mai "didactic" poate fi consultat n [GRAY93].
deea de la care se pleac este c pentru o obine o blocare la nivel de articol
(linie de tabel), o tranzacie trebuie s-i manifeste aceast intenie, cernd mai
nti o blocare la nivel de tabel. n felul acesta se simplific procesul de
detectare a unor cereri conflictuale de blocare la nivel de linie, deoarece ele
trebuie nti s se manifeste la nivel de tabel. Protocolul bazat pe "intenii de
blocare" (intent loc-ing) introduce trei noi tipuri de blocare (la nivel de tabel),
alturi de cele dou tipuri de blocri uzuale (S-lock i X-lock) care, aa cum am
artat deja, au sens i la nivel de tabel. Avem astfel cinci tipuri de blocri pe
care o tranzacie T le poate solicita la nivelul ntregii tabele R, prezentate n
ordinea cresctoare a "triei" lor relative:
#' - intent shared. Tranzacia T intenioneaz s blocheze pentru citire (S loc-)
anumite linii ale tabelei R, pentru a garanta stabilitatea acestora n timpul
procesrilor pe care le va efectua.
#= - intent exclusi#e. La fel ca S, dar T s-ar putea s vrea s modifice anumite
articole i deci s solicite blocarea exclusiv a acestora.
' - shared. Este obinuita blocare partajat. T admite citiri concurente ale tabelei
R, dar nu i scrieri. T nu va face nici o scriere la nivelul liniilor tabelei.
'#= - shared intent exclusi#e. Combin S i X. n plus fa de S, T s-ar putea s
vrea s modifice anumite linii din R i, n consecin, s solicite blocarea
exclusiv a acestora.
= - exclusi#e. T nu admite citiri concurente n tabela R. T ar putea s actualizeze
anumite linii ale tabelei R.
Cteva observatii:
a. Noiunea de "trie" a blocrii se refer la faptul c o cerere de blocare de un
anumit tip care eueaz, va eua cu siguran pentru orice tip mai "tare". (vezi
"Focus: blocri").
b. Tipurile X i S sunt egale din punct de vedere al "triei".
c. Si aceste tipuri de blocri sunt n mod obinuit cerute n mod implicit. Cu toate
acestea, sistemele care implementeaz aceste tipuri de blocare (DB2,
Openngres) ofer de obicei i o instruciune de blocare explicit pentru aceste
tipuri.
d. Varianta pe care am prezentat-o este mult simplificat. De fapt blocrile se pot
referi la orice granulaii i orice obiecte ale bazei de date (inclusiv indeci).
.1
n fine, protocolul bazat pe intenii de blocare (intent loc-ing protocol), impune
dou reguli care mbin blocrile la nivel de tabel i de articol ntr-o combinaie
care adesea s-a dovedit mai eficient n aplicatii:
1. nainte de a obine o blocare partajat (S) la nivel de linie, o tranzacie trebuie
s obin o blocare de tip S (sau mai tare) la nivelul ntregii tabele.
2. nainte de a obine o blocare de tip exclusiv (X) la nivel de linie, o tranzacie
trebuie s obtin o blocare de tip X sau mai tare la nivelul ntregii tabele.
11. Protocolul 9n dou faze !3P$
E interesant c doar punnd ncuietori n jurul acceselor la date nu e suficient. Ca
s ne convingem, considerai tranzaciile T1 i T2 n forma n care exact fiecare
acces este protejat, ca n exemplul urmtor pentru T2:
Begin T2;
lock(salariu, readLock);
y := Read(salariu);
unlock(salariu);
y := y + 200;
lock(salariu, writeLock);
Write(salariu, y);
unlock(salariu);
End T2;
E uor de observat c o astfel de ncuiere permite execuii neserializabile (chiar
execuia indicat mai sus este posibil). Nu ajunge deci s ncuiem, trebuie s
respectm un protocol de ncuiere. Adic un set de reguli pentru toat lumea.
Cel mai simplu i mai des folosit protocol este cel n dou faze (two-phase
locking; 2PL). Acest protocol se poate enuna astfel:
n prima faz se pot numai obine ncuietori (adic se execut instruciuni lock i
upgrade).
n a doua faz se pot numai dealoca ncuietori (unlock sau degrade).
Dac facem un grafic al numrului de ncuietori posedate de o tranzacie, el
trebuie s arate cam ca n figura urmtoare: s aib o faz de cretere (growing
phase) i una de descretere (shrinking phase).
growing shrinking
^ ____
.6
| / \
numar de | / \____
incuietori | __/ |
| / \
0----------------------->
timp
Acest protocol garanteaz serializabilitatea. Este un exerciiu interesant s
demonstrm acest lucru. at o schi a demonstraiei.
S presupunem (prin absurd) c o serie de tranzacii T1, T2, ... Tn, care respect
protocolul 2PL, au avut o execuie ne-serializabil. Asta nseamn c n graful lor
de dependene exist un ciclu, T1 T2 ...Tn T1. Ce nseamn c avem
un arc de la T1 la T2? nseamn c T1 a operat asupra unei valori nainte de T2,
cu o operaie care nu comut cu cea a lui T2. Dar noi tim c T1 nu are voie s
opereze asupra unei valori ne-ncuiate. Asta nseamn c T2 a ncuiat acea
valoare dup ce T1 a descuiat-o. Arcul T2 T3 indic un lucru asemntor, i
anume c T3 a ncuiat o valoare (nu necesar aceeai) dup ce T2 a descuiat-o.
Din aproape n aproape obinem c, n fine, T1 a ncuiat o valoare dup ce T1 a
descuiat o alt valoare, ceea ce este absurd. Concluzia iniial era deci greit.
n concluzie 2PL garanteaz serializabilitate.
S observm ca 2PL nu este acelai lucru cu serializabilitatea, ci c 2PL doar o
implic.
Din punctul de vedere al abordrii blocrilor exista doua tipuri de 2PL:
A%6 ; Cu A+teptare si A%6 B Cu "estart. Primul tinde sa blocheze tranzacia
care ntmpina un conflict la blocarea resurselor necesare , in timp ce al doilea
tinde sa o restarteze. Un caz particular extrem al celui de-al doilea tip este
algoritmul A%6 B ?r A+teptare . Politica algoritmului A%6 B ?r A+teptare
consta in restartarea de fiecare data unei tranzacii care a ncercat blocarea unei
resurse deinuta de ctre o alta tranzacie. Modelul din lucrarea de fata este
bazat tocmai pe aceasta politica.
n contrast cu acest model este politica de A+teptare )enerala , in care o
tranzacie ce ntmpina un conflict la blocarea unei resurse se blocheaz ,
exceptnd cazul apariiei unei blocri totale , cnd se renuna la una dintre
tranzaciile implicate in blocare . Un astfel de mecanism va duce la o deteriorare
a performantelor datorata blocrilor si anularilor tranzaciilor. n particular A%6 B
cu A+teptare )enerala tinde spre un efect de avalan , in sensul ca blocarea
.9
unei tranzacii produce mai departe alte blocri pariale sau totale de tranzacii ,
fenomen cunoscut sub denumirea de Data Contention Thrashing (limitare din
punctul de vedere al accesului la date) . n principiu, pe msur ce MPL-ul
(MultiProgramming Level = Nivelul de MultiProgramare, adic numrul total de
tranzacii dintr-un sistem de baze de date) creste, throughput ul (rezultatele
prelucrrilor) creste aproape liniar pentru nceput, se plafoneaz la un moment
dat dup care scade brusc. Acest fenomen are ca rezultat o scdere drastica a
performantelor sistemului de baze de date. La ora actuala tendina principala
este de cretere a MPL-ului la valori cat mai mari posibile evitnd apariia acestui
fenomen. n acest sens , algoritmii de control al concurentei orientai pe restart
sau dovedit mai potrivii.
Comportamentul de acaparare a resurselor al unei tranzacii depinde in
principal de doi factori:
Numrul de granule (entiti) de date deja blocate (pentru scriere
si/sau citire)de ctre alte tranzacii
Numrul de granule (entiti) de date deja blocate de ctre
tranzacia in cauza, deoarece fiecare tranzacie necesita un set distinct de
granule (entiti de date).
Modelarea analitica a unui sistem real de baze de date este un lucru
destul de complicat avnd in vedere spaiul foarte mare al strilor posibile ale
unui sistem de baze de date.
Printre problemele atinse de modelele analitice propuse pana in prezent
pentru metode de Control al Concurentei ?r A+teptare se numra : acces
uniform si neuniform la date, tranzacii de lungime fixa si variabila. Rezultatele
obinute sunt sub forma unei analize a valorilor medii. Nu este prezentata o
soluie pentru probabilitatea strilor staionare a tranzaciilor.
Modelele stohastice aprute pana in prezent abordeaz doar o parte din
structura unui sistem de baze de date distribuit fr a lua in considerare efectele
strilor diferitelor tranzacii sau a numrului de granule (entiti) de date blocate
de ctre o tranzacie.
.>
n lucrarea de fata se va prezenta un model stohastic general de spaiu
multidimensional al strilor pentru studiul performantelor algoritmului A%6 -?r
A+teptare. Studiul mediului de baze de date si al strilor tranzaciilor se bazeaz
pe procese Markov. Modelul abordeaz accesul neuniform, blocarea pentru
scriere a granulelor de date, blocarea pentru citire a granulelor de date si
tranzacii mprite in clase.
Analiza consta din urmtorii pai: rezolvarea probabilitii strilor
staionare a sistemului, urmata de aflarea numrului mediu de tranzacii cu -
blocri de granule de date, a numrului mediu total de blocri de granule de date
deinute de toate tranzaciile, a numrului mediu de blocri de granule de date
deinute de o tranzacie, a numrului mediu de blocri de citire respectiv scriere
deinute de o tranzacie, a numrului mediu de granule blocate intr-o baza de
date. Aceti parametrii ofer o imagine mai detaliata a mecanismelor
tranzaciilor si a mediului unei baze de date. n cele din urma sunt calculai
throughput-ul(randamentul) si rata de restartari, care sunt cei doi parametrii
eseniali de performanta ai unui algoritm de acces la o baza de date distribuita.
1!. !P$ strict
Exist un dezavantaj al lui 2PL i o implementare care l evit. S
considerm urmtorul scenariu: o tranzacie T1 ncuie o valoare , o modific i
apoi o descuie. T2 vine la rnd, ncuie i citete . Dac acum T1 vrea s
execute Abort, valoarea lui trebuie pus cum era nainte ca T1 s o fi
modificat. Dar T2 a citit-o deja! Asta nseamn nimic altceva dect c dac T1
execut Abort, T2 trebuie s fie ``ucis'' de sistem, pentru a respecta
proprietatea de izolare! E clar c lanul poate fi mai lung: T3 poate a citit la rndul
ei , i atunci trebuie terminate (kill) i ea.
O astfel de situaie foarte neplcut (pentru c o mulime de operaii trebuie
``terse'') se numete cascaded abort (abort n cascad). (O alt consecin
neplcut este c T2 nu se poate termina nainte de T1, pentru c dac T2 face
Commit iar T1 Abort am ncurcat-o, cci T2 a promis c valoarea lui este
permanent, dar nu avea voie s-o citeasc! Deci T2 trebuie s atepte ca T1 s
se termine.)
Soluia este simpl: restrngi concurena, dar nu lai pe nimeni s vad ce-ai
modificat. Nu descui nimic pn la sfrit, cnd descui totul dintr-o micare (de
.!
exemplu folosind End Transaction, care elibereaz ncuietorile). Graficul ar arta
atunci cam aa:
+ro1in+ shrin2in+
3
4 5 4
numar de 4 5 4
incuietori 4 5 4
4 5 4terminare
0666666666666666666666667
tim'
13. Prototocolul send3on3demand
Sistemele de baze de date distribuite au caracteristici unice n mediile de
mare vitez. Cel mai important criteriu de studiere a performanelor ntr-o reea
de mari dimensiuni este latenta de comunicaie (ntrzierile de propagare a
semnalului). Succesul oricrui protocol n aceste medii depinde de modul n care
acesta tie s ,ascund' aceste ntrzieri.
n aceast nou schem, elementele de date nu mai sunt "limitate la un
anumit calculator, n mod special. Fiecare calculator, ce face parte din BDD,
ntreine o coad de pretenii, pentru fiecare element de date care este localizat
n mod curent pe acel calculator. Coada de pretenii pentru un element de date
conine o list a tranzaciilor (cu identificatoarele calculatoarelor unde este
executat tranzacia) care cer acel element de date i de asemenea specific
aciunea inclus n tranzacie asupra acelui element de date (citit/scris). Setul de
operaii de acces, impreun cu marca timpului de sosire al tranzaciei T - TS(T) a
fiecarei tranzacii care vine este transmis ctre toate calculatoarele din BDD.
Un mesaj tipic de transmisie, trimis de un calculator ce proceseaz o
tranzacie cu k elemente de date n setul sau de operaii de acces este dat
mai jos:
1+
Setul de operaii de acces al tranzaciei este introdus n coada de pretenii, al
unui calculator n ordinea marcilor de timp ale sosirii tranzaciei. Nici o aciune
nu este luat pn cand nu este sigur c toate calculatoarele din BDD au
primit aceast informaie. n acest punct, tranzacia este confirmat i durata
pe care un calculator trebuie s-o atepte pn cnd o tranzacie e confirmat
se numete durat de confirmare (B). O coad de pretenii, n orice moment
de timp, conine un set de tranzacii confirmate i un set de tranzacii
neconfirmate.
n figura de mai jos este descris o coad de pretenii pentru un element de
date cu m tranzacii din care n sunt tranzacii confirmate:
Durata confirmrii unei tranzacii este un timp mai mare sau egal cu cel
necesar trimiterii informaiei setului de operaii acces spre toate calculatoarele
din BDD. Acest lucru asigur ca la fiecare calculator, coada de pretenii s aib
intrri n ordine (n timp), i n acest fel nu pot aprea interblocri.
La pornirea sistemului, toate elementele de date se afl pe calculatoare
oarecare. Cand tranzaciile ncep s soseasc, cozile de pretenii ncep s se
ocupe. Toate calculatoarele ii transmit elementele de date rezidente spre
sistemul care a iniiat prima tranzacie confirmat, completnd cozile de pretenii
respective. n timp ce coada de pretenii este transmis, alte tranzacii,
11
ID4$l
%al++63$lat*r$l$i
%are a initiat tranza%tia
TSCTD
Alte
inf*r&atii
D1 R7L
J
D3 R7L
T
&
J T
nH1
T
n
J T
2
T
1
Neconfirmate
Con#irmate
Preten0ii n*i
necesitnd acelai element de date, pot sosi n sistem. nformaii despre aceste
tranzacii pot fi obinute din informaia de transmisie (vezi formatul unui mesaj de
transmisie). Fiecare calculator care iniiaz o tranzacie ateapt pentru ca
ntregul set de operaii de acces s ajung la locaia lui, termina procesarea
tranzaciei i apoi transmite elementele de date la alte calculatoare care se afl
la rnd n cozile de pretenii respective. Acest mecanism elimin necesitatea de
deblocare a elementelor de date, fa de sistemele tradiionale, n care, pentru a
se menine atomicitatea tranzaciilor, se implementeaz protocoale speciale de
validare (commit). Noul algoritm are nevoie doar de un protocol de validare local.
Atta timp ct fiecare calculator ntreine cozi de pretenii doar pentru acele
elemente de date care rezid n mod curent pe acel calculator, necesitile de
memorie nu sunt foarte mari.Fiecare calculator trebuie s aib alocat memorie
necesar stocrii informaiei despre setul de operaii de acces al tranzaciilor
confirmate.
O tranzacie tipic de actualizare are un set de operaii de citire precum i
un set de operaii de scriere. Astfel, o coad de pretenii tipic pentru un element
de date are intrri de citire i intrri de scriere. ntrrile consecutive de citire pot fi
procesate n paralel, n timp ce intrrile de scriere trebuiesc servite serial. De
exemplu, considerand coada de pretenii a unui singur element de date D
j
, unde
se afl dou intrri de scriere separate de cateva intrri de citire. Dup ce prima
scriere a fost completat de calculatorul care deine (acum) copia scris a lui D
j
,
se trimite mai departe versiunea actualizat a lui D
j
ctre toate calculatoarele
care au o intrare de citire n coada de pretenii, nainte de scrierea urmatoare.
Copia scris actuala este trimis calculatorului care este responsabil pentru
ultima intrare de citire inainte de a doua intrare de scriere. Dupa ce este
terminat fiecare tranzacie care necesit citirea lui D
j
, exist un mecanism de
informare a calculatorului care vrea sa-l modifice pe D
j
. Acest mecanism este
realizat prin calculatoarele care-l citesc pe D
j
care trimit cate un mesaj ctre
calculatorul care ateapt sa-l scrie pe D
j
; acesta ateapt momentul propice
actualizrii i anume acela cnd s-a sfarit citirea lui D
j
. Calculatorul care are
12
copia de scriere transmite aceast copie a lui D
j
impreun cu mesajul i apoi
actualizarea la acel calculator poate ncepe.
Algoritmul send-on-demand poate fi rezumat in forma urmatoare :
Toate calculatoarele actualizeaz cozile de pretenii, iar dac sunt
responsabile de transmiterea unui fragment din baza de date,
adaug informaia marcii de timp la elementul de date i apoi terge
informaia despre tranzacia actualizat din cozile de pretenii prin
verificarea marcii de timp.
Calculatoarele care proceseaz actualizri transmit ntregul set de
operaii de acces (setul de operaii de citire i setul de operaii de
scriere) al actualizrii catre toate calculatoarele, ateapt
evenimentele (a) sunt primite toate elementele de date din setul de
operaii de acces i (b) mesajul "completat a ajuns de la tranzaciile
care dein o copie de citire a elementelor de date n setul lor de
operaii de citire, execut actualizarea, trimite o copie a fiecarei
actualizari (odat cu timpul la care s-a executat actualizarea) ctre
calculatoarele respective responsabile pentru transmiterea lor, dac
deine o copie de citire a elementului de date D
j
, trimite o completare
a mesajului ctre urmtoarea scriere n coada de pretenii pentru D
j
,
iar dac deine o copie de scriere a lui D
j
, trimite o copie de citire a
lui D
j
ctre toate calculatoarele care au o intrare de citire n coada de
pretenii nainte de scrierea urmtoare i trimite copia de scriere
ctre urmatoarea scriere.
Calculatoare care proceseaz interogri scaneaz canalele de
transmisie pe care elementele de date sunt transmise, urmarind
elementele de date din setul de operaii de acces al interogrii,
citete doar acele copii care sunt consistente mutual prin verificarea
informaiei mrcii de timp respective i execut interogarea.
Aplicabilitate>
13
Din punct de vedere practic, algoritmii de tip ,send on demand in afara
controlului concurential al accesului la date este intalnit in replicarile
tranzactionale, de tip merge etc.
Concluzii>
1. Din punct de vedere practic, cei mai utilizati algoritmii sunt
algoritmii de tip 2-PL ;
2. Performantele algoritmului de tip optimist sunt net superioare
celui de blocare in cazul in care nu apare concurenta.
-ibliografie>
1. SQL 2005 Books OnLine ;
2. Manuale curs Microsoft (curs 2779).
1.