Sunteți pe pagina 1din 21

Cap.

6 GESTIUNEA TRANZACIILOR Conceptul de gestiune a tranzaciilor se refer la problematica meninerii ntr-o stare consistent a bazei de date n condiiile n care accesul la date se face ntr-un regim concurent i este posibil apariia unor defecte. n consecin se disting dou domenii de sine stttoare n cadrul problematicii generale a gestiunii tranzaciilor : Controlul concurenei Se ocup cu mecanismele de sincronizare a acceselor astfel nct s fie meninut integritatea bazei de date. Atunci cnd controlul concurenei este realizat prin mecanismele de blocare (care la ora actual sunt cele mai rspndite) mai apare o problem, colateral, i anume aceea a interblocrilor. Datorit importanei sale problema gestiuni interblocrilor este de multe ori tratat ca o problematic de sine stttoare a gestiunii tranzaciilor. Rezistena la defecte Se refer la tehnicile prin care se asigur att tolerana sistemului fa de apariia unor defecte, ct i capacitatea de recuperare a acestuia, adic posibilitatea de revenire la o stare consistent n urma apariiei unui defect care a cauzat intrarea lui ntr-o stare inconsistent. 6.1 Definiia conceptului de tranzacie Prin controlul concurenei i rezistena la defecte se urmrete asigurarea consistenei i siguranei bazei de date. O baz de date este ntr-o stare consistent dac respect toate constrngerile de integritate a datelor definite asupra sa. n timpul operaiilor de adugare, tergere i modificare, baza de date trece dintr-o stare n alta. Evident, starea rezultat dup orice prelucrare asupra bazei de date trebuie s fie o stare consistent, chiar dac n timpul prelucrrii baza de date s-a aflat temporar ntr-o stare inconsistent. Sigurana bazei de date se refer la tolerana acesteia fa de defecte i la capacitatea de recuperare dup apariia unui defect. O tranzacie este o unitate logic de prelucrare care asigur consistena i sigurana bazei de date. n principiu, orice execuie a unui program se poate considera o tranzacie dac baza de date este ntr-o stare consistent att nainte ct i dup execuia sa. Consistena bazei de date este garant independent de faptul c : 1. tranzacia a fost executat n mod concurent cu alte tranzacii ; 2. au aprut defecte n timpul execuiei tranzaciei. n general, o tranzacie const dintr-o secven de operaii de citire i scriere a bazei de date, la care se adaug o serie de operaii de calcul. Baza de date poate fi ntr-o stare temporar inconsistent n timpul executrii tranzaciei dar trebuie s fie n stri consistente att nainte ct i dup execuia acesteia. Tranzaciile ar trebui s conin doar acele comenzi DML care realizeaz o singur modificare asupra datelor. De exemplu un transfer de fonduri (s spunem 1000$) ntre dou conturi ar trebui s implice un debit al unui cont de 1000$ i un credit al altui cont de 1000$. Ambele aciuni ar trebui s se ncheie cu succes sau s dea eroare mpreun. Creditul nu ar trebui executat fr debit.

Condiii de terminare a tranzaciilor O tranzacie nu se termin ntotdeauna cu succes totui orice tranzacie trebuie s se termine, indiferent de situaia existent (chiar i n cazul unor defecte). Dac tranzacia reuete s execute cu succes toate operaiile prevzute, atunci aceasta se va termina printr-o operaie de validare (commit). n schimb, dac dintr-un motiv sau altul tranzacia nu reuete s-i execute complet operaiile prevzute, atunci se va termina printr-o operaie de abortare (abort sau rollback). Motivele pentru care o tranzacie se aborteaz sunt numeroae, ele pot fi interne tranzaciei sau externe acesteia (ex. : detectarea de ctre SGBD a unei situaii de interblocare). n cazul abortrii, execuia tranzaciei este oprit iar efectele tuturor operaiilor pe care le-a executat pn n acel moment sunt anulate astfel nct baza de date revine la starea de dinaintea lansrii tranzaciei. Comanda de validare a unei tranzacii are dublu rol : indic SGBD-ului momentul de la care efectele tranzaciei pot fi reflectate n baza de date i devin vizibile altor tranzacii ; marcheaz momentul ncepnd de la care efectele tranzaciei nu mai pot fi anulate (tranzacia nu se mai poate aborta) i modificrile efectuate n baza de dte devin permanente. Operaia de validare este vital n cazul sistemelor concurente, deci acolo unde este posibil executarea n acelai timp a mai multor tranzacii care acceseaz aceeai baz de date. Prin validare se pot preveni o serie de fenomene nedorite cum este abortarea n cascad a tranzaciilor. S presupunem c o tranzacie T este abortat dup ce a efectuat una sau mai multe operaii de actualizare a bazei de date. n acest caz datele alterate de ctre tranzacia T vor fi readuse la valorile pe care le-au avut nainte de a fi modificate de aceasta. Este ns posibil ca unele dintre tranzaciile executate n mod concurent cu tranzacia T s fi accesat aceste date nainte de abortarea lui T. Aceste tranzacii vor trebui s fie, la rndul lor, abortate deoarece au avut acces la date inconsistente din baza de date iar rezultatele produse de ele pot fi compromise. Acest efect se poate propaga n continuare i asupra altor tranzacii, pe un numr nedefinit de nivele, conducnd la abortarea n cascad a tranzaciilor. Fenomenul este cunoscut n literatura de specialitate sub numele de efect domino. Dac se folosete un mecanism de validare care respect cele dou reguli de mai sus, atunci apariia fenomenului de abortare n cascad devine imposibil. ntr-adevr, conform primei reguli, nici o tranzacie nu va putea accesa datele modificate de tranzacia T dect dup validarea acesteia. Pe de alt parte, conform regulii a doua, dup validarea sa, tranzacia T nu mai poate fi abortat, deci nu poate declana un lan de abortri n cascad. Validarea unei tranzacii marcheaz, din punct de vedere logic, terminarea acesteia. Validarea nu se poate face nainte ca operaiile specificate prin codul tranzaciei s fie executate integral i nainte ca tranzacia s ajung ntr-o stare ncepnd de la care exist certitudinea c nu mai poate fi abortat. Pn n momentul validrii, actualizrile efectuate de tranzacie sunt invizibile alror tranzacii, au caracter tentativ i pot fi oricnd revocate (odat cu abortarea tranzaciei).

