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