Upload
anonymous-rrgvqj
View
85
Download
3
Embed Size (px)
DESCRIPTION
Kurs Special
Citation preview
1
LEKSIONE LEKSIONE
Disiplina/Moduli : Kurs Special: Baza Te Dhenash II
Programi i Studimit : Teknologji Informacioni
Forma e Studimit : Me kohe te plote
Kursi III Semestri V Viti Akademik 2014 - 2015
Emri i Pedagogut : M.Sc. Kosta Lili
REPUBLIKA E SHQIPËRISËREPUBLIKA E SHQIPËRISË
UNIVERSITETI ” EQREM ÇABEJ ”UNIVERSITETI ” EQREM ÇABEJ ”
I. MENAXHIMI I TRANSAKSIONEVE
Ne kete kapitull do te shqyrtojme konceptin e transaksionit, qe eshte baza e egzekutimit te
njekohshem dhe rimekembjes nga deshtimet ne nje system te menaxhimit te bazave te te
dhenave (SMBD). Transaksioni perkufizohet si nje egzekutim cfaredo i programeve te
perdoruesve ne nje SMBD dhe eshte shume i ndryshem nga egzekuimi i nje programi jashte
nje SMBD. Per arsye performance, nje SMBD duhet te nderthure veprimet e disa
transaksioneve. Megjithate nderthurja kryhet me kujdes ne menyre qe te garantohet se
rezultatet e nje egzekuimi te njekohshem te transaksioneve eshte ekuivalent me me nje
egzekutim serial (njeri pas tjetrit) te transaksioneve. Menyra se si SMBD menaxhon
egzekutimin e njekohshem eshte nje aspect i rendesishem i menaxhimit te transaksioneve
trajtohet nga kontrolli i egzekutimit te njekohshem. Nje ceshtje e lidhur ngushte me sa me
larte eshte menyra se si SMBD menaxhon transaksione te pjeshme ose transaksione tecilat
nderpriten perpara se te perfundojne normalisht. SMBD garanton se ndryshimet e kryera nga
transaksione te tilla nuk jane te te dukshme per transaksione te tjera. Menyra se si arrihet kjo
trajtohet nga rimekembja nga deshtimet. Ne kete kapitull paraqitet nje hyrje e pergjithshme
ne menaximin e egzekutimit te njekohshem dhe rimekembjen nga deshimet ne nje SMBD.
I.1 Koncepti i Transaksionit
Nje perdorues shkruan komanda per leximin/modifikimin e te dhenave nepermjet nje gjuhe te
nivelit te larte e cila mbeshtetet nga SMBD (p.sh. SQL). Per te kupuar se si SMBD vepron
me keto komanda ne lidhje me egzekutimin e njekohshem dhe rimekembjen nga deshtimet,
na ndihmon te konsiderojme egzekutimin e nje programi te perdoruesit (transaksion) si nje
sekuence leximesh dhe shkrimesh (modifikimesh) te objekteve te bazes se te dhenave:
Per te lexuar nje objekt ai fillimisht sillet nga disku ne memorjen kryesore dhe vlera e
tij kopjohet ne nje variabel te programit
Per te shkruar nje objekt nje kopje e tij modifikohet dhe ne vazhdim shkruhet ne disk
Objektet e bazes se te dhenave jane njesite me te cilat programi lexon apo shkruan te dhenat
dhe mund te jene faqe, rreshta tabelash etj.
2
Egzistojne kater karakteristika te rendesishme te transaksioneve te cilat duhet te garantohen
nga SMBD gjate egzekutimit te njekohshem dhe deshtimeve te sistemit:
1. Atomic: duhet te egzekutohen te gjitha veprimet e nje transaksioni ose asnje prej tyre.
Perdoruesit nuk duhet te shqetesohen per efektet e transaksioneve te pjeshme.
2. Consistency: cdo transaksion nese egzekutohet i vetem (jo njekohesisht me te tjere)
duhet te ruaje konsistencen e bazes se te dhenave. Kjo eshte detyre e perdoruesit.
3. Isolation: perdoruesve duhet t’u duket sikur transaksioni i tyre kryhet i vetem ne
sistem (nuk duhet te shqetesohen per egzekutimn e njekohshem).
4. Durability: nese SMBD informon perdoruesin se transaksioni u kompletua me sukses
efektet e transaksionit duhet te jene perfundimtare edhe nese sistemi deshton.
Fjala ACID perdoret zakonisht per tiu referuar kater karakteristikave te transaksioneve qe u
paraqiten me larte. Ne vazhdim do te shikojme se si garantohet secila karakteristike nga
SMBD.
I.1.1 Consistency dhe Isolation
Perdoruesi eshte pergjegjes per garantimin e konsistences se transaksioneve. Kjo do te thote
se perdoruesi i cili egzekuton nje transaksion duhet te garantoje se nese ky transaksion
egzekutohet i vetem ne nje baze konsistente e le ate po konsistente pas egzekutimit te tij. Per
shembull, nje perdorues mund te kete si kriter konsistence se transferime midis llogarive
bankare nuk duhet te ndryshojne totalin e vleres ne gjithe llogarite. Per te transferuar para
nga njera llogari tek tjetra, nje transaksion duhet te debitoje llogarine e pare duke lene
perkohesisht bazen ne gjendje jo konsistente. Baza kthehet perseri ne gjendje konsistente ne
momentin kur llogarija e dyte kreditohet me vleren e transferuar. Nese nje transaksion i
gabur gjithmone krediton llogarine e dyte me nje lek me pak se sa debiton llogarine e pare,
SMBD nuk mundet te dedektoje mungesen e konsistences. Pra, eshte detyre e perdoruesit te
shkruaje transaksione konsistente.
Isolation arrihet duke garantuar se me gjithe egzekutimin e nderthurur te transaksioneve
rezultati eshte i njejte me egzekutimin serial (njeri pas tjetrit) te tyre. Per shembull, nese dy
3
transaksione T1 dhe T2 egzekutohen njekohesisht (ne menyre te nderthurur) garantohet se
rezultati eshte ekuivalent me egzekutimin vecmas te T2 dhe pastaj te T2 apo anasjelltas.
I.1.2 Atomicity dhe Durability
Transaksionet mund te egzekutohen ne menyre te pjesshme per tre arsye. Se pari, nje
transaksion mund te nderpritet (anullohet) nga SMBD per arsye te ndonje anomalie gjate
egzekutimit te tij. Nese nje transaksion nderpritet nga SMPD per arsye te brendshme, ai
rifillohet atotomatikisht. Se dyti, sistemi mund te deshtoje (p.sh. per shkak te ndeprerjes se
energjise) nderkohe qe nje apo me shume transaksione jane duke u egzekutuar. Se treti, nje
transaksion mund te arrije ne nje situate te paparashikuar (p.sh. te mos mundet te aksesoje
disk-un) dhe te vendose te nderpritet (te ndaloje venet e vet).
Perderisa perdoruesit presin qe transaksionet te jene aomic, nje transaksion i nderprere mund
te leje bazen ne nje gjendje jo konsistente. SMBD duhet te gjeje nje menyre te c’beje efektet
e transaksioneve te pjesshem nga baza, pra duhet te garantoje atomicity: ose te gjitha
veprimet e nje transaksioni do te egzekutohen ose asnje. SMBD garanton atomicity duke
anulluar veprimet e transaksioneve te pjeshme. Per te mundesuar kete SMBD mban nje ditar
te quajtur log ku shenohen gjithe shkrimet ne bazen e te dhenave. Log-u perdoret gjithashtu
edhe per te garantuar durability: nese sistemi deshton perpara se modifikimet e kryera nga nje
transaksion te shkruhen ne disk, log-u perdoret per te “mbajtur mend” dhe per te rikryer
modifikimet kur sistemi te rikthehet.
I.2 Transaksionet dhe Planet
Nje transaksion shihet nga SMBD si nje sekuence apo liste veprimesh. Veprimet qe mund te
kryhen nga nje transaksion jane lexime dhe shkrime te objekteve te bazes. Veprimi i leximit
te nje objekti O nga transaksioni T simbolizohet si RT(O), ndersa ai i shkrimit simbolizohet si
WT(O).
Pervec shkrimit dhe leximit, cdo transaksion duhet te specifikoje veprimn e tij perfundimtar
qe mund te jete ose konfirmim (commit) ose anullim (abort). AT simbolizon anullimin e
transaksionit T ndersa CT konfirmimin e tij.
4
Plan eshte nje liste veprimesh (lexim, shkrim, konfirmim apo anullim) nga nje bashkesi
transaksionesh dhe rradha me te cilen dy veprime te transaksionit T shfaqen ne nje plan duhet
te jete e njejte si ajo ne te cilen shfaqen ne transaksionin T. Per shembull, per dy
transaksione T1 me veprime RT1(A) WT1(A) R T1(C) W T1(C) dhe T2 me veprime RT2(B) WT2(B),
Figura 1 tregon dy plane te mundshme.
T1 T2 T1 T2
R(A) R(A)
W(A) W(A)
R(B) R(C)
W(B) W(C)
R(C) R(B)
W(C) W(B)
a) b)
Figura 1. Dy plane te mundshme.
Planet e treguara ne figure nuk permbajne veprime anullimi apo konfirmimi. Nje plan i cili
permban nje veprim konfirmimi apo anullimi per cdo transaksion quhet plan i plote. Nje
plan i plote duhet te permbaje gjithe veprimet e gjithe transaksioneve qe shfaqen ne te. Nese
veprimet e transaksioneve te ndryshme nuk nderthuren plani quhet plan serial (p.sh. plani i
treguar ne Figuren 1.b eshte serial).
I.3 Egzekutimi i Njekohshem
Pasi u njohem me konceptin e planit mundemi te pershkruajme egzekutimin e nderthurur te
transaksioneve. SMBD nderthur veprimet e transaksioneve te ndryshme per permiresimin e
performances per sa i perket numrit te transaksioneve qe perfundojne ne njesine e kohes
(throughput) dhe kohes se egzekutimit te transaksioneve (response time). P.sh. duke
nderthurur veprimet e dy transaksioneve ku i pari pret te lexoje nga disku (proces i ngadalte)
5
dhe i dyti proceson te dhena ne memorje (proces i shpejte) dy transaksione egzekutohen
njekohesisht duke permiresuar keshtu throughput. Gjithashtu nderthurja e nje transaksioni te
shkurter me nje te gjate (ne kohe) i mundeson transaksionit te shkurter te perfundoje shpejt.
Ne nje egzekutim serial nje transaksion i shkurter do te ngecej pas nje te gjati duke sjelle
vonesa te medha.
I.3.1 Serializueshmeria
Sic u diskutua me larte konsistenca e transaksioneve eshte pergjegjesi e perdoruesit dhe jo e
SMBD. Ne vazhdim supozojme se cdo transaksion individualisht ruan konsistencen e bazes
se te dhenave. Rrjedhimisht, cdo plan i plote serial ruan konsistencen e bazes se te dhenave.
Nje plan i serializueshem per nje bashkesi bashkesi S transaksionesh eshte ai efekti i te cilit
ne nje baze konsistente eshte i njejte me ate te nje plani te plote serial mbi S-ne. Kjo do te
thote se baza e te dhenave qe rezulton nga egzekutimi in je plani te dhene eshte identike me
ate qe do te rezultonte nga nje egzekutim serial i transaksioneve. Kujdes:
Egzekutimi serial i transaksioneve me rradhe te ndryshme mund te prodhoje rezultate
te ndryshme, port e gjitha jane te pranueshme. SMBD nuk jep garanci se cili nga
rezultatet e mundshme do te jete rezultati i nje egzekutimi te nderthurur.
Perkufizimi i mesiperm i planeve te serializueshme nuk mbulon planet te cilat
permbajne transaksione qe anullohen. Per thjeshtesi, fillimisht do te diskutojme plane
qe perbehen nga plane te plota te konfirmuara.
I.3.2 Probleme nga Egzekutimi i Nderthurur
Ne vazhdim to te tregojme tre menyra kryesore se si nje plan qe perbehet nga transaksione
konsistenete te kompletuara qe egzekutohen ne nje baze konsistente mund te rezultoje ne nje
baze jo konsistente. Dy veprime mbi te njejtin objekt shkaktojne konflikt nese te pakten njeri
nga veprimet eshte shkrim. Tre situatat problematike mund te pershkruhen ne lidhje me kur
veprimet e dy transaksioneve T1 dhe T2 shkaktojne konflikt: ne nje konflikt shkrim-lexim
(WR) transaktioni T2 lexon nje object te shkruar me pare nga T1; konfliktet lexim-shkrim
(RW) dhe shkrim-shkrim (WW) perkufizohen ne menyre te ngjashme.
6
I.3.2.1 Leximi i te dhenave te pa konfirmuara (konflikte WR)
Burimi i pare i problemeve eshte kur transaksioni T2 lexon nje object te modifikuar nga nje
transaksion T1 i cili nuk eshte konfirmuar ende. Ky lexim quhet dirty read. Nje shembull i
thjeshte ilustron problemin: Kosideroni dy transaksione T1 dhe T2 ku transaksioni T1
transferon 100 leke nga llogaria A ne llogarine B, ndersa transaksioni T2 shton te dyja
llogarite me 6% (p.sh. interesi vjetor shtohet tek dy llogarite). Ne figuren dy tregohen dy
rezultatet e mundshme nga egzekutimi serial i dy transaksioneve te cilat jane a) A = 106 dhe
B = 212 ose b) A = 112 dhe B = 206.
T1 T2 T1 T2
R(A) 200 R(A) 200
W(A) 100 W(A) 212
R(B) 100 R(B) 100
W(B) 200 W(B) 106
R(A) 100 R(A) 112
W(A) 106 W(A) 112
R(B) 200 R(B) 106
W(B) 212 W(B) 206
a) b)
Figura 2. Dy egzekutime seriale.
Supozojme se plani i gjeneruar nga SMBD eshte ai i Figures 3. Sic e shikojme rezultati nga
egzekutimi i planit eshte A = 106 dhe B = 206 qe shte i ndryshem nga de dyja rezultatet e
egzekutimit serial. Problemi konsiston ne faktin se vlera e A-se qe shkruhet nga T1 lexohet
nga T2 perpara se T1 te perfundoje veprimet e tij.
T1 T2
7
R(A) 200
W(A) 100
R(A) 100
W(A) 106
R(B) 100
W(B) 106
R(B) 106
W(B) 206
Figura 3. Lexim i te dhenave te pa konfirmuara.
Problemi i pergjithshem i ilustruar me kete shembull eshte se transaksioni T1 mund te
shkruaje nje vlere ne objektin A e cila e ben bazen perkohesisht jo konsistente. Per sa kohe qe
T1 e mbishkruan kete vlere me vleren e sakte perpara se te perfundoje baza ngelet konsistente
nese T1 dhe T2 egzekutohen ne menyre serial, pasi T2 nuk do te shikoje mungesen e
perkohshme te konsistences. Nga ana tjeter, egzekutimi i nderthurur mund te shfaqe kete
mungese konsistence dhe te coje ne nje baze jo konsistente.
Vini re se megjithese egzekutimi i transaksioni duhet te rezultoje ne nje baze konsistente pasi
ka perfunduar, nuk eshte e domosdoshme qe baza te jete konsistente nderkohe qe transaksioni
eshte ne progres.
I.3.2.2 Lexim i pa perseritshem (konflikte RW)
8
Menyra e dyte me te cilen mund te udhehiqemi ne problem eshte kur transaksioni T2
ndryshon vleren e nje objekti A i cili eshte lexuar me pare nga nje transaksion T1, nderkohe
qe transaksioni T1 eshte akoma ne proces. Kjo situate mund te shkaktoje dy probleme.
Se pari, nese transaksioni T1 perpiqet te lexoje peseri vleren e A-se do te marre rezultat te
ndryshem nga leximi i pare megjithese transaksioni T1 nuk ka modifikuar A-ne. Kjo situate
nuk mund te ndodhe ne nje egzekutim serial dhe quhet lexim i pa perseritshem.
Se dyti, supozojme se T1 dhe T2 lexojne te njejten vlere per objektin A, p.sh. vleren 5, dhe ne
vazhdim transaksioni T1 e modifikon ate duke e shtuar me nje (i jep vleren 6), ndersa
transaksioni T2 i zbter nje (i jep vleren 4). Cilido egzekutim serial i ketyre dy transaksioneve
rezulton ne vleren 5 per objektin A, pra egzekutimi i nderthurur rezulton ne nje baze jo
konsistente. Problemi ketu qendron ne faktin se megjithese shkrimi nga T2 nuk lexohet
drejtperdrejt nga transaksioni T1, ky shkrim ben te pavlefshme vleren e lexuar nga
transaksioni T1 mbi te cilen bazohen veprimet e mtejshme te transaksioni T1.
I.3.2.3 Lexim i te dhenave te pa konfirmuara (konflikte WW)
Burimi itrete i problemeve eshte rasti kur nje transaksion T2 mbivendos vleren e nje objekti A
i cili eshte shkruar me pare nga nje transaksion T1 nderkohe qe T1 nuk ka perfunduar akoma.
Edhe nese transaksioni T2 nuk lexon vleren e A-se qe eshte shkruar nga transaksioni T1 und te
shkaktohen problem sic ilustron shembulli i meposhtem.
Supozojme se dy punonjes, Genci dhe Agimi, duhet te kene rroga te barabarta. Transaksioni
T1 ben rrogat e te dyve ne vleren 30000 leke dhe transaksioni T2 i ben ato 40000 leke.
Egzekutimi serial i dy transaksioneve mund te jape si rezultat rroge 30000 apo 40000 per te
dy punonjesit. Cilido nga dy rezultatet eshte i pranueshem (megjithese Genci dhe Agimi do
te preferonin rrogen 40000 leke!). Vini re se asnjeri nga transaksionet nuk lexon vleren e
rroges perpara se ta shkruaje ate, gje qe quhet shkrim i verber (blind write).
Le te konsiderojme nderthurjen e meposhtme te veprimeve te transaksioneve: transaksioni T1
ben rrogen e Gencit 30000 leke, transaksioni T2 ben rrogen e Agimit 40000 leke, transaksioni
T1 ben rrogen e Agimit 30000 leke, dhe se fundi transaksioni T2 ben rrogen e Gencit 40000
leke. Rezultati (Genci me rroge 40000 leke dhe Agimi me rroge 30000 leke) nuk eshte i
9
njejte me asnje nga rezultatet e mundshme te egzekutimeve seriale. Per me teper, ky rezultat
shkel dhe kriterin e konsistences sipas te cilit dy rrogat duhet te jene te barabarta.
I.3.3 Plane qe Permbajne Transaksione te Anulluara
Tani zgjerojme perkufizimin e serializueshmerise duke perfshire dhe transaksione te
anulluara. Intuitivisht, te gjitha veprimet e transaksioneve te anulluara duhet te c’behen dhe si
rrjedhoje mund te imagjinojme se ato nuk jane egzekutuar kurre. Duke u bazuar ne kete
perkufizimi i serialisueshmerise zgjerohet si me poshte: Plan i serializueshem per nje
bashkesi S transaksionesh eshte ai efekti i te cilit ne nje baze konsistente eshte i njejte me ate
te nje plani te plote serial mbi bashkesine SC Í S, ku SC permban transaksionet e kompletuara
ne S.
Ky perkufizim i serializueshmerise presupozon se veprimet e transaksioneve te anulluara
mund te c’behen totalisht, gje qe nuk eshte gjithmone e mundur. Per shembull, supozojme se
(1) nje transaksion T1 terheq 100 leke nga llogaria A dhe ne vazhdim (2) nje transaksion T2
lexon vlerat e dy llogarive A dhe B dhe shton 6% ne vlerat e te dyjave dhe konfirmohet, dhe
se fundi (3) transaksioni T1 anullohet (shikoni Figuren 4). Ne kete menyre transaksioni T2 ka
lexuar nje vlere te A-se qe nuk duhej te egzistonte. Nese T2 nuk do te ishte konfirmuar ne
momentin e anullimit te T1 atehere do te mundeshim te anullonim edhe T2 gjate anullimit te
T1 (e keshtu me rradhe gjithe transaksionet e tjere qe mund te kene lexuar A-ne). Por
transaksioni T2 eshte konfirmuar dhe ne baze te karakteristikes durability nuk mund te
anullohet. Ne kete rast themi se plani eshte i parikuperueshem. Nje plan i rikuperueshem
eshte ai ne te cilin cdo transaksion Ti konfirmohet vetem pasi konfirmohen gjithe
transaksionet Tn te cilat kane modifikuar te dhena qe lexon Ti. Ne plane te rikuperueshme
anullimi i nje transaksioni T mund te sjelle anullimin e disa te tjereve qe kane lexuar te dhena
te modifikuara nga T-ja e keshtu me rradhe (cascading aborts). Nese transaksionet e nje plani
lexojne vetem objekte te shkruara nga transaksione te konfirmuara atehere themi se plani
shmang anullimet e njepasnjeshme (avoids cascading aborts).
T1 T2
R(A) 200
10
W(A) 100
R(A) 100
W(A) 106
R(B) 100
W(B) 106
CT2
AT1
Figura 4. Plan i parikuperueshem.
Egziston edhe nje problem tjeter qe mund te vije nga c’berja e veprimeve te transaksioneve te
anulluara. Supozojme se nje transaksion T2 mbishkruan vleren e nje objekti A qe eshte
modifikuar me pare nga nje transaksion T1 nderkohe qe T1 eshte akoma ne proces, dhe ne
vazhdim transaksioni T1 anullohet. Te gjitha modifikimet e kryera nga T1 ne baze c’behen
duke kthyer vleren e cdo objekti te modifikuar nga transaksioni ne vleren qe kishte perpara
modifikimit. Kjo do te thote qe edhe modifikimi i A-se nga transaksioni T2 do te humbase,
edhe sikur transaksioni T2 te vendose te konfirmohet. Per shembull, suposojme se fillimisht
A-ja kishte vleren 5, transaksioni T1 e modifikon ne 6 dhe ai T2 ne 7. Ne vazhdim
transaksioni T1 anullohet dhe vlera e A-se behet perseri 5, qe do te thote se edhe nese
transaksioni T2 konfirmohet modifikimi i tij mbi objektin A humbet. Ky problem mund te
shmanget nepermjet nje teknike te kontrollit te egzekutimit te njekohshem te quajtur Strict
2PL te cilin do ta shikojme ne vazhdim.
I.4 Kontrolli i Egzekutimit te Njekohshem Bazuar ne Kycje
Nje SMBD duhet te garantoje se vetem plane te serializueshme dhe te rikuperueshme do te
lejohen te egzekutohen , dhe se ansje veprim i transaksioneve te konfirmuara nuk do te
humbase gjate anullimit te transaksioneve. Zakonisht SMBD-te perdorin nje protokoll kycjeje
per ta arritur kete. Nje prorokoll kycjeje eshte nje numer rregullash qe duhen ndjekur nga
11
cdo transaksion ne menyre qe te garantohet se megjithe nderthurjen e veprimeve te
transaksioneve efekti ne baze eshte i njejte me nje egzekutim serial te tyre.
I.4.1 Strict Two-Phase Locking (Strict 2PL)
Protokolli me i perdorur i kycjes eshte i quajturi Strict Two-Phase Locking ose Strict 2PL,
dhe ka dy rregulla:
1. Nese nje transaksion T deshiron te lexoje (respektivisht te modifikoje) nje objekt
duhet fillimisht te kerkoje nje celes te perbashket (respektivisht ekskluziv) mbi te.
Natyrisht, nje transaksion qe ka marre celes ekskluziv mbi nje objekt mundet edhe ta lexoje
ate, pra nuk nevojitet nje celes tjeter i perbashket. Kur nje transaksion kerkon nje celes
bllokohet deri sa SMBD te mundet t’ia jape ate. SMBD garanton se nese nje transaksion T ka
nje celes ekskluziv per nje objekt asnje transaksion tjeter nuk do te marre celes tjeter (te
perbashket apo ekskluziv) per objektin deri sa T-ja ta leshoje celesin e marre.
2. Te gjitha celesat e marra nga nje transaksion leshohen kur ai perfundon.
Praktikisht protokolli i kycjes lejon vetem nterdhurje te “sigurta” te veprimeve te
transaksioneve. Nese dy transaksione aksesojne pjese te pavarura te bases se te dhenave, ato
munden te marrin celesa njekohesish dhe te vazhdojne egzekutimin pa pengesa. Nga ana
tjeter, nese dy transaksione aksesojne te njejtin objekt dhe njeri nga te dy deshiron ta
modifikoje ate, veprimet e transaksioneve rradhiten ne menyre seriale; te gjitha veprimet e
njerit transaksion (atij qe morri i pari celesin) do te perfundojne perpara se transaksioni tjeter
te mundet te vazhdoje.
Kerkimi i nje celesi te perbashker (respektivisht ekskluziv) mbi nje objekt O nga nje
transaksion T simbolizohet si ST(O) (respektivisht XT(O)). Per shembull konsideroni planin ne
Figuren 3. Kjo nderthurje do te rezultonte ne nje gjendje qe nuk mund te rezultoje nga asnje
egzekutim serial i transaksioneve. Per shembull, transaksioni T1 mund te ndryshoje A-ne nga
200 ne 100, ne vazhdim transaksioni T2 lexon vleren 100 per A-ne dhe ndryshon B-ne nga
100 ne 106 dhe me pas transaksioni T1 do te lexoje vleren 106 per B-ne. Nese do te
egzekutoheshin ne menyre serial T1 ose T2 do te egzekutohej i pari dhe do te lexonte vlerat
12
200 dhe 100 per A-ne dhe B-ne, pra skenari i nderthurjes se mesiperme nuk eshte ekuivalent
me asnje nga skenarest e egzekutimit serial.
T1 T2
R(A) 200
W(A) 100
X(A)
R(B) 100
W(B) 200
CT1
R(A) 100
W(A) 106
R(B) 200
W(B) 212
CT2
Figura 5. Plan serial nga Strict 2PL.
Nese do te perdorej protokolli Strict 2PL, nderthurja e mesiperme nuk lejohet. Le te
shikojme pse me ndihmen e Figures 5. Transaksioni T1 fillimisht do te marre nje celes
ekskluziv mbi objektin A dhe do te lexoje dhe shkruaje A-ne. Ne vazhdim transaksioni T2 do
te kerkoje nje celes mbi A-ne dhe do te bllokohet deri sa transaksioni T1 te leshoje celesin e
tij ekskluziv. Ne hapin tjeter transaksioni T1 do te marre celes ekskluziv mbi objektin B te
cilin shkruan dhe lexon, de perfundimisht transaksioni konfirmohet duke leshuar keshtu edhe
cekesat qe kishte marre. Se fundi, transaksioni T2 c’bllokohet, merr celesat e nevojshem dhe
konfirmohet dhe ai.
13
T1 T2
S(A)
R(A)
S(A)
R(A)
X(B)
R(B)
W(B)
CT2
X(C)
R(C)
W(C)
CT1
Figura 6. Plan i nderthurur nga Strict 2PL.
Ne shembullin e mesiperm protokolli i kycjes rezulton ne nje plan serial, por ne pergjithesi
edhe nepermjet protokollit Strict 2PL lejohet nderthurja e veprimeve sic duket edhe ne
Figuren 6.
I.5 Hyrje ne Rimekembien nga Deshtimet
Menaxheri i rimekembjes ne nje SMBD eshte pergjegjes per garantimit e atomicity dhe
durability. Ai garanton atomicity duke c’bere veprimet e transaksioneve te anulluara dhe
durability duke siguruar qe gjithe veprimet e transaksioneve te konfirmuara t’u mbijetojne
deshtimeve te sistemit apo deshtimeve te disqeve.
14
Kur nje SMBD rikthehet pas deshtimit, menaxheri i rimekembjes merr kontrollin dhe duhet
te sjelle bazen ne nje gjendje konsistente. Menaxheri i rimekembjes eshte gjithashtu
pergjegjes per c’berjen e veprimeve te transaksioneve te anulluara. Per te kuptuar se cfare
nevojitet per implementimin e menaxherit te rimekembjes eshte e nevojdhme te kuptojme se
cfare ndodh gjate funksionimit normal te sistemit.
Menaxheri i transkasoineve ne nje SMBD kontrollon egzekutimin e transaksioneve. Gjate
funksionimit normal te sistemit perpara leximit apo shkrimit te objekteve duhen te merren
celesa sipas protokollit te kycjes.
I.5.1 Menaxhimi i Objekteve ne Memorje
Per sa i perket shkrimi te objekteve ngrihen dy pyetje:
1. Eshte e mundur qe modifikimet e kryera nga nje transaksion T mbi nje object O ne
memorje te shkruhen ne disk perpara se T-ja te konfirmohet? Shkrime te tilla ndodhin
kur nje transaksin tjeter kerkon te bjere nje faqe ne memorje dhe menaxheri i
memorjes vendos te zevendesoje faqen qe permban O-ne. Nese keto shkrime lejohen
themi se perdoret metoda steal ne te kundert themi se perdoret metoda no-steal.
2. Kur nje transaksion konfirmohet jemi te detyruar te shkruajme menjehere ne disk
gjithe objektet qe ka modifikuar ky transaksion? Nese po, themi se perdoret metoda
force ne te kundert themi se perdoret metoda no-force
Nga kendveshtrimi i implemenimi te nje menaxheri rimekembjeje, eshte me e thjeshte te
perdoret nje menaxher memorjeje qe perdor metoden no-steal, force. Nese perdoret no-steal
atehere nuk eshte e nevojshme te c’behen veprimet e transaksioneve te anulluara (pasi ato
nuk jane shkruar ne disk), dhe nese perdoret force, nuk eshte e nevojshme te ribehen
ndryshimet e transaksioneve te konfirmuara pas nje deshtimi (pasi force garanton se gjithe
ndryshimet shkruhen ne disk perpara konfirmimit).
Megjithate, metoda no-steal, force ka disavantazhe te rendesishme. Metoda no-steal supozon
se memorja nxe gjithe faqet e modifikuara nga transaksione ne proces, supozim qe nuk eshte
realist. Metoda force sjell kosto te larta per aksesimin e disqeve, p.sh. nese nje faqe qe
perdore shpesh modifikohet nga 20 transaksione njeri pas tjetrit, do te shkruhet 20 here ne
15
disk. Me metoden no-force nga ana tjeter, kjo faqe do te mdifikohej ne memorje 20 here dhe
do te shkruhej ne disk vetem nje here. Per keto arsye, shumica e sitemeve perdorin medoden
steal, no-force. Pra, nese ne faqe e modifikuar zgjithet per zevendesim nga menaxheri i
memorjes ajo shkruhet ne disk akoma edhe nese transaksioni qe e ka modifikuar nuk eshte
konfirmuar akoma, dhe faqet e modifikuara nga transaksione te konfirmuara nuk shkruhen
detyrimisht ne disk ne momentin e konfirmimt te transaksioneve.
I.5.2 Hapa qe Ndiqen Gjate Funksionimit Normal te Sistemit
Menaxheri i rimekembjes ne nje SMBD mban disa informacione gjate funksionimit normal
te sistemit ne menyre qe te mundesoje rimekembjen nga deshtimet. Specifikisht, krijohet nje
ditar (log) i modifikimeve te bera ne bazen e te dhenave i cili ruhet ne nje vend te sigurt dhe
garantohet se u mbijeton deshtimeve. Eshte shume e rendesishme te sigurohet se regjistrimet
ne ditar do te shkruhen ne vend te sigurt perpara se te kryhet modifikimi; ne rast te kunndert,
sistemi mund te deshtoje menjehere pas modifikimit, duke beret e pamundur regjistrimin e
ndryshimit.
Ditari i mundeson menaxherit te rimekembjes te c’beje veprimet e transaksioneve te anullura
apo te pjeshme, dhe te ribeje veprimet e trnsaksioneve te konfirmuara. Per shembull, nje
transaksion qe u konfirmua perpara deshtimit mund te kete modifikuar nje objekt ne memorje
dhe, si pasoje e perdorjes se metodes no-force, ky modifikim mund te mos jete shkruar ne
disk. Modifikime te tilla do te identifikohen nepermjet ditarit dhe do te shkruhen ne disk
gjate rimekembjes. Nga ana tjeter, modifikimet e kryera nga transaksione qe nuk u
konfirmuan perpara deshtimit mund te jene shkruar ne disk si pasoje e perdorjes se metodes
steal. Edhe keto modifikime identifikohen nepermjet ditarit dhe c’behen gjate rimekembjes.
II. KONTROLLI I EGZEKUTIMIT TE NJEKOHSHEM
Ne kete kapitull do te shikojme ne menyre me te detajuar kontrollin e egzekutimit te
njekohshem. Fillimisht do te shikojme protokolle kycjeje, si ata garantojne karakteristika te
rendesishme te planeve dhe si ata implementohen ne nje SMBD.
16
II.1 Kontrolli i Egzekutimit te Njekohshem Bazuar ne Kycje
Ketu do te shikojme se si protokollet bazuar ne kycjegarantojne disa karakterisika te
rendesishme te planeve si plane te serializueshem dhe plane te rikuperueshem.
II.1.1 2 PL, Plane te Serializueshem dhe Plane te Rikuperueshem
Dy plane quhen ekuivalente ne baze konfliktesh nese permbajne veprimet e te njejtave
transaksione dhe cdo cift veprimesh qe kane konflikt kane te njejten renditje ne secilin plan.
Sic pame ne seksionin I.3.3., dy veprime te dy transaksioneve shkaktojne konflikt nese
kryhen mbi te njejtin objekt dhe te pakten njeri nga te dy eshte shkrim. Rezultati i nje plani
varet vetem nga renditja e veprimeve qe shkaktojne konflikt; mundemi te shkembejme
cilindo cift veprimesh qe nuk shkaktojne konflikt pa ndryshuar rezultatin e planit ne bazen e
te dhenave. Nese dy plane jane ekuivalente ne baze konfliktesh atehere ato kane te njejtin
rezultat mbi bazen e te dhenave.
Nje plan quhet i serializueshem ne baze konfliktesh nese eshte ekuivalent me baze
konfliktesh me nje plan serial. Cdo plan i serializueshem ne baze konfliktesh eshte i
serializueshem, por jo cdo plan i serializueshem eshte i serializueshem ne baze konfliktesh
sic mund te shihet ne Figuren 7. Ky plan eshte ekuivalent me egzekutimin e transaksioneve
ne menyre seriale sipas rradhes T1, T2, T3, por nuk eshte ekuivalent ne baze konfliktesh me
kete plan serial pasi shkrimet e T1 dhe T2 renditen ndryshe.
T1 T2 T3
R(A)
W(A)
CT2
W(A)
CT1
17
W(A)
CT3
Figura 7. Plan i serializueshem por jo i serializueshem ne baze konfliktesh.
Per percaktimin e konflikteve ne nje plan shpesh perdoret grafi i serializueshmerise ose
ndryshe grafi i serializueshmerise. Ky graf permban:
Nje nyje per cdo transaksion
Nje brinje nga transaksioni Ti ne transaksionin Tj nese nje veprim i Ti i paraprin dhe
ka konflikt me nje vepim te Tj .
Grafi i serializueshmerise per planet e Figurave 5, 6, 7 tregohet ne Figuren 8 (a), b) dhe c)
respektivisht).
Protokolli Strict 2PL lejon vetem plane te serializueshme sic duket edhe nga dy rezultatet e
meposhtme:
1. Nje plan P eshte i serializueshem ne baze konfliktesh atehere dhe vetem atehere kur
grafi i serializueshmerise per te nuk ka qark te mbyllur.
2. Protokolli Strict 2PL garanton se grafi i serializueshmerise nuk ka qark te mbyllur per
cilindo plan ai lejon.
Figura 8. Shembuj Grafesh Serializueshmerie.
18
T1 T2 T1 T2
T1 T2
T3
a) b)
c)
Nje variant i Strict 2PL, i quajtur Two-Phase Locking (2PL) modifikon rregullin e dyte te
protokollit Strict 2PL duke lejuar transaksionet te leshojne celesat qe kane marre perpara se
te perfundojne, pra perpara se te konfirmohen apo te anullohen. Konkretisht, per 2PL rregulli
i dyte behet si me poshte:
2. Nje transaksion nuk mundet te kerkoje celesa te tjere pasi ka leshuar cilindo celes qe
ka marre.
Pra me 2PL cdo transaksion ka dy faza, nje faze zgjerimi ne te cilen merr celesa dhe nje faze
tkurrjeje ne te cilen i leshon ata. Mund te tregohet se edhe 2PL garanton se grafi i
serializueshmerise nuk ka qark te mbyllur. Intuitivisht, nje rradhe ekuivalente me nje
egzekutim serial jepet nga rradha me te cilen transaksionet hyjne ne fazen e tkurrjes: Nese
transaksioni T2 lexon apo shkruan nje objekt O te shkruar nga T1, T1 duhet te kete leshuar
celesin e tij mbi O-ne perprara se T2 te kryeje leximin, pra transaksioni T1 i paraprin atij T2.
Nje plan quhet strikt nese nje vlere e shkruar nga nje transaksion T nuk lexohet apo shkruhet
nga transaksione te tjera deri sa T-ja ose te konfirmohet ose te anullohet. Planet strikte jane te
rikuperueshme, nuk shkaktojne anullime te njepasnjeshme dhe veprimet e transaksioneve te
anulluara mund te c’behen duke kthyer vlerat e meparshme te objekteve te modifikuara.
Protokolli Strict 2PL permireson ate 2PL duke garantuar se cdo plan i lejuar eshte strikt
pervec se i serializueshem ne baze konfliktesh. Arsyeja qendron tek fakti se kur nje
transaksion T shkruan nje objekt duke ndjekur protokollin Strict 2PL, T-ja mban celesin
ekskluziv deri ne perfundimin apo anullimin e tij. Pra, asnje transaksion tjeter nuk mund te
lexoje apo modifikoje kete objekt deri sa transaksioni T te perfundoje.
II.2 Menaxhimi i Kycjeve
Pjesa e SMBD qe celesta e dhene per transaksionet quhet menaxheri i kycjeve. Ai mban nje
tabele celesash, e cila eshte nje tabele hash me celes objektet e bazes, si dhe nje tabele
transaksionesh e cila, midis te tjerash, permban per secilin transaksion nje liste celesash te
cilat ai ka marre.
19
Tabela e celesave permban nje rresht per cdo objekt te bazes me informacionin e meposhtem:
numrin e transaksioneve qe kane celes mbi kete objekt (qe mund te jete me i madh se nje ne
rasin e celesave te perbashket), llojin e celesit dhe nje liste kerkesash per celesa mbi objektin.
II.2.1 Dhenia e Celsave
Sipas protokollit Strict 2PL, perpara se nje transaksion te lexoje apo shkruaje nje objekt O te
bazes, duhet te marre nje celes te perbashket apo ekskluziv mbi O-ne dh eta mbaje ate deri sa
te konfirmohet apo anullohet. Kur nje transaksioni i nevojitet nje celes mbi nje objekt, ai ben
nje kerkese tek menaxheri i kycjeve i cili vepron si me poshte:
1. Nese kerkohet nje celes i perbashket, lista e kerkesave eshte bosh dhe objekti nuk
eshte i kycur me celes ekskluziv, menaxheri i kycjeve jep celesin dhe perditeson
rreshtin perkates ne tabelen e celesave per objektin (shton me nje numrin e celesave
mbi objektin dhe shenon se objekti eshte i kycur me celes te perbashket).
2. Nese kerkohet celes ekskluziv dhe asnje transaksion tjeter nuk ka celes mbi objektin,
menaxheri i kycjeve jep celesin dhe perditeson tabelen e celsave.
3. Ne cdo rast tjeter perkesa nuk mund te plotesohet dhe ajo shtohet ne listen e
kerkesave per objektin, dhe transaksioni qe kerkoi celesin bllokohet.
Kur nje transaksion konfirmohet apo anullohet ai leshon gjithe celesat. Kur nje celes
leshohet, menaxheri i kycjeve perditeson rreshtin perkates ne tabelen e celesave dhe shqyrton
koken e listes se kerkesave per kete objekt. Nese kerkesa e pare ne liste mund te plotesohet,
transaksioniqe beri kerkesen c’bllokohet dhe merr celesin. Nese ka disa kerkesa ne krye te
listes per celes te perbashket, te gjitha ato mund te plotesohen se bashku.
Vini re se nese nje transaksion T1 ka nje celes te perbashket mbi nje objekt O dhe nje
transaksion T2 kerkon nje celes te ekskluziv, kerkesa e transaksionit T2 shtohet ne listen e
kerkesave. Nese tani nje transaksion T3 kerkon nje celes te perbashket, kerkesa e tij shtohet
ne liste pas asaj te transaksionit T2, megjithese celesi i kerkuar eshte kompatibel me celesin
qe ka transaksioni T1. Ky rregull ben te mundur qe transaksioni T2 nuk bllokohet
pergjithmone ne rradhe (starvation) duke u “kapercyer” gjithmone nga kerkesa per celesa te
perbashket.
20
Sic u permend me larte nje nga informacionet qe permban tabela e trransaksioneve eshte lista
e celesave qe ka nje transaksion. Kjo liste konrollohet perpra se te kerkohet nje celes per nje
transaksion ne menyre qe transaksonet te mos kerkojne te njejtin celes dy here. Megjithate,
disa here nje transaksioni mund t’i nevojitet te marre nje celes ekskluziv per mbi nje objekt
mbi te cilin ka marre tashme nje celes te perbashket. Ne raste te tilla celesi ekskluziv jepet
menjehere nese asnje transaksion tjeter nuk ka celes mbi objektin ose kerkesa vendoset ne
filim te listes se kerkesave ne rast te kundert. Transaksioni qe ka celes te perbashket mbi
objektin favorizohet pasi nese do te vendosej ne rradhe pas nje kerkese te nje transaksioni
tjeter te dyja transaksionet do te pristnin njeri tjetrin duke u bllokuar pergjithmobe.
II.2.2 Bllokime (Deadlocks)
Konsideroni shembullin e meposhtem: nje transaksion T1 merr nje celes ekskluziv mbi nje
objekt A, nje transaksion T2 merr nje celes ekskluziv mbi nje objekt B, ne vazhdim
transaksioni T1 kerkon nje celes ekskluziv mbi B-ne dhe si rrjedhoje bllokohet, dhe se fundi
transaksioni T2 kerkon celes mbi A-ne dhe bllokohet dhe ai. Pra, transaksioni T1 pret qe
transaksioni T2 te leshoje celesin mbi B-ne dhe transaksioni T2 pret qe transaksioni T1 te
leshoje celesin mbi A-ne. Ky cikel trensaksionesh qe presin njeri tjetrin quhet bllokim
(deadlock). Ne kete menyre asnje nga dy transaksionet nuk mundet te egzekutohet me tej
dhe, per me teper te dyja transaksionet mbajne celese qe mund t’iu duhen transaksioneve te
tjere. SMBD duhet te parandaloje ose te identifikoje situata te tilla bllokimi.
II.2.2.1 Parandalimi i bllokimeve
Bllokimet mund te parandalohen duke i dhene secilit transaksion perparesi te ndryshme dhe
duke garantuar se transaksione me perparesi me te ulet nuk lejohet te presin per transaksione
me perparesi me te larte (ose anasjelltas). Nje menyre per tu dhene perparesi transaksioneve
eshte tu jepet atyre perparesi ne baze te moshes (kohes se fillimit te tyre). Transaksionet me
te vjetra marrin perparesi me te larte.
Nese nje transaksion Ti kerkon nje celes dhe nje transaksion Tj ka nje celes qe mund te
shkaktoje bllokim perdoret nje nga politikat e meposhtme:
21
Wait-die: nese Ti ka prioritet me te larte se Tj atehere Ti mund te prese; ndryshe
anullohet.
Wound-wait: nese Ti ka prioritet me te larte, Tj anullohet; ndryshe Ti pret.
Me metoden wait-die, transaksionet me prioritet me te ulet nuk presin kurre per transaksione
me prioritet me te larte. Me metoden wound-wait, transaksione me prioritet me te larte nuk
presin kurre per transaksione me prioritet me te ulet. Me cilendo nda dy metodat nuk mund te
ndodhe bllokim.
Duhet te meren masa qe transaksionet me prioritet te ulet te mos anullohen vazhdimisht. Kur
nje transaksion anullohet dhe rifillohet duhet te marre te njejtin prioritet qe kishte dhe me
pare. Ne kete menyre cdo transaksion do te arrije te behet me i vjetri (me prioritet me te
larte) dhe do te perfundoje.
Me metoden wait-die vetem transaksione qe kerkojne nje celes mund te anullohen. Nje
transaksion i ri qe ndeshet me transaksione te vjetra mund te anullohet vazhdimisht, por nga
ana tjeter, nje transaksion qe ka marre gjithe celesat qe i nevjiten nok do te anullohet kurre
per shkak te bllokimeve.
II.2.2.2 Identifikimi i bllokimeve
Bllokimet zakonish jane te rralla dhe implikojne nje numer shume te vogel transaksionesh.
Kjo sugjeron se ne vend te marrjes se masave per parandalimin e bllokimeve, mund te jete
me mire te identifikohen dhe te zgjidhen ato. Per ientifikimin, SMBD duhet te kontrolloje
periodikisht per bllokime.
Kur nje transaksion Ti bllokohet per arsye se celesi qe kerkon nuk mund ti jepet, ai duhet te
prese deri sa gjithe transaksionet Tj qe kane celesa konflikues ti leshojne ato. Per
identifikimin e bllokimeve menaxheri i kycjeve nderton nje graf qe quhet grafi pret-per. Ne
kete graf nyjet jane transaksionet active dhe nje brinje nga nyja Ti ne ate Tj do te thote se
transaksioni Ti pret qe transaksioni Tj te leshoje nje celes. Menaxheri i kycjeve shton brinje
ne graf kur ai shton kerkesa per celesa ne listen e kerkesave dhe fshin brinje kur ai jep celesa.
22
Konsideroni planin ne Figuren 9. Hapi i fundit qe shfaqet poshte vijes krijon nje qark ne
grafin pret-per i cili tregohet ne Figuren 10.
T1 T2 T3 T4
S(A)
R(A)
X(B)
W(B)
S(B)
S(C)
R(C)
X(C)
X(B)
X(A)
Figura 9. Plan me bllokim
Vini re se grafi pret-per pershkruan gjithe transaksionet active, disa nga te cilat mundet ne
vazhdim te anullohen. Nese egziston nje brinje nga nyja Ti ne ate Tj ne grafin pret-per dhe de
dyja transakaionet perkatese konfirmohen, atehere do te egzistoje nje brinje nga Tj ne Ti ne
grafin e serializueshmerise per planin.
23
Figura 10. Grafi pret-per a) perpara dhe b) pas bllokimit
Grafi pret-per kontrollohet periodikisht per qarqe te cilat tregojne bllokim. Bllokimet
zgjidhen duke anulluar nje nga transaksionet pjesemarrese dhe duke leshuar celesta e tij.
Nje alternative e krijimit te grafit pret-per per identifikimin e bllokimeve eshte anullimi i
transaksioneve te cilat kane pritur shume per te marre nje celes. Pra supozohet se vonesa e
madhe eshte treguese e nje bllokimi.
II.2.2 Performanca e Kontrollit te Egzekutimit te Njekohshem Bazuar ne
Kycje
Dizenjimi i nje mekanizmi per kontrollin e egzekutimit te njekohshem perfshin berjen e disa
zgjedhjeve:
Duhet te perdoret parandalim apo identifikim bllokimesh?
Nes perdoret identifikim, sa shpesh duhet kontrolluar per bllokime?
Nese perdoret identifikim dhe identifikohet nje bllokim cili transaksion duhet
anulluar?
Metodad e bazuara ne kycje jane dizenjuar te zgjidhin konflikte midis transaksioneve duke
perdorur nje nga dy mekanizmat: bllokim dhe anullim transaksionesh. Te dyja mekanizmat
ndikojne negativisht mbi performancen; transaksionet e bllokuara mund te kene celesa qe
detyrojne transakaione te tjera te presin, dhe anullimi dhe rifillimi i transaksioneve sjell
humbje te punes se bere nga to deri ne momentin e anullimit.
24
T1 T2
a)
T4 T3
T1 T2
b)
T4 T3
II.2.2.1 Identifikim apo Parandalim?
Me parandalmin e bllokimeve, anullimet perdoren per shmangien e bllokimeve. Nga ana
tjeter, me identifikimin e bllokimeve, transaksionet e perfshira ne bllokim mbajne celesa
duke penguar keshtu transaksione te tjera te avancojne. Throughput i sistemit zvogelohet pasi
shume transaksione mund te bllokohen duke pritur per celesa qe mbahen nga transaksione te
bllokuara. Per te permiresuar situaten mundet te ritet frekuenca me te cilen kontrollohet per
bllokime por kjo sjell rritje te kostos (ne kohe) te procesit te dedektimit.
Nje variant i protokollit 2PL qe quhet Conservative 2PL mundet gjithashtu te parandaloje
bllokimet. Sipas Conservative 2PL, cdo transaksion merr gjithe celesat qe do ti duhen qe ne
fillim nese mundet ose bllokohet deri sa ato te jene te disponueshme. Ky protokoll garanton
se nuk do te kete bllokime dhe, per me teper, se nje transaksion qe ka marre isa celesa nuk do
te prese per celesa te tjere.
II.2.2.2 Frekuenca e identifikimt te bllokimeve
Rezultate empirike tregojne se bllokimet jane relativisht te rralla dhe metodat e identifikimit
funksionojne mire ne praktike. Megjithate, nese konkurenca per celesa eshte e larte, pra
egziston nje probabilitet i larte per bllokime, metodat e bazuara ne parandalim do te kene nje
performance me te mire.
II.2.2.3 Zgjedhja e viktimes se bllokimit
Kur identifikohet nje bllokim zgjedhja e transaksionit qe do te anullohet mund te behet me
disa kritere: transaksioni qe ka marre numrin me te vogel te celesave, transaksioni qe ka
kryer me pak pune, transaksioni qe eshte me larg perfundimit, e keshtu me rradhe. Per me
teper nje transaksion mund te jete zgjedhur ne menyre te perseritur si viktima e bllokimit.
Transaksione te tilla duhet te favorizohen eventualisht gjate zgjedhjes se viktimes.
II.3 Kontrolli i Egzekutimit te Njekohshem pa Kycje
Kycja eshte metoda me e perdorur per kontrollin e egzekutimit te njekohshem ne nje SMBD,
por nuk eshte e vetmja. Ne vazhdim to te shikojme disa metoda alternative.
25
II.3.1 Kontrolli Optimist i Egzekutimit te Njekohshem
Protokollet qe perdorin kycje kane nje qasje pesimiste ndaj konflikteve midis transaksioneve
dhe perdorin ose anullime ose bllokime transaksionesh per zgjidhjen e tyre. Ne nje sistem me
pak konkurrence per objektet e bazes se te dhenave, kostoja per marrjen e celesave dhe
ndjekjen e protokollit te kycjes duhet paguar gjithsesi.
Me kontrollin optimist te egzekutimit te njekohshem, supozon se shumica e transaksioneve
nuk do konfliktohen me transaksione te tjera, dhe ideja eshte qe te lejohen transaksionet te
egzekutohen lirisht. Transaksionet egzekutohen ne tre faza:
1. Leximi: Transaksioni lexon te dhenat nga baza dhe i shkruan ne nje memorje private.
2. Validimi: Nese transaksioni vendos te konfirmohet, SMBD kontrollon, dhe nese
mund te kete konflikt me ndonje transaksion tjeter atehere transaksioni anullohet dhe
rifillohet.
3. Shkrimi: Nese validimi nuk gjen konflikte atehere ndryshimet e bera nga
transaksioni ne memorjen e tij private kopjohen ne bazen e te dhenave.
Nese vertet egzistojne pak konflikte dhe validimi mund te kryhet me efikasitet, kontrolli
optimist mund te sjelle performance me te mire se sa kycja. Nese egzistojne shume konflikte,
kostoja e rifillimit te shpeshte te transaksioneve do te ndikoje negativisht mbi performancen.
Ne fillim te validimit cdo transaksioni Ti i jepet nje etikete (timestamp) TS(Ti) (koha ne te
cilen fillon validimi per transaksionin Ti) dhe validimi kontrollon nese renditja e etiketave te
transaksioneve eshte ekuivalente me nje renditje seriale. Qe te validohet nje transaksion Tj
duhet qe per cdo transaksion te konfirmuar Ti ku TS(Ti) < TS(Tj):
1. Transaksioni Ti ka perfunduar te treja fazat perpara se transaksioni Tj te filloje; ose
2. transaksioni Ti ka perfunduar perpara se transaksioni Tj te filloje fazen e shkrimit, dhe
Ti nuk ka shkruar asnje objekt qe lexon Tj ; ose
3. transaksioni Ti ka perfunduar fazen e leximit perpara se transaksioni Tj te perfundoje
fazen e leximit, dhe Ti nuk ka shkruar te dhena qe ka lexuar apo shkruar Tj.
26
Secili nga kushtet e mesiperme garanton se modifikimet e kryera nga transakaioni Tj nuk jane
te dukshme per transaksioni Ti. Kushti i pare lejon transaksionin Tj te shikoje disa nga
modifikimet e transaksionit Ti, por dy transaksionet egzekutohen ne nje renditje seriale.
Kushti i dyte lejon transaksionin Tj te lexoje nderkohe qe transaksioni Ti eshte ne fazen e
shkrimit, por nuk ka konflikt pasi Tj nuk lexon objekte te modifikuara nga Ti. Megjithese
transaksioni Tj mund te mbishkruaje objekte te modifikuara nga transaksioni Ti, te gjitha
shkrimet e Ti u paraprijne atyre te Tj. Kushti i trete lejon transaksionet Ti dhe Tj te shkruajne
objekte ne te njejten kohe (me shume nderthurje), por objektet e shkruara nga secili
transaksion jane te ndryshme. Pra asnje nga konfliktet RW, WR apo WW nuk eshte i mundur
nese cilido nga tre kushtet plotesohet.
Per kryerjen e procesit te validimt nevojitet nje liste me objektet e lexuara apo shkruara nga
cdo transaksion. Gjithashtu, nderkohe qe nje transaksion po validohet, asnje transaksion tjeter
nuk lejohet te konfirmohet; ndryshe validimi mund te humbase konflikte qe lidhen me
transaksionin e kompletuar.
Eshte e qarte se kontrolli optimist i egzekutimit te njekohshem nuk eshte pa kosto;
perkundrazi, kostoja e kycjes zevendesohet me ate te mbajtjes se listave te leximeve dhe
shkrimeve te transaksioneve, kontrollin per konflikte dhe kopjimin e modifikimeve nga
memorja private. Ne menyre te ngjashme, kostoja e bllokimit zevendesohet nga ajo e punes
se humbur nga transaksionet qe rifillohen.
II.3.2 Kontrolli i Egzekutimit te Njekohshem Bazuar ne Etiketa
(Timestamps)
Sipas kesaj metode cdo transaksioni i jepet nje etikete (qe simbolizon kohen e fillimit) kur ai
fillon egzekutimin. Garantohet se nese veprimi vi i transaksionit Ti ka konflikt me veprimin vj
te transaksionit Tj, vi egzekutohet perpara vj nese TS(Ti) < TS(Tj). Nese nje transaksion shkel
kete renditje anullohet dhe rifillohet.
Per implementimin e kesaj metode, cdo objekti O te bazes i jepet nje etikete leximi RTS(O)
dhe nje etikete shkrimi WTS(O). Nese nje transaksion T deshiron te lexoje nje objekt O, dhe
TS(T) < WTS(O), rradha e ketij leximi ne lidhje me shktimin me te fundit mbi O-ne do te
shkelte renditjen e etiketave midis ketij transaksioni dhe transaksionit modifikues. Per kete
27
arsye, transaksioni T anullohet dhe rifillon me nje etikete te re me te madhe se ajo e
meparshme. Vini re se nese transaksioni T rifillon me te njejten etikete qe kishte perpara,
eshte e garantuar se do re anulohet perseri per shkak te te njejtit konflikt. Nese TS(T) >
WTS(O), transaksioni T lexon O-ne dhe RTS(O) mer vleren me te madhe midis RTS(O) dhe
TS(T).
Le te shikojme se cfare ndodh kur nje transaksion T deshiron te shkruaje nje objekt O:
1. Nese TS(T) < RTS(O), shkrimi shkakton konflikt me leximin me te fundit mbi O-ne
dhe si rrjedhoje transaksioni T anullohet dhe rifillon.
2. Nese TS(T) < WTS(O), nje qasje naive do te ishte te anulohej transaksioni T pasi
shkrimi i tij shkakton konflikt me leximin me te fundit te O-se. Rezulton se mundemi
te injorojme keto shkrime dhe te vazhdojme me tej, pra shkrimi i T-se injorohet
(Thomas Write Rule).
3. Ndryshe, transaksioni T shkruan O-ne dhe WTS(O) = TS(T).
II.3.2.1 Rreguli i Thomas Write (Thomas Write Rule)
Sic u permend me larte nese TS(T) < WTS(O), veprimi i shkrimit eshte cvleresuar nga
shkrimi me i fundit i objektit O qe pason shkrimin korrent sipas renditjen e transaksioneve ne
baze te etiketave. Mundemi te supozojme se shkrimi nga T-ja ka ndodhur menjehere perpara
shkrimit me te fundit te O-se dhe asnje transaksion tjeter nuk e ka lexuar ate.
Nese nuk perdoret rregulli i Thomas Write, pra transaksioni T anullohen ne piken 2. me larte,
protokolli i bazuar ne etiketa, ashtu si 2PL, lejon vetem plane te serializueshem ne baze
konfliktesh. Nese perdoret rregulli i Thomas Write, lejohen disa plane te serializueshme te
cilat nuk jane te serializueshme ne baze konfliktesh sic duket dhe ne shembullin ne Figuren
11. Meqenese shkrimi nga transaksioni T2 pason leximin nga T1 dhe i paraprin shkrimit nga
T1 te pot e njejtit objekt, ky pan nuk eshte i serializueshem ne baze konfliktesh. Rregulli i
Thomas Write bazohet ne fatin se shkrimi nga transaksioni T2 nuk shihet nga asnje
transaksion she si rrjedhoje eshte ekuivalent me planin e serializueshem qe perftohet duke
fshire shkrimin e T2-shit, plan qe tregohet ne figuren 12.
28
T1 T2
R(A)
W(A)
CT2
W(A)
CT1
Figura 11. Plan i serializueshem por jo i serializueshem ne baze konfliktesh.
II.3.2.2 Mundesia e rikuperimit
Fatkeqesisht, protokolli i bazuar ne etiketa qe u pershkrua me larte lejon plane te cilat nuk
jane te rikuperueshme, sic ilistrohet ne Figuren 13. Nese TS(T1) = 1 dhe TS(T2) = 2, ky plan
lejohet nga protokolli i bazuar ne etiketa (me apo pa rregullin e Thomas Write). Ky protokoll
mund te modifikohet ne menyre qe te mos lejoje plane te tilla duke ruajtur perkohesisht te
gjitha veprimet e shkrimit ne nje memorje private deri sa transaksioni tekonfirmohet. Ne
shembullin tone, kur transaksioni T1 deshiron te dhkruaje objektin A, WTS(A) perditesohet
analogjikisht por modifikimi i a-se nuk kryhet menjehere por ruhet ne nje memorje private.
Kur transaksioni T2 deshiron te lexoje A-ne, etiketa e tij krahasohet me WTS(A) dhe
mundesohet leximi. Megjithate, transaksioni T2 bllokohet deri sa ai T1 te perfundoje. Nese
transaksioni T1 konfirmohet, mofikikimet e tij mbi objektin A shkruhen ne baze; ndryshe, ato
injorohen. Se fundi, transaksioni T2 lejohet te lexoje A-ne.
T1 T2
R(A)
CT2
W(A)
29
CT1
Figura 12. Plan i serializueshem ne baze konfliktesh.
Bllokimi i transaksionit T2 eshte i ngjashem me marrjen e nje celesi ekskluziv nga
transaksioni T1 mbi objektin A. Megjithate, edhe mekete modifikim protokolli i bazuar ne
etiketa lejon disa plane qe nuk lejohen nga protokolli 2PL.
T1 T2
W(A)
R(A)
W(B)
CT2
Figura 13. Plan i parikuperueshem.
Meqenese mundesia e rikuperimit eshte esenciale, modifikimi i pershkruar me larte duhet te
perdoret ne menyre qe protokolli i bazuar ne etiketa te mund te perdoret ne praktike. Keshtu
qe, duke marre parasysh dhe koston e larte per menaxhimin e etiketave te leximit the
shkrimit, ky protokoll eshte inferior ndaj atyre te basuar ne kycje per sa u perket sistemeve te
centralizuara. Protokolli i bazuar ne etiketa eshte studiuar kryesisht per sisteme te shperndara
te cilat do ti shikojme ne kapituj te mepasshem.
II.3.3 Kontrolli i Egzekutimit te Njekohshem Bazuar ne Versione te
Shumefishta
Ky protokoll demonstron nje menyre tjeter te perdorimit te etiketave kohore qe jepen ne
fillim te egzekutimit per arritjen e serializueshmerise. Qellimi eshte te garantohet se
transaksionet nuk do te presin kurre per te lexuar nje objekt te bazes se te dhenave, dhe ideja
eshte te mbahen disa versione (kopje) te secilit objekt se bashku me nje etikete per kohen e
shkrimit te tyre, dhe cdo ransaksion Ti te lejohet te lexoje versionin me te fundit etiketa e te
cilit i pataprin TS(Ti).
30
Nese transaksioni Ti deshiron te lexoje nje objekt, duhet te garantohet se ky objekt nuk eshte
lexuar me pare nga nje transaksion Tj te tille qe TS(Ti) < TS(Tj). Nese transaksioni Ti lejohet
te shkruaje kete objekt, modifikimi i bere duhet te shihet nga transaksioni Tj per arsye
serializueshmerie, por meqenese Tj-ja e ka lexuar objektin me pare nuk do te shikoje
modifikimn e bere nga Ti-ja.
Per te beret e mundur kontrollin e ketij rregulli cdo objekt ruan edhe nje etikete per kohen e
leximit te tij, dhe sa here qe nje transaksion lexon objektin, etiketa behet sa maksimumi i
etiketes korrente dhe etiketes se transaksionit lexues. Nese transaksioni Ti deshiron te
shkruaje nje objekt O dhe TS(Ti) < RTS(O), Ti-ja anullohet dhe rifillon me nje etikete me te
madhe (re). Ne te kundert (pra TS(Ti) > RTS(O) ose TS(Ti) = RTS(O)), transaksioni Ti krjon
nje version te ri te O-se dhe ben etiketat e leximit dhe te shkrimit te ketij versioni sa TS(Ti).
Disavantazhet e ketij protokolli jane te ngjashme me ato te kontrollit bazuar ne etiketa, dhe
per me teper shtohet edhe kostoja e menaxhimit te versioneve te shumefishta. Nga ana tjeter,
leximet nuk bllokohen kurre, gje qe mund te jete e rendesishme per sisteme qe dominohen
nga transaksione qe vetem lexojne te dhena nga baza.
III. RIMEKEMBJA NGA DESHTIMET
Menaxheri i rimekembjes ne nje SMBD shte pergjegjes per te garantuar dy karakteristika te
rendesishme te transaksioneve: atomicity dhe durability. Ai garanton atomicity duke anulluar
veprimet e transaksioneve te pakonfirmuara dhe durability duke garantuar se gjidhe veprimet
e transaksioneve te konfirmuara u mbijetojne deshtimeve te sistemit dhe deshtimeve te
disqeve.
Menaxheri i rimekembjes eshte nje nga komponentet me te veshtire per du dizenjuar dhe
implementuar ne nje SMBD. Ne kete kapitull to te prezantohet algotimi i rimekembjes
ARIES, i cili eshte lehtesisht i konceptueshem, bashkpunon mire me nje sere mekanizmash
te kontrollit te egzekutimit te njekohshem, dhe perdoret gjeresisht ne SMBD.
31
III.1 Hyrje ne ARIES
ARIES eshte nje algoritem rimekembjeje qe eshte dizenjuar te funksionoje ne sisteme qe
perdorin metoden steal, no-force. Kur thirret menaxheri i rimekembjes pas nje deshtimi,
restart-imi kryhet ne tre faza:
1. Analizimi: Identifikohen faqet ne memorje me te dhena te modifikuara te pa shkruara
ne disk (dirty pages) dhe transaksionet aktive ne momentin e deshtimit.
2. Perseritja: Perseriten gjithe veprimet duke filluar nga nje pike e caktuar ne ditar
(log), dhe baza kthehet baza e te dhenave ne gjendjen qe kishte ne momentin e
deshtimit.
3. Anullimi: Anullohen veprimet e transaksioneve te pa konfirmuara ne menyre qe baza
te reflektoje vetem veprimet e transaksioneve te konfirmuara.
Konsideroni historine e thjeshte te egzekutimit te treguar ne Figuren 14. Kur sistemi restart-
ohet, faza e Analizimit identifikon transaksionet T1 dhe T3 si transaksione te cilat ishin aktive
ne momentin e deshtimit pra qe duhen anulluar; transaksionin T2 si transaksion te konfirmuar
veprimet e te cilit duhet te shkruhen ne disk; dhe faqet P1, P3 dhe P5 si dirty pages te
mundshme. Gjate fazes se Perseritjes, te gjitha modifikimet (duke perfshire ato te kryera nga
transaksionet T1 dhe T3) perseriten sipas rradhes. Se fundi, gjate fazes se Anullimit, veprimet
e transaksioneve T1 dhe T3 anullohen ne rradhe te kundert nga ajo e treguar, pra shkrimi i
faqes P3 nga transaksioni T3 anullhet i pari me pas anullohet shkrimi i faqes P1 nga
transaksioni T3 dhe se fundi anullohet shkrimi i faqe P5 nga transaksioni T1.
32
Figura 14. Histori egzekutimi me deshtim.
Egzistojne tre parime baze ne themel te algoritmit ARIES:
1. Write-ahead logging: Cdo modifikim i nje objekti te bazes se te dhenave regjistrohet
fillimisht ne ditar (log) dhe regjistrimi ne ditar duhet te shkruhet ne vend te sigurt
perpara se te shkruhet objekti ne disk.
2. Perseritja e historise gjate Perseritjes: Gjate ritart-imit te sistemit, ARIES gjurmon
gjithe veprimet e SMBD perpara deshtimi dhe e kthen sistemin ne gjendjen egzakte
qe ai ndodhej ne momentin e deshtimit. Me pas, ARIES anullon veprimet e
transaksioneve qe ishin aktive ne kohen e deshtimit.
3. Mbajtja e ditarit gjate Anullimit: Modifikimet e bera ne bazen e te dhenave gjate
anullimit te nje transaksioni regjistrohen ne ditar ne menyre qe keto veprime te mos
perseriten ne rast deshtimesh te perseritura.
Pika e dyte dallon ARIES nga algoritmet e tjera te rimekembjes dhe eshte baza e thjeshtesise
dhe fleksibilitetit te tij. Specifikisht, ARIES mund te suportoje protokolle te kontrollit te
egzekutimit te njekohshem qe perdorin kycje ne nivel me te detajuar se faqja.
33
III.1.1 Ditari
Ditari eshte nje histori e veprimeve te kryera nga SMBD. Praktikisht, ditari eshte nje file
regjistrimesh i cili ruhet ne nje vend te sigurt qe i mbijeton deshtimeve. Kjo mund te arrihet
due ruajtur dy apo me shume kopje te ditarit ne disqe te ndryshem keshtu qe probabiliteti i
humbjes se gjithe kopjeve ne te njejten kohe te jete i paperfillshem. Pjesea e fundit te ditarit
(ajo aktuale) quhet bishti i ditarit, mbahet ne memorje dhe periodikisht shkruhet ne vend te
sigurt.
Cdo regjistrim i ditarit merr nje nmer unik identifikimi qe quhet quhet numri serial i Log
(NSL). NSL duhet te gjenerohen ne menyre rritese, pra cdo NSL i gjenerur duhet te jete me i
madh se paraardhesi. Per nevojat e rimekembjes, cdo faqe ne baze permban NSL-ne e
regjistrimit me te fundit te ditarit qe pershkruan modifikim te kesaj faqeje. Ky NSL quhet
NSLfaqes.
Nje regjistrim ne ditar shkruhet per secilin nga veprimet e meposhtme:
Modifikimi i nje faqeje: Pas modifikimi te nje faqeje, shtohet ne fund te diratit nje
regjistrim i tipit update. NSLfaqes per faqen behet sa NSL i regjistrimi perkates ne
ditar.
Konfirmim: Kur nje transaksion vendos te konfirmohet, ai shkruan ne ditar nje
regjistrim te tipit commit i cili permman identifikuesin (id) te transaksionit. Ne
vazhdim bishti i ditarit shkruhet ne vend te sigurt. Transaksioni konsiderohet i
konfirmuar ne momentin qe regjistrimi i tipit commit ne ditar shkruhet ne vend te
sigurt.
Anullim: Kur nje transaksion anullohet, shkruhet ne ditar nje regjistrim i tipit abort, i
cili permban id-ne e transaksionit, dhe fillon procesi i Anullimit pr kete transaksion.
Fund: Kur nje transaksion anullohet apo konfirmohet duhen kryer disa veprime te
tjera pertej shtimit ne ditar te regjistrimeve te tipit abort apo commit. Pasi jane kryer
gjjithe keto veprime, shtohet ne ditar nje regjistrim i tipit end i cili permban id-ne e
transaksionit.
34
Anullimi i nje modifikimi: Kur nje transaksion anullohet (per shkak te anullimit te
tij apo gjate rimekembjes), modifikimet e kryera nga ai c’behen. Kur veprimi i
pershkruar nga nje regjistrim ne ditar anullohet, shtohet ne ditar nje regjistrim i tipit
CLR (compensation log record).
Cdo regjistrim ne ditar ka disa fusha: NSLmep (NSL i regjistrimit paraprires ne ditar per
transaksionin), IDtrans (id-ja e transaksionit) dhe tipi (tipi i regjistrimit). Bashkesia e
regjistrimeve ne ditar per nje transaksion ruhen si nje liste e lidhurme drejtim te kundert ne
kohe duke perdorur fushen NSLmep. Kjo list duhe perditesuar sa here qe shtohet nje
regjistrim per transaksionin ne ditar. Ne varesi te tipit cdo rejistrim mund te kete fusha te
tjera pervec atyre baze.
III.1.1.1 Regjistrimet e tipit update
Fushat e nje regjistrimi te tipit update tregohen ne Figuren 15. Fusha IDfaqe eshte
identifikuesi i faqes se modifikuar; gjatesia ne bytes dhe offset i modifikimit jane dy fusha te
tjera. Fusha perparaeshte vlera e bytes te modifikuara perpara modifikimit dhe pas eshte vlera
e bytes te modifikuara pas mofikimit. Nje regjistrim i tipit update qe permban vlera tek te
dyja fushat perpara dhe pas mund te perdoret edhe per perseritjen edhe per anullimin e
modifikimit perkates.
Figura 15. Fushat e nje regjistrimi te tipit update ne ditar.
III.1.1.2 Regjistrimet e tipit CLR
Nje regjistrim i tipit CLR shkruhet menjehere perpara se te c’behet veprimi i resgjitruar ne
nje regjistrim te tipit update ne ditar. Nje CLR C pershkruan veprimin qe u krye per te c’bere
nje veprim te regjistruar ne ditar dhe shtohet ne fund te ditarit njelloj si cdo regjistrim tjeter.
35
Regjistrimi i tipit CLR permban gjithashtu nje fushe te quajtur NSLanullPas, qe eshte NSL e
regjistrimit te rradhes qe duhet c’bere per transaksionin qe shtoi regjistrimin e tipit update U.
NSLanullPas merr vleren e fushes NSLmep ne regjistrimin U.
Si nje shembull, konsideroni regjistrimin e kater te ditarit ne Figuren 16. Nese ky modifikim
c’behet do te shtohet nje CLR qe d te perfshinte vlerat e IDtrans, IDfaqe, gjatesia, offset dhe
perpara te kopjuara nga regjistrimi perkates i tipit update. Fusha NSLanullPas merr si vlere
vleren e NSL te regjistrimi te pare te ditarit ne figure.
Ndryshe nga regjistrimet e tipit update, nje regjistrim i tipit CLR pershkruan nje veprim i cili
nu mund te c’behet kurre, pra kurre nuk c’behet nje veprim c’berjeje. Arsyeja per kete eshte
e thjeshte: nje regjistrim i tipit upate pershkruan nje modifikim te kryer nga nje transaksion
gjate egzekutimit normal dhe transaksioni ne vazhdim mund te anullohet, ndersa nje
regjistrim i tipit CLR pershkruan nje veprim per anullimin e nje transaksioni per te cilin eshte
marre tashme vendimi per anullim. Rrjedhimisht, transaksioni duhet te anullohet dhe veprimi
i pershkruar nga CLR duhet te kryhet pa tjeter.
Mund te ndodhe qe nje regjistrim i tipit CLR te shkruhet ne disk por veprimi c’beres qe ai
pershkruan te mos jete shkruar aoma ne disk kur sistemi deshton perseri. Ne kete rast veprimi
c’beres qe pershkruhet nga CLR rikryhet gjate fazes se Perseritjes.
III.1.2 Struktura te Tjera te Dhenash qe Perdoren per Rimekembjen
Pervec ditarit, perdoren dy struktura te tjera permbajne informacion te rendesishem per
rimekembjen nga deshtimet:
Tabela e transaksioneve: Kjo tabele permban nje rresht per cdo transaksion aktiv.
Cdo rresht permban (midis te tjerash) id-ne e transaksionit, gjendjen e transaksionit
dhe nje fushe qe quhet NSLfun, e cila eshte NSL i regjistrimit me te fundit ne ditar
per kete transaksion. Gjendja e nje transaksioni mund te jete: ne process, i konfirmuar
apo i anulluar.
Tabela e dirty pages: Kjo tabele permban nje rresht per cdo dirty page ne memorje,
pra per cdo faqe modifikimet mbi te cilen nuk jane shkruar ne disk. Cdo rresht
permban nje fushe te quajtur NLSfill qe eshte NLS-ja e regjistrimit te pare ne ditar qe
36
ka shkaktuar faqen te behet dirty. Kjo fushe percakton regjistrimin me te hershem tne
ditar i cili mund te duhet te perseritet gjate rimekembjes.
Gjate egzekutimit normal te sistemit, keto dy struktura perditesohen nga menaxheri i
transaksioneve dhe menaxheri i memorjes perkatesisht, dhe gjate rimekembjes ato
rindertohen gjate fazes se Analizimit.
Konsideroni shembulln e meposhtem: Transaksioni T1000 modifikon vleren e byte-ve 21 deri
me 23 ne faqen P500 nga ‘ABC’ ne ‘DEF’, transaksioni T2000 modifikon ‘HIJ’ ne ‘KLM’ ne
faqen P600, transaksioni T2000 modifikon vleren e byte-ve 20 deri me 22 ne faqen P500 nga
‘GDE ne ‘QRS’, dhe transaksioni T1000 modifikon ‘TUV’ ne ‘WXY’ ne faqen P505. Tabela
dirty page, tabela e transaksioneve dhe ditari ne kete moment tregohen ne Figuren 16. Vini re
se ditari rritet nga larte poshte, pra regjistrimet me te vjetra jane ne krye.
Figura 16. Ditari dhe tabelat e transaksioneve dhe dirty page.
III.1.3 Protokolli Write-Ahead Log
Perpara se nje faqe te shkruhet ne disk, cdo regjistrim i tipit update ne ditar qe pershkruan
modifikim ne kete faqe duhet shkruar ne disk. Kjo arihet duke shkruar ne disk gjithe
37
regjistrimet e ditarit duke perfshire ate me NSL te barabarte me NSLfill, perpara se te
shkruhet faqja e modifikuar.
Protokolli Write-Ahead Log (WAL) eshte shume rregulli baze qe garanton se nje eshte i
disponueshem regjistrim per cdo modifikim ne baze gjate rimekembjes nga deshtimet. Nese
nje transaksion ben nje mdifikim dhe konfirmohet, metoda no-force mundeson qe disa nga
keto modfikime mund te mos jene shkruar ne disk ne momentin e deshtimit. Pa nje resgistrim
ne ditar te keryte modifikimeve, nuk eshte emundur te garantohet se modifikimet e
transaksioneve tekonfirmuara do ti mbijetojne deshtimit.
Kur nje transaksion konfirmohet, bishti i ditarit shkruhet ne disk, akoma edhe kur perdoret
metoda no-force. Eshte e rendesishme te krahasohet ky veprim me veprimet qe do te
ndiqeshin nga metoda force: Nese do te perdorej metoda force, gjithe faqet e modifikuara nga
transaksioni duhet te shkruhen ne disk, ndersa me WAL vetem nje pjese e ditarit shkruhet ne
disk. Faqet e modifikuara jane shume me te medha (ne bytes) se sa bishti i ditarit pasi nje
regjistrim i tipit update eshte dy here me i madh se sa bytes te modifikuara, qe eshte shume
me e vogel se nje faqe.
III.1.4 Checkpointing
Nje pike kontrolli (checkpoint) eshte si nje fotografi e gjendjes se SMBD, dhe duke ruajtur
checkpoints periodikisht, sic do te shikojme, SMBD mun de pakesoje punen qe nevojitet
gjate rimekembjes nga deshtimi.
Checkpointing ne ARIES ka tre hapa. Se pari, shtohet ne ditar nje regjistrim i tipit
begin_checkpoint per te treguar se kur fillon checkpoint. Se dyti, shtohet ne ditar nje
regjistrim i tipit end_checkpoint i cili perfshin permbajtjet e tabelave te transaksioneve the
dirty pages. Hapi i trete kryhet pas shkrimit te regjistrimit end_checkpoint ne disk: nje
regjistrim special i cili permban NSL-ne e regjistrimit begin_checkpoint shkruhet ne vend te
sigurt. Nderkohe qe ndertohet regjistrimi end_checkpoint, SMBD vazhdon egzekutimin e
transaksioneve dhe shtimin e regjistrimeve ne ditar. E vatmja garanci qe kemi eshte tabelat e
transaksioneve dhe dirty pages jane te sakta deri ne kohen e regjistrimit begin_checkpoint.
38
Kjo menyre checkpoint-i quhet fuzzy checkpoint dhe nuk eshte e kushtueshme pasi nuk
kerkon ndalimin e sistemit apo shkrimin ne disk te faqeve qe ndodhen ne memorje. Nga ana
tjeter, efektiviteti i kesaj teknike limitohet nga NSLfill me i hershem ne faqet e tabeles dirty
pages, pasi gjate rimekembjes perseritja duhet te filloje nga regjistrimi i ditarit me NSL sa ky
NSLfill.
III.2 Rimekembja nga Deshtimi
Kur sistemi restart-ohet pas nje deshtimi menazheri i rimekembjes ndjek tre faza sic tregohet
ne Figuren 17.
Figura 17. Tre fazat e rimekembjes ne ARIES.
Faza e Analizimit fillon duke lokalizuar regjistrimin me te fundit te tipit begin_checkpoint,
NSL-ja per te cilin simbolizohet me C ne figure, dhe avanson ne ditar deri ne regjistrimin e
fundit ne ditar. Faza e Perseritjes ndjek fazen e Analizimit dhe perserit gjithe modifikimet ne
sdo faqe qe mund te ishte dirty ne momentin e deshimit; keto faqe dhe pika nga do te filloje
Perseritja percaktohen gjate Analizimit. Faza e trete eshte ajo e Anullimit dhe c’ben
modifikimet e gjithe transaksioneve qe ishin aktive ne momentin e deshtimit; perseri, keo
transaksione percaktohen gjate fazes se Analizimit. Vini re se Perseritja persrit modifikimet
39
ne rradhen qe ato jane kryer, ndersa Anullimi i c’ben modifikimet ne rradhe te kunder duke
filluar nga modifikimi me i fundit.
III.2.1 Faza e Analizimit
Faza e analizimit kryen tre detyra:
1. Percakton piken ne ditar nga ku do te filloje faza e Perseritjes.
2. Percakton faqet ne memorje qe ishin dirty ne momentin e deshtimit.
3. Identifikon transaksionet qe ishin aktibe ne momentin e deshtimit dhe duhet te
anullohen.
Analizimi fillon duke lokalizuar regjistrimin me te fundit te tipit begin_checkpoint dhe duke
inicializuar tabelat e transaksioneve dhe dirty pages me vlerat e ruatjura ne regjistrimin
end_chekckpoint perkates. Pra, keto tabela permbajne transaksionet akive dhe faqet dirty ne
momentin e checkpoint. Ne vazhdim Analizimi lexon regjistrimet e ditarit ne rradhen qe jane
shtuar deri sa arrin ne fund te tij:
Nese lexohet nje regjistrim i tipit end per nje transaksion T, T-ja fshihet nga tabela e
transaksioneve pasi ai nuk eshte me aktiv.
Nese lexohet nje regjistrim i cfaredo tipi pervec end per nje transaksion T dhe T-ja
nuk ndodhet ne tabelen e transaksioneve atehere shtohet ne te. Per me teper
regjistrimi pe T-ne modifikohet si me poshte:
1. NSLfun behet sa NSL i regjistrimit qe lexohet.
2. Nese regjistrimi eshte i tipit commit, statusi i transaksionit behet C, ne cdo
rast tjeter statusi i transaksionit behet U (qe do te those se ai do te anullohet).
Nese lexohet nje regjistrim qe modifikon faqen P dhe P-ja nuk eshte ne tabelen dirty
page atehere shtohet ne te me NSLfill sa NSL i regjistrimit qe po lexohet.
Ne fund te fazes se Analizimit, tabela e transaksioneve permban nje liste te perpikte te gjithe
transaksioneve qe ishin aktive ne momentin e deshtimit (transaksionet ne tabele me status U).
40
Tabela e dirty pages permban gjithe faqet qe ishin dirty ne momentin e deshtimit, por mund
te permbaje gjithashtu disa faqe qe ishin shkruar ne disk perpara deshtimit.
Si nje shembull konsideroni egzekuimin ne Figuren 16. Le te supozojme se transaksioni T2000
konfirmohet, me pas transaksioni T1000 modifkion faqen P700, shton nje regjistrim te tipit
update ne ditar dhe me pas sistemi deshton (perpara se ky regjistrim ne ditar te shkruhet ne
disk).
Tabela e transaksioneve dhe ajo e dirty pages humbasin gjate deshtimit (nuk shkruhen ne
disk). Checkpoint-i me i fundit eshte ai ne fillim te egzekutimit ku dy tabelat ishin bosh, pra
dhe faza e Analizimit fillon me tabelat boshe. Duke lexuar regjistrime e ditarit, transaksioni
T1000 shtohet ne tabelen e transaksioneve dhe faqja P500 ne tabelen dirty pages me NSLfill sa
NSL i regjistrimit te pare ne ditar. Ne menyre te ngjashme, transaksioni T2000 shtohet ne
tabelen e transaksioneve dhe faqja P600 ne tabelen dirty pages. Rreshti i trete i ditarit nuk
shkakton asnje ndryshim ndersa regjistrimi i katert shkakton shtimin e faqes P505 ne tabelen
dirty pages. Regjistrimi i tipit commit per transaksionin T2000 (nuk duket ne figure) lexohet ne
vazhdim dhe si rrjedhoje transaksioni T2000 fshihet nga tabela e transaksioneve.
Tanime faza e Analizimit ka perfunduar dhe eshte percaktuar se transaksioni i vetem aktiv ne
momentin e deshtimit ishte ai T1000, me NSLfun sa NSL e regjistrimit te katert ne ditar.
Tabela edirty pages eshte identike me ate te treguar ne figure. Regjistrimi i tipit update ne
ditar per modifkimin e faqes P700 humbi gjate deshtimit dhe nuk u pa gjate Analizimit. Por,
fale protokollit WAL, cdo gje eshte ne rregull pasi as modifikimi i faqes nuk eshte shkruar ne
disk.
Disa nga modifikimet mund te jene shkruar ne disk perpara deshtimit. Le te supozojme se
modifikimi i faqes P600 eshte shkruar ne disk perpara deshtimit, qe do te thote se kjo faqe nuk
eshte dirty por ajo perfshihet nga Analizimi ne tabelen dirty pages. Megjithate, NSLfaqes per
faqen P600 reflekton shkrimin pasi ajo eshte ebarabarte me NSL te rreshtit te trete te ditarit ne
figure.
41
III.2.2 Faza e Perseritjes
Gjate fazes se Perseritjes, ARIES perseriten modifikimet e gjithe transaksioneve, te
konfirmuara apo jo. Gjithashtu, nese nje transaksion ishte anulluar perpara deshtimit dhe
modifikimet e tij ishin anulluar, sic duket nga regjistrimet CLR, veprimet e pershkruara ne
CLR perseriten gjithashtu.
Faza e Perseritjes fillon me regjistrimin e ditarit me NSL sa NSLfill me i vogel ne gjithe
faqet qe ndodhen ne tabelen dirty page te ndertuar ne fazen e Anullimit, pasi ky regjistrim
perfaqeson meofikimin me te hershem i cili mund te mos jete shkruar ne disk perpara
deshtimit. Duke filluar nga ky regjistrim, Perseritja lexon gjithe regjistrimet deri ne fund te
ditarit. Per cdo regjistrim te tipit update apo CLR, Perseritja kontrollon nese veprimi perkates
duhet perseritur. Veprimi duhet perseritur me perjashtim te rasteve kur nje nga kushtet e
meposhtme eshte i vertete:
Faqja perkatese nuk eshte ne tabelen dirty page.
Faqja perkatese eshte ne tabelen dirty page por NSLfill per te eshte me i madh se sa
NSL i regjistrimit.
NSLfaq per faqen eshte me i madh apo i barabarte me NSL te regjistrimit.
Kushti i pare nenkupron se gjithe modifikimet ne kete faqe jane shkruar ne disk. Meqenese
NSLfill perfaqeson modifikimin e pare ne kete faqe i cili mund te mos jete shkruar ne disk,
kushti i dyte tregon se modifikimi qe po shqyrtohet eshte shkruar ne disk. Kushti i trete, i cili
eshte i fundit qe kontrollohet pasi kerkon leximin e faqes nga disku, gjithashtu garanton se
modifikimi eshte shkruar ne disk, pasi ose ky modifikim ose nje me i vonet u shkrua ne disk.
Nese veprimi duhet perseritur atehere:
1. Veprimi perseritet.
2. NSLfaq per faqen perkatese behet sa NSL i regjistrimit qe perseritet.
Le te vazhdojme shembullin qe pame ne seksionin II.2.1. Nga tabela e dirty pages rezulton se
NSLfill me i vogel eshte NSL i regjistrimit te pare ne ditar. Perseritja lexon nga disku faqen
42
P500 dhe krahason NSL per regjistrimin me NSLfaq te faqes dhe, meqenese supozuam se
modifikimet ne kete faqe nuk jane shkruar ne disk perpara deshtimit, rezulton se NSLfaq <
NSL. Modifikimi perseritet: bytes 21 deri ne 23 ndryshohen ne ‘DEF’ dhe NSLfaq behet sa
NSL i regjistrimit korrent.
Ne vazhdim, Perseritja egzaminon regjistrimin e dyte. Perseri, faqja perkatese, P600, lexohet
nga disku dhe krahasohet NSL per regjistrimin me NSLfaq te faqes. Ne kete rast, meqenese
supozuam se faqja P600 ishte shkruar ne disk perpara deshtimit NSL = NSLfaq dhe
modifikimi nuk ka nevoje te perseritet.
Regjistrimet embetura te ditarit procesohen ne menyre te ngjashme duke sjelle sistemin ne te
njejten gjendje qe ishte perpara deshtimit. Vini re se dy kushtet e para qe mundesojne
mosperseritjen e veprimit nuk plotesohen kurre ne kete shembull. Ato veprojne kur tabela e
dirty pages permban nje NSLfill shume te vjeter, me te vjeter se checkpoint-i me i fundit. Ne
kete rast kur Perseritja lexon regjistrimet e ditarit duke filluar nga regjistrimi me NSL =
NSLfill, do te gjeje regjistrime per faqe qe jane shkruar ne disk perpara checkpoint-it dhe qe
rrjedhimisht nuk ndodheshin ne tabelen ditry pages ne momentin e checkpoint-it. Disa nga
keto faqe mund te modifikohen perseri ne vazhdim, por megjithate modifikimet ne keto faqe
perpara checkpoint-it nuk nevojitet te perseriten. Megjithese kushti i trete mjafton per te
percaktuar se keto modifikime nuk duhen perseritur, atij i nevojitet te sjelle faqen perkatese
nga disku. Dy kushtet e para e mundesojne kete pa sjelle faqen nga disku.
Ne perfundim te fazes se Perseritjes, shkruhen regjistrime te tipit end per cdo transaksion me
status C, te cilat fshihen nga tabela e transaksioneve.
III.2.3 Faza e Anullimit
Faza e anullimit, ndryshe nga dy fazat e tjera, lexon ditarin mbrapsht duke filluar nga fundi i
ditarit. Qellimi i kesaj faze eshte te anulloje veprimet e gjithe transaksioneve qe ishin aktive
ne momentin e deshtimit. Keto transaksione identifikohen nepermjet tabeles se
transaksioneve te ndertuar nga faza e Analizimit.
III.2.3.1 Algorimtmi i anullimit
43
Anullimi fillon me tabelen e transaksioneve te ndertuar nga faza e Analizimit, duke lexuar
vleren e NSLfun per secilin transaksion ne kete tabele. Keto transaksione quhen
transaksione humbese. Te gjitha veprimet e transaksioneve humbese duhet te c’behen ne
rradhe te kundert me ate qe shfaqen ne ditar.
Konsideroni listen e vlerave te NSLfun per gjithe transaksionet humbese. Le te quajme kete
liste lista PerAnullim. Deri sa lista PerAnullim te zbrazet, zgjidhet NSL me i madh ne liste
dhe:
1. Nese regjistrimi i ditarit me kete NSL eshte i tipit CLR dhe vlera e NSLanullPas per
te nuk eshte boshe, vlera e NSLanullPas shtohet tek lista PerAnullim. Nese
NSLanullPas eshte boshe, shtohet nje regjistrim i tipit end per transaksinonin perates
pasi ai eshte anulluar teresisht.
2. Nese regjistrimi i ditarit me kete NSL eshte i tipit update, shtohet ne ditar nje
regjistrim i tipit CLR dhe veprimi perkates anullohet sic u pershkrua ne seksionin
III.1.1, dhe vlera e NSLmep per regjistrimin e tpit update shtohet ne listen
PerAnullim.
Pasi lista PerAnullim eshte boshatisur, faza e Anullimit ka perfunduar, bashke me te ka
perfunduar dhe rimekembja, dhe sistemi mund te vazhdoje punen normalisht.
Le te vazhdojme me shembullin qe pame ne seksionet III.2.1 dhe III.2.2. Transaksioni i
vetem aktiv ne momentin e deshtimit ishte ai T1000. Nga tabela e transaksioneve gjejme se
NSL me vleren me te madhe i cili i korrespondon regjistrimit te katert te tipit update.
Modifikimi c’behet, nje regjistrimi i tipit CLR shtohet ne ditar me NSLanullPas sa NSL i
regjistrimit te pare ne ditar. Regjistrimi tjeter per u anulluar eshte i pari ne ditar. Pasi edhe ky
regjistrim c’behet, shtohen nje regjistrim i tipit CLR dhe nje regjistrim i tipit end ne ditar,
dhe faza e anullimit perfundon.
III.2.3.2 Anullimi i nje transaksioni
Anullimi i nje transaksioni eshte nje rast i vecante i fazes se Anullimit kun je transaksion i
vetem, ne vend te disa prej tyre, anullohet.
44
III.2.3.3 Deshtime gjate rimekembjes
Eshte e rendesishme te kuptojme se si algoritmi i Anullimit menaxhon deshtime te
njepasnjeshme gjate rimekebjes. Per te ilistruar se si kjo arrihet do te shikojme nje shembull
bazuar ne ditarin e thjeshtuar treguar ne Figuren 18. Ne figure per thjeshtesi, shfaqen disa
regjistrime te ditarit ne nje rresht te vetem te ndara me presje.
Figura 18. Shembull deshtimesh te njepasnjeshme.
Regjistrimi me NSL 30 tregon se transaksioni T1 anullohet. Te gjitha veprimet e transaksionit
duhet te anullohen ne rradhe te kundert, dhe veprimi i vetem i transaksionit T1 qe pershkruhet
nga regjistrimi me NSL 10 anullohet sic duket nga regjistrimi CLR me NSL 40.
Pas deshtimit, Analizimi identifikon faqet P1 (ne NSLfill 50), P3 (me NSLfill 20) dhe P5 (me
NSLfill 10) si dirty pages. Regjistrimi me NSL 45 tregon se transaksioni T1 eshte i
kompletuar keshtu qe tabela e transaksioneve perbehet nga transaksionet T2 (me NSLfun 60)
dhe T3 (me NSLfun 50) si transaksione aktive ne momentin e deshtimit. Faza e Perseritjes
fillon me regjistrimin me NSL 10, i cili eshte NSLfill me i vogel ne tabelen dirty pages, dhe
perserit gjithe veprimet e regjistruara sipas algoritmit te Perseritjes.
45
Lista PerAnullim perbehet nga NSL-te 60 per transaksionin T2 dhe 50 per transaksionin T3.
Faza e Anullimit fillon me regjistrimin me NSL 60 pasi ai eshte me i madhi ne listen
PerAnullim. Modifikimi c’behet dhe nje regjistrim i tipit CLR shtohet ne ditar (me NSL 70).
Ky regjistrim ka NSLanullPas te barabarte me 20 pasi kjo eshte vlera e NSLmep per
regjistrimin me NSL 60, pra regjistrimi me NSL 20 eshte veprimi i rradhes per tu c’bere per
transaksionin T2. Tani NSL-ja me e madhe ne listen PerAnullim eshte ajo me vlere 50.
Modifikimi korrespondues c’behet dhe shtohet nje regjistrim i tipit CLR me NSL 80 dhe
NSLanullPas boshe pasi regjistrimi me NSL 50 eshte i vetmi per transaksionin T3. Pra ky
transaksion eshte anulluar teresisht dhe nje regjistrim i tipit end shtohet ne ditar per te.
Regjistrimet me NSL 70, 80 dhe 85 shkruhen ne vend te sigurt perpara perpara se sistemi te
deshtoje per here te dyte, ndersa modifikimet e pershkruara ga keto regjistrime mund te mos
jene shkruar ne disk.
Pasi sitemi restart-ohet pas deshtimit te dyte, Analizimi shton ne tabelen e ransaksioneve
vetem transaksionin T2 ndersa tabela dirty page eshte identike me ate pas restart-imit te pare.
Regjistrimet me NSL 10 deri ne 85 procesohen perseri gjate Perseritjes (nese disa nga
modifikimet e kryera gjate Peresritjes se meparshme ishin shkruar ne disk, NSLfaq e faqes
perkatese perdore per te shmangur shkrimin e tyre perseri). Ne faen e Anullimit lista
PerAnullim permban vetem NSL-ne me vlere 70 dhe pasi e ka procesuar ate duke shtuar ne
liste vleren e NSLanullPas (20) ne listen PerAnullim. Ne vazhdim procesohet regjistrimi me
NSL 20 duke anulluar mdifikimin e transaksonit T2 mbi faqen P3 dhe duke shtuar nje
regjistrim te tipit CLR (me NSL 90). Meqenese regjistrimi me NSL 20 eshte regjistrimi i
fundit per tu anulluar per transaksionin T2, NSLanullPas per regjistrimin e tipit CLR eshte
boshe dhe shtohet nje regjistrim i tipit end per transaksionin, dhe lista PerAnullim eshte
boshe.
Rimekembja ka perfunduar tashme dhe sistemi mund te fillje punen normalisht me shkrimin
e nje regjistrimi checkpoint.
Le te shikojme se cfare ndodh nese sistemi deshton gjate fazes se Analizimit apo se
Perseritjes. Nese sistemi deshton gjate fazes se Analizimit, gjithe puna e kryer gjate saj
humbet, dhe pase restart-imit te rradhes faza e Analiziit fillon nga fillimi me te njejtin
informacion si me pare. Nese sitemi deshton gjate fazes se Perseritjes, e vetmja gje qe i
46
mbijeton deshtimit jane disa nga modifikimet e bera gjate kesaj faze qe mund te jene shkruar
ne disk perpara deshtimit. Pas restart-imit egzekutohet perseri faza e Analizimit dhe me pas
disa nga modifikimet e meparshme nuk do te rikryhen pasi NSLfaq per faqet perkatese do te
jene te barabarta me NSL-te e regjistrimeve te tipit update.
III.2 Algoritma te Tjere dhe Nderveprimi i Tyre me Kontrollin e
Egzekutimit Te Njekohshem
Ashtu si ARIES, shumica e algoritmeve alternative te rimekembjes mbajne nje ditar te
veprimeve ne baze sipas protokollit WAL. Ndryshimi baze midis ARIES dhe algoritmeve te
tjere eshte se ARIES gjate fazes se Perseritjes perserit historine, pra perserit veprimet e gjithe
transaksioneve jo vetem te kompletuarve. Algoritmet e tjere perserisin vetem veprimet e
transaksioneve te kompletuara dhe ne fazen e perseritjes c’behen veprimet e transaksioneve
te anulluara apo te pa kompletuara.
Fale perseritjes se histories dhe perdorimin e CLR-ve, ARIES ka mundesine te mbeshtese
kycje ne nivel me te detajuar (ne nivel rreshti) dhe regjistrimin ne ditar te veprimeve llogjike
ne vend te modifikimeve ne nivel byte. Regjistrimi i veprimeve llogjike mundeson perdorim
me te larte te egzekutimit te njekohshem megjithese perdorimi i kycjeve ne nivel me te
detajuar mund te sjelle aktivitet me te larte per menaxhimin e celesave.
IV. BAZA PARALELE DHE TE SHPERNDARA
Deri tani kemi pare SMBD te centralizuara ne te cilat te dhenat ruhen ne nje vend (server)
dhe procesimi i transaksioneve eshte serial. Nje nga tendencat me te rendesishme ne bazat e
te dhenave eshte perdorimi gjithnje e ne rritje e teknikave te egzekutimit parallel dhe te
shperndare. Ka kater arsye per kete:
Performanca: Perdorimi i disa burimeve paralelisht mund te permiresoje
performancen ne menyre te ndjeshme.
Disponueshmeri e larte: Nese nje server qe permban nje pjese te bazes deshton, baza
vazhdon te jete e disponueshme nese ruhet nje kopje ne nje server tjeter.
47
Akses i shperndare tek te dhenat: Nje organizate mund te kete dege ne disa qytete.
Megjithese analistet duhet te aksesojne te gjithe te dhenat e organizates, zakonisht te
dhenat aksesohen lokalisht (p.sh. nje drejtor banke me shume mundesi do te aksesoje
llogarite eklienteve locale), dhe ky lokalitet mund te shfrytezohet duke shperndare te
dhenat ne menyre te pershtatshme.
Analizim i te dhenave te shperndara: Organizatat kne gjithmone e me shume
nevoje te aksesojne gjithe te dhenat e disponueshme, edhe nese ato jane te ruajtura ne
disa server-a apo SMBD.
Sisteme paralele te bazave te te dhenave perpiqen te permiresojne performancen nepermjet
implementimit paralel te veprimeve te ndryshme si leximi i te dhenave, krijimi i indekseve,
dhe egzekutimi i pyetjeve. Megjithese te dhenat mund te ruhen ne menyre te shperndare ne
keto sisteme, shperndarja kryhet me te vetmin qellim performance.
Ne sistemet e shperndara te bazave te te dhenave, te dhenat ruhen fizikisht ne server-a ne
vendndodhje te ndryshme, dhe cdo server menaxhohet nga nje SMBD i cili egzekutohet ne
menyre te pa varur nga server-at e tjere. Vendndodhja e te dhenave dhe shkalla e autonomise
se server-ave ka impakt te rendesishem ne gjithe aspektet e sistemit si optimizimi i pyetjeve,
procesimi i pyetjeve, kontrolli i egzekutimit te njekohshem, dhe rimekembja nga deshtimet.
Ndryshe nga bazat paralele, shperndarja e te dhenave ndikohet nga faktore si disponueshmeri
e larte dhe lokaliteti.
IV.1 Arkitektura per Baza te Shperndara
Idea baze e bazave paralele eshte egzekutimi i hapave paralelisht kur eshte e mundur ne
menyre qe te permiresohet perfromanca. Egzistojne shume mundesi paralelizimi ne nje
SMBD; bazat e te dhenave jane nje nga shembujt me te suksesshem te llogaritjes paralele.
Jane propozuat tre arkitektura per ndertimin e SMBD paralele. Ne nje sistem memorje e
perbashket, CPU te shumefishta lidhen nepermjet nje rrjeti nderlidhes dhe munden te
aksesojne nje memorje te perbashket. Ne sisteme disk i perbashket, cdo CPU ka nje
memorje private dhe ka akses ne disqet e perbashket nepermjet nje rrjeti nderlidhes. Ne
48
sisteme asgje e perbashket, cdo procesor ka memorje dhe disk privat dhe komunikojne
nepermjet nje rrjeti nderlidhes. Tre arkitekturat ilustrohen ne Figuren 19.
Figura 19. Arkitektura bazash paralele
Arkitektura memorje e perbashket eshte me afer asaj te nje kopjuteri te zakonshem, dhe si
pasoje shume sisteme bazash te dhenash komerciale jane aplikuar me lehtesi ne platforma
memorjeje te perbashket. Kostoja e komunikimit eshte e ulet, pasi memorja kryesore mund te
perdoret per kete qellim dhe service-t e sistemit te shfrytezimit mund te modifikohen per te
perdorur CPU-te shtese. Megjithese kjo arkitekture eshte mjaft terheqese per arritjen e nje
paralelizmi ten je shkalle mesatare (disa dhjetera CPU mund te shfrytezohen ne kete
menyre), konkurenca per memorje shkakton probleme me rritjen e numrit te CPU-ve.
Arkitektura disk i perbashket ka nje problem te ngjashem pasi nje sasi e madhe te dhenash
leviz ne rrjetin nderlidhes.
49
Memorje e perbashket Disk i perbashket Asgje e perbashket
Problemi baze me arkitekturat memorje e perbashket dhe disk i perbashket eshte
interferenca: Me rritjen e numrit te CPU-ve, ato egzistente ngadalesohen per arsye te
konkurences per memorje apo rrjet. Eshte vene re se akoma edhe me nje ngadalesim mesatar
prej 1% per cdo CPU te shtuar, sistemi pershpejtohet deri ne momentin qe ka 37 CPU, dhe
shtimi i nje CPU-je tjeter ngadaleson sistemin; pra nje sistem me 1000 CPU arrin 4% te
efektivitetit te nje sistemi me nje CPU te vetme! Ky fakt ka motivuar zhvillimin e
arkitektures asgje e perbashket, e cila konsiderohet si arkitektura me e mire per sisteme
paralele te medha.
Arkitektura asgje e perbashket kerkon riorganizim te SMBD, por ofron pershpejtim linear,
pra koha per egzekutimin e veprimeve zvogelohet ne menyre te drejte me numrin e CPU-ve
dhe disqeve, pershkallezim linear, pra performance mbetet e njejte nese numri i CPU-ve dhe
disqeve rritet ne menyre te drejte me sasine e te dhenave.
IV.2 Egzekutimi Paralel i Pyetjeve
Ne kete session do te diskutojme egzekutimin paralel te nje pyetjeje SQL ne nje SMBD me
arkitekture asgje e perbashket. Plani i egzekutimit te nje pyetjeje SQL eshte nje graf
operatoresh dhe keta operatore mund te egzekutohen paralelisht. Nese nje operator punon me
rezultatin e nje operatori tjeter, kemi paralelizim pipelined (rezultati i nje operatori perdoret
nga operatoti tjeter sapo ai gjenerohet); ne te kundert dy operatoret mund te punojne ne
menyre te pavarur. Nje operator bllokohet nese nuk mundet te gjeneroje rezultat deri sa te
kete lexuar gjithe te dhenat qe i duhen. Paralelizimi pipelined limitohet nga prezenca e
operatoreve qe bllokohen.
Pervec egzekutimit te operatoreve paralelisht, mundemi te egzekutojme cdo operator ne nje
plan egzekutimi ne menyre paralele. Celesi per te arritur kete eshte copezimi e te dhenave qe
u nevojiten; ne vazhdim cdo cope mund te procesohet paralelisht dhe te kombinohen
rezultatet. Kjo qasje quhet data-partitioned parallel evaluation.
IV.2.1 Copezimi i te Dhenave
Copezimi horizontal i nje baze te dhenash dhe shperndarja e copave ne disa disqe mundeson
leximin dhe shkrimin paralel te te dhanve. Ka disa menyra per te copezuar nje tabele
50
horizontalisht. Mundemi tu analogojme CPU-ve rreshta te tabeles ne menyre rrethore (round-
robin), duke perdorur funksione hash apo sipas segmenteve te vlerave te te dhenave. Nese
egzistojne n CPU, copezimi ne menyre rrethore i analogon rreshtin e i i-te CPU-se i % n.
Ne copezimin nepermjet hash, perdoret nje funksion hash mbi disa fusha te rreshtit per te
percaktuar procesorin perkates. Ne copezimin sipas segmenteve te vlerave, rreshtat renditen
dhe caktohen n segmente ne menyre qe cdo segment te permbaje nje numer thuajse te
barabarte rreshtash, dhe rreshtat ne segmentin i i analogohen CPU-se i.
Copezimi ne menyre rrethore eshte i pershtatshem per egzekutimin e fikas te pyetjeve qe
aksesojne gjithe tabelen. Nese kerkohet vetem nje nenbashkesi e rreshtave (p.sh. ato per
punonjesit me moshe 20 vjec), copezimi nepermjet hash dhe ai sipas segmenteve te vlerave
performojne me mire se copezimi rrethor pasi na mundesojne te aksesojme vetem ato disqe
qe permbajne rreshtat e duhur. (Kuptohet qe per kete nevojitet qe fusha e zgjedhur per
fuknsionin hash apo per renditjen te jete mosha). Nese kemi pyetje qe kerkojne segmente
rreshtash (p.sh. 15 < mosha < 25), copezimi sipas segmenteve eshte superior ndaj atij hash
pasi rreshtat e rezultatit pe shume mundesio ndodhen te grupuara ne pak CPU. Nga ana tjeter,
copezimi sipas segmenteve te vlerave mund te shkaktoje disbalanca ne permasat e copave.
Procesore te cileve u jane analoguar copa te medha perbejne pika ngadalesimi te sistemit.
Copesimi hash e shmang kete pasi ai shperndan te dhenat ne menyre uniforme akoma edhe
kur te dhenat shtohen dinamikisht.
IV.3 Paralelizimi i Veprimeve Individuale
Ne kete seksion do te shikojme se si munden te implementohen ne paralel disa veprime ne
nje arkitekture paralele asgje e perbashket. Supozojme se cdo tabele eshte e copezuar
horizontalisht ne disa disqe.
IV.3.1 Leximi i Gjithe Rreshtave
Faqet mund te lexohen paralelisht gjate leximit te rreshtave, dhe rreshtat e lexuara mund te
bashkohen nese tabela eshte copezuar ne disa disqe. E njejta qe behet edhe kur lexohen disa
rreshta qe plotesojne nje kriter. Nese eshte perdorur hash apo copezim sipas segmenteve,
pyetje mund te pergjigjet duke aksesuar vetem procesoret qe kane rreshtat e duhur.
51
IV.3.2 Renditja
Nje ide e thjeshte eshte te lejohet cdo processor te rendise rreshtat qe ka dhe ne vazhdim te
bashkohen gjithe keto bashkesi rreshtash te renditur per te perftuar rezultatin perfundimtar.
Paralelizimi limitohet nga faza e bashkimit.
Nje ide me e mire eshte rishperndarja e rreshtave duke perdorur copezim sipas segmenteve.
Per shembull, nese duam te rendisim rreshtat qe perfaqesojne punonjesit sipas rrogave, ku
rrogat variojne nga 10 ne 210, dhe kemi 20 CPU, mundemi te dergojme gjithe rreshtat me
rroge 10 deri ne 20 ne procesorin e pare, ata me rroge 21 deri ne 30 ne te dytin e keshtu me
rradhe. Ne vazhdim, cdo processor rendit rreshat e tij sipas nje algoritmi te caktuar, dhe
rezultati perfundimtar mund te perftohet duke “vizituar” gjithe procesoret me rradhe sipas
vlerave te segmenteve qe kane.
IV.3.3 Join
Supozojme se duam te egzekutojme nje join midis dy tabelave A dhe B ne baze te fushes
mosha. Supozojme se fillimisht rreshtat jane copezuar ne nje menyre qe nuk eshte e
pershtatshme per join, pra copecimin nuk eshte bazuar ne fushen mosha. Ideja baze per te
kryer veprimin join midis A-se dhe B-se ne paralel eshte dekompozimi i tij ne nje bashkesi k
join me te vogla. Nese copezojme te dyja tebelat nepermjet hash duke perdorur te njejtin
funksion hash, garantojme se bashkimi i k join-eve me te vogla na jep rezultatin e duhur.
Meqenese tabelat A dhe B jane te copezuara copezimi i ri mund te behet edhe ai ne paralel.
Ne cdo CPU lexohen rreshtat perkates te cilet copezohen sipas funksionit hash, nese kemi ne
dispozicion k CPU atehere copecimi kryhet ne k copa. Me pas secili procesor dergon rreshtat
e copes i tek procesori i ku kryhet edhe veprimi join per keto copa. Pasi gjithe CPU-te kane
perfunduar, rezultatet bashkohen per te dhene rezultatin perfundimtar.
IV.4 Optimizimi i Pyetjeve Paralele
Pervec paralelizimit te veprimeve individuale, mundemi te egzekutojme disa pyetje
paralelisht. Optimizimi i nje pyetjeje te vetme per egzekutim paralel ka terhequr vemendjen e
kerkuesve; zakonisht sistemet optimizojne pyetjet pa marre parasysh pyetjet e tjera qe mund
te egzekutohen ne te njejten kohe.
52
Dy lloje paralelizmi mund te shfrytezohen ne nje pyetje:
Rezultati i nje operatori mund ti kalohet (pipeline) nje operatori tjeter ne momentin e
gjenerimit (pra pa pritur te gjenerohet gjithe rezultati).
Disa operatore te pavarur mund te egzekutohen njekohesisht.
IV.5 Hyrje ne Bazat e Shperndara
Sic permendem me larte, te dhenat ne nje sistem te shperndare ruhen ne disa vende (servera)
te ndryshme, dhe cdo srver menaxhohet nga nje SMBD qe egzekutohet ne menyre te pavarur
nga server-at e tjere. Per sisteme te tilla jane te deshirueshme karakteristikat e meposhtme:
Pavaresi nga shperndarja e te dhenave: Perdoruesit te munden te bejne pyetje pa
pasur nevoje te specifikojne se ku ndodhen te dhenat.
Atomicity i transaksioneve te shperndara: Ose te gjitha ose asnje nga veprimet e
nje transaksioni do te kryhen.
IV.5.5 Tipa Bazash te Dhenash te Shperndara
Nese te dhenat jane te shperndara por gjithe serverat kane te njejtin software per SMBD,
atehete kemi nje sistem te shperndare bazash te dhenash homogjen. Nese setverat e
ndryshem kane SMBD te ndryshme atehere kemi nje sistem te shperndare bazash te
dhenash heterogjen.
Celesei per te ndertuar sisteme heterogjene eshte egzistenca e standarteve te pranuara per
protokolle komunikimi. Keto protokolle ekspozojne funksionalitetet e SMBD ndaj
aplikacioneve te jashtme.
IV.6 Arkitektura te DBMS te Shperndara
Egzistojne tre alternativa per ndarjen e funksionalitetit midis proceseve te SMBD-ve.
53