Documente Academic
Documente Profesional
Documente Cultură
Metode de Accesare La BD
Metode de Accesare La BD
Cuprins
1.
Prezentare generala.
10
11
4.2 Definitii.
12
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 multiversiune.
5.2 Citirea consistenta, segmentele rollback 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-only
Implicit, 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,
14
15
16
7. Tranzacii
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.
Indiferent 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.
O tranzacie (transaction) este o unitate logic de prelucrare indivizibil
(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:
CURSE(IdCursa,AeroportPlecare,AeroportSosire,Data,
NrLocuriLibere)
PASAGERI(IdPasager,Nume,Prenume,Adresa, NrCreditCard)
REZERVARI(IdRezervare,IdPasager,IdCursa)
FACTURI(IdFactura,IdPasager,DataFacturarii,Pret)
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.
17
18
19
20
21
22
pentru efectuarea acestei tranziii. n cursul strii ACTIV, orice tranzacie poate
fi abandonat (i trecut n starea ABANDONAT prin execuia unei operaii
abort), dac diferite verificri efectuate nu sunt ndeplinite.
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.
8. TEHNICI DE CONTROL AL CONCURENEI
24
25
T1
A t1
A t2
A t3
A t4
A t5
A t6
begin_transaction
cit(balx)
balx = balx - 10
scrie(balx)
commit
T2
balx
begin_transaction
cit(balx)
balx = balx + 10
scrie(balx)
commit
100
100
100
200
90
90
T3
begin_transaction
cit(balx)
balx = balx - 10
T4
balx
begin_transaction
cit(balx)
balx = balx + 10
scrie(balx)
100
100
100
200
200
100
rollback
26
A t7
A t8
scrie(balx)
190
190
commit
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 T5 i T6 executate serial, adic una dup alta, ar
trebui s dea rezultatele:
T5T6 balx=100-10=90, balz=25+10=35, sum=90+50+35+175
sau T6T5 sum=100+50+25=175, balx=100-10=90, balz=25+10=35
i putem vedea n figura urmtoare ce se poate ntmpla ncazul concurenei
libere, necontrolate:
Time
A t1
A t2
A t3
A t4
A t5
A t6
T5
T6
balx baly
balz
sum
begin_transaction
cit(balx)
balx = balx
-10
scrie(balx)
cit(balz)
begin_transaction
sum = 0
cit(balx)
sum = sum +
balx
cit(baly)
sum = sum +
baly
100
100
100
100
50
50
50
50
25
25
25
25
0
0
100
90
90
50
50
25
25
100
150
balz = balz +
90
50
25
150
scrie(balz)
90
90
90
50
50
50
35
35
35
150
150
185
90
50
35
185
A t7
10
A t8
A t9
A t10
A t11
commit
cit(balz)
sum = sum +
balz
commit
27
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 partajat
(part_bloc) o anumit unitate de memorie, o alt tranzacie nu mai poate s
rescrie tot acolo, iar cnd o tranzacie blocheaz exclusiv (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:
ntreaga baz de date
tabela(fiier)
nregistrare (cel mai des)
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
n 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 T1 ,T2 respectiv T3 , T4, T5 , T6
cu protocolul n dou faze i realizeaz planuri serializabile.
Time
T1
A t1
A t2
A t3
A t4
A t5
A t6
A t7
A t8
A t9
A t10
A t11
begin_transaction
ex_bloc(balx)
ATEAPT
ATEAPT
ATEAPT
cit(balx)
balx = balx -10
scrie(balx)
debloc(balx)
commit
Time
T3
A t1
A t2
A t3
T2
balx
begin_transaction
ex_bloc(balx)
cit(balx)
balx = balx +100
scrie(balx)
debloc(balx)
commit
100
100
100
100
200
200
200
200
190
190
190
T4
balx
begin_transaction
ex_bloc(balx)
cit(balx)
100
100
100
28
A t4
A t5
A t6
A t7
A t8
A t9
A t10
A t11
A t12
Time
A t1
A t2
A t3
A t4
A t5
A t6
A t7
A t8
A t9
A t10
A t11
A t12
A t13
A t14
A t15
A t16
A t17
A t18
A t19
A t20
A t21
A t22
begin_transaction
ex_bloc(balx)
ATEAPT
ATEAPT
cit(balx)
balx = balx -10
scrie(balx)
debloc(balx)
commit
100
200
100
100
100
100
90
90
90
T5
T6
balx baly
balz
sum
begin_transaction
begin_transaction
sum = 0
100 50
100 50
100 50
25
25
25
0
0
part_bloc(balx)
ATEAPT
100 50
100 50
25
25
0
0
ATEAPT
ATEAPT
90
90
50
50
25
25
0
0
ATEAPT
ATEAPT
90
90
50
50
25
25
0
0
ATEAPT
ATEAPT
90
90
50
50
35
35
0
0
ATEAPT
cit(balx)
sum = sum + balx
part_bloc(baly)
cit(baly)
sum = sum + baly
part_bloc(balz)
cit(balz)
sum = sum + balz
90
90
90
90
90
90
90
90
90
90
50
50
50
50
50
50
50
50
50
50
35
35
35
35
35
35
35
35
35
35
0
0
90
90
90
140
140
140
175
175
90
50
35
175
ex_bloc(balx)
cit(balx)
balx = balx
-10
scrie(balx)
ex_bloc(balz)
cit(balz)
balz = balz +
10
scrie(balz)
debloc(balx ,
balz)
commit
debloc(balx,baly,balz)
commit
29
Time
T7
A t1
A t2
A t3
A t4
A t5
begin_transaction
ex_bloc(balx)
cit(balx)
part_bloc(baly)
balx = baly +
balx
scrie(balx)
debloc(balx)
rollback
A t6
A t7
A t8
A t9
A t10
A t11
A t12
A t13
A t14
A t15
A t16
A t17
A t18
T8
T9
begin_transaction
ex_bloc(balx)
cit(balx)
balx = balx +100
scrie(balx)
debloc(balx)
rollback
begin_transaction
part_bloc(balx)
rollback
30
Time
T10
T11
A t1
A t2
A t3
A t4
A t5
A t6
A t7
A t8
A t9
A t10
A t11
begin_transaction
ex_bloc(balx)
cit(balx)
balx = balx -10
scrie(balx)
ex_bloc(baly)
ATEAPT
ATEAPT
ATEAPT
begin_transaction
ex_bloc(baly)
cit(baly)
baly = baly +100
scrie(baly)
ex_bloc(balx)
ATEAPT
ATEAPT
ATEAPT
T10
T11
31
Time
Op
T7
A t1
A t2
A t3
A t4
A t5
A t6
A t7
A t8
A t9
A t10
A t11
A t12
A t13
A t14
A t15
A t16
A t17
A t18
cit(balx)
balx = balx +10
scrie(balx)
cit(baly)
baly = baly +20
cit(baly)
scrie(baly)
baly = baly +30
scrie(baly)
balz=100
scrie(balz)
balz=50
scrie(balz)
cit(baly)
baly = baly +20
scrie(baly)
T8
begin_transaction
cit(balx)
balx = balx +100
scrie(balx)
T9
begin_transaction
cit(baly)
baly = baly +20
begin_transaction
cit(baly)
scrie(baly)**
balz=50
scrie(balz)*
commit
Faza 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.
33
9. CONTROLUL TRANZACIILOR
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 TRANSACTION optiuni
COMMIT [WORK] ROLLBACK [WORK]
Comanda SET TRANSACTION stabilete proprietile tranzaciilor i
admite urmtoarele opiuni de setare a modului de gestiune a tranzaciilor:
0 Nivelul de izolare a tranzaciilor (ISOLATION LEVEL) cu valorile
posibile: READ UNCOMMITTED, READ COMMITTED, REPETABLE
READS, SERIALIZABLE.
1 Modul de acces la articole - cu valorile posibile READ ONLY, READ
WRITE.
2 Modul de refacere a datelor (SET CONSTRAINTS), cu valorile
posibile DEFERRED (refacere amnat) i IMMEDIATE (refacere
imediat).
34
36
37
38
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 (locking) 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.
Idea 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 lock - a ncuia, a zvor). Controlul
blocrii datelor este asigurat de o component a SGBD-ului numit Lock
Manager (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 (wait) pn cnd obiectul este eliberat.
S re-analizm a doua anomalie prezentat n seciunea precedent
(uncommitted dependency). 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:
Blocare partajat (share lock sau S lock) - Permite citirea obiectului dar
interzice modificarea acestuia, motiv pentru care mai este numit "blocare
pentru citire" (read lock). Mai multe tranzacii pot bloca simultan pentru
citire un anumit obiect.
Blocare exclusiv (exclusive lock sau X lock) - Interzice accesul altor
tranzacii la obiectul blocat, fie pentru citire, fie pentru modificare. Blocarea
39
exclusiv este mai "tare" dect blocarea partajat, fiind folosit doar
pentru actualizri, motiv pentru care mai este numit "blocare pentru
scriere" (write lock).
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" (lock 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 lock pentru citire, X lock pentru actualizare - ntelegnd prin
"actualizare" operaiile UPDATE, INSERT 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 COMMIT).
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 (IBM DB2, Sybase SQL Server, Raima db_VISTA)
folosesc o aa-numit "blocare pentru actualizare" (update lock), 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.
40
10.1 Deadlock
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 deadlock 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. Prevenirea interblocrii. Implic stabilirea unui protocol de acces la date
care s fac imposibil apariia situaiilor de deadlock. 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 deadlock 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" (Wait-For Graph). 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.
41
42
43
44
45
growing shrinking
____
46
|
numar de
incuietori
/ \
| /
| __/
\____
|
|/
\
0----------------------->
timp
Acest protocol garanteaz serializabilitatea. Este un exerciiu interesant s
demonstrm acest lucru. Iat 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:
2PL - Cu Ateptare si 2PL Cu Restart. 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 2PL Fr Ateptare . Politica algoritmului 2PL Fr Ateptare
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.
In contrast cu acest model este politica de Ateptare Generala , 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. In particular 2PL
cu Ateptare Generala tinde spre un efect de avalan , in sensul ca blocarea
47
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) . In 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. In 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:
48
49
numar de
incuietori
growing
shrinking
^
_________
|
/
|
|
/
|
| __/
|
| /
|terminare
0----------------------->
timp
50
ID-ul
cal0063ulatorului
care a initiat tranzactia
TS(T)
Alte
informatii
D1
R/W
Dk
R/W
Pretenii noi
Neconfirmate
Confirmate
Tm Tn+1
Tn T2 T1
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,
51
necesitnd acelai element de date, pot sosi n sistem. Informaii 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. Intrrile 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 Dj; acesta ateapt momentul propice
actualizrii i anume acela cnd s-a sfarit citirea lui D j. Calculatorul care are
52
al
actualizrii
catre
toate
calculatoarele,
ateapt
Aplicabilitate:
53
Concluzii:
1.
2.
Bibliografie:
1. SQL 2005 Books OnLine ;
2. Manuale curs Microsoft (curs 2779).
54