Sunteți pe pagina 1din 18

TRANZACTII

Obiective
La sfarsitul acestui capitol, veti putea sa:
1. Definiti o tranzactie
2. Folositi declaratii , formulari, instructiuni de genul BEGIN TRAN(inceperii unei
activitati), COMMIT WORK(realizarii unei activitati) si ROLLBACK (revenirii
asupra unei acitvitati,reluarea ei) in cadrul unei tranzactii
Ce este o tranzactie?
Gestiunea tranzactiilor, se refera la capacitatea unui SGBD relational de a efectua
tranzactii intr-o baza de date.
O tranzactie este o multime de instructiuni care se executa in grup. Daca oricare din
instructiune nu poate fi incheiata, toate celelalte actiuni trebuiesc refacute. Tranzactiile
sunt unitati de prelucrare(program) care trebuie efectuate fie in intregime, fie deloc. Prin
unitate de prelucrare intelegem ca o tranzactie are un inceput si un sfarsit.
Prin urmare o tranzactie are intotdeauna un inceput si un sfarsit. Server-ul bazei de date
garanteaza ca operatiile realizate in limitele unei tranzactii vor fi fie complet si perfect
salvate pe disc, sau daca acest lucru nu este posibil, baza de date va reveni in stadiul in
care era inainte ca tranzactia sa fi inceput.
Daca ceva gresit se petrece intimpul unei tranzactii, intreaga unitate de prelucrare
poate fi anulata, dupa dorinta utilizatorului. Daca totul este corect, unitatea de prelucrare
poate fi salvata in intregime in baza de date
O tranzactie bancara
Transferul banilor din contul de economii in contul curent este un bun exmplu de
tranzactie.
Actiuniile implicate in aceasta tranzactie sunt:
Actualizarea contului de economii prin indicarea unei retrageri.
Actualizarea contului curent pentru a pune in evidenta un depozit.
Aceste actiuni trebuiesc amandoua incheiate cu succes inainte ca transferul sa fie
terminat. Daca ceva nu merge,cu oricare dintre cele doua actiuni, tranzactia esueaza. De
exmplu daca ati incercat sa transferati, in contul curent, mai multi bani decat aveti in
contul de economii transferul nu va avea loc si balanta conturilor dumneavoastra va
ramane la fel cum a fost inainte ca dumneavoastra sa incercati sa realizati transferul.

Logarea unei tranzactii


Multe lucruri, ca de exemplu o defectiune software sau hardware, pot duce la
esecul unei tranzactii. Din aceasta cauza server-ul bazei de date terbuie sa aiba o
modalitate de urmarire a modificarilor relizate in timpul tranzactiei. Acest lucru este
posibil prin intermediul logarii unei tranzactii.Server-ul foloseste logarea unei tranzactii
pentru a inregistra fiecare modificare facuta bazei de date in timpul tranzactiei. Daca
tranzactia nu poate fi realizata, server-ul foloseste automat datele din jurnalul( logarea)
tranzactiei pentru a anula modificarile.
Bazele de date nu sunt prevazute cu un sistem de jurnalizare automata a tranzactiilor.
Administartorul bazei de date trebuie sa decida daca realizeaza sau nu o baza de date
prevazuta cu un sistem de logare a tranzactiilor. Daca baza de date nu este prevazuta cu
un sistem de logare tranzactiile nu sunt valabile.
Specificarea unei tranzactii in INFORMIX
Declaratiile, formularile,instructiunile SQL sunt folosite pentru a specifica de
unde si pana unde se intinde o tranzactie. Se foloseste declaratia, instructiunea
BEGIN WORK
pentru a specifica inceperea unei tranzactii cu instructiuni multiple si
COMMIT WORK
pentru a specifica incheierea unei tranzactii. In momentul in care server-ul bazei de date
intalneste instructiunea COMMIT WORK se asigura ca toate modificarile au fost
completate, incheiate corect si salvate pe disc. Daca orice fel de defectiune provenita din
exterior impiedica incheierea tranzactiei, tranzactia partiala va fi reluata in momentul in
care sistemul este repornit.
BEGIN WORK
Update econom
set sold=sold-100
Update cont-curent
set sold=sold+100
COMMIT WORK

Bazele de date ANSI


In bazele de date ANSI , nu este necesara marcarea inceputului unei tranzactii cu
instructiunea BEGIN WORK. O tranzactie este intotdeauna in actiune si este deci
necesara doar indicarea incheierii fiecarei tranzactii cu instructiunea COMMIT WORK.

Reluarea activitatii (ROLLBACK)