Dup validare actualizrile se nscriu cu caracter permanent n baza de date i devin irevocabile. Dup validare nu maie ste posibil abortatrea tranzaciilor. Proprietile tranzaciilor Prin definie, tranzaciile sunt uniti de execuie care garanteaz consistena i sigurana bazei de date. Pentru aceasta orice tranzacie trebuie s satisfac un set de patru condiii sintetizate n literatura de specialitate prin acronimul ACID atomicitate, consisten, izolare, durabilitate. Atomicitatea Se refer la faptul c o tranzacie este considerat o unitate elementar de prelucrare. Aceasta nseamn c execuia unei tranzacii se face dup regula totul sau nimic , adic ori sunt executate toate operaiile din tranzacie ori nu se execut nimic. Dac o tranzacie este ntrerupt datorit unor cauze oarecare, atunci i revine SGBD-ului sarcina de a asigura, ntr-un fel sau altul, terminarea tranzaciei. Dup eliminarea cauzei care a dus la ntreruperea tranzaciei, n funcie de stadiul de execuie n care s-a aflat aceasta n momentul apariiei ntreruperii, SGBD-ul poate proceda ntr-unul dintre modurile urmtoare : fie completeaz operaiile rmase neexecutate din cadrul tranzaciei, terminnd tranzacia cu succes fie anuleaz toate efectele operaiilor executate pn n momentul ntreruperii, terminnd tranzacia prin abortare. Consistena Consistena unei tranzacii const pur i simplu n corectitudinea ei. Orice tranzacie, dac este executat independent, trebuie s menin consistena bazei de date. Altfel spus, o tranzacie este un program corect care transform baza de date dintr-o stare consistent ntr-o alt stare consistent a sa. Prin consistena bazei de date nelegem satisfacerea tuturor constrngerilor de integritate, explicite sau implicite, cum ar fi : unicitatea cheilor primare ; integritatea referenial ; orice predicat exprimat n sens de constrngere de integritate asupra bazei de date. Bineneles c este de neconceput verificarea tuturor acestor condiii dup executarea fiecrei tranzacii. De aceea unicul criteriu pentru stabilirea proprietii de consisten a unei tranzacii rmne corectitudinea sa din punct de vedere logic. Spre deosebire de celelalte proprieti din complexul ACID, care sunt asigurate de ctre sistem, proprietatea de consisten a tranzaciei cade n sarcina programatorului de aplicaii. De remarcat faprul c strile intermediare prin care trece baza de date n timpul execuiei unei tranzacii nu sunt neaprat consistente. Izolarea

Se refer la proprietatea oricrei tranzacii de a avea acces doar la strile consistente ale bazei de date. Aceasta nseamn c modificrile efectuate de ctre o tranzacie sunt inaccesible altor tranzacii concurente pn n momentul validrii acesteia. Prin proprietatea de izolare se creeaz iluzia c fiecare tranzacie este executat singur n sistem. Utilizatorul care a lansat o tranzacie nu va percepe n nicu un fel (cel puin n ceea ce privete rezultatele) faptul c alte tranzacii sunt executate n acelai timp. Izolarea tranzaciilor este asigurat prin algoritmi de control al concurenei. Proprietatea de izolare este important deoarece elimin fenomenul de abortare n cascad a tranzaciilor (efect domino). ntr-adevr dac rezultatele incomplete ale unei tranzacii ar fi vizibile altor tranzacii nainte de validarea acesteia i dac se ntmpl ca aceast tranzacie s aborteze, atunci toate tranzaciile care au accesat rezultatele incomplete vor trebui abortate. Aceasta poate conduce la abortarea altor tranzacii .a.m.d. rezultnd efectul domino. Durabilitatea Durabilitatea unei tranzacii este proprietatea prin care se garanteaz faprul c, odat tranzacia validat, rezultatele sale devin permanente i sunt nscrise n baza de date. Chiar dac dup momentul validrii apare un defect care mpiedic nscrierea normal a rezultatelor tranzaciei n baza de date, acestea vor fi trecute n baza de date dup reluarea activitii. Rezultatele tranzaciilor validate vor supravieui oricrei cderi de sistem. Mecanismul prin care re realizeaz proprietatea de durabilitate are la baz conceptul de jurnal. Jurnalul este un fiier secvenial n care sunt nregistrate toate operaiile efectuate de tranzaciile din sistem. Jurnalul conine istoria evoluiei ntegului sistem. El este folosit la reluarea activitii de ctre procedurile de recuperare care vor completa eventualele operaii neterminate ale tranzaciilor care au fost validate nainte de apariia defectului. Controlul tranzaciilor cu instruciuni SQL Exist dou clase de tranzacii. Tranzacii DML - care conin un numr oarecare de blocuri DML i pe care ORACLE le trateaz ca o singur entitate sau o singur unitate logic de lucru, i tranzactii DDL care conin un singur bloc DDL. O tranzacie nou este lansat fie imediat dup conectarea la serverul de baze de date (de exemplu, printr-o sesiune SQL*Plus) fie dup o comand care a ncheiat tranzacia precedent (execuia unui COMMIT sau ROLLBACK), cnd este ntlnit primul bloc executabil DML sau DDL. O tranzacie se termin n una din urmtoarele situaii : * ntlnirea comenzior COMMIT/ROLLBACK * Sfritul comenzii DDL * Apariia anumitor erori (DEADLOCK) * ntlnirea comenzii EXIT - iesire din SQL*Plus * Apariia unei erori de sistem

Un bloc DDL este executat automat i de aceea implicit ncheie o tranzacie. Dup ncheierea unei tranzacii, urmtorul bloc executabil SQL va lansa automat urmtoarea tranzacie. Erorile de Sistem Cnd o tranzacie este ntrerupt de o eroare serioas, de exemplu o eroare de sistem, ntreaga tranzacie este anulat. Aceasta previne erorile datorate modificrilor nedorite asupra datelor, i realizeaz ntoarcerea tabelelor la strile de dup ultimul COMMIT. n acest fel SQL protejeaz integritatea tabelelor. Anularea automata este cauzat cel mai des de ctre o eroare de sistem, ca de exemplu o resetare a sistemului sau o cdere de tensiune. Erorile de tastare a comenzilor, ca de exemplu tastarea gresit a unor nume de coloane sau ncercrile de a realiza operaii neautorizate asupra tabelelor altor utilizatori, nu ntrerup tranzacia i nu realizeaz anularea automat. Aceasta se datoreaz faptului c aceste erori sunt detectate n cursul compilrii (de ctre PARSER, cnd un bloc SQL este scanat i verificat), i nu n timpul execuiei. Urmtoarele instruciuni SQL sunt utilizate cnd apar finalizri (commit) sau refaceri (rollback) : * COMMIT[WORK] * SAVEPOINT nume_savepoint * ROLLBACK[WORK] to [SAVEPOINT] nume_savepoint; De notat ca att COMMIT ct i ROLLBACK sunt instruciuni SQL. Cele trei instruciuni SQL utilizate pentru controlul tranzaciilor sunt explicate mai jos: COMMIT[WORK] Sintaxa : COMMIT[WORK]; * Permanentizeaz schimbrile din tranzacia curent * terge toate punctele de salvare (savepoint) din tranzacie * Termin tranzacia * Elibereaz toate blocrile (Lock) tranzaciei * Cuvantul cheie WORK este opional Utilizatorul trebuie s expliciteze sfritul tranzaciei n programul aplicaie utiliznd COMMIT (sau ROLLBACK). Dac nu se finalizeaz explicit tranzacia i programul se termin anormal, ultima tranzacie executat va fi anulat. Finalizri implicite (commit) apar n urmtoarele situaii : + nainte de o comand DDL + dup o comand DDL + la nchiderea normal a unei baze de date Dac introducei un bloc DDL dup cteva blocuri DML, blocul DDL cauzeaz apariia unui commit naintea propriei execuii, incheind tranzacia curenta. Apoi, dac blocul DDL este executat pn la capt, este i nregistrat (commit). SAVEPOINT

Sintaxa : SAVEPOINT nume_savepoint Exemplu : SAVEPOINT terminare_actualizari * Poate fi utilizat pentru a mpri o tranzacie n buci mai mici * Punctele de salvare (savepoints) permit utilizatorului s rein toat munca sa la orice moment din timp, cu opiunea de a nregistra mai trziu totul, a anula totul sau o parte din ea. Astfel, pentru o tranzacie lung, se pot salva pri din ea, pe msura execuiei, la sfrit nregistrndu-se sau refcndu-se coninutul iniial. La apariia unei erori nu trebuie executat din nou fiecare bloc. * La crearea unui nou punct de salvare cu acelai nume ca al unuia dinainte, primul punct este ters. * Numrul maxim de puncte de salvare pentru un proces utilizator este implicit 5. Aceast limit poate fi schimbat. ROLLBACK[WORK] to [SAVEPOINT] nume_punct_salvare * Instructiunea ROLLBACK este utilizata pentru a reface starea bazei de date. * Cuvantul cheie "work" este opional. ntoarcerea la un punct de salvare este de asemenea opionala. * Dac se utilizeaz ROLLBACK fr clauza TO SAVEPOINT, atunci : + se termin tranzacia + se anuleaz modificrile din tranzacia curent + se terg toate punctele de salvare din tranzacie + se elibereaz blocrile tranzaciei ntoarcerea la Nivel de Bloc O parte a unei tranzacii poate fi anulat. Dac un singur bloc DML d eroare, ORACLE va ntoarce napoi doar acel bloc. Aceast facilitate este cunoscut ca STATEMENT LEVEL ROLLBACK. ntoarcerea la nivel de bloc const n faptul c dac un singur segment DML d eroare la execuia unei tranzacii, efectul lui este anulat, dar schimbrile realizate de precedentul bloc DML n tranzactie nu vor fi anulate i pot fi nscrise (COMMIT) sau ntoarse (ROLLBACK) explicit de ctre utilizator. Dac blocul este unul de tip DDL, nscrierea (commit) care precede imediat acest bloc nu este anulat (schimbrile au fost fcute deja permanente). ORACLE realizeaz ntoarcerea la nivel de bloc prin crearea unui punct de salvare implicit nainte de executarea fiecarei comenzi DML. Utilizatorul nu poate referi acest punct de salvare n mod direct. Astfel, dac v ntoarcei la un punct de salvare, atunci: * se anuleaz o parte din tranzacie ; * se reine punctul de salvare pentru ntoarcere, dar se pierd toate celelalte puncte create dup punctul de salvare respectiv ; * se elibereaz toate blocrile de tabele i linii. ntoarceri implicite

ntoarcerile implicite apar cnd se ntlnesc terminri anormale ale execuiei (de exemplu cnd se ntrerupe un proces utilizator). ntoarcerile implicite la nivel de bloc apar la eroarea de execuie a unui bloc. Este recomandat ca tranzaciile s se termine explicit utiliznd COMMIT[WORK] ori ROLLBACK[WORK]. Urmtorul exemplu ilustreaz utilizarea unui punct de salvare i a instruciunilor ROLLBACK i COMMIT. INSERT INTO OFFICES VALUES ( 23, 'LAS VEGAS',WESTERN,null, null, 0 ); SAVEPOINT insert_done; UPDATE SALESREPS SET REP_OFFICE = 23, MANAGER=106; ROLLBACK TO insert_done ( modificrile sunt abandonate ); UPDATE SALESREPS SET REP_OFFICE = 23, MANAGER=106 WHERE EMPL_NUM=102 ; ( revizuim comanda UPDATE ) UPDATE OFFICES SET MGR=102 WHERE OFFICE=23 ; COMMIT; AUTOCOMMIT COMMIT sau ROLLBACK pot fi date manual sau automat, prin utilizarea opiunii AUTOCOMMIT a comenzii SET. Opiunea AUTOCOMMIT controleaz cnd schimbrile dintr-o baz de date sunt fcute permanente. Exist dou setri : COMANDA + DESCRIEREA SET AUTO[COMMIT] ON COMMIT este utilizat automat la fiecare INSERT, UPDATE sau DELETE SET AUTO[COMMIT] OFF

COMMIT poate fi utilizat de utilizator explicit. De asemenea, COMMIT se execut dup execuia comenzilor DROP, ALTER, CREATE sau la ieirea din SQL*Plus. ROLLBACK poate fi executat explicit de ctre utilizator pentru refacerea bazei de date. De reinut c SET este o comand SQL*Plus.

6.2 Controlul concurenei La sistemele n care o baz de date este accesat simultan de ctre mai muli utilizatori apar situaii de coflict datorate accesului concurent la datele care constituie o resurs comun. Consistena la citire Utilizatorii bazelor de date fac dou tipuri de accesri asupra bazelor de date: Operaii de citire ( SELECT ) Operaii de scriere ( INSERT, UPDATE, DELETE ) Cititorului i scriitorului unei baze de date trebuie s i se garanteze o vedere consistent asupra bazei de date. Cititorii nu trebuie s vizualizeze o dat care este n curs de modificare iar scriitorii trebuie s fie siguri c schimbrile dintr-o baz de date sunt fcute ntr-un mod consistent : schimbrile fcute de un scriitor s nu distrug sau s intre n conflict cu schimbrile pe care le face un alt scriitor. Scopul consistenei la citire este acela de a asigura faptul c fiecare utilizator vede data ca fiind cea de la ultimul COMMIT, inainte ca o operatie DML s nceap. Consistena la citire este implementat prin inerea unor copii pariale ale bazei de date n segmente de ntoarcere (ROLLBACK). Cnd de execut operaii de scriere ntr-o baz de date, ORACLE va face o copie a datelor nainte de schimbare i o va scrie ntr-un segment de ntoarcere. Toi cititorii, exceptndu-i pe cei care au facut schimbrile, nc mai vd baza de date care exista nainte ca schimbrile s fie fcute - ei vd segmentul de ntoarcere de fapt. Oricum, nainte ca schimbrile s fie fcute permanente n baza de date, doar utilizatorul care modific datele poate s vad baza de date cu alteraiile ncorporate. Toi ceilali vd baza de date nemodificat (fereastra din segmentul de ntoarcere ). Aceasta garanteaz citirea unor date consistente care nu fac subiectul unor modificari n curs. Cnd execuia unui bloc DML se ncheie (commit), schimbrile fcute n baza de date devin vizibile oricarui utilizator care execut SELECT. Modificrile sunt fcute 'universale' i acum toi utilizatorii vd baza de date cu modificarile ncorporate. Spaiul ocupat de ctre 'vechile' date n segmentul de ntoarcere este eliberat pentru a fi reutilizat. Dac tranzacia este anulat (ROLLBACK), atunci toate schimbrile sunt 'anulate' : Versiunea veche ('original') a bazei de date aflat n segmentul de ntoarcere este scris napoi ('recuperat') n baza de date. Toi utilizatorii vd baza de date existent nainte de nceperea tranzaciei. Tranzacii de citire

Implicit, modelul consistent al ORACLE DBMS garanteaz c rezultatul execuiei unui bloc este consistent. n anumite situaii se poate dori efectuarea unor interogri multiple, asupra datelor din mai multe tabele i se dorete asigurarea consistenei datelor. Adic, rezultatele din orice tabel sunt consistente n timp n raport cu rezultatele din orice alt tabel. Comanda SQL : SET TRANSACTION READ ONLY este utilizat pentru a ncepe o tranzactie de citire exclusiv. Consistena la citire pe care READ ONLY o furnizeaz este implementat n acelai fel cu consistena la nivel de bloc - utiliznd segmente de ntoarcere. Fiecare bloc vede implicit o fereastr consistent a datelor la momentul nceperii blocului. Aceast facilitate este foarte folositoare pentru rapoarte care efectueaz mai multe interogri asupra mai multor tabele, n timp ce ali utilizatori actualizeaz aceleai tabele. Observaii : SET TRANSACTION READ ONLY este utilizat pentru a ncepe o tranzacie doar de citire. Sunt permise doar cereri ( blocuri SELECT ). Comenzile DML nu sunt permise. SELECT FOR UPDATE va genera o eroare. O instruciune COMMIT, ROLLBACK, sau un bloc DDL va termina tranzacia de citire ( de reinut c blocurile DDL genereaz implicit suprascrieri - COMMIT ). n cazul blocurilor DDL, nu este dat nici o indicaie referitoare la faptul c tranzacia se termin implicit. n timpul tranzaciei de citire, toate cererile se refer la aceeai copie a bazei de date ( schimbrile sunt efectuate nainte ca tranzacia de citire s nceapa). Ali utilizatori pot continua s citeasc sau s modifice datele. Urmatoarele instruciuni pot fi rulate pentru a extrage datele din tabelele SALESREPS i OFFICES. COMMIT; SET TRANSACTION READ ONLY; SELECT EMPL_NUM, NAME, REP_OFFICE, TITLE FROM SALESREPS; SELECT OFFICE, CITY, REGION FROM OFFICES; COMMIT; Ultimul COMMIT este necesar pentru a termina explicit tranzacia de citire. Niveluri de izolare a tranzaciilor Serverul Oracle 9i garanteaz consistena citirii datelor la nivel de fraz SQL ns nu garanteaz implicit consistena la nivel de tranzacie, acest lucru depinznd de nivelul de izolare (serial) a tranzaciilor.

Serializarea presupune derularea tranzaciilor fr nici o posibilitate de intercalare a operaiilor lor, fiind regula care impune programarea acestora n uniti atomice. Acest lucru nseamn c, o dat ce o tranzacie a devenit activ, prin execuia primei operaii de citire sau scriere, tranzaciile iniiate de ali utilizatori nu pot fi derulate (sunt blocate n stare de ateptare) pn cnd cea dinti se ncheie. Totui, nici un sistem de baze de date nu impune o planificare att de strict a operaiilor tranzacionale, din urmtorul motiv: intercalarea operaiilor tranzacionale ofer oportuniti deosebite de mbuntire a performanelor n folosirea concurenial a resurselor, lucru care se poate determina prin numrul de tranzacii ncheiate ntr-o anumit perioad de timp. O astfel de abordare trebuie totui s respecte principiul seriabilizrii, n caz contrar fiind ameninat integritatea datelor. Cu alte cuvinte, chiar n condiii concureniale, modul de derulare a tranzaciilor trebuie s fie echivalent cu derularea serial ca uniti atomice a acestora, adic situaia n care fiecare tranzacie s-ar fi derulat n ordine, dup ce precedenta s-a ncheiat complet. Pentru a obine un grad de concuren mai ridicat s-a recurs la slbirea principiului seriabilizrii pentru a scadea numrul de tranzacii blocate n starea de ateptare. Consecina mai puin dorit, dar acceptabil n anumite condiii, va fi scderea gradului de izolare a tranzaciilor, crescnd astfel posibilitatea executrii operaiilor tranzacionale ntr-o ordine neechivalent serializabil. Serverul de baze de date Oracle 9i suport dou nivele de izolare a tranzaciilor, numite READ COMMITED i SERIALIZABLE, care pot fi obinute dac la iniierea unei noi tranzacii va fi execuat o comand SET TRANSACTION de genul : SET TRANSACTION ISOLATION LEVEL READ COMMITED ; SET TRANSACTION ISOLATION LEVEL SERIALIZABLE ; Implicit (adic nefolosind comanda SET TRANSACTION n mod explicit), nivelul de izolare este READ COMMITED. Figurile 6.1 i 6.2 prezint un exemplu simplu n acest sens, prin dou sesiuni ce deruleaz tranzacii concurente astfel : n prima sesiune este adugat o nou nregistrare care va deveni vizibil, imediat ce a fost comis, i n a doua sesiune produnnd un efect cunoscut drept citiri nerepetabile sau phanton reads.
SQL> SELECT * FROM SALESREPS ;

SQL> INSERT INTO SALESREPS 2 values (111, Sandra Grant, 30, 13, Sales Rep, 19-SEP-90, 104, null, 0) ;

10

1 row created. SQL> COMMIT ; Commit complete. Figura 6.1 n prima sesiune adugm o nou nregistrare i o comitem.

SQL> SET TRANSACTION ISOLATION LEVEL READ COMMITED ; Transaction set. SQL> SELECT * FROM SALESREPS ;

SQL> SELECT * FROM SALESREPS ;

Figura 6.2 n a doua sesiune, pe durata tranzaciei curente, starea tabelei SALESREPS se modific

Dac vom modifica nivelul de izolare n SERIALIZABLE, atunci repetarea experimentului anterior va duce la un alt rezultat, si anume : nregistrarea comis n prima sesiune va deveni vizibil i n cealalt abia dup ncheierea tranzaciei curente (dup ROLLBACK sau COMMIT), vezi figurile 6.3 i 6.4.
SQL> INSERT INTO SALESREPS 2 values (1132, James Williams, 35, 11, Sales Rep, 08-APR-86, 106, null, 0) ;

11

SQL> COMMIT ; Commit complete.

Figura 6.3 n prima sesiune adugm o nou nregistrare i o comitem SQL> SET TRANSACTION ISOLATION LEVEL SERIALIZABLE ; Transaction set. SQL> SELECT * FROM SALESREPS ;

SQL> SELECT * FROM SALESREPS ;

SQL> ROLLBACK ; Rollback complete. SQL> SELECT * FROM SALESREPS ;

12

Figura 6.4 n a doua sesiune, actualizrile efectuate n tranzaciile concurente comise vor fi vizibile dup ncheierea tranzactiei curente (ROLLBACK)

Despre bocaje n tranzacii concurente Derularea unui blocaj Am exemplificat mai nainte derularea a dou tranzacii concurente ce vizau aceai tabel, SALESREPS, dar n condiiile n care modificrile erau efectuate doar ntruna dintre ele. Ce s-ar ntmpla dac cele dou tranzacii vor ncerca s modifice n acelai timp aceleai nregistrri ? Dac facem un experiment simplu i deschidem dou sesiuni n care se vor derula tranzaciii concurente, iar n prima sesiune sunt modificate (presupunem) datele vanztorului cu id-ul 102, lucrurile vor decurge deocamdat fr nici o problem. Atunci cnd n cea de-a doua sesiune vom ncerca s modificm tot datele vnztorului cu id-ul 102, vom observa c acesta va rmane suspendat pn cnd tranzacia din prima sesiune se ncheie. Explicaia fenomenului este urmtoarea : la nivelul tabelei SALESREPS, n momentul n care s-a produs o modificare asupra unei nregistrri, acesteia i-a fost asociat un marcaj de blocare care previne invocarea ei ulterioar din alte tranzacii concurente, marcaj care nu va fi anulat dect n momentul cnd respectiva tranzacie este ncheiat (explicit, prin COMMIT ori ROLLBACK, sau forat, de ctre serverul Oracle) . Sistemul blocajelor este mecanismul care permite derularea tranzaciilor concurente ntr-o manier totui ct mai aproape de principiul seriabilizrii, pentru a evita intercalarea operaiilor din tranzaciile concurente ntr-un mod care s afecteze integritatea i/sau consistena datelor. n aceast privin , serverul Oracle permite obinerea blocajelor la dou nivele : la nivelul liniilor cei care citesc date nu-i vor atepta pe cei care scriu iar cei care scriu nu-i vor atepta dect, eventual, pe cei care au nceput s modifice aceleai date naintea lor ; la nivelul tabelelor pentru a preveni modificarea structurii acestora prin comenzi DDL, n timp ce nregistrrile acestora au fost accesate prin comenzi DML, sau pentru a rezerva accesul exclusiv la o tabel (n general la modificare) unei singure tranzacii, mpiedicnd astfel obinerea altor blocaje.

13

Moduri de blocare parametri de iniializare Blocajele pot fi obinute implicit, la iniiativa serverului BD, atunci cnd o tranzacie ncepe execuia unei fraze DML, sau la iniiativa utilizatorilor (aplicaiilor) prin comenzi SQL explicite gen LOCK TABLE. Comportamentul de blocare implicit al serverului BD este dependent de valoarea a doi parametri de iniializare : ROW_LOCKING i SERIALIZABLE. Astfel, valoarea default pentru ROW_LOKING este always, ceea ce nseamn c la execuia unei fraze DML(update) se obine automat blocarea liniilor vizate iar tabela este blocat n mod partajabil, permitnd i altor tranzacii s acceseze spre modificare alte linii. Dac modificm valoarea acestui parametru n intent, lucru realizabil n fiierul de iniializare urmat de repornirea instanei, atunci simpla actualizare a unei linii va determina blocarea restrictiv a ntregii tabele, astfel nct alte tranzacii concurente pot cel mult citi date, dar nu pot efectua modificri. Cel de-al doilea parametru, SERIALIZABLE, se refer la nivelul de izolare i are implicit valoarea false sau disable, ecchivalent cu READ COMMITED. Dac modificm valoarea acestui parametru n true, tranzaciile se vor derula echivalent SERIALIZABLE, fr a mai fi nevoie de execuia comenzii SET TRANSACTION ISOLATION LEVEL SERIALIZABLE la nceputul lor. Fiierul care conine parametrii de iniializare se gsete, de regul, n %ORACLE_HOME%\admin\<nume_serviciu_bd>\pfile, iar dup modificare instana trebuie repornit. Blocaje mortale (DEADLOCK) Mecanismele de blocare a nregistrrilor au marele avantaj de a face posibil concurena la nivelul tabelelor accesate simultan, totui cu anumite amendamente. Acestea sunt legate de suspendarea pe timp ndelungat a tranzaiilor care ateapt eliberarea anumitor blocaje sau, n cel mai ru caz, blocarea reciproc a dou tranzacii deadlock. Un blocaj mortal apare n cazul unui scenariu cum este cel prezentat n figura 6.5.

14

Tranzacia 1
Timp x1 : Acceseaz/cere blocarea liniei R Blocheaz linia R

Tranzacia 2

Tabel R N
Figura 6.5 Scenariu de producere a unui deadlock

Timp x2 : Acceseaz/cere blocarea liniei N Blocheaz linia N

Timp x3 : Acceseaz/cere blocarea liniei N Trece n ateptare

Un astfel de scenariu poate avea loc dup cum este exemplificat n figurile 6.6 i 6.7 : se observ mai nti c, la momentul T1, prima tranzacie acceseaz nregistrarea vnztorului cu id-ul 102, iar la momentul T2, cea de-a doua tranzacie acceseaz nregistrarea vnztorului cu id-ul 107. Apoi prima tranzacie ncearc s modifice nregistrarea cu id-ul 107, blocat anterior de cea de-a doua tranzacie, motiv pentru care va fi trecut n ateptare. n sfrit, cea de-a doua tranzacie ncearc, la rndul ei, s modifice datele vnztorului cu id-ul 102 i se mpiedic de blocajul pe aceast nregistrare iniiat de prima tranzacie.
SQL> SELECT * FROM SALESREPS ;

Timp x4 : Acceseaz/cere blocarea liniei R Trece n ateptare DEADLOCK

SQL> SELECT TO_CHAR(SYSDATE,HH24 :MI) t1 FROM dual ; T1 ----10 :53 SQL> UPDATE SALESREPS SET SALES=500000 WHERE EMPL_NUM=102 ; 1 row updated.

15

SQL> SQL> SELECT TO_CHAR(SYSDATE,HH24 :MI) t3 FROM dual ; T3 ----10 :55 SQL> UPDATE SALESREPS SET SALES=255730 WHERE EMPL_NUM=107 ; Figura 6.6 Derularea primei tranzacii pna la blocarea acesteia din cauza activitii din cea de-a doua tranzacie. SQL> SELECT * FROM SALESREPS ;

SQL> SELECT TO_CHAR(SYSDATE,HH24 :MI) t2 FROM dual ; T2 ----10 :54 SQL> UPDATE SALESREPS SET QUOTA=250000 WHERE EMPL_NUM=107 ; 1 row updated. SQL> SELECT TO_CHAR(SYSDATE,HH24 :MI) t4 FROM dual ; T4 ----10 :56 SQL> UPDATE SALESREPS SET QUOTA=400000 WHERE EMPL_NUM=102 ; Figura 6.7 Derularea celei de-a doua tranzacii pn la blocarea ei din cauza activitii din prima tranzacie

Serverul Oracle are ns capacitatea de a detecta astfel de situaii de blocaj total i efectueaz un arbitraj oblignd una dintre tranzacii s renune la modificarea curent i genereaz un mesaj de eroare, similar cu cel din figura 6.8
SQL> UPDATE SALESREPS SET EMPL_NUM = 104 WHERE EMPL_NUM = 102 ;

16

UPDATE SALESREPS SET EMPL_NUM = 104 WHERE EMPL_NUM = 102 * ERROR at line 1 : ORA-00060 : deadlock detected while waiting for resource Figura 6.8 Serverul BD a detectat un deadlock

Blocaje la nivel de tabela. Comenzile SQL LOCK TABLE Pentru a defini mecanisme de blocare specifice, impuse de strategiile particulare de dezvoltare a aplicaiilor, se recomand folosirea comenzilor SQL LOCK TABLE. Prin urmare, utilizatorii pot modifica sistemul de blocare sau modul de partajare a tabelelor, ns mecanismul de blocare exclusiv la nivel de linie nu poate fi ocolit sau dezactivat. a) Protejarea liniilor modificate sau care urmeaz a fi modificate Gradul de concuren cel mai mare poate fi obinut folosind la nivel de tabel blocaje gen ROW SHARE sau ROW EXCLUSIVE. Acestea se mai numesc i blocaje la nivel de date. Caracteristica lor definitorie rezid n faptul c respectiva tabel este partajabil la nivelul liniilor, tranzacii concurente pot actualiza linii concurente din aceeai tabel, dar se previne blocarea exclusiv pentru scriere a ntregii tabele. ntre ele, aceste blocaje se difereniaz prin faptul c ROW SHARE blocheaz liniile din tabel n vederea unor actualizri viitoare iar ROW EXCLUSIVE blocheaz liniile ca efect al actualizrilor imediate (ca efect al execuiei frazelor UPDATE, DELETE, INSERT). Acest tip de blocaj se poate obine n dou moduri : Implicit, prin comenzi SELECT nsoite de clauza FOR UPDATE, pentru ROW SHARE, i frazele obinuite INSERT, UPDATE, DELETE pentru ROW EXCLUSIVE. Explicit, prin urmtoarele comenzi : LOCK TABLE nume_tabela IN ROW SHARE MODE ; LOCK TABLE nume_tabela IN ROW EXCLUSIVE MODE ; Un astfel de blocaj este necesar dac se intenioneaz cel puin modificarea ulterioar sau imediat a unor date disponibile, spre exemplu printr-o interfa grafic. O fraz de genul SELECT * FROM SALSESREPS WHERE EMPL_NUM IN (102, 104) FOR UPDATE ; Ar fi dus la evitarea deadlock-ului exemplificat n figurile 6.6, 6.7, 6.8 pentru c ar fi prevenit modificarea nregistrilor respective prin tranzacii concurente. b) Protejarea n totalitate a tabelelor fa de modificrile ce ar putea proveni din tranzacii concurente Pe lng blocaje la nivel de date, n Oracle mai exist i blocajele SHARE, SHARE ROW EXCLUSIVE i EXCUSIVE, care previn modificarea din alte tranzacii a oricrei linii din tabela vizat. De obicei, aceste tipuri de blocaje sunt utilizate n situaii n care se dorete dobndirea exclusiv a dreptului de actualizare asupra unei tabele.

17

Blocajele SHARE sunt utilizate, n general, atunci cnd n decursul unei tranzacii este necesar pstrarea nealterat a setului de nregistrri, astfel nct rezultatul interogrilor care implic tabela vizat s fie consistent pn la sfritul tranzaciei. Blocajele de tip SHARE ROW EXCLUSIVE sunt necesare atunci cnd, n plus fa de ceea ce se poate realiza cu blocajele SHARE, se vizeaz i modificarea exclusiv a datelor din tabel. n mod normal, n condiiile unui singur blocaj SHARE din tranzacia care l-a iniat se poate realiza modificarea datelor din tabela implicat. ns, spre deosebire de blocajele SHARE ROW EXCLUSIVE, care nu permit nici un alt fel de blocaj la nivel de tabel cu excepia celor determinate de comenzi SELECT FOR UPDATE, blocajele SHARE simple pot fi paralelizate n tranzacii simultane, lucru ce va determina ca toate aceste tranzacii s nu mai poat efectua modificri asupra tabelelor implicate. Att blocajele SHARE ct i cele SHARE ROW EXCLUSIVE sunt permisive n ceea ce privete blocajele ROW SHARE la nivel de date. Prin urmare, tranzaciile care restrictive care au monopolizat momentan tabela la scriere permit altor tranzacii concurente s blocheze anumite nregistrri, ns pentru modificri ulterioare i nu imediate. Aceast situaie ascunde ns un potenial de apariie a fenomenelor dedlock, fiindc tranzaciile SHARE sau SHARE ROW EXCLUSIVE ar putea cere modificarea nregistrrilor blocate de ctre alte tranzacii prin SELECT FOR UPDATE. n figurile 6.9 i 6.10 este prezentat un exemplu n acest sens.
SQL> SELECT TO_CHAR(SYSDATE,HH24 :MI) t1 FROM dual ; T1 ----11 :28 SQL> LOCK TABLE SALESREPS IN SHARE ROW EXCLUSIVE MODE ; Table(s) Locked. SQL> SELECT TO_CHAR(SYSDATE,HH24 :MI) t3 FROM dual ; T3 ----11 :30 SQL> UPDATE SALESREPS SET EMPL_NUM=112 WHERE EMPL_NUM=102 ;

Figura 6.9 Prima tranzacie care blocheaz tabela SALESREPS n mod SHARE ROW EXCLUSIVE

SQL> SELECT TO_CHAR(SYSDATE,HH24 :MI) t2 FROM dual ; T2

18

----11 :29 SQL> SELECT * FROM SALESREPS WHERE EMPL_NUM=102 FOR UPDATE ;
EMPL_NUM NAME AGE REP_OFFICE TITLE HIRE_DATE MANAGER QUOTA SALES

---------------------------------------------------------------------------------------------------------------------102 Sue Smith 48 21 Sales Rep 10-DEC-86 108 350.000,00 474.050,00 SQL> SELECT TO_CHAR(SYSDATE,HH24 :MI) t4 FROM dual ; T4 ----11 :31 SQL> UPDATE SALESREPS SET EMPL_NUM=114 WHERE EMPL_NUM=104 ;

Figura 6.10 A doua tranzacie care blocheaz tabela SALESREPS n mod ROW SHARE prin SELECT FOR UPDATE

Scenariul prin care s-a obinut fenomenul deadlock anterior este urmtorul : mai nti, prima tranzacie obine un blocaj SHARE ROW EXCLUSIVE asupra tabelei SALESREPS, dup care cea de-a doua tranzacie (concurent cu prima) obine i ea un blocaj ROR SHARE asupra aceleiai tabele, pe nregistrarea vnztorului cu id-ul 102, folosind o comand SELECT FOR UPDATE. Apoi, prima tranzacie ncearc actualizarea liniei cu id-ul 102 i rmAne suspendat ca urmare a blocrii anterioare a acestei linii n cealalt tranzacie. n fine, n a doua tranzacie se ncearc modificarea unei linii oarecare din tabela SALESREPS i, ca urmare, apare un deadlock care va determina apariia unei erori pe prima tranzacie (figura 6.11).

SQL> UPDATE SALESREPS SET EMPL_NUM=112 WHERE EMPL_NUM=102 ; UPDATE SALESREPS SET EMPL_NUM=112 WHERE EMPL_NUM=102

* ERROR at line 1 : ORA-00060 :deadlock detected while waiting for resouce


Figura 6.11 Fenomenul deadlock relevat prin eroarea ORA-00060 aprut n sesiunea primei tranzacii

Pentru a se evita astfel de situaii se recomand folosirea blocajelor de tip EXCLUSIVE. Acestea dau exclusivitate la scriere i previn oricare alt blocaj (indiferent de tip) iniiat dintr-o tranzacie concurent. Fraza SQL prin care se poate invoca un astfel de blocaj este urmtoarea : LOCK TABLE nume_tabela IN EXCLUSIVE MODE ; Un tablou complet al modului n care sunt activate diversele tipuri de blocaje este prezentat n tabelul urmtor :

19

Tabelul 6.1 Modul de obinere a blocajelor Fraza SQL SELECT FROM nume_tabela INSERT INTO nume_tabela UPDATE nume_tabela DELETE FROM nume_tabela SELECT FROM nume_tabela FOR UPDATE OF LOCK TABLE nume_tabela IN ROW SHARE MODE ROW EXCLUSIVE MODE SHARE MODE SHARE EXCLUSIVE MODE EXCLUSIVE MODE Tip de blocaj la nivel de linie X X X X Tip de blocaj asupra tabelei RX RX RX RS RS RX S SRX S RS : row share S : share SRX : share row exclusive

X : exclusive RX : row exclusive

Problema timpului n care o tranzacie ce solicit un blocaj la nivel de tabel rmne suspendat n stare de ateptare, ca urmare a conflictelor de blocare cu alte tranzacii concurente, este rezolvabil prin folosirea clauzelor NOWAIT n frazele SQL FOR UPDATE i LOCK TABLE. n consecin, dac un anumit tip de blocaj nu poate fi obinut imediat, va fi generat o excepie specific. Iat un exemplu n acest sens :

SQL> SELECT TO_CHAR(SYSDATE,HH24 :MI) t1 FROM dual ; T1 ----09 :38 SQL> LOCK TABLE SALESREPS IN EXCLUSIVE MODE NOWAIT ; Table(s) Locked.

Figura 6.12 O prim tranzacie care solicit i obine un blocaj EXCLUSIVE asupra tabelei SALESREPS

SQL> SELECT TO_CHAR(SYSDATE,HH24 :MI) t2 FROM dual ; T2

20

----09 :39 SQL> SELECT * FROM SALESREPS FOR UPDATE NOWAIT ; SELECT * FROM SALESREPS FOR UPDATE NOWAIT * ERROR at line 1 : ORA-00054 : resource busy and acquire with NOWAIT specified Figura 6.13 A doua tranzacie solicit blocarea liniilor tabelei SALESREPS n modul ROW SHARE

Dup cum se poate deduce din figura 6.12, prima tranzacie obine un blocaj EXCLUSIVE , care va preveni apariia altor blocaje concurente. n figura 6.13, a doua tranzacie solicit obinerea unui blocaj prin comanda SELECT FOR UPDATE, a crei clauz NOWAIT va determina renunarea la aceast aciune dac blocajul nu poate fi obinut imediat. Ca urmare, va fi generat eroarea ORA-00054. Durata blocrilor Toate blocrile acumulate de-a lungul unei tranzacii sunt eliberate cnd tranzacia se termin. Toate blocrile acumulate de-a lungul unei tranzacii sunt eliberate cnd tranzacia se anuleaz . Toate blocrile acumulate dupa un punct de salvare sunt eliberate cnd tranzacia se ntoarce la punctul de salvare.

21