In unele cazuri poate veti dori ca programul dvs. sa anuleze o tranzactie, in mod
deliberat, in functie de unele circumstante. Pentru aceasta se foloseste instructiunea
ROLLBACK (reluarea sau revenirea la un anumit punct in cadrul activitatii).
Instructiunea ROLLBACK face ca server-ul bazei de date sa anuleze tranzactia curenta
si sa anuleze si modificarile facute. In exemplul dat in pseudo-cod declaratia
ROLLBACK este executata doar daca @v este setat pe zero inainte ca tranzactia sa fie
realizata.
BEGIN TRANSACTION
Select @v=1
update economii set sold=sold-100
If sold < 0
(este balanta negativa?)
Then
@v=0
else
update cont-curent set sold=sold+100
end
If @v=0 then
ROLLBACK -- una sau mai multe actiuni au esuat
else
COMMIT
-- toate actiunile s-au incheiat cu succes
end
Exercitii propuse pentru laborator
Completati execitiul descris mai jos. Intrebarile(interogarile) ar trebui executate
separat pentru a va permite observarea comportamentului fiecarei interogari.
1. Incepeti o tranzactie.
2. Inserati un nou client numit Albu Ion in tabelul clienti .
3. Selectati toti clientii numiti Albu din tabelul clienti .
Intrebare: A fost inregistrat clientul Fred Flinstone in tabelul clienti?
4. Reluati tranzactia.
5. Selectati toti clientii numiti Fred din tabelul clienti . In ce mod difera SELECT-ul
primei interogari fata de SELECT-ul celei de-a doua interogari.
Nu uitati sa includeti un place holder pentru numarul coloanei clientului in instructiunile
INSERT. De asemenea nu uitati sa separati instructiunile prin intrmediul ;.
Solutii

1. BEGIN TRANSACTION
2. INSERT INTO clienti (customer_nu,fname,lname)
VALUES(0,Fred,Flinstone);
3. SELECT * FROM clienti WHERE fname=Fred
4. ROLLBACK WORK
5. SELECT * FROM clienti WHERE fname=Fred
Primul SELECT returneaza doi clienti inclusiv noul client inserat. Al doilea SELECT
returneaza doar un singur client deoarece instructiunea INSERT a fost reluata.
TRANZACTII (SQL-SERVER)
.

Inceperea unei tranzactii


BEGIN TRAN [ SACTION] [ nume_tranzactie | @tran_nume_variabila
[ WITH MARK [ 'description' ] ] ]
nume_tranzactie Este numele asignat tranzactiei care trebuie sa se conformeze regulilor pentru
identificatori care nu trebuie sa aiba mai mult de 32 de caractere.
@tran_nume_variabila
Este numele unei variabile definite de utilizator ce contine numele unei tranzactii valide. Variabila
trebuie sa fie declarata de tipul char, varchar, nchar, sau nvarchar.
WITH MARK ['description']
Specifica faptul ca tranzactia este marcata in fisierul de log. description este un sir de caractere
care descrie marcarea.
Daca WITH MARK este folosit, numele tranzactiei trebuie sa fie specificat. WITH MARK permite
pentru restaurarea fisierului de log de la numele marcat.
Terminarea unei tranzactii
COMMIT [ TRAN [ SACTION ] [ nume_tranzactie | @tran_nume_variabila]
Comanda COMMIT salveaza toate modificarile efectuate in cursul unei tranzactii. Deseori este
mai bine sa executati o instructiune COMMIT inaite de a incepe o tranzactie noua
Anularea unei tranzactii
ROLLBACK [ TRAN [ SACTION ]
[ nume_tranzactie | @tran_nume_variabila
nume-punct-de salvare | @variabila-punct-de salvare] ]
nume-punct-de salvare
Este numele punctului de salvare pentru un enunt SAVE TRANSACTION.
Folositi nume-punct-de salvare cand o anulare a tranzactiei trebuie sa afecteze doar o parte din
tranzactie.

@variabila-punct-de salvare
Este numele unei variabile definite de utilizator ce contine numele punct de salvare valid.
Variabile trebuie sa fie declarata de tipul char, varchar, nchar, sau nvarchar.
Dupa inceperea unei tranzactii, este efectuata de obicei o procedura de verificare a erorilor
pentru a determina daca tranzactia a fost executata cu succes pana in momentul respectiv.
Instructiunea ROLLBACK readuce tranzactia la forma initiala. Aceasta inseamna ca starea bazei
de date este refacuta in forma care exista inaite de inceperea tranzactiei.
Folosirea punctelor de salvare in tranzactii
SAVE TRAN [ SACTION ] { nume-punct-de salvare | @variabila-punct-de salvare }
Am mentionat ca operatia de readucere a unei tranzactii la punctul de inceput inseamna de fapt
anularea intregii tranzactii. Cu toate acestea, in unele cazuri, ati dori sa executati doar o parte din
tranzactie adica o parte din instructiunile din cadrul tranzactiei. Pentru a realiza acest lucru,
trebuie sa folositi un punct de salvare. Dincolo de acest punct, daca apare o comanda de
revenire, tranzactia este adusa la starea din punctul de salvare. Toate instructiunile care au fost
executate pana in acest punct de salvare sunt salvate.

----------------BEGIN TRANSACTION
INSERT INTO catalog VALUES('222','3',8,'17-06-2005')
COMMIT TRANSACTION
GO
SELECT * FROM Catalog
----------------BEGIN TRANSACTION tran1
INSERT INTO catalog VALUES('222','3',10,'17-06-2005')
COMMIT TRANSACTION tran1
GO
SELECT * FROM Catalog
----------------DECLARE @TranName VARCHAR(20)
SELECT @TranName = 'TransactiaMea'
BEGIN TRANSACTION @TranName
GO
USE dbStud
GO
UPDATE catalog
SET Nota = Nota +1
WHERE NrLeg LIKE '22%'
GO
COMMIT TRANSACTION TransactiaMea
GO
SELECT * FROM Catalog

----------------BEGIN TRANSACTION TranModif


WITH MARK 'Modificarea Valorilor'
GO
USE dbStud
GO
UPDATE Catalog
SET Nota = Nota +2
WHERE NrLeg LIKE '11%'
GO
COMMIT TRANSACTION TranModif
GO
SELECT * FROM Catalog
----------------BEGIN TRANSACTION AddStudNou
INSERT
INTO
Student
VALUES('210','Traian','I','Titi','M','10-091980','N','10303', NULL)
IF EXISTS (SELECT * FROM Student WHERE NrLeg='210')
BEGIN
BEGIN TRANSACTION AddNota
INSERT INTO Catalog VALUES('210', '2',5,'4-9-2001')
INSERT INTO Catalog VALUES('210', '4',7,'12-9-2001')
END
ELSE
ROLLBACK TRANSACTION
COMMIT TRANSACTION
GO
SELECT * FROM Student
GO
SELECT * FROM Catalog
----------------BEGIN TRANSACTION Tran1
UPDATE Student
SET NrLeg_sot = '104'
WHERE NrLeg = '210'
UPDATE Student
SET NrLeg_sot = '210'
WHERE NrLeg = '104'
SAVE TRANSACTION savepoint1
UPDATE Catalog
SET nota = Nota +1
WHERE NrLeg='210'
SELECT s.NrLeg, Nume, Prenume, Nota, Cod_materie, NrLeg_sot
FROM Student s, Catalog n
WHERE s.NrLeg=n.NrLeg
ROLLBACK TRANSACTION savepoint1
COMMIT TRANSACTION

CAPITOLUL 10
CONTROLUL CONCURENTEI
Obiective
La sfarsitul acestui capitol, veti putea sa:
1. Descrieti tipurile de control al concurentelor in bazele de date Informix
2. Descrieti cele patru niveluri de izolare, separare pentru citirea datelor in bazele de
date IDS
3. Descrieti cele patru trepte de blocare(sau inchidere, fixare) a granularitatii

Tipuri de concurente
Controlul concurentelor influenteaza modul in care datele pot fi vizualizate si actualizate
de catre utilizatori accesand aceeasi informatie la un moment dat. De exmplu, doriti ca un
utilizator sa vizualizeze o comanda ce este modificata de catre un alt utilizator? Doriti ca
un utilizator sa modifice o comanda care este vizualizata de catre un alt utilizator ?
Exista doua tipuri de control al concurentelor:
Primul tip de concurenta este cel care se aplica bazelor de date cu accesul readonly si este SELECT. Acesta este referit ca un nivel de izolare(separare). Exista 4
niveluri de izolare(separare).
Cel de-al doilea tip de concurenta este cel care se aplica inregistrarilor actualizate
ale bazelor de date si avem: INSERT, DELETE si UPDATE.
Sigurante(sau lacate sau inchizatori)
Informix impune, constrange controlul concurentelor folosind sigurante(sau lacate sau
inchizatori). Exista 3 tipuri de sigurante care pot fi folosite:
Exclusive lock: nici o alta siguranta nu poate fi fixata unei date ce contine o
siguranta exclusiva (exclusive lock).
Shared lock: sunt palsate de procesele de citire a datelor . O siguranta shared nu
poate fi pusa unei date ce are deja o siguranta exclusiva. Unei date i se poate atasa
una sau mai multe sigurante shared.
Update lock: este asemanatoare cu o siguranta shared exceptand faptul ca nu
poate fi avansata, mai tarziu, ca siguranta exclusiva .
Citirea concurentelor: cele 4 niveluri de izolare( separare)

Nivelurile de separare pentru citire sunt:


Dirty read (Citire Dirty(elementara))
Commited read (Citire realizata)
Cursor stability (Stabilitatea cursorului)
Repetable read (Citire repetabila )
Informix Dynamic Server asigura 4 niveluri de separare pentru citire. (Bazele de date
Informix-SE pot folosi doar Citirea Dirty) .
Penru a furniza aceste niveluri, Informix Dynamic Server foloseste sigurante shared.
Sigurantele shared permit celorlalte procese sa citeasca linii insa fara a permite
actualizarea lor. Aceste niveluri de separare sunt descrise detaliat in paginile urmatoare.
Citirile Dirty(Dirty Reads)
La nivelul de separare al Citirii Dirty procesul nu este separat, izolat deloc. Nu exista nici
un fel sigurante si procesul nu verifica existenta sigurantelor, de orice tip, inainte de a citi
o linie. In timpul refacerii, remedierii putem vedea orice linie, chiar si pe cele ce contin
modificari neefectuate. Asemenea linii sunt referite ca dirty data (date dirty).
Liniile ce contin dirty data pot fi linii fantoma. O linie fantoma este o linie care a fost
inserata intr-o tranzactie, care mai tarziu a fost reluata(asupra careia s-a revenit) inainte
ca tranzactia sa se incheie, sa fie completa. Desi randul fantoma nu a existat in
adevaratul sens al cuvantului, ar fi putut fi vizualizat de un proces folosind un nivel de
separare Dirty Read.
Citirile Dirty(Dirty Reads) pot fi totusi folositoare atunci cand:
Tabelul este static.
Acuratetea, precizia 100% nu este la fel de importanta ca viteza si
independenta,libertatea din controversa (intrecere).
Nu puteti astepata pana in momentul in care sigurantele sunt eliberate.
Citirile Realizate(Commited Reads)
O citire realizata (Commited Read) incearca sa dobandesca o siguranta shared pe o linie
inainte de a o citi. De fapt nu incerca sa plaseze, sa puna o siguranta, mai de graba
incearca sa dobandesca siguranta. Daca acest lucru este posibil existenta liniei este
garantata si de asemeanea este garantat faptul ca acea linie nu este reactualizata de un alt
proces in timp ce este citita. De retinut - o siguranta shared nu poate fi dobandita de o
linie care este inchisa exclusiv, acesta fiind intotdeauna cazul in care o linie este
actualizata.
Cu o citire realizata(Commited Read) avem o izolare de nivel redus. In timpul refacerii,
remedierii nu ne putem uita la linii fantoma sau date dirty (dirty data). Se stie ca linia
curenta a fost realizata(cel putin in momentul in care procesul respectiv citeste acea
linie). Dupa ce procesul respectiv a citit linia alte procese o pot schimba.
Citirile realizate(Commited Reads) pot fi folositoare pentru:
Verificari
Interogari
9

Rapoarte continand informatii generale


De exmplu Commited Reads sunt folositoare pentru rapoarte de tip sumar de genul
analizelor unor vanzari la sfarsitul lunii.
Stabilitatea Cursorului (Cursor Stability)
Cu scopul de a aduce(FETCH) liniile bazei de date intr-o aplicatie linie cu linie, trebuie
folosit un cursor sau un pointer . Cand cursoarele sunt folosite un nivel de izolare
aditional este disponibil Cursor Stability(Stabilitatea Cursorului).
Cu satabilitatea cursor-ului(Cursor Stability) o siguranta shared este dobandita, pe fiecare
rand, in timp ce este citita via cursor. Aceasta siguranta shared este retinuta pana cand
urmatoarea linie este redobandita, refacuta. Daca datele sunt redobandite folosind
cursor-ul, siguranta shared este retinuta pana cand urmatorul FETCH este executat.
La acest nivel putem nu numai sa vizualizam liniile realizate dar si sa fim siguri ca liniile
isi vor continua existenta in timp ce sunt vizualizate. Nici un proces nu poate
modifica(Update(actualiza) sau Delete(sterge)) acea linie in timp ce este vizualizata.
SELECT-urile ce folosesc nivelul de izolare al stabilitatii cursorului(cursor stability) pot
fi folosite pentru:
Verificari
Interogari
Rapoarte continand date operationale
De exmplu SELECT-urile ce folosesc stabilitatea cursorului(cursor stability) sunt
folositoare pentru rapoartele gen detaliu precum cotarea preturilor sau a sistemelor de
urmarire, monitorizare a locurilor de munca.
Daca nivelul de izolare al stabilitatii cursorului(cursor stability) este setat si nu este
folosit un cursor, Cursor Stability se comporta la fel ca si Commited Read(siguranta
shared nu este de fapt niciodata plasata, pusa).
Citiri repetabile (Repeatable Reads)
Nivelul de separare al citirilor repetabile(Repetable Reads) plaseaza o siguranta shared
tuturor randurilor examinate de sever-ul bazei de date; toate aceste sigurante sunt retinute
pana cand tranzactia este realizata. Prin intermediul citirilor repetabile avem un nivel
ridicat de izolare, separare. In tranzactiile explicite suntem asigurati ca linia isi va
continua existenta nu doar in timp ce aceasta este vizualizata dar de asemenea atunci cand
aceasta este recitita dupa un anumit timp. Nici un alt proces nu poate modifica
(Update(actualiza) sau Delete(sterge)) linia pana in momentul in care tranzactia nu a fost
realizata(Commit). Citirile repetabile(Repetable Reads) sunt folositoare cand citirea
tuturor liniilor trebuie tratata ca o unitate sau cand trebuie sa se garanteze ca o anumita
valoare nu se va schimba. De exmplu:
aritmetica critica,totala(de exmplu echilibrarea conturilor)
verificari coordonte din cateva tabele(de exmplu sistemele de rezervare).
Este important sa retinem ca prin intermediul citirilor repetabile(Repetable Reads) toate
liniile examinate sunt blocate(inchise). Aceasta include si linii care nu satisfac un criteriu

10

de selectie dar care au trebuit citite pentru a le determina neeligibilitatea, nepotrivirea. De


exemplu daca folositi separarea, izolarea citirilor repetabile(Repetable Reads) pe o
interogare ce prsupune citirea secventiala a tabelului(daca de exmplu nici un indice nu
este disponibil) toate liniile din tabel sunt blocate, si acele sigurante sunt retinute pe tot
parcursul desfasurarii tranzactiei. Aditional pentru a ne asigura de integriatea multimii de
date (adica de a ne asigura ca noile linii, care satisfac criteriul, nu sunt adaugate) cheile
index corespunzatoare sunt de asemenea blocate. Folositi doar nivelul de izolare a
citirilor repetabile (Repetable Reads) asupra interogarilor care pot realiza citiri indexate.
Setarea nivelului de izolare
Exmple:
SET ISOLATION TO DIRTY READ;
SET ISOLSTION TO COMMITED READ;
SET ISOLATION TO CURSOR STABILITY;
SET ISOLATION TO REPEATABLE READ;
Pentru a face folositor procesul de separare(izolare) baza de date trebuie sa foloseasca
sistemul de logare. Pentru a alege un nivel de izolare se foloseste decalratia SET
ISOLATION. Sintaxa acestei instructiuni este prezentata in exemplul de mai sus.
Daca sistemul de logare nu este activat toate citirile sunt Citiri Dirty(Dirty Reads) si
nivelul izolare nu poate fi setat.
Bazele de date INFORMIX-SE pot folosi doar Citirile Dirty(Dirty Read).
Fiecare proces al server-ului bazei de date isi poate seta propriul nivel de izolare.
Setarea unei tranzactii
SET TRANSACTION

SET ISOLATION

Read Uncommited
Read Commited
Not Supported
(ANSI)Repeatable Read
Serializable

Dirty Read
Commited Read
Cursor Stability
(Informix)Repeatable Read
(Informix)Repeatable Read

Instructiunea SET TRANSACTION este in acord cu ANSI SQL-92. Aceasta instructiune


este similara instructiunii SET ISOLATION din Informix; oricum instructiunea SET
ISOLATION nu este in conformitate cu ANSI si nu furnizeaza moduri, procedee de
acces.
Nivelurile de izolare care pot fi setate cu instructiunea SET TRANSACTION sunt
aproape paralele cu nivelurile de separare(izolare) setate cu instructiunea SET
ISOLATION (vezi tabelul de mai sus).

11

O alta deosebire intre instructiunile SET TRANSACTION si SET ISOLATION este


comportamentul nivelurilor de izolare(separare) in interiorul tranzactiilor. Cu ajutorul
instructiunii SET ISOLATION, dupa ce o tranzactie a fost inceputa, se poate modifica
nivelul de izolare(separare) de mai multe ori, nu numai o data intr-o tranzactie.
Nivelurile de Izolare Default
Informix
DIRTY READ
(Citire Dirty)

ANSI
READ UNCOMMITED
( Nerealizarea citirilor)

Descriere
Nivelul default de izolare al
unei baze de date fara a fi
inregistrata.
COMMITED READ
READ COMMITED
Nivelul default de izolare al
(Citire Realizata)
(Realizarea Citirilor)
unei
baze
de
date
inregistrata fara a fi insa in
conformitate cu ANSI.
REPEATABLE READ
SERIALIZABLE
Nivelul default de izolare al
(Citire repetabila)
(Transmitere in serie)
unei baze de date in
conformitate cu ANSI.
Nivelul default de izolare pentru o baza de date particulara este stabilit in momentul in
care baza de date este creata. Nivelul default de izolare pentru fiecare tip de baza de date
este descris in tabelul de mai sus.
Gradul de tolerabilitate a inferentelor
Nivelul de izolare(separare)
DIRTY READ (Citire Dirty) sau READ
UNCOMMITED( Nerealizarea Citirilor)
COMMITED READ (Citire Realizata) sau
READ COMMITED(Realizarea Citirilor)
CURSOR
STABILITY(Stabilitatea
Cursorului)
(ANSI)Repeatable Reads(Citiri Repetabile)
sau Serializable (Transmitere in serie)

Descriere
Permite procesului sa vizualizeze datele
dirty.
Nu permite procesului sa vizualizeze datele
dirty.
Nu le este permis altor procese sa-mi
modifice linia curenta.
Nu le este permis altor procese sa-mi
modifice nici una din liniile blocate pana
cand nu am incheiat .

Pentru a face un sumar tabelul de mai sus expune nivelurile de izolare(separare) la


gradele de tolerabilitate a inferentelor.
Actualizarea Concurentelor- Blocarea(sau Inchiderea, Fixarea) Granularitatii
Nivele de blocare(sau inchidere, fixare) a granularitatii:
Nivelul bazei de date
Nivelul tabelului
Nivelul paginii
Nivelul liniei
Nivelul unei chei
12

Blocarea(sau inchiderea, fixarea) granularitatii se refera la marimea obiectului care este


blocat (sau inchis, fixat). Granularitatea strabate cinci niveluri de la macrogranulat (sau
brut, neprelucrat) pana la microgranulat(sau fin,precis, bine prelucrat). Aceasta ne
permite realizarea fie a concurentei si blocarii(sau inchiderii, fixarii) superioare fie doar
a uneia dintre ele.
Informix Dynamic Server asigura 5 niveluri diferite de blocare(sau inchidere, fixare) a
granularitatii. Nivelul inferior este nivelul inchiderii,fixarii bazei de date; nivelul superior
este nivelul inchiderii,fixarii liniei. Nivelul inchiderii,fixarii la nivel de cheie se relizeaza
la indexarea intrarilor.
Nivelul de blocare(sau inchidere,fixare) al bazei de date
Uneori este necesar sau avantajos sa prevenim accesul altor utilizatori la unele parti
componente ale bazei de date pentru o perioada de timp. Acest lucru ar trebui realizat
atunci cand:
Executati un numar mare de actualizari folosind un numar mare de tabele.
Arhivati fisierele bazei de date pentru backup.
Modificarea structurii bazei de date.
Intreaga baza de date poate fi blocata(inchisa) folosind instructiunea DATABASE cu
optiunea EXCLUSIVE. Optiunea EXCLUSIVE deschide baza de date intr-un mod
exclusiv si permite accesul la baza de date doar utilizatorului curent.
Pentru a permite si accesul altor utilizatori la baza de date trebuie executata instructiunea
CLOSE DATABASE (inchidere baza de date) si apoi trebuie redeschisa baza de date.
Utilizatorii care au un nivel oarecare de permisie asupra bazei de date pot deschide baza
de date in modul exclusiv. Actionand astfel nu vor avea un nivel de acces mai rdicat decat
au in mod obisnuit.
Nivelul de blocare(sau inchidere,fixare) la nivel de tabel
Inchiderea, fixarea la nivel de tabel poate fi folosita pentru a preveni modificarea bazei de
date de catre alti utilizatori. Folositi inchiderea,fixarea la nivel de tabel pentru:
Evitarea conflictului cu ceilalti utilizatori in timpul seriei de operatii ce afecteaza
majoritatea liniilor unui tabel.
Evitarea lipsei de sigurante in momentul rularii unei operatii ca o tranzactie.
(Aceasta chestiune este lamurita in paginile urmatoare ale capitolului).
Prevenirea acualizarii tabelului de catre utilizatori pe o anumita perioada de timp.
Prevenirea accesului la un tabel in timp ce ii este modificata structura sau sunt
creeati indici.
Blocarea(inchiderea, fixarea) la nivel de tabel ar trebui folosita doar atunci cand se fac
modificari majore asupra unei baze de date intr-un mediu multi-utilizator, si cand
intreractiuni simultane ale unui alt utilizator vor interveni.

13

Doar o singura siguranta poate fi aplicata unei baze de date la un anumit timp asta in
conditiile in care utilizatorul blocheaza(inchide) un tabel, nici un alt utilizator nu mai
poate bloca tabelul pana in momentul in care primul utilizator il deblocheaza.
Tabelele catalog-system nu pot fi blocate(inchise).
Daca baza de date contine tranzactii tabelele pot fi blocate doar in interiorul tranzactiilor.
De aceea fiti siguri ca ati executat BEGIN WORK( cu exceptia folosirii bazei de date in
modul ANSI) inainte de a incerca sa blocati un tabel. Tabelul va fi deblocat cand
tranzactia este incheiata.
Blocarea(sau inchidere sau fixare) unui tabel in SHARE MODE
Daca doriti sa acordati celorlalti utilizatori acces la citirea tabelului dar sa preveniti
modificarea oricarei date continute de acesta atunci ar trebui sa folositi instructiunea
LOCK TABLE cu optiunea IN SHARE MODE.
Cand un tabel este blocat in SHARE MODE alti utilizatori pot selecta date din tabel dar
nu pot(nu le este permis) sa insereze, stearga sau actualizeze(INSERT, DELETE,
UPDATE) linii dintr-un tabel sau sa modifice(ALTER) un tabel.
Ar trebui retinut ca blocarea unui tabel in SHARE MODE nu previne sigurantele liniilor
de a fi amplasate(pozitionate) astfel incat permit actualizarea de catre procesul dvs. .
Daca doriti sa evitati sigurantele exclusive ale liniilor in completarea sigurantelor share
ale unui tabel, trebuie sa blocati(inchideti) tabelul in modul exclusiv(EXCLUSIVE
MODE).
Blocarea unui tabel in modul exclusiv(EXCLUSIVE MODE)
Dca doriti sa impiedicati accesul utilizatorilor la tabel atunci ar trebui sa-l blocati cu
modul exclusiv( EXCLUSIVE MODE).
In modul exclusiv(EXCLUSIVE MODE) alti utilizatori nu vor putea sa selectze(doar
daca este folosita izolarea dirty read), insereze, stearga sau actualizeze(SELECT,
INSERT,DELETE , UPDATE) linii in tabel pana in momentul in care nu deblocati
tabelul.
Doar o siguranta este folosita pentru a bloca tabelul, in ceea ce priveste numarul de linii
care sunt actualizate in interiorul unei tranzctii.
Tabele ce contin BLOBs intr-un blobspace
Daca un tabel este blocat cu modul exclusiv (EXCLUSIVE MODE) si sunt facute
modificari valorilor BLOB asociate, fiecare BLOB accesat obtine siguranta exclusiva
proprie. Aceste sigurante sunt amplasate si eliberate automat. Pentru un blobpage sunt
folosite doua sigurante. Tabelele ce contin BLOB-uri localizate in tabel nu obtin sigurante
aditionale.
Deblocarea unui tabel

14

Instructiunea UNLOCK TABLE (Deblocare Tabel) restabileste accesul la tabelul bazei de


date anterior blocat. Folositi aceasta instructiune cand nu mai este necesara prevenirea
accesului si modificarii tabelului de catre alti utilizatori.
Daca intr-o tranzactie tabelul a fost blocat UNLOCK TABLE este nepermisa si astfel se
genereaza o eroare. Incheierea tranzactiei (via COMMIT sau ROLLBACK) va debloca
tabelul.
Setarea modului de blocare(LOCK MODE)
SET LOCK MODE TO WAIT Asteptare continua a deblocarii
(Modul de blocare este setat sa astepte)
SET LOCK MODE TO NOT WAIT Nu se asteapta deblocarea sigurantei
(Modul de blocare este setat sa nu astepte)
SET LOCK MODE TO WAIT 20 Se asteapta 20 de secunde pentru deblocarea
(Modul de blocare este setat sa astepte)
Instructiunea SET LOCK MODE este folosita pentru a determina daca apelurile ce
modifica sau sterg o linie asteapta ca o linie sa fie deblocata.
Optiunea TO NOT WAIT(a nu se astepta) cauzeaza returnarea unei erori daca o
instructiune incearaca sa modifice sau sa stearga o linie( sau sa selecteze o linie pentru
actualizare) pe care un alt proces a blocat-o. Acesta este modul default(DEFAULT
MODE).
Optiunea TO WAIT(de asteptare) face ca o instructiune sa astepte la o incercare de a
modifica sau sterge o linie care a fost blocata de un alt proces pana cand linia blocata se
deblocheaza. Optional se poate specifica numarul de secunde destinat asteptarii.
Blocare la nivel pagina si linie

Determinat la timpul de creeare al tabelului


Blocarea paginii(PAGE LOCKING) blocheaza intreaga pagina de date
Blocarea liniei(ROW LOCKING) blocheaza doar randul
Trade-off-urile concurentelor/resurselor

Cand creeati un tabel alegeti modul de blocare folosit in momentul accesarii oricarei linii
din tabel. Nivelul de blocare de pagina cauzeaza blocarea intregii pagini de date oricand
o singura linie localizata in acea pagina trebuie sa fie blocata. Nivelul de blocare de linie
cauzeaza doar blocarea liniei respective.Modul default de blocare atunci cand se creeaza
un tabel este page level (nivelul pagina).
Sigurantele paginii sunt folositoare atunci cand, intr-o tranzactie, procesul trece in aceeasi
ordine ca si multimea indexata a tabelului sau procesul trece intr-o ordine fizica
secventiala.
Sigurantele liniei sunt folositoare atunci cand, intr-o tranzactie, procesul trece intr-o
ordine arbitrara.

15

Cand numarul liniilor blocate este mare putem intalni urmatoarele riscuri:
Numarul permis de sigurante este epuizat
Superioritatea management-ului sigurantelor devine significanta
Exista un trade-off intre aceste doua niveluri de blocare. Page level (nivelul pagina) are
nevoie de mai putine resurse decat blocarea la nivel de rand (row level) dar de asemenea
reduce concurenta. Daca o pagina blocata este amplasata intr-o pagina ce contine multe
linii, altor procese ce necesita alte date din aceeasi pagina li se poate nega accesul la acele
date.
Accesul la sigurante:nivelul linie/pagina
A(contine sigurantele)
B(solicitat)
x=exclusiv
u=actualizare
s=shared

X
U
S

X
n
n
n

U
n
n
y

S
n
y
y

vid
y
y
y

Harta de mai sus pune in evidenta interactiunea dintre sigurantele detinute si cele
solicitate de doua procese diferite in cadrul aceleiasi resurse a nivelului linie/pagina.
Pe axa orizontala se afla sigurantele care ar putea fi detinute de procesul A. Pe axa
verticala se afla sigurantele solicitate de procesul B. Matricea arata rezultatul sigurantei
solicitate(y=siguranta admisa, n=siguranta refuzata).
Detectarea impasurilor(DEADLOCK)

16

Procesul A
Detine o siguranta pe linia x
Doreste o siguranta pe linia y
A

Procesul B
Doreste o siguranta pe linia x
Detine o siguranta pe linia y
B

Cand mai multe procese acceseaza aceleasi linii dintr-un tabel exista posibilitatea
aparitiei unui impas.
In exemplul de mai sus procesul A detine o siguranta pe linia x. Procesul A vrea sa obtina
o siguranta pe o a doua linie, linia y. Linia y este blocata curent de un alt utilizator
procesul B. Daca procesul A asteapta sigurante(folosind modul SET LOCK TO WAIT)
atunci va astepta ca procesul B sa elibereze siguranta de pe linia y. Procesul B intre timp
detine siguranta pe linia y si vrea sa obtina o siguranta pe linia x. Linia y este blocata de
un alt utilizator si daca procesul B asteapta sigurante va astepta linia x sa fie libera.
Altfel spus A asteapta B si B asteapta A. aceasta este o situatie de impas amandoua
procesele asteptand la nesfarsit. Aceasta situatie poate sa apara de asemenea in cazul unui
numar mai mare de utilizatori.

Detectarea impasurilor
Impasurile reprezinta probeleme serioase deoarece ele pot opri cea mai mare parte a
activitatii intr-un sistem al bazei de date. Informix are un mecanism incorporat care
detecteaza aceste impasuri si preintampina aparitia lor.
Server-ul bazei de date pastreaza pe sistem o lista de sigurante pentru fiecare utilizator.
Inainte ca o siguranta sa fie admisa este verificata lista de sigurante pentru fiecare
utilizator este examinata. Daca o siguranta este retinuta de o resursa pe care procesul
doreste sa o blocheze, posesorul acelei sigurante este identificat si lista de sigurante este
traversata penru a se observa daca se gasesc asteptari ale oricaror sigurante retinute de
utilizatorul care doreste noua siguranta. Daca exista, impasul este detectat la acest pas si
utilizatorului care doreste siguranta ii este transmis un mesaj de eroare.

17

Codul de eroare ISAM trnsmis este: -143 ISAM error: deadlock detected.

18

S-ar putea să vă placă și