UNIVERSITATEA POLITEHNICA BUCURETI Facultatea de Electronic Telecomunicaii i Ingineria Informaiei Catedra de Electronic Aplicat i Ingineria Informaiei

Metode concureniale de acces la baze de date distribuite. Protocoalele 2-PL, Send-on-Demand. Platformele SQL i Oracle.

Conductor tiinific U.P.B.: Conf. Dr. Ing. TEFAN STNCESCU Masterand: Bastea GABRIEL BUCURESTI 2008 1

Cuprins
Prezentare generala. Definitii...............................................................................................2 Prezentare generala..........................................................................................................3 2. FACILITATILE SI ARHITECTURA SISTEMULUI ORACLE ..................................6 3. . FACILITATILE SI ARHITECTURA SISTEMULUI SQL.........................................9 3.1 Trsturi caracteristice ale limbajului SQL...............................................................9 3.2 Setul de comenzi SQL.............................................................................................10 3.3 Arhitectura SQL:......................................................................................................10 4. Proprieti ale bazelor de date relaionale......................................................................11 4.1 Proprietile relaiilor tabelare ................................................................................12 4.2 Definitii........................................................................................................................12 5. Concurenta si consistenta datelor ..................................................................................13 5.1 Citirea consistenta....................................................................................................13 5.2 Citirea consistenta, segmentele rollback si tranzactiile ..........................................14 5.3 Tranzactii read-only ................................................................................................14 5.4 Mecanismul de blocare ...........................................................................................15 5.5 Blocarea automata ...................................................................................................15 5.6 Blocarea manuala ...................................................................................................15 6. Procesare distribuita si baze de date distribuite ............................................................16 6.1 Arhitectura client / server: Procesare distribuita .....................................................16 7. Tranzacii.......................................................................................................................17 7.1 ANOMALII DE EXECUIE CONCURENTA A TRANZACIILOR ................18 7.2 PROPRIETILE TRANZACIILOR .................................................................20 7.3 STRILE TRANZACIILOR ...............................................................................21 8. TEHNICI DE CONTROL AL CONCURENEI..........................................................24 8.1 CONTROLUL CONCURENEI ...........................................................................24 8.2 ANALIZA CONTROLULUI CONCURENEI ....................................................25 8.3 Tehnici optimiste.....................................................................................................32 8.4 TEHNICI DE REFACERE A BAZELOR DE DATE............................................34 9. CONTROLUL TRANZACIILOR..............................................................................34 10. Blocari..........................................................................................................................36 10.1 Deadlock................................................................................................................41 10.2 Serializare..............................................................................................................42 10.3 Blocare ierarhic....................................................................................................44 11. Protocolul n dou faze 2-PL.......................................................................................46 12. 2PL strict .....................................................................................................................49 13. Prototocolul send-on-demand......................................................................................50

Prezentare generala. Definitii.

Prezentare generala.

Modelul relaional a fost propus de ctre IBM i a revoluionat reprezentarea datelor fcnd trecerea la generaia a doua de baze de date. Modelul este simplu, are o solid fundamentare teoretic fiind bazat pe teoria seturilor (ansamblurilor) i pe logica matematic. Pot fi reprezentate toate tipurile de structuri de date de mare complexitate, din diferite domenii de activitate. Modelul relaional este definit prin: structura de date, operatorii care acioneaz asupra structurii i restriciile de integritate. 1) Conceptele utilizate pentru definirea structurii de date sunt: domeniul, tabela (relaia), atributul, tuplul, cheia i schema tabelei. Domeniu este un ansamblu de valori caracterizat printr-un nume. El poate fi explicit sau implicit. Tabela/relaia este un subansamblu al produsului cartezian al mai multor domenii, caracterizat printr-un nume, prin care se definesc atributele ce aparin aceleai clase de entiti. Atributul este coloana unei tabele, caracterizat printr-un nume. Cheia este un atribut sau un ansamblu de atribute care au rolul de a identifica un tuplu dintr-o tabel. Tipuri de chei: primare/alternate, simple/comune, externe. Tuplul este linia dintr-o tabel i nu are nume. Ordinea liniilor (tupluri) i coloanelor (atribute) dintr-o tabel nu trebuie s prezinte nici-o importan. Schema tabelei este format din numele tabelei, urmat ntre paranteze rotunde de lista atributelor, iar pentru fiecare atribut se precizeaz domeniul asociat. Schema bazei de date poate fi reprezentat printr-o diagram de structur n care sunt puse n eviden i legturile dintre tabele. Definirea legturilor dintre tabele se face logic construind asocieri ntre tabele cu ajutorul unor atribute de legtur. Atributele implicate n realizarea legturilor se gsesc fie n tabelele asociate, fie n tabele distincte construite special pentru legturi. Atributul din tabela iniial se numete cheie extern iar cel din tabela final este cheie primar. Legturile posibile sunt 1:1, 1:m, m:n. Potenial, orice tabel se poate lega cu orice tabel, dup orice atribute. Legturile se stabilesc la momentul descrierii datelor prin limbaje de descriere a datelor (LDD), cu ajutorul restriciilor de integritate. Practic, se stabilesc i legturi dinamice la momentul execuiei. 2) Operatorii modelului relaional sunt operatorii din algebra relaional i operatorii din calculul relaional. Algebra relaional este o colecie de operaii formale aplicate asupra tabelelor (relaiilor), i a fost conceput de E.F.Codd. Operaiile sunt aplicate n expresiile algebrice relaionale care sunt cereri de regsire. Acestea sunt compuse din operatorii relaionali i operanzi.

Operanzii sunt ntotdeauna tabele (una sau mai multe). Rezultatul evalurii unei expresii relaionale este format dintr-o singur tabel. Algebra relaional are cel puin puterea de regsire a calcului relaional. O expresie din calculul relaional se poate transforma ntr-una echivalent din algebra relaional i invers. Codd a introdus ase operatori de baz (reuniunea, diferena, produsul cartezian, selecia, proiecia, jonciunea) i doi operatori derivai (intersecia i diviziunea). Ulterior au fost introdui i ali operatori derivai (speciali). n acest context, operatorii din algebra relaional pot fi grupai n dou categorii: pe mulimi i speciali. Operatori pe mulimi (R1, R2, R3 sunt relaii (tabele)) sunt: Reuniunea. R3 = R1 R2, unde R3 va conine tupluri din R1 sau R2 luate o singur dat; Diferena. R3 = R1 \ R2, unde R3 va conine tupluri din R1 care nu se regsesc n R2; Produsul cartezian. R3 = R1 R2, unde R3 va conine tupluri construite din perechi (x1x2), cu x1R1 i x2R2; Intersecia. R3 = R1 R2, unde R3 va conine tupluri care se gsesc n R1 i R2 n acelai timp, etc. Operatori relaionali speciali sunt: Selecia. Din R1 se obine o subtabel R2, care va conine o submulime din tuplurile iniiale din R1 ce satisfac un predicat (o condiie). Numrul de atribute din R2 este egal cu numrul de atribute din R1. Numrul de tupluri din R2 este mai mic dect numrul de tupluri din R1. Proiecia. Din R1 se obine o subtabel R2, care va conine o submulime din atributele iniiale din R1 i fr tupluri duplicate. Numrul de atribute din R2 este mai mic dect numrul de atribute din R1. Jonciunea este o derivaie a produsului cartezian, ce presupune utilizarea unui calificator care s permit compararea valorilor unor atribute din R1 i R2, iar rezultatul n R3. R1 i R2 trebuie s aib unul sau mai multe atribute comune care au valori comune. Algebra relaional este prin definiie neprocedural (descriptiv), iar calculul relaional permite o manier de cutare mixt (procedural/neprocedural). Calculul relaional se bazeaz pe calculul predicatelor de ordinul nti (domeniu al logicii) i a fost propus de E.F. Codd. Predicatul este o relaie care se stabilete ntre anumite elemente i care poate fi confirmat sau nu. Predicatul de ordinul 1 este o relaie care are drept argumente variabile care nu sunt predicate. Variabila poate fi de tip tuplu (valorile sunt dintr-un tuplu al unei tabele) sau domeniu (valorile sunt dintr-un domeniu al unei tabele). Construcia de baz n calculul relaional este expresia relaional de calcul tuplu sau domeniu (funcie de tipul variabilei utilizate). Expresia relaional de calcul este format din: operaia de efectuat, variabile (tuplu respectiv domeniu), condiii (de comparaie, de existen), formule bine definite (operanzi-constante, variabile, funcii, predicate; operatori), cuantificatori. Pentru implementarea acestor operatori exist comenzi specifice n limbajele de manipulare a datelor (LMD) din sistemele de gestiune a bazelor de

date relaionale (SGBDR). Aceste comenzi sunt utilizate n operaii de regsire (interogare). Dup tehnica folosit la manipulare, LMD sunt bazate pe: calculul relaional (QUEL n Ingres, ALPHA propus de Codd); algebra relaional (ISBL, RDMS); transformare (SQL, SQUARE); grafic (QBE, QBF). Transformarea ofer o putere de regsire echivalent cu cea din calculul i algebra relaional. Se bazeaz pe transformarea (mapping) unui atribut sau grup de atribute ntr-un atribut dorit prin intermediul unor relaii. Rezultatul este o relaie (tabel) care se poate utiliza ntr-o alt transformare. Grafica ofer interactivitate mare pentru constrirea cererilor de regsire. Utilizatorul specific cerea alegnd sau completnd un ecran structurat grafic. Poate fi folosit de ctre toate categoriile de utilizatori n informatic. 3) Restriciile de integritate ale modelului relaional sunt structurale i comportamentale. Restriciile structurale sunt: 1 Restricia de unicitate a cheii. ntr-o tabel nu trebuie s existe mai multe tupluri cu aceeai valoare pentru ansamblul cheie; 2 Restricia referenial. Intr-o tabel t1 care refer o tabel t2, valorile cheii externe trebuie s figureze printre valorile cheii primare din t2 sau s ia valoarea null (neprecizat); 3 Restricia entitii. Intr-o tabel, atributele din cheia primar nu trebuie s ia valoarea NULL. Cele trei restricii de mai sus sunt minimale. Pe lng acestea, exist o serie de alte restricii structurale care se refer la dependenele dintre date: funcionale, multivaloare, jonciune etc. (sunt luate n considerare la tehnicile de proiectare a bazelor de date relaionale - BDR). Restriciile de comportament sunt cele care se definesc prin comportamentul datelor i in cont de valorile din BDR: 1 Restricia de domeniu. Domeniul corespunztor unui atribut dintr-o tabel trebuie s se ncadreze ntre anumite valori; 2 Restricii temporare. Valorile anumitor atribute se compar cu nite valori temporare (rezultate din calcule etc.). Restriciile de comportament fiind foarte generale se gestioneaz fie la momentul descrierii datelor (de exemplu prin clauza CHECK), fie n afara modelului la momentul execuiei. Restriciile de integritate suportate de Oracle sunt:

1 NOT NULL nu permite valori NULL n coloanele unei tabele; 2 UNIQUE nu sunt permise valori duplicat n coloanele unei tabele; 3 PRIMARY KEY nu permite valori duplicate sau NULL n coloana sau coloanele definite astfel; 4 FOREIGN KEY presupune ca fiecare valoare din coloana sau setul de coloane defini astfel s aib o valoare corespondent identic n tabela de legtur, tabel n care coloana corespondent este definit cu restricia UNIQUE sau PRIMARY KEY; 5 CHECK elimin valorile care nu satisfac anumite cerine (condiii) logice. Termenul de chei (keys) este folosit pentru definirea ctorva categorii de constrngeri i sunt: primary key, unique key, foreign key, referenced key. Se consider c modelul relaional are o serie de limite cum ar fi: 1 Simplitatea modelului l face dificil de aplicat pentru noile tipuri de aplicaii (multimedia, internet etc.); Nu asigur o independen logic total a datelor de aplicaie; Poate crete redundana datelor. EXEMPLE DE SISTEME DE GESTIUNE A BAZELOR DE DATE RELAIONALE Oracle. Este realizat de firma Oracle Corporation USA. Sistemul este complet relaional, robust, se bazeaz pe SQL standard extins. Arhitectura sistemului este client / server, permnd lucrul, cu obiecte i distribuit. Are BD Internet i modul de optimizare a regsirii. Ultima versiune este Oracle 11g. SQL Server. Este realizat de firma Microsoft. Se bazeaz pe SQL i ruleaz n arhitectura client/server. Ultima versiune este SQL Server 2005.

2. FACILITATILE SI ARHITECTURA SISTEMULUI ORACLE Componentele care formeaz arhitectura de baz Oracle sunt dispuse ntr-o configuraie client/server. Aceste componente sunt plasate pe calculatoare diferite ntr-o reea asigurnd funcionaliti specifice, astfel: serverul asigur memorarea i manipularea datelor, precum i administrarea bazei de date iar clientul asigur interfaa cu utilizatorul i lanseaz aplicaia care acceseaz datele din baza de date.

Fig 2.1 Arhitectura sistemului Oracle Arhitectura Oracle se ncadreaz n tendinele actuale i anume este structurat pe trei niveluri: nucleul, interfeele i instrumentele de ntreinere. Nucleul Oracle conine componentele care dau tipul relaional pentru SGBD Oracle: limbajul relaional de regsire SQL i limbajul procedural propriu PL/SQL. Sistemul Oracle creeaz i ntreine automat dicionarul de date. Acesta face parte din baza de date Oracle i conine un set de tabele i viziuni (vederi) accesibile utilizatorilor doar n consultare. Dicionarul conine informaii de tipul: numele utilizatorilor autorizai, drepturile de acces, numele obiectelor din baza de date, structurile de date, spaiul ocupat de date, chei de acces etc. Interfeele sunt componentele care permit dezvoltarea aplicaiilor cu BD, astfel: 1 DEVELOPER SUITE este componenta destinat dezvoltatorilor (programatorilor) de aplicaii. Conine generatoarele FORMS (meniuri i videoformate), REPORTS (rapoarte i grafice), JDEVELOPER; 2 DESIGNER este component destinat analitilor/proiectanilor de aplicaii. Ofer elemente de CASE pentru proiectarea aplicaiilor cu BD; 3 PRO*C este componenta destinat programatorilor n limbajele de programare universale (FORTRAN, COBOL, Pascal, C, ADA, PL1); 4 DATAWAREHOUSE BUILDER este destinat analizei datelor multidimensionale, folosind tehnologia de tip OLAP (On Line Analitical Processing); 5 ORACLE APPLICATIONS permite dezvoltarea unor aplicaii de ntreprindere (Financials, Manufacturing, Projects etc.);

Instrumentele sunt componente destinate ntreinerii i bunei funcionri a unei BD Oracle. ENTERPRISE MANAGER CONSOLE conine mai multe utilitare destinate administratorului BD (deschidere/nchidere BD, autorizarea accesului, refacerea BD, conversii de date, etc.). Procesele background (Background processes) sunt create pentru fiecare instan Oracle pentru a executa asincron anumite funcii. Acestea sunt: 1 Database Writer (DBWR) scrie datele modificate n baza de date; 2 Log Writer (LGWR) scrie nregistrrile redo log pe disc; 3 Checkpoint (CKPT) scrie nregistrrile checkpoint la timpul potrivit ; 4 System Monitor (SMON) execut recuperarea unei instane la momentul pornirii, colecteaz spaiul liber etc; 5 Process Monitor (PMON) recupereaz procesele utilizator dac acestea cad accidental; 6 Archiver (ARCH) copiaz n mod online fiierele Redo Log n fiiere de arhiv atunci cnd acestea se umplu cu datei; 7 Recoverer (RECO) rezolv tranzaciile suspendate n sistemul cu baze de date distribuite; 8 Dispacher (Dnnn) folosit n sistemul multithreaded; 1 Lock (LCKn) blochez procesele n sistemul Parallel server. Legtura dintre procesele utilizator i procesele Oracle este prezentat n figura de mai jos :

Fig 2.2 Legtura dintre procesele utilizator i procesele Oracle . 8

3. . FACILITATILE SI ARHITECTURA SISTEMULUI SQL

SQL poate fi folosit astfel:

direct la terminal, adic n mod comand (interactiv, sau batch) Cu ajutorul tools-urilor SQL (Query Analyzer , Enterprize Manager,Business Inteligence etc in functie de versiunea utilizata ). n cadrul unor programe scrise ntr-un limbaj de programare, precum C++, C# , Visual Basic etc.

In concluzie: Un sistem de management al bazei de date necesit un limbaj de interogare pentru a permite utilizatorului s acceseze datele. SQL (iniial numit SEQUEL, ca limbaj de interogare structurat) este limbajul standardizat ANSI i ISO, utilizat de majoritatea sistemelor ce manevreaz baze de date relaionale. 3.1 Trsturi caracteristice ale limbajului SQL

SQL, folosete cuvinte din limba englez. In mod special cuvintele select, update, insert, delete ca elemente ale setului de comenzi. SQL este un limbaj neprocedural: specific care sunt informaiile dorite, nu cum se obin acestea. Cu alte cuvinte, SQL nu cere s fie specificat metoda de acces la date. Execuia comenzilor SQL asupra nregistrrilor nu se poate face dect secvenial, asupra cte unei singure nregistrri. Setul de nregistrri fiind vzut ca set de linii ale unui tabel. SQL poate fi folosit de un ir de utilizatori, incluznd administratorul bazei de date, programatorii de aplicaii, personalul de management i multe alte tipuri de utilizatori. SQL include comenzi pentru o varietate de sarcini, incluznd: o selecia unor date o inserarea, extragerea i tergerea rndurilor dintr-un tabel o crearea, modificarea i tergerea obiectelor de tip baz de date o controlul accesului la baza de date i la obiectele de tip baz de date o verificarea - garantarea consistenei bazei de date

La nceput, sistemele de management a bazelor de date au utilizat un limbaj separat pentru fiecare categorie de sarcini n parte. SQL le-a unificat pe toate acestea ntr-un singur limbaj. Logic, comenzile limbajului SQL sunt mprite n trei componente:

limbajul de definire a datelor (Data Definition Language)- DDL, limbajul de manipulare a datelor (Data Manipulation Language)- DML, limbajul de control al datelor (Data Control Language)-DCL.

Primul pentru crearea structurii de baz de date, al doilea, dup ce structura exist, pentru a aduga date n tabele i pentru a le manipula. A treia component ofer posibilitatea de a proteja (securiza) datele. 3.2 Setul de comenzi SQL Comenzile de definire a datelor (DDL): CREATE, ALTER, DROP aceste trei comenzi sunt utilizate dinamic pentru a crea, utiliza i terge orice structur de date, n particular tabele. Comenzile de manipulare a datelor (DML): INSERT, UPDATE, DELETE i SELECT utilizate pentru a introduce noi rnduri, pentru a schimba (actualiza) rndurile existente, pentru a terge rndurile nedorite din baza de date respectiv, i, n fine, SELECT - comanda cea mai utilizat, folosit pentru a cuta, a selecta nregistrri din tabel sau dintr-o combinaie de tabele ale bazei de date. Comenzile de control (grupul DCL), la dispoziia administratorului(DBA): GRANT, REVOKE utilizate pentru a da sau a lua drepturi de acces (la comenzi DML, deci la operarea unor modificri a bazei de date).

Sintaxa comenzilor difer de la un grup la altul. Ne limitm acum doar la un exemplu: CREATE TABLE [dbo].[IC] ( [Institutie] [char] (10) COLLATE Romanian_CI_AS NULL , [functia] [char] (100) COLLATE Romanian_CI_AS NULL , [telefon] [char] (10) COLLATE Romanian_CI_AS NULL 3.3 Arhitectura SQL:

10

Fig . 3.1 Arhitectura Sistemului SQL 4. Proprieti ale bazelor de date relaionale

O baz de date relaional apare ca o colecie de relaii (tabele) Exist o mulime de operatori pentru transformarea i combinarea relaiilor: o selecia, o proiecia, o produsul, o join-ul, o reuniunea, o intersecia, o diferena. Nu apar pointeri; conexiunile sunt fcute numai pe baza datelor. Exist o independen total a datelor. Limbajul utilizat pentru interogarea bazei de date este non-procedural i similar limbii engleze. Utilizatorul nu specific calea de acces i nu are nevoie s tie cum este aranjat fizic informaia.

11

Comenzile pentru selecia sau refacerea datelor, ct i acelea pentru realizarea schimbrilor n baza de date sunt incluse ntr-un singur limbaj, standardizat acum ca SQL.

4.1 Proprietile relaiilor tabelare Fiecare tabel, individual, are urmtoarele proprieti:

Nu exist rnduri duplicate Nu exist nume de coloane identice (duplicate) Ordinea rndurilor este neimportant Ordinea coloanelor este neimportant Valorile (cmpurile) sunt atomice (nedecompozabile).

4.2 Definitii.

Tabela sau relaia este un ansamblu format din n coloane (atribute/subansambluri) i m rnduri (tupluri/linii) care respect urmtoarele condiii minime: nu conine date la nivel agregat (valorile aflate la intersecia liniilor cu coloanele s fie la un nivel elementar); liniile sunt distincte unele fa de altele; nu conine coloane repetitive n descriere. Cheia primar este un atribut care are valori distincte. Deci, fiecare linie se identific printr-o valoare distinct. Dou sau mai multe atribute care pot fi chei primare se numesc chei candidate. Cheile sunt de trei tipuri : cheie candidat, cheie primar i cheie surogat. Orice atribut sau combinaie de atribute care identific n mod unic o instan a unui tip de entitate se numete cheie candidat. Cheia candidat care a fost aleas ca identificator pentru un tip de entitate se numete cheie primar. Cheia surogat este atributul introdus artificial la o entitate pe post de cheie primar. n general, cheile sunt chei simple atunci cnd sunt formate dintr-un singur atribut i chei compuse cnd sunt formate din mai multe atribute, caz n care conteaz i ordinea n care sunt precizate atributele (cheile compuse sunt poziio-nale). Coloana tabelei este format din valorile pe care le ia atributul n liniile tabelei respective. Rndul / tuplul / linia este format din valorile coloanelor ce se refer la o entitate a tabelei. Baza de date relaional este un ansamblu de tabele normalizate, grupate n jurul unui subiect, n principiu, bine definit. ntr-o baz de date relaional, entitile i legturile sunt transpuse n tabele. Viziunea este o tabela logic i reprezint o fereastr la date, dintr-una sau mai multe tabele. Pentru ca accesul la date sa se fac mai rapid, se utilizeaz indexarea.

12

Un index reprezint o cheie pe una sau mai multe coloane. Indexarea este dinamic deoarece se pot adaug sau terge indeci oricnd, fr ca datele memorate sau aplicaiile scrise s fie afectate. Pentru realizarea unor operaii sau pentru a utiliza n cereri nume mai scurte, se pot defini sinonime ale unor nume de tabele sau viziuni. Un cluster reprezint o anumit modalitate de grupare a rndurilor uneia sau mai multor tabele. Aceast grupare mrete viteza de execuie a unor operaii consumatoare de timp. Comanda este o instruciune emis din SQL ctre o baz de date Oracle respectiv SQL. Blocul reprezint un grup de instruciuni SQL. Cererea este o comanda SQL (SELECT) care regsete date din baza de date. Rezultatul cererii l formeaz datele regsite din baza de date. Raportul este rezultatul cererii formatat cu ajutorul comenzilor si poate fi afisat in format .csv, importat in .xls din format csv, sau afisat cu ajutorul aplicatiei Crystal Reports. 5. Concurenta si consistenta datelor Principala grija a unui sistem de gestiune a bazelor de date multiuser este modul cum controleaza concurenta sau accesul simultan la aceeasi data de catre mai multi utilizatori. Fara un control adecvat al concurentei, datele pot fi actualizate si schimbate necorespunzator compromitind integritatea datelor. Daca mai mulit utilizatori acceseaza aceeasi data, o cale de a gestiona concurenta este de a face ca fiecare sa-si astepte rindul. Scopul sistemului de gestiune a bazelor de date este de a face aceasta asteptare inexistenta sau neglijabila pentru fiecare utilizator. Toate comenzile de manipulare a datelor (DML) vor trebui efectuate astfel incit sa fie prevenita interactiunea distructiva intre tranzactiile concurente. Interactiunea distructiva este oricare interactiune care actualizeaza incorect date sau modifica incorect structura datelor. Oracle rezolva aceste probleme folosind un tip variat de blocari si un modul de consistenta multiversiune. Aceste caracteristici sint bazate pe conceptul de tranzactie. 5.1 Citirea consistenta Citirea consistenta, suportata de Oracle, face urmatoarele: - garanteaza ca setul de date consultate de o comanda este consistent cu respectarea unui singur moment de timp si nu se schimba in cursul executiei comenzii (citire consistenta la nivel de comanda) ; 1- asigura ca cititorii datelor nu asteapta pentru scriere sau dupa alti cititori ai aceleasi date ;

13

2- asigura ca cei care scriu in baza de date nu asteapta numai dupa altii care scriu daca acestia incearca sa actualizeze rinduri identice in tranzactii concurente. Modul simplu in care se intelege implementarea Oracle a citirii consistente este de a se imagina ca fiecare utilizator opereaza o copie privata a bazei de date, de aici modelul de consistenta multiversiune. 5.2 Citirea consistenta, segmentele rollback si tranzactiile Pentru a gestiona modelul consistenta multiversiune, Oracle trebuie sa creeze un set de date citire consistenta cind o tabela este interogata (citita) sau actualizata (scrisa) simultan. Cind se intilneste o actualizare, valorile originale ale datelor schimbate prin actualizare sint scrise in segmentul rollback al bazei de date. Atita timp cit aceste actualizari ramin parte a unei tranzactii nerealizate, oricare utilizator care mai tirziu interogheaza datele modificate vede valorile originale ale datelor. Oracle foloseste informatia curenta din SGA si informatia din segmentul rollback pentru a construi o vizualizare consistenta ( read-consistent view) pentru datele tabelei interogate. Numai cind o tranzactie este comisa schimbarile tranzactiei sint facute permanente. Comenzile lansate dupa ce tranzactia utilizatorului este realizata vad numai schimbarile facute prin intermediul tranzactiei realizate. De notat ca tranzactia este cheia strategiei Oracle pentru a furniza citirea consistenta. Aceasta unitate a comenzilor SQL de realizare (sau nerealizare) 1 dicteaza punctul de start pentru view-urile de citire consistenta generate in beneficiul cititorilor 2 controleaza cind datele modificate pot fi vazute de alte tranzactii ale bazei de date pentru citire sau actualizare 5.3 Tranzactii read-only Implicit, Oracle garanteaza citire consistenta la nivel de comanda. Aceasta stabileste ca setul de date returnat de o singura cerere este consistent cu respectarea unui moment de tip. Totusi, in anumite situatii, se poate cere citire consistenta la nivel de tranzactie - capacitatea de a rula mai multe cereri intr-o singura tranzactie, toate fiind citiri consistente cu respectarea aceluiasi moment de timp astfel incit cererile acestei tranzactii sa nu vada efectele intervenite prin tranzactiile efectuate. Daca se doreste rularea unui numar de cereri intre tabele multiple si nu se doreste actualizarea se prefera tranzactiile read-only. Dupa indicarea ca tranzactia este read-only, se pot executa mai multe cereri intre orice tabele,

14

cunoscind ca rezultatul oricarei cereri este consistent cu respectarea aceluiasi moment de timp.

5.4 Mecanismul de blocare Oracle foloseste blocarea pentru a controla accesul concurent la date. Blocarea este un mecanism cu intentia de a preveni interactiunile distructive intre utilizatorii care acceseaza date Oracle respectiv SQL. Blocarea este utilizata pentru a realiza doua scopuri importante ale bazei de date: 1- consistenta - asigura ca, datele unui utilizator sau schimbarile nu sint efectuate (de alti utilizatori) pina cind utilizatorul nu termina cu datele. 2- integritatea - asigura ca datele bazei de date si structurile reflecta toate schimbarile facute in acestea in secventa corecta. Blocarea garanteaza integritatea datelor prin furnizarea accesului concurent maxim la date pentru un numar nelimitat de utilizatori. 5.5 Blocarea automata Oracle executa blocarea automata si nu cere actiunea utilizatorului. Blocarea implicita intilnita pentru comenzi SQL la nevoie, depinde de actiunea ceruta. Managerul de blocare Oracle automat blocheaza datele tabelei la nivel de rind. Prin blocarea datelor la nivel de rind, conflictele pentru aceleasi date sint minimizate. Managerul Oracle mentine citeva tipuri de blocare a rindurilor, depinzind de tipul operatiei care stabileste blocarea. In general sint doua tipuri de blocare: blocare exclusiva si blocare partajata. Numai o blocare exclusiva poate obtine o resursa (cum ar fi un rind sau o tabela); totusi, mai multe blocari partajate pot obtine o singura resursa. Ambele blocari permit interogarea resursei blocate dar interzic alte activitati asupra resursei (ca actualizare sau stergere). 5.6 Blocarea manuala In anumite circumstante, utilizatorul poate modifica blocarea implicita. Oracle permite modificarea manuala a caracteristicilor blocarii automate la nivel de rind (prin prima cerere pentru rindurile care vor fi actualizate in comanda urmatoare) si la nivel de tabela.

15

6. Procesare distribuita si baze de date distribuite Lucrul calculatoarelor in retea devine din ce in ce mai obisnuit in mediile de calcul de zi cu zi de aceea sistemele de gestiune a bazelor de date trebuie sa fie capabile sa ia avantajele proceselor si capacitatilor de memorare distribuite. 6.1 Arhitectura client / server: Procesare distribuita Procesarea distribuita foloseste mai mult de un procesor pentru a imparti procesarea unui set stabilit de lucrari. Procesarea distribuita reduce incarcarea procesului la un singur procesor permitind diferitelor procesoare sa se concentreze la un subset de sarcini (taskuri), prin aceasta crescind capacitatile si performanta sistemului. O baza de date Oracle poate lua usor avantajele procesarii distribuite folosind arhitectura client/server. In aceasta arhitectura baza de date sistem este impartita in doua parti: front-end sau portiunea client si back-end sau portiunea server. Portiunea client - este partea aplicatiei bazei de date care interactioneaza cu tastatura, monitorul si mousele; Nu are responsabilitati de accesare a datelor; concentreaza cererea, procesarea si prezentarea datelor gestionate de portiunea server. Statiile de lucru client pot fi optimizate pentru aceste lucrari. Ele nu necesita discuri de capacitati mari dar beneficiaza de capacitati grafice sporite. Portiunea server - ruleaza softul Oracle si manipuleaza functiunile cerute pentru accesul concurent si partajat la date. Portiunea server receptioneaza si proceseaza comenzile SQL si PL/SQL generate de aplicatia client. Calculatorul care gestioneaza partea server poate fi optimizat pentru realizarea acestuia: discuri de capacitate mare si procesoare rapide. Realizarea in doua faze Oracle furnizeaza aceeasi siguranta a consistentei in mediu distribuit ca si in mediu nedistribuit. Oracle furnizeaza aceasta siguranta folosind modelul tranzactional si mecanismul de realizare in doua faze. Ca si intr-un sistem nedistribuit, tranzactiile vor fi planificate exact sa includa un set logic de comenzi SQL care se vor succede. Mecanismul Oracle de realizare in doua faze garanteaza ca indiferent de tipul defectiunii intilnite, sistem sau retea, se realizeaza o tranzactie distribuita sau o anuleaza in toate nodurile implicate pentru mentinerea consistentei datelor intre baza de date distribuita globala.

16

7. Tranzacii n mod obinuit, un sistem SGBD deservete mai muli utilizatori, care acceseaz concurent datele din tabele. Accesul concurent al utilizatorilor este asigurat prin capacitatea de multiprogramare a sistemului de operare al calculatorului gazd, care permite execuia concurent a mai multor procese. Execuia concurent a mai multor procese poate avea loc att ntr-un sistem uniprocesor, prin partajarea (mprirea) timpului de execuie al procesorului ntre mai multe procese, ct i ntr-un sistem multiprocesor n care mai multe procese pot fi executate n mod real simultan, pe mai multe procesoare ale sistemului. Indiferent de numrul de procesoare ale sistemului, accesul concurent al mai multor utilizatori la datele memorate n tabelele unei baze de date necesit tehnici de meninere a consistenei (corectitudinii) i a siguranei datelor memorate. Meninerea consistenei i a siguranei bazelor de date n situaia n care mai muli utilizatori le acceseaz concurent i n condiiile n care pot s apar erori de funcionare (defecte) ale sistemului de calcul se bazeaz pe conceptul de tranzacie care va fi prezentat n seciunea urmtoare. O tranzacie (transaction) este o unitate logic de prelucrare indivizibil (atomic) a datelor unei baze de date prin care se asigur consistena acesteia. n principiu, orice execuie a unui program care acceseaz o baz de date poate fi considerat o tranzacie, dac baza de date este ntr-o stare consistent att nainte ct i dup execuie. O tranzacie trebuie s asigure consistena bazei de date indiferent dac a fost executat individual sau concurent cu alte tranzacii precum i n condiiile n care au aprut defecte ale sistemului hardware n cursul execuiei tranzaciei. Se va studia problema consistenei bazelor de date pe exemplul unui sistem de rezervare a locurilor la curse aeriene. Un numr mare de ageni de vnzri vor accesa relaiile care memoreaz datele de rezervare i vnzare a biletelor de avion. De exemplu, vor exista relaiile: CURSE(IdCursa,AeroportPlecare,AeroportSosire,Data, NrLocuriLibere) PASAGERI(IdPasager,Nume,Prenume,Adresa, NrCreditCard) REZERVARI(IdRezervare,IdPasager,IdCursa) FACTURI(IdFactura,IdPasager,DataFacturarii,Pret) Cheile primare i strine au fost marcate conform conveniilor care au mai fost folosite i n seciunile precedente, iar semnificaia atributelor acestor relaii este destul de clar exprimat chiar prin numele lor. Detalii ca: tipul locului rezervat (turist, business, etc), reduceri de plat a biletului (bilet copil, etc.), mai multe rezervri fcute de acelai client, intervalul de timp dintre rezervare i cumprarea biletului, posibilitatea ca o rezervare s fie anulat, etc., au fost ignorate, dat fiind c nu modific fondul problemei de consisten a bazei de date.

17

Atunci cnd un agent de vnzri rezerv un loc la o curs i vinde biletul corespunztor, se efectueaz mai multe operaii: 11. Se insereaz o linie nou n tabelul PASAGERI, care conine datele pasagerului. 22. Dac exist locuri libere la cursa dorit, atunci se face propriu-zis rezervarea, prin inserarea unei linii noi n tabelul REZERVARI, linie care conine numrul de identificare al pasagerului, numrul de identificare al cursei i (eventual) numrul locului rezervat; altfel, rezervarea este imposibil. 33. La achitarea biletului se insereaz o linie n tabelul FACTURI. Acest nregistrare este folosit pentru a tipri o factur, care va fi folosit pentru plata n numerar sau va fi trimis companiei de cri de credit. 44. Se emite (tiprete) biletul (pornind de la datele din rezervare i factura corespunztoare). Dac sistemul se defecteaz dup ce s-a executat pasul 2, s-a fcut o rezervare, dar biletul nu a fost facturat i nici emis. Mai ru, dac defeciunea are loc dup ce s-a executat pasul 3, atunci clientului i se trimite factura, dar el nu a primit biletul. Astfel de situaii sunt, bineneles, inacceptabile. Chiar dac nu se defecteaz sistemul, pot s apar probleme dac baza de date este accesat concurent de mai muli utilizatori. De exemplu, dac doi ageni de vnzri atribuie acelai loc la doi pasageri diferii, atunci vor fi probleme la mbarcarea pasagerilor. Dac toate aciunile aferente unei rezervri ar fi grupate ca o operaie indivizibil (atomic), o parte din problemele artate mai sus ar disprea. O operaie indivizibil de acces la baza de date este numit tranzacie i ea fie execut cu succes toate aciunile i se termin cu o validare a modificrilor efectuate asupra bazei de date (commit), fie nu poate efectua (din diferite motive) toate aciunile i este abandonat i anulat (abort, rollback). n cazul n care o tranzacie a efectuat cu succes toate aciunile i este validat, n momentul validrii toate modificrile efectute asupra bazei de date devin permanente (durabile), vor fi vizibile altor tranzacii i nu mai pot fi anulate. Pn n momentul validrii, modificrile efectuate de tranzacie au un caracter provizoriu, nu sunt vizibile altor tranzacii i pot fi oricnd revocate (anulate). n cazul abandonrii unei tranzacii, execuia acesteia este oprit i efectele tuturor aciunilor executate pn n momentul abandonrii sunt anulate, astfel nct baza de date este adus n starea de dinaintea lansrii tranzaciei. 7.1 ANOMALII DE EXECUIE CONCURENTA A TRANZACIILOR Pentru studierea controlului concurenei i al refacerii datelor se vor aborda operaiile asupra bazei de date la nivel de articol de date (data item) i

18

bloc de memorare pe disc. La acest nivel, operaiile de acces la baza de date care pot s apar n cursul unei tranzacii sunt: 1 read(X): citete articolul X din baza de date ntr-o variabil a programului; pentru simplificarea notaiilor se va considera c variabila n care se citete articolul X este notat, de asemenea, cu X. 2 write(X): scrie variabila de program X n articolul X al bazei de date. Unitatea de transfer a datelor ntre discul magnetic i memoria principal a sistemului este un bloc, care corespunde unui sector de pe disc. n general, un articol de date este un cmp care memoreaz valoarea unui atribut dintr-o nregistrare (tuplu), dar poate fi o ntreag nregistrare sau chiar un bloc ntreg. Tranzaciile lansate de diferii utilizatori se pot executa concurent i este posibil s actualizeze aceleai articole ale bazei de date. Dac execuia concurent a tranzaciilor este necontrolat, este posibil ca baza de date s ajung ntr-o stare inconsistent (incorect), chiar dac fiecare tranzacie n parte este un program corect, a fost executat corect i nu au aprut defecte de funcionare ale sistemului. Actualizare pierdut (lost update). n figura de mai jos, este prezentat una din cele cteva situaii posibile de inconsisten a datelor memorate atunci cnd dou sau mai multe tranzacii sunt executate concurent, dar ntr-un mod necontrolat. Cele dou tranzacii T1 i T2 actualizeaz acelai articol (X) al bazei de date i se execut concurent prin partajarea (i ntreeserea) timpului de execuie al procesorului.

Inconsistena datelor provenit din execuia concurent necontrolat a dou tranzacii: a - actualizare pierdut; b - citire improprie. Pentru modul de ntreesere n timp a celor dou tranzacii prezentate n figura de mai sus, a valoarea memorat n articolul X n baza de date este X+M,

19

n locul valorii corecte XN+M (X fiind valoarea iniial a articolului, nainte de lansarea tranzaciilor). Actualizarea efectuat de tranzacia T1 a fost pierdut, dat fiind c tranzacia T2 folosete valoarea iniial a articolului X, nainte ca valoarea calculat de T1(XN) s fie memorat n baza de date. Acest tip de funcionare concurent incorect se numete actualizare pierdut. Citire improprie (dirty read). n figura de mai sus unde in cazul b este exemplificat o alt situaie de inconsisten a datelor, cunoscut sub denumirea de citire improprie - dirty read, sau dependen nevalidat - uncommited dependence sau actualizare temporar - temporary update. Aceast anomalie poate s apar atunci cnd una din tranzacii este abandonat, iar alt tranzacie concurent a utilizat articolele modificate, nainte de readucerea acestora la valoarea iniial. n acest exemplu tranzacia T1 a modificat articolul X, dup care a fost abandonat dintr-o cauz oarecare, dar tranzacia T2 a citit i a utilizat articolul modificat X, nainte ca acesta s fie readus la valoarea sa iniial. Rezultatul celor dou tranzacii este valoarea X N + M, n locul valorii corecte, X + M. Citire irepetabil (nonrepetable read). O alt problem de inconsisten a datelor, cunoscut sub numele de citire irepetabil (nonrepetable read, sau analiz inconsistent - inconsistent analysis), poate s apar dac o tranzacie T citete un articol de dou ori, iar ntre cele dou citiri, o alt tranzacie (T) a modificat chiar acel articol. n aceast situaie tranzacia T primete dou valori diferite ale aceluiai articol. Citire fantom (phantom read). Asemntoare problemei citirii irepetabile este problema citirii fantom, care apare atunci cnd o tranzacie prelucreaz un set de linii rezultat al unei interogri; dac n timpul acestei prelucrri o alt tranzacie a inserat sau a ters o linie care satisface condiia interogrii respective, atunci pot s apar sau s dispar linii din mulimea de linii rezultat, comportare asemntoare cu aparia sau dispariia fantomelor. Diferena dintre citirea fantom i citirea irepetabil este aceea c citirea fantom apare dac tranzaciile concurente modific numrul de linii utilizate de tranzacia curent (prin instruciuni INSERT sau DELETE), pe ct vreme citirea irepetabil apare dac tranzaciile concurente modific valorile din liniile existente i prelucrate de tranzacia curent (prin instruciuni UPDATE). Astfel de anomalii, care pot s apar la execuia concurent necontrolat a dou sau mai mai multor tranzacii, evideniaz necesitatea controlului concurenei n bazele de date. Consistena datelor memorate n baza de date trebuie s fie asigurat chiar n condiiile n care o tranzacie nu poate fi terminat cu succes, datorit apariiei unei erori de funcionare. 7.2 PROPRIETILE TRANZACIILOR Cele mai importante proprieti ale tranzaciilor sunt identificate n literatur prin acronimul ACID: atomicitate, consisten, izolare, durabilitate.

20

Atomicitatea (atomicity) este proprietatea unei tranzacii de a reprezenta o unitate de execuie indivizibil, adic de a executa totul sau nimic. Dac o tranzacie este ntrerupt dintr-o cauz oarecare, atunci sistemul SGBD va asigura, dup eliminarea cauzei care a ntrerupt executarea tranzaciei, fie completarea i validarea tranzaciei, fie abandonarea tranzaciei i anularea tuturor efectelor aciunilor efectuate de tranzacie pn n momentul ntreruperii. Consistena (consistency) unei tranzacii nseamn proprietatea acesteia de a efectua modificri corecte ale bazei de date. Cu alte cuvinte, o tranzacie transform baza de date dintr-o stare consistent n alt stare consistent. n strile intermediare prin care trece o baz de date n cursul unei tranzacii, este posibil s existe unele inconsistene, dar starea final n care ajunge baza de date dup execuia unei tranzacii trebuie s fie consistent. Starea unei baze de date este consistent dac respect toate constrngerile de integritate implicite sau explicite. Sistemul SGBD nu verific consistena bazei de date dup fiecare operaie (tranzacie), ci este sarcina proiectanilor aplicaiilor de baze de date ca operaiile prevzute n tranzacii s produc o stare consistent a bazei de date. Izolarea (isolation) este proprietatea unei tranzacii de a face vizibile modificrile efectuate numai dup ce a fost validat (committed). Dac n acest timp sunt executate alte tranzacii concurente, acestea nu vd modificrile pariale efectuate de tranzacia respectiv pn n momentul validrii tranzaciei. Proprietatea de izolare a tranzaciilor este important deoarece elimin fenomenul de abandonare n cascad a tranzaciilor. Dac rezultatele pariale ale unei tranzacii sunt vizibile altor tranzacii nainte de validarea acesteia i dac se ntmpl ca aceast tranzacie s fie abandonat i anulat (rollback), atunci toate tranzaciile care au accesat rezultatele pariale ale acesteia vor trebui s fie anulate; aceste operaii de anulare pot produce, la rndul lor alte anulri, .a.m.d. Acest fenomen de anulare n cascad creeaz un efect de domino. Izolarea este impus prin metode de control al concurenei, pe diferite niveluri de izolare. Durabilitarea (durability, sau permanena - permanency) este proprietatea prin care, dup validarea unei tranzacii, modificrile efectuate de aceasta n baza de date nu vor mai fi pierdute datorit unor defectri ulterioare a sistemului. Proprietatea de durabilitate este asigurat prin metode de refacere (recovery) ale sistemului SGBD.

7.3 STRILE TRANZACIILOR Dac operaiile de acces la baza de date ale unei tranzacii sunt numai operaii de citire, acea tranzacie se numete tranzacie de citire (read-only transaction) i controlul concurenei unor astfel de tranzacii este mult mai simplu. n cele ce urmeaz se va studia cazul general, al tranzaciilor de citire i scriere (read-write transactions) care efectueaz att regsiri de date (prin

21

operaii de citire) ct i actualizri (prin operaii de scriere), i care necesit tehnici de control al concurenei mult mai complexe. Operaiile efectuate de o tranzacie i nregistrate de administratorul de refacere (recovery manager), pentru a asigura cele patru proprieti importante ale tranzaciilor (ACID), sunt urmtoarele: 0 1. begin: aceast operaie marcheaz nceputul execuiei unei tranzacii. 1 2. read sau write: sunt operaii de citire sau scriere a articolelor n baza de date, executate n cadrul unei tranzacii. 2 3. end: aceast operaie marcheaz terminarea operaiilor de scriere sau citire din baza de date, ceea ce nseamn c tranzacia se poate termina; totui, este posibil s fie necesare unele operaii de verificare nainte de validarea (commit) tranzaciei. 3 4. commit: aceast operaie semnaleaz terminarea cu succes a tranzaciei, validarea tuturor modificrilor efectuate n baza de date i vizibilitatea modificrilor efectuate pentru alte tranzacii; din acest moment, modificrile efectuate nu mai pot fi anulate, nici pierdute printr-o defectare ulterioar a sistemului (bineneles, dac mecanismul de refacere al SGBD-ului funcioneaz corect). 4 5. rollback (sau abort): aceast operaie semnaleaz faptul c tranzacia a fost abandonat i c orice efect pe care tranzacia l-a avut asupra bazei de date trebuie s fie anulat (printr-o rulare napoi a operaiilor). 5 6. undo: aceast operaie este similar operaiei rollback, dar se aplic unei singure operaii, nu unei ntregi tranzacii. 6 7. redo: aceast operaie specific faptul c unele operaii ale unei tranzacii trebuie s fie executate din nou pentru a se putea valida ntreaga tranzacie. Ultimele dou operaii sunt necesare numai n anumite tehnici de refacere. n figura de mai jos este reprezentat diagrama de stare a unei tranzacii folosind limbajul UML, unde fiecare stare are o denumire i fiecare operaie provoac o anumit tranziie ntre stri. n starea ACTIVA se ajunge ca urmare a lansrii unei tranzacii prin operaia begin, iar execuia corect a operaiilor read sau write nu modific aceast stare. Atunci cnd o tranzacie se termin, ea trece n starea PARTIAL VALIDATA n care se efectueaz operaii de verificare impuse de tehnicile (protocoalele) de control al concurenei i de refacere. Dac ambele verificri sunt ndeplinite cu succes, atunci tranzacia este validat (prin execuia unei operaii commit) i trecut n starea VALIDATA; dac una sau ambele condiii nu sunt ndeplinite, tranzacia este trecut n starea ABANDONAT prin execuia operaiei abort. Starea TERMINAT este consecina imediat a atingerii uneia din strile VALIDAT sau ABANDONAT i nu necesit nici o alt operaie

22

pentru efectuarea acestei tranziii. n cursul strii ACTIV, orice tranzacie poate fi abandonat (i trecut n starea ABANDONAT prin execuia unei operaii abort), dac diferite verificri efectuate nu sunt ndeplinite.

Fig. 7.1 Diagrama de stare a unei tranzacii. Pentru refacerea bazei de date n condiiile n care unele tranzacii sunt abandonate sau n care pot aprea defecte de funcionare, sistemul SGBD menine un fiier jurnal, n care memoreaz operaiile efectuate de tranzacii. Fiierul jurnal este memorat pe disc i nu este afectat de diferite erori de execuie, cu excepia unei defectri catastrofice a discului. n plus, fiierul jurnal este salvat periodic pe un suport auxiliar (band magnetic), ca o msur de prevedere pentru astfel de defecte catastrofice. n fiierul jurnal (log file -> .LDF) se nregistreaz operaiile efectuate de fiecare tranzacie (cu exceptia tranzactiilor de tip bcp respectiv insert into), identificat printr-un identificator unic (T) generat de sistem. Prima nregistrare referitoare la o tranzacie cu identificatorul T este nregistrarea de start a tranzaciei: [begin,T]. La fiecare operaie write(X) executat de o tranzacie T, n fiierul jurnal se memoreaz o nregistrare de tipul [write,T,X,vechea_valoare,noua_valoare], dac pentru refacerea datelor se folosesc operaii undo, sau o nregistrare de tipul [write,T,X,noua_ valoare], dac se folosesc operaii redo. Sistemele care nu evit abandonarea n cascad a tranzaciilor nregistreaz n fiierul jurnal i operaiile de citire read(X), printr-o nregistrare de tipul [read,T,X,valoare]. Pentru fiecare tranzacie T, n fiierul jurnal se mai memoreaz starea de terminare: validat (printr-o nregistrare [commit,T] ) sau anulat (printr-o nregistrare[rollback,T]). Dup executarea validrii i nregistrarea ei n fiierul jurnal, efectul tranzaciei este permanent memorat n baza de date. Dac sistemul se defecteaz, la reluarea execuiei dup ndeprtarea defectului, sistemul SGBD va aduce baza de date ntr-o stare consistent prin examinarea fiierului jurnal. Dat fiind c fiierul jurnal conine o nregistrare 23

pentru fiecare operaie de scriere care a modificat valoarea unui articol al bazei de date, este posibil de a anula efectul tuturor operaiilor de scriere efectuate de o tranzacie care a fost lansat dar nu a fost validat, parcurgnd napoi fiierul jurnal i nlocuind valoarea existent a articolului modificat cu vechea valoare, memorat n fiierul jurnal. n cazul abandonrii n cascad, trebuie s fie abandonate i tranzaciile care au citit valori modificate de tranzaciile abandonate. 8. TEHNICI DE CONTROL AL CONCURENEI

Controlul execuiei concurente a mai multor tranzacii este necesar pentru a asigura proprietile de atomicitate, izolare i durabilitate a tranzaciilor i, prin aceasta, consistena datelor memorate. Controlul concurenei se poate realiza prin protocoale (set de reguli) impuse tranzaciilor astfel nct, dac acestea sunt respectate de fiecare tranzacie, orice planificare n care astfel de tranzacii particip este serializabil i, deci, corect. Cele mai utilizate tehnici de control al concurenei sunt cele bazate pe blocarea datelor prin intermediul zvoarelor (locks) i cele bazate pe mrci de timp (timestamps). Protocoalele de control al concurenei sunt implementate de sistemele de gestiune a bazelor de date astfel nct programatorii de aplicaii nu opereaz n mod explicit cu zvoare sau mrci de timp, ci stabilesc opiunile prin care sistemul SGBD adopt anumite tehnici de control al concurenei. Descrierea n continuare a algoritmilor i a operaiilor de execuie a tranzaciilor este o descriere de principiu, prezentat cu scopul nelegerii mecanismelor de baz ale controlului concurenei.

8.1 CONTROLUL CONCURENEI

Controlul concurenei tranzaciilor prin blocare (concurrency control using locking technique) se realizeaz folosind zvoare. Un zvor (lock) este o variabil asociat cu un articol al unei baze de date care descrie starea acelui articol n raport cu operaiile care se pot aplica acelui articol. Pentru un articol X, zvorul care controleaz accesul la acel articol va fi notat L(X). n sistemele de gestiune a bazelor de date se pot utiliza dou tipuri de zvoare, zvoare binare i zvoare cu stri multiple. Un zvor binar (binary lock) poate avea dou stri: liber (sau neblocat - free, unlocked) i ocupat (sau blocat - busy, locked) sau, mai simplu, strile 1 i 0. Asupra unui zvor L(X)se pot executa dou operaii: operaia de blocare, lock(X) i operaia de eliberare, unlock(X). Dac zvorul articolului X este deja blocat (L(X)=0), atunci operaia de blocare lock pune n ateptare tranzacia pn cnd zvorul se elibereaz. Dac zvorul este liber (L(X)=1), atunci tranzacia achiziioneaz zvorul, trecndu-l n starea ocupat, dup care execut operaiile necesare asupra articolului X. Dup

24

terminarea operaiilor asupra acelui articol, tranzacia elibereaz zvorul, prin execuia operaiei unlock. Dac zvorul a fost ocupat, tranzacia ateapt pn ce acesta este eliberat (de o alt tranzacie, care i-a terminat operaiile de acces la acel articol), dup care execut aceeai secven de operaii: blocarea zvorului, execuia operaiilor care acceseaz articolul respectiv i eliberarea zvorului. Pentru ca, n orice moment de timp, cel mult o tranzacie s dein un anumit zvor, trebuie ca operaia de blocare s fie executat ca operaie indivizibil. Acest cerin este implementat prin instruciuni speciale ale procesorului (de tip TestAndSet(TS)). Se pot preciza urmtoarele reguli (protocolul) pe care trebuie s le urmeze fiecare tranzacie care folosete zvoare binare: 1. O tranzacie T trebuie s lanseze o operaie de blocare a zvorului asignat articolului X (lock(X)), nainte de a efectua orice operaie de citire (read(X)) sau de scriere (write(X)) a articolului X. 2. O tranzacie T trebuie s elibereze zvorul unui articol X (prin operaia unlock(X)) dup ce a efectuat toate operaiile de citire (read(X)) sau de scriere (write(X)) a articolului X. 3. O tranzacie T nu poate cere un zvor pe care l deine deja. 4. O tranzacie T nu poate elibera un zvor pe care nu l deine.

1ntre operaia de blocare (lock(X)) lansat de o tranzacie T i operaia de eliberare (unlock(X)) a unui zvor L(X), tranzacia T deine zvorul respectiv. n cazul zvoarelor binare, cel mult o tranzacie poate deine un zvor la un moment dat, i nici o alt tranzacie nu poate accesa articolul respectiv. Se poate spune c zvoarele binare realizeaz un mecanism de excludere mutual, prin care accesul unei tranzacii la un articol (tranzacia care deine zvorul acelui articol) exclude accesul altor tranzacii la acel articol. Dei este foarte general i relativ simplu de utilizat, tehnica zvoarelor binare este prea restrictiv i limiteaz n mod nejustificat concurena n execuia tranzaciilor. De exemplu, mai multe tranzacii pot efectua operaii de citire n mod concurent, fr ca acest lucru s afecteze consistena bazei de date, dar acest lucru este interzis n tehnica zvoarelor binare. De aceea, multe sisteme de gestiune a bazelor de date utilizeaz zvoare cu stri multiple.

8.2 ANALIZA CONTROLULUI CONCURENEI

25

Dac fiecare tranzacie lucreaz pe rnd, se pierde timp cnd calculatorul st s atepte terminarea unei operaii de intrare/ieire, sau n timpul altei ntreruperi. Pe de alt parte, dac lsm s lucreze deodat, fiecare n timpul lsat liber de cel din nainte, zicem c avem tranzacii concurente. Concurena va mri randamentul timpului de lucru al calculatorului dar ea trebuie controlat pentru c altfel poate da natere la inconsisten. Prezint n continuare, trei exemple n care art cum se poate pierde cinsistena. n primul exemplu tranzacia T1 citete contul lui x (balx) i scade 10 din cont. Tranzacia T2 citete contul lui x (balx) i adun 100 la cont. Pornind cu un cont de 100, evident c dac se executa mai nti prima tranzacie i apoi a doua contul lui x ar fi fost 100-10+100=190. n cealalt ordine am fi avut 100+100-10=190 aceeai valoare. S considerm urmtorul plan de tranzacii. Un plan de tranzacii este o secven posibil n timp a modului de execuie a tranzaciilor. Putem observa, n timpii nscrii n stnga, cum evolueaz contul din ultima coloan. Time A t1 A t2 A t3 A t4 A t5 A t6 T1 begin_transaction cit(balx) balx = balx - 10 scrie(balx) commit T2 begin_transaction cit(balx) balx = balx + 10 scrie(balx) commit balx 100 100 100 200 90 90

Problema se numete problema pierderii actualizrii. Problema dependenei de o tranzacie neterminat apare cnd o tranzacie este lsats vad rezultatele intermediare alei alte tranzacii nainte ca ea s fac commit. Aceleai tranzacii ca n figura precedent se desfoar acum dup un alt plan. Time A t1 A t2 A t3 A t4 A t5 A t6 T3 T4 begin_transaction cit(balx) balx = balx + 10 scrie(balx) rollback balx 100 100 100 200 200 100

begin_transaction cit(balx) balx = balx - 10

26

A t7 A t8

scrie(balx) commit

190 190

Rezultatul este 190, ai putea spune c este bun, dar inei cont c tranzacia 4 a fost ntrerupt i, cnd se va relua, va mai mri cu 100 contul ceea ce va deveni incorect. Chiar i cnd unele tranzacii numai citesc baza de date se pot ntmpla neplceri. Aceast problem este problema analizei inconsistente sau problema citirii murdare. De exemplu tranzaciile T5 i T6 executate serial, adic una dup alta, ar trebui s dea rezultatele: T5T6 balx=100-10=90, balz=25+10=35, sum=90+50+35+175 sau T6T5 sum=100+50+25=175, balx=100-10=90, balz=25+10=35 i putem vedea n figura urmtoare ce se poate ntmpla ncazul concurenei libere, necontrolate: Time A t1 A t2 A t3 A t4 A t5 A t6 A t7 10 A t8 A t9 A t10 A t11 scrie(balz) commit cit(balz) sum = sum + balz commit 90 90 90 90 50 50 50 50 35 35 35 35 150 150 185 185 T5 begin_transaction cit(balx) balx = balx -10 scrie(balx) cit(balz) balz = balz + T6 begin_transaction sum = 0 cit(balx) sum = sum + balx cit(baly) sum = sum + baly balx baly 100 100 100 100 90 90 90 50 50 50 50 50 50 50 balz 25 25 25 25 25 25 25 sum 0 0 100 100 150 150

Nu putem, deci, lsa concurena necontrolat, dar nici nu este profitabil s o desfiinm de tot. Spunem c un plan de tranzacii este serial cnd tranzaciile se execut una dup alta fr a intercala operaii din alt tranzacie. Spunem c un plan de tranzacii este neserial cnd tranzaciile snt concurente , adic ntre operaiile unei tranzacii se intercaleaz operaiile alteia. Vom spune c un plan de tranzacii este corect atunci cnd el are ca rezultat acelai cu unul executat serial; acesta se va numi serializabil. Avei deja exemple de planuri neserializabile. Am vzut c problemele apar atunci cnd o tranzacie vede (citete) sau scrie ntr-un moment nepotrivit. Ideile de a controla concurena snt legate de a

27

nu lsa pe cellalt (de a bloca) sau de a ine cont de momente (de a marca timpul). Ce nseamn s blocm : Cnd o tranzacie blocheaz partajat (part_bloc) o anumit unitate de memorie, o alt tranzacie nu mai poate s rescrie tot acolo, iar cnd o tranzacie blocheaz exclusiv (ex_bloc) o alta nu mai poate nici s o citeasc. Despre ce unitate de memorie este vorba? Aceasta este problema granularitii la care se face blocajul. Blocajul se poate face la nivel de: ntreaga baz de date tabela(fiier) nregistrare (cel mai des) cmp din nregistrare Mai spunem c avem granularitate dinamic atunci cnd SGBD-ul poate s schimbe granularitatea n timpul unei tranzacii. Cititorul poate s demonstreze singur pe un exemplu (vezi problema ) c numai simpla blocare urmat cndva de deblocare (debloc) nu asigur serializabilitatea. Serializabilitatea este asigurat dac se respect protocolul de blocare n dou faze. Acesta const din mprirea tranzaciei n dou faze una de blocri i creteri de blocaje i a doua de descreteri i deblocaje. Aceasta nseamn c dup ce s-a fcut prima deblocare nu se mai pot face blocri. Urmtoarele trei exemple reiau tranzaciile T1 ,T2 respectiv T3 , T4, T5 , T6 cu protocolul n dou faze i realizeaz planuri serializabile.

Time A t1 A t2 A t3 A t4 A t5 A t6 A t7 A t8 A t9 A t10 A t11

T1 begin_transaction ex_bloc(balx) ATEAPT ATEAPT ATEAPT cit(balx) balx = balx -10 scrie(balx) debloc(balx) commit

T2 begin_transaction ex_bloc(balx) cit(balx) balx = balx +100 scrie(balx) debloc(balx) commit

balx 100 100 100 100 200 200 200 200 190 190 190

Time A t1 A t2 A t3

T3

T4 begin_transaction ex_bloc(balx) cit(balx)

balx 100 100 100

28

A t4 A t5 A t6 A t7 A t8 A t9 A t10 A t11 A t12

begin_transaction ex_bloc(balx) ATEAPT ATEAPT cit(balx) balx = balx -10 scrie(balx) debloc(balx) commit

balx = balx +100 scrie(balx) debloc(balx) rollback

100 200 100 100 100 100 90 90 90

Time A t1 A t2 A t3 A t4 A t5 A t6 A t7 A t8 A t9 A t10 A t11 A t12 A t13 A t14 A t15 A t16 A t17 A t18 A t19 A t20 A t21 A t22

T5 begin_transaction ex_bloc(balx ) cit(balx) balx = balx -10 scrie(balx) ex_bloc(balz ) cit(balz) balz = balz + 10 scrie(balz) debloc(balx , balz) commit

T6 begin_transaction sum = 0 part_bloc(balx) ATEAPT ATEAPT ATEAPT ATEAPT ATEAPT ATEAPT ATEAPT ATEAPT cit(balx) sum = sum + balx part_bloc(baly) cit(baly) sum = sum + baly part_bloc(balz) cit(balz) sum = sum + balz debloc(balx,baly,balz ) commit

balx baly 100 50 100 50 100 50 100 50 100 50 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50

balz 25 25 25 25 25 25 25 25 25 35 35 35 35 35 35 35 35 35 35 35 35 35

sum 0 0 0 0 0 0 0 0 0 0 0 0 90 90 90 140 140 140 175 175 175

29

Protocolul de blocare n dou faze asigur serializanilitatea dar nu ne scutete de probleme. Pezentm n cele dou exemple urmtoare rollback-ul n cascad i blocajul ciclic. La momentul t14 tranzacia T7 face rollback (dintr-un motiv extern) i, pentru c T8 este dependent de T7 care a citit o nregistrare care a fost actualizat de T7, trebuie s fac i T8 rollback, ceea ce pe urm se ntmpl i cu T9.

Time A t1 A t2 A t3 A t4 A t5 A t6 A t7 A t8 A t9 A t10 A t11 A t12 A t13 A t14 A t15 A t16 A t17 A t18

T7 begin_transaction ex_bloc(balx) cit(balx) part_bloc(baly) balx = baly + balx scrie(balx) debloc(balx) rollback

T8

T9

begin_transaction ex_bloc(balx) cit(balx) balx = balx +100 scrie(balx) debloc(balx) rollback

begin_transaction part_bloc(bal x) rollback

O alt problem este blocarea ciclic prezentat n exemplul urmtor. Cele dou trnzacii T10 i T11 se blocheaz reciproc.

30

Time A t1 A t2 A t3 A t4 A t5 A t6 A t7 A t8 A t9 A t10 A t11

T10 begin_transaction ex_bloc(balx) cit(balx) balx = balx -10 scrie(balx) ex_bloc(baly) ATEAPT ATEAPT ATEAPT

T11 begin_transaction ex_bloc(baly) cit(baly) baly = baly +100 scrie(baly) ex_bloc(balx) ATEAPT ATEAPT ATEAPT

Blocajul ciclic este detectat , de obicei, prin constuirea unui graf de preceden care arat dependena ntre tranzacii n felul urmtor: se creaz un nod pentru fiecare tranzacie se creaz o muchie direcionat Ti Tj dac tranzacia Ti ateapt s blocheze o nregistrare care este deja blocat de Tj. Pe acest graf se detecteaz un blocaj ciclic dac exist un circuit. Graful tranzactiilor:

T10

T11

O alt metod de a evita blocajul ciclic pstrnd serializabilitatea este protocolul cu marcarea timpului (time stamp). Acest protocol ataeaz un timp (timpul real din calculator sau un numr care se mrete autmat de cte ori este solicitat) fiecrei tranzacii (marc(T)) i timpul tranzaciei care realizeaz operaia fiecrei citiri sau scrieri a unei nregistrri. Deci fiecare tranzacie va avea o valoare de marcj i fiecare nregiistrare prelucrat va avea dou marcaje; unul care spune ce marcaj a avut tranzacia care a citit-o (cit_marc) i cellalt care spune ce marcaj a avut tranzacia care a scris-o (scri_marc). Numai n urmtoarele trei situaii se pun probleme deosebite: 1. Tranzacia T cere s citeasc o nregistrare x care a fost deja actualizat de o tranzacie cu scri_marc(x) > marc(T), adic o nregistrare scris de o tranzacie care a nceput mai trziu. Ce ar rescrie ea ar putea da natere la inconsisten deci trnzacia respectiv trebuie ntrerupt.

31

2. Tranzacia cere s scrie nregistrarea x a crei valoare a fost deja citit de o tranzacie care a nceput mai trziu marc(T) < cit_marc(x). Aceasta nseamn c tranzacia vrea s rescrie o nregistrare, pe care o alt tranzacie nceput mai trziu, a citit-o i o folosete. i n acest caz tranzacia trebuie ntrerupt. 3. Tranzacia cere s scrie o nregistrare x a crei valoare a fost deja scris de o tranzacie care a nceput mai trziu, adic marc(T) < scri_marc(x). Este o ncercare de a scrie o valoare perimat i n acest caz se ignor aceast scriere. n figura urmtoare se poate observa cum funcioneaz acest protocol.

Time A t1 A t2 A t3 A t4 A t5 A t6 A t7 A t8 A t9 A t10 A t11 A t12 A t13 A t14 A t15 A t16 A t17 A t18

Op

T7 begin_transaction cit(balx) balx = balx +100 scrie(balx)

T8

T9

cit(balx) balx = balx +10 scrie(balx) cit(baly) baly = baly +20 cit(baly) scrie(baly) baly = baly +30 scrie(baly) balz=100 scrie(balz) balz=50 scrie(balz) cit(baly) baly = baly +20 scrie(baly)

begin_transaction cit(baly) baly = baly +20 scrie(baly)**

begin_transaction cit(baly) baly = baly +30 scrie(baly) balz=100 scrie(balz) commit

balz=50 scrie(balz)* commit

begin_transaction cit(baly) baly = baly +20 scrie(baly) commit

* la timpul t8 scrierea de ctre tranzacia T13 violeaz regula 2 i de aceea este ntrerupt i reluat la momentul t14 ** la timpul t14 scrierea de ctre tranzacia T12 poate fi ignorat conform celei de a treia reguli 8.3 Tehnici optimiste. Nu ntotdeuna este necesar s pierdem timp n calculator controlnd concurena. Atunci cnd conflictele ntre tranzacii snt rare putem adopta aa32

numitele tehnici optimiste. Asta nseamn s lsm tranzaciile s ruleze fr s impunem ntrzieri care s asigure serializabilitatea, iar cnd o tranzacie vrea s fac commit s efectum un control care s determine dac a avut loc un conflict. Dac a avut loc un conflict, tranzacia trebuie ntrerupt i restartat. Pentru c am spus c aceeste conflicte snt rare, aceste nteruperi i restartri vor fi, i ele, rare. Distingem trei faze ale unui control optimist al concurenei. Faza de citire. Aceast faz dureaz de la nceputul tranzaciei pn nainte de commit. Tranzacia citete valorile de care are nevoie din baza de date i le stocheaz in variabile locale. Actualizrile nu snt fcute direct n baza de date ci ntr-o copie local. Faza de validare. Urmeaz dup faza de citire i controleaz dac nu sar nclca serializabilitatea n cazul c s-ar aplica actulizarea n baza de date. Dac avem o tranzacie care numai citete baza (adic nu scrie), controlul const n a verifica dac datele citite snt nc datele curente n baz i, dac este aa, atunci se face commit, altfel se ntrerupe i se reia mai trziu. Dac trnzacia face i rescrieri n baz, atunci se verific dac se pstreaz serializabilitatea i dac baza de date rmne ntr-o stare consistent; dac acest lucru nu se ntmpl, atunci se ntrerupe. Faza de scriere. Este o faz care este necesar numai la tranzaciile care fac rescrieri. Dac faza anterioar s-a terminat cu succes, atunci actualizrile efectuate n copia local, snt nregistrate definitiv n baza de date.

Iat cum se desfoar acest tip de control: Fiecrei tranzacii i este ataat, la nceputul primei faze, un marcaj start(T), la nceputul celei de a doua faze, valid(T) i la sfrit fin(T), dup scriere n copia local, daceste cazul. Ca s treac faza de validare trebuie s avem una din urmtoarele situaii: 1) Toate tranzaciile cu un marcaj mai mic, trebuie s se fi terminat nainte ca tranzacia T s fi nceput; adic fin(S) < start(T). 2) Dac tranzacia start(S) < start(T) (S a nceput naintea lui T) i nu s-a terminat adic fin(S) < fin(T) atunci: a. Datele scrise de tranzacia anterioar S nu snt cele citite de cea curent T i b. Tranzacia anterioar S i completeaz faza de scriere nainte ca tranzacia curent T s intre n faza de validare adic start(T) < fin(S) < valid(T). Dei tehnicile optimiste snt eficiente cnd conflictele snt rare totui pot aprea multe reluri (rollback); s reinem c aceste reluri nu snt n cascad pentru c se lucreaz pe o coppie local. Ce ne facem dac apar totii inconsistene? Trebuie s{ [putem recupera baza de date ntr-o stare anterioar consistent.

33

8.4 TEHNICI DE REFACERE A BAZELOR DE DATE

Refacerea unei baze de date dup producerea unui defect (database recovery) nseamn aducerea bazei de date ntr-o stare precedent corect, din care, eventual, se poate reconstrui o nou stare corect i ct mai apropiat de momentul apariiei defectului. Pentru operaiile de refacere se folosete fiierul jurnal, i (sau) o copie de rezerv a bazei de date (database backup) stocat n general pe band magnetic. Dac baza de date nu este distrus fizic, dar a devenit inconsistent datorit unui defect necatastrofic, atunci strategia de refacere const n a anula modificrile care au produs inconsistena (prin operaii undo) sau, uneori, de a executa din nou anumite modificri care s-au pierdut (prin operaii redo). n acest caz nu este necesar copia de rezerv, ci se folosete starea actual a bazei de date i fiierul jurnal. Dac baza de date a fost puternic distrus, datorit unei defectri serioase a discului, atunci se restaureaz starea bazei de date din copia de rezerv, dup care se reconstruiete o stare ct mai actual prin reaplicarea tuturor tranzaciilor validate existente n fiierul jurnal, dac acesta nu a fost deteriorat, sau din ultima copie salvat a fiierului jurnal.

9. CONTROLUL TRANZACIILOR Tehnicile de gestiune a tranzaciilor i de refacere a datelor prezentate n seciunile precedente sunt incluse n componentele sistemelor de gestiune a bazelor de date (administratorul de tranzacii i administratorul de refacere) ntr-o form specific fiecrui SGBD, cu diferite grade de complexitate. Aplicaiile de baze de date au un control destul de limitat asupra opiunilor de gestiune a tranzaciilor prin intermediul unor comenzi care se bazeaz pe standardul SQL2. n standardul SQL2 sunt prevzute urmtoarele comenzi de specificare a tranzaciilor: SET TRANSACTION optiuni COMMIT [WORK] ROLLBACK [WORK] Comanda SET TRANSACTION stabilete proprietile tranzaciilor i admite urmtoarele opiuni de setare a modului de gestiune a tranzaciilor: 0 Nivelul de izolare a tranzaciilor (ISOLATION LEVEL) cu valorile posibile: READ UNCOMMITTED, READ COMMITTED, REPETABLE READS, SERIALIZABLE. 1 Modul de acces la articole - cu valorile posibile READ ONLY, READ WRITE. 2 Modul de refacere a datelor (SET CONSTRAINTS), cu valorile posibile DEFERRED (refacere amnat) i IMMEDIATE (refacere imediat).

34

1Nivelul de izolare reprezint gradul pn la care o tranzacie trebuie s fie izolat de celelalte tranzacii. Izolarea total a tranzaciilor, n care starea bazei de date este consistent n permanen, iar n tranzacii nu apar nici un fel de anomalii, este obinut pe nivelul cel mai nalt de izolare, denumit SERIALIZABLE, care corespunde planificrilor serializabile (echivalente cu planificri seriale ale tranzaciilor). Acest nivel de izolare total micoreaz gradul de concuren a tranzaciilor, i, ori de cte ori este posibil, se admit niveluri de izolare mai sczute, care admit unele anomalii (controlabile) de execuie a tranzaciilor i asigur un grad de concuren mai ridicat. Nivelurile de izolare determin modul n care sistemul de gestiune a bazei de date introduce diferitele mecanisme de control al concurenei (cel mai frecvent zvoare cu stri multiple). De exemplu, pe nivelul READ COMMITTED, sunt prevzute zvoare partajate pentru toate articolele citite, ceea ce mpiedic apariia citirilor improprii, dar aceste zvoare sunt eliberate nainte de terminarea tranzaciei i, de aceea, pot rezulta citiri nerepetabile i citiri fantom (tabelul de mai jos)

Nivelurile de izolare a tranzaciilor . Pe orice nivel de izolare, inclusiv pe cel mai slab (READ UNCOMMITTED), se folosesc mecanisme de control al concurenei tranzaciilor care previn pierderea actualizrilor. Astfel de anomalii sunt foarte grave, baza de date nu reflect operaiile care s-au efectuat asupra datelor i nici nu exist vreo posibilitate de refacere a acestor pierderi. De aceea nu este prevzut nici un nivel de izolare care s permit pierderea actualizrii datelor. Pe toate nivelurile de izolare, cu excepia nivelului SERIALIZABLE, pot s apar diferite anomalii, dar aceste anomalii sunt anomalii de citire, care pot fi gestionate de tranzacii, i nu anomalii memorate permanent n baza de date. De exemplu, dac se tie c o tranzacie va fi executat pe nivelul de izolare READ COMMITTED, atunci se poate scrie codul tranzaciei astfel nct aceasta s nu citeasc datele din tabele dect o singur dat i s le memoreze local pentru o alt utilizare, n loc s citeasc de mai multe ori din tabele. Cu ct nivelul de izolare a tranzaciilor este mai sczut, cu att pot s apar mai multe anomalii de actualizare, dar crete gradul de concuren a execuiei i scade probabilitatea de apariie a impasului. De aceea, pentru proiectarea unor tranzacii eficiente se recomand utilizarea unor niveluri de izolare ct mai sczute, att ct este posibil pentru ca tranzaciile respective s se execute totui corect. O tranzacie se poate termina fie prin validare (cu comanda 35

COMMIT), fie prin anulare (cu comanda ROLLBACK). Comanda COMMIT garanteaz c toate modificrile efectuate de tranzacia respectiv au devenit permanente. Comanda ROLLBACK termin o tranzacie i anuleaz (ruleaz napoi) toate modificrile executate pn n acel punct de acea tranzacie; aceast comand se trimite atunci cnd apare o anumit condiie (posibil o eroare), care face imposibil continuarea cu succes a tuturor operaiilor tranzaciei. Instruciunile COMMIT i ROLLBACK elibereaz resursele ocupate de tranzacie, cum ar fi zvoarele articolelor. n general, sistemele SGBD implementeaz protocoalele i funciile de control al concurenei i gestioneaz automat execuia tranzaciilor i refacerea datelor, pentru a asigura consistena i integritatea datelor memorate. Tranzaciile sunt administrate la nivelul conexiunii unei aplicaii client cu serverul bazei de date: atunci cnd o tranzacie a fost nceput pe o conexiune, toate instruciunile urmtoare executate pe acea conexiune fac parte din acea tranzacie, pn ce aceasta se termin. Programatorii de aplicaii au responsabilitatea s stabileasc punctele de nceput i de sfrit ale tranzaciilor i s prevad n fiecare tranzacie secvenele de modificri ale datelor astfel nct acestea s lase baza de date ntr-o stare consistent, care s respecte toate constrngerile, implicite i explicite. De asemenea, se pot selecta prin program diferite opiuni de control (nivel de izolare, mod de acces, etc.). Aceste operaii se pot realiza prin intermediul unor comenzi care sunt variante ale comenzilor SQL de baz i care se transmit SGBD-ului, fie prin instruciuni ale unui limbaj procedural de extensie a limbajului SQL, fie prin funcii ale interfeelor de programare (cum sunt interfeele ODBC, JDBC) (exemple in manual). Tranzaciile sunt corecte dac las baza de date ntr-o stare consistent i sunt cu att mai eficiente cu ct sunt mai scurte (ca timp de execuie i ca numr de articole ale bazei de date accesate). Respectarea acestor cerine are o influen pozitiv asupra performanelor bazelor de date att prin limitarea frecvenei de apariie a impasului (n cazul folosirii zvoarelor), ct i din punct de vedere al eficienei operaiilor de anulare i de blocare a resurselor. Ori de cte ori se poate nlocui o tranzacie complex, cu numr de operaii i timp de execuie ridicate, cu mai multe tranzacii scurte, este indicat s se fac aceast transformare. De asemenea, pentru meninerea tranzaciilor ct mai scurte posibil, se recomand ca o tranzacie s nu fie pornit pn ce nu au fost pregtite toate datele (citirea datelor de intrare, parcurgerea, analiza i prelucrarea acestora). 10. Blocari n absena unor mecanisme de control al concurenei pot aprea fenomene nedorite, care pot conduce la rezultate eronate sau la coruperea consistenei bazei de date. Literatura de specialitate menioneaz n general trei anomalii tipice care pot s apar [DATE95]. Pentru exemplificare vom considera

36

o aplicaie de rezervare de locuri pentru o companie de transporturi aeriene (vezi caseta "Exemplu aplicativ"). S considerm dou tranzacii de tip "Rezervare", R1 i R2, care se execut n mod concurent i care, ntmpltor, se refer la acelai zbor Z. Vom face abstracie de operatia de inserare (care nu este important n acest context) i vom folosi o notaie simplificat: deoarece selecia este - n esent - o citire, o vom nota cu Read. Modificarea, fiind o scriere, o vom nota cu Write. O posibil succesiune temporal a evenimentelor ar putea fi urmtoarea: t1 - R1: Read Z t2 - R2: Read Z t3 - R1: Write Z t4 - R2: Write Z ... Citirile efectuate de cele dou tranzacii vor gsi linia n aceeai stare. S presupunem c valoarea cmpului VINDUT este 25. Ambele tranzacii vor seta variabilele lor locale vndut la valoarea 25. Actualizarea efectuat de tranzacia R1 la momentul t3 va modifica valoarea cmpului la 26. La momentul t4, tranzacia R2 actualizeaz i ea linia Z, plasnd ns n cmpul VINDUT aceeai valoare. Se realizeaz dou rezervri, dar numrul locurilor vndute crete doar cu o unitate. Dac numrul solicitrilor este mare, este foarte probabil c va fi vndut un loc n plus la cursa respectiv. Anomalia, numit "modificarea pierdut" (the lost update) a survenit datorit faptului c tranzacia R2 i-a bazat actualizarea de la momentul t4 pe o valoare citit la momentul t2, care ns a fost ntre timp (la momentul t3) modificat de tranzacia R1. Practic, efectul actualizrii realizate de tranzacia R1 la momentul t3 s-a pierdut. Dac tranzacia R2 ar fi citit linia Z dup ce ea a fost modificat de R1, atunci R2 ar fi plasat n cmpul VINDUT valoarea 27, ceea ce ar fi fost corect. O alt situatie posibil este cea n care una dintre tranzacii este anulat. S considerm scenariul urmtor: t1 - R2: Read Z t2 - R2: Write Z t3 - R1: Read Z t4 - R2: ROLLBACK t5 - R1: Write Z ... n aceast situaie, tranzacia R1 va avea n variabilele locale rezultatul scris de tranzacia R2 la momentul t2. Anularea tranzaciei R2 poate surveni din motive diverse (s presupunem c adugarea liniei corespunztoare rezervrii n tabela

37

REZ eueaz din lips de spaiu pe disc) i va provoca revenirea liniei Z la valorile dinainte de momentul t2. n acest caz, tranzacia R1 i va baza aciunile viitoare pe nite valori care, practic, nu au existat niciodat n baza de date! S presupunem c la momentul t1 cmpul VINDUT al liniei Z coninea valoarea 25. La momentul t2 aceast valoare este incrementat, astfel nct tranzacia R1 va citi la momentul t3 valoarea 26. La momentul t4, tranzacia R2 este anulat i, n consecint, valoarea cmpului VINDUT al liniei Z va fi adus la valoarea pe careo avea nainte de nceperea tranzaciei R2, deci 25. La momentul t5, tranzacia va scrie n linia Z valoarea 27. Ceea ce este, evident, greit. Anomalia (numit uncommitted dependency) provine din faptul c tranzacia R1 a citit rezultate intermediare ale tranzaciei R2. Pentru a exemplifica o a treia anomalie, numit "analiza inconsistent" (inconsistent analysis) vom considera tabela CLIENT, asupra creia se execut n mod concurent dou tranzacii. Tranzacia T1 calculeaz suma total ncasat de la pasagerii cursei Z, n timp ce tranzacia T2 transfer o anumit sum x din contul unui client C3 n contul unui client C1 (care s-a ntmplat c au zburat mpreun). n mod normal suma total ar trebui s fie aceeai indiferent n care cont se afla suma x. S presupunem c soldurile clientilor C1, C2 i C3 sunt 200, 100 i respectiv 300, iar x este 20. Dar iat ce se poate ntmpla: t1 - T1: Read C1 (sold = 200, total = 200) t2 - T1: Read C2 (sold = 100, total = 300) t3 - T2: Read C3 (sold = 300) t4 - T2: Write C3 (sold = 280) t5 - T2: Read C1 (sold = 200) t6 - T2: Write C1 (sold = 220) t7 - T2: Commit t8 - T1: Read C3 (sold = 280, total = 580) ... Pentru clientii C1, C2 i C3 totalul ar fi trebuit s fie, desigur, 600. Este evident c suma total va fi greit. Spre deosebire de celelalte dou cazuri prezentate, nu mai este vorba despre citirea unor valori actualizate de o tranzacie nainte de comiterea acesteia. T1 nu citete nimic n timpul dintre momentul nceperii tranzaciei T2 i pn la comiterea acesteia. Problema provine din faptul c T1 a citit unul dintre conturi nainte de transfer iar pe cellalt dup transfer. n toate cele trei cazuri, anomaliile sunt provocate de interferenele dintre tranzacii care se execut n mod concurent. O metod simpl (ba chiar simplist...) de evitare a acestor interferene ar fi executarea complet a tranzaciilor n ordinea nceperii lor. n acest caz ns performanele serverului de date ar fi afectate n mod inacceptabil. Ar fi ca i cum ntr-un mare magazin cu

38

autoservire clienii ar fi lsai nuntru unul cte unul, fiecare dup ce clientul precedent i-a terminat toate cumprturile. Pentru a echilibra ct mai bine performana i sigurana, constructorii de sisteme de gestiune a bazelor de date au dezvoltat mai multe procedee prin care interferenele ntre tranzaciile concurente s poat fi controlate. Cel mai rspndit este mecanismul bazat pe blocarea (locking) unor poriuni ale bazei de date pentru a interzice altor tranzacii accesul la datele respective pe durat unor operaiuni critice efectuate de o tranzacie. O alt metod este cea bazat pe aplicarea unor "mrci de timp" (timestamping) asupra tranzaciilor i a obiectelor implicate n tranzacii. Ambele procedee (precum i procedeele "hibride") pornesc de la premisa pesimist c interferenele nedorite sunt oricnd posibile i chiar probabile, deci se bazeaz pe prevenirea lor. Exist ns i o abordare optimist, care pleac de "prezumia de nevinovie" i care ncearc doar s depisteze i s rezolve conflictele n cazul n care acestea apar. Toate metodele au avantaje i dezavantaje, fiecare dintre ele se preteaz la anumite aplicaii i sunt inacceptabile n cazul altora. Idea pe care se bazeaz tehnica blocrii este foarte simpl: o tranzacie care a nceput s opereze asupra unor date trebuie s interzic accesul altor tranzacii la datele respective pn n momentul n care operaia se ncheie. n acest timp, datele sunt "inute sub cheie" (to lock - a ncuia, a zvor). Controlul blocrii datelor este asigurat de o component a SGBD-ului numit Lock Manager (LM). n momentul n care o tranzacie T dorete s acceseze un anumit obiect al bazei de date (pies de date), va cere componentei LM blocarea obiectului. Dac obiectul este blocat de o alt tranzacie, tranzacia T va fi pus n stare de ateptare (wait) pn cnd obiectul este eliberat. S re-analizm a doua anomalie prezentat n seciunea precedent (uncommitted dependency). La momentul t1 tranzacia R2 blocheaz linia Z. La momentul t3, tranzacia R1 cere la rndul ei blocarea liniei Z dar, linia fiind deja blocat de R2, este pus n stare de ateptare. La momentul t4, tranzacia R2 se termin (prin ROLLBACK) i elibereaz linia Z. Abia acum R1 obine blocarea liniei Z i poate s o acceseze. Datele asupra crora acioneaz acum R1 sunt "curate" (efectele tranzaciei R2 au fost anulate), deci anomalia a fost evitat. Se poate observa cu uurin c aceast modalitate de blocare este prea restrictiv. Anomaliile apar doar n cazul actualizrilor datelor, ceea ce sugereaz c o rafinare a tehnicii implic folosirea a dou tipuri de blocri:

Blocare partajat (share lock sau S lock) - Permite citirea obiectului dar interzice modificarea acestuia, motiv pentru care mai este numit "blocare pentru citire" (read lock). Mai multe tranzacii pot bloca simultan pentru citire un anumit obiect. Blocare exclusiv (exclusive lock sau X lock) - Interzice accesul altor tranzacii la obiectul blocat, fie pentru citire, fie pentru modificare. Blocarea

39

exclusiv este mai "tare" dect blocarea partajat, fiind folosit doar pentru actualizri, motiv pentru care mai este numit "blocare pentru scriere" (write lock). Se poate observa c anumite cereri de blocare asupra unui obiect pot fi compatibile sau nu, n functie de tipul blocrii. Compatibilitatea cererilor de blocare poate fi exprimat sintetic printr-o matrice de compatibilitate (vezi caseta "Focus: Blocri"). O situaie special este cea n care o tranzacie blocheaz pentru citire un obiect i dorete s obin o blocare exclusiv. Dac obiectul respectiv nu este blocat partajat i de ctre alte tranzacii, blocarea exclusiv este obinut de tranzacia n cauz. Procedeul de numete "promovarea blocrii" (lock promotion). S ne oprim puin pentru cteva observaii: a. n cazul celor mai multe SGBD-uri, blocarea este implicit: orice operaie asupra datelor este automat precedat de cererea pentru obinerea blocrii datelor respective (S lock pentru citire, X lock pentru actualizare - ntelegnd prin "actualizare" operaiile UPDATE, INSERT i DELETE). ncheierea tranzaciei (cu sau fr succes) elibereaz n mod automat blocrile pe care aceasta le deinea. Anumite sisteme (de pild Adabas D) permit "nlnuirea tranzaciilor" (transaction chaining) cu pstrarea anumitor blocri (prin clauza KEEP LOCK a instruciunii COMMIT). b. Standardul SQL nu face nici o prezumie legat de modul de implementare a mecanismelor de control al accesului concurent (prin blocare, prin mrci de timp sau alte metode) i, n consecin, nu prevede instruciuni explicite de blocare. Cu toate acestea, majoritatea SGBD-urilor relaionale ofer n propriile dialecte SQL instruciuni de blocare explicit (LOCK). Anumite sisteme non-relaionale (Raima, de exemplu) folosesc doar blocri explicite. De obicei, aceste sisteme prevd i instruciuni de deblocare explicit (UNLOCK). c. Dei sunt cele mai uzuale, blocrile partajate i exclusive nu sunt singurele posibile. Unele SGBD-uri (IBM DB2, Sybase SQL Server, Raima db_VISTA) folosesc o aa-numit "blocare pentru actualizare" (update lock), care este un nivel intermediar ntre blocarea partajat i cea exclusiv. Dac mai multe tranzacii blocheaz partajat (pentru citire) un anumit obiect, una dintre ele (doar una) poate obine o blocare pentru actualizare (remarcai c o blocare exclusiv nu poate fi obinut n aceste conditii). De obicei utilizarea blocrii pentru actualizare este posibil doar n situaia unui mecanism de control special (bazat n general pe versiuni multiple ale datelor) care s avertizeze o alt tranzacie care solicit o blocare pentru actualizare c datele au fost modificate.

40

10.1 Deadlock S revedem acum problema "actualizrii pierdute", folosind blocrile partajate i exclusive. La momentul t1 tranzacia R1 solicit o blocare partajat a liniei Z i (presupunnd c linia nu era blocat pentru scriere de o alt tranzacie) o obine. La momentul t2, tranzacia R2 solicit i ea o blocare partajat a liniei Z i o obine la rndul ei. Ambele tranzacii blocheaz n acest moment pentru citire linia Z. La momentul t3, tranzacia R1 solicit blocarea exclusiv a liniei Z, pentru a face o actualizare. Nu obine blocarea, deoarece linia este blocat pentru citire de tranzacia R2, deci este pus n stare de ateptare. Tranzacia R2 cere i ea blocarea exclusiv i, evident, nu o obine din motive similare. Nici una dintre tranzacii nu poate continua, deoarece fiecare ateapt ca cealalt s elibereze linia Z. Aceast situatie se numeste deadlock sau "interblocare". Este uor de verificat c i n situaia "analizei inconsistente" se va ajunge la o interblocare. Rezultatul este c am rezolvat problema anomaliilor (ntr-adevr, acestea nu mai apar) dar am obinut o alt problem, cea a interblocrilor. Rezolvarea noii probleme cuprinde dou aspecte: 1. Prevenirea interblocrii. Implic stabilirea unui protocol de acces la date care s fac imposibil apariia situaiilor de deadlock. O variant posibil este ca fiecare tranzacie s blocheze "n bloc" toate liniile de care are nevoie. Alta variant este stabilirea unei ordini a obiectelor iar cererile de blocare s fie rezolvate n conformitate cu aceast ordine. Ambele metode au dezavantajul c limiteaz semnificativ performanele prin blocarea resurselor pe durate mai lungi dect cele strict necesare. Pe de alt parte, prima metod nu este aplicabil ntotdeauna, deoarece este posibil ca o tranzacie s nu cunoasc de la nceput toate datele de care are nevoie. 2. Detectarea interblocrii. Cea mai simpl metod de detectare a unei situaii de deadlock este cea bazat pe un mecanism de time-out: dac durata execuiei unei tranzacii depete o valoare prestabilit, sistemul deduce c a aprut o interblocare. O alt metod se bazeaz pe construirea i meninerea dinamic a unui "graf de ateptare" (Wait-For Graph). Nodurile acestui graf reprezint tranzaciile care se execut (T1, T2, ..., Tn) iar arcele reprezint relaia de dependen (ateptare): existena unui arc de la Ti la Tj semnific faptul c tranzacia Ti ateapt ca tranzacia Tj s elibereze anumite resurse. Detectarea unei interblocri revine la detectarea existenei unui ciclu n graful de ateptare. n practic, cel mai adesea se utilizeaz o mixtur de tehnici: se impune un protocol de acces care s reduc posibilitatea interblocrii (fr s o previn total, dar i fr s inhibeze semnificativ concuren), se implementeaz un mecanism care s detecteze interblocrile cele mai uzuale, lsndu-le pe celelalte pe seama unui mecanism de time-out.

41

Rezolvarea efectiv a unei interblocri revine la stabilirea unei "victime" dintre tranzaciile implicate n deadlock i anularea ei (ROLLBACK). Dup ce interblocarea a fost nlturat, tranzacia poate fi lansat din nou n execuie. Observaii: a. Desigur, ntr-o interblocare pot s intervin mai mult de dou tranzacii (dei experimentele cu System R au demonstrat c n realitate astfel de situaii sunt extrem de rare). n acest caz este posibil ca mai multe tranzacii s trebuiasc anulate pentru a debloca execuia. b. Cele mai multe sisteme reprogrameaz automat pentru execuie tranzaciile anulate. Exist ns i sisteme care returneaz doar un cod de eroare aplicaiei, acesteia revenindu-i sarcina s se ocupe de rezolvarea problemei. 10.2 Serializare Problema care se pune este: cum putem s tim dac execuia concurent a unui grup de tranzacii este corect sau nu? S ncepem cu o definiie: Se numete planificare (schedule) oricare ordine posibil de executare a operaiilor grupului de tranzacii considerat. O prim constatare este c, dac presupunem c fiecare tranzacie n parte din grup este corect, atunci orice planificare serial a tranzaciilor (una dup alta, indiferent de ordine) este corect. Dei afirmaia este intuitiv, se poate justifica uor prin faptul c orice program execut o secven de tranzacii (deci niciodat dou tranzacii simultan). Aadar, tranzaciile din grupul considerat sunt executate de programe diferite (sunt deci independente), ordinea execuiei lor fiind irelevant (de regul FIFO: first in, first out). n cazul n care se execut operaii ale unei tranzacii n timp ce execuia altor tranzacii nu a fost nc ncheiat avem de-a face cu o planificare intercalat (interleaved), caz n care este posibil ca execuia s nu fie corect (cum a fost cazul celor trei exemple prezentate la nceput). Dou planificri ale unui grup de tranzacii sunt echivalente dac vor produce mereu acelai rezultat, oricare ar fi starea iniial a bazei de date (aceasta nseamn, de fapt, c operaiile conflictuale sunt n aceeasi ordine). O planificare este serializabil dac este echivalent cu o planificare serial. Orice planificare serial fiind corect, nseamn c am gsit criteriul de corectitudine cutat. Execuia unui grup de tranzacii este corect dac s-a fcut conform unei planificri serializabile. S remarcm c nici una dintre planificrile utilizate ca exemple pentru cele trei anomalii nu este serializabil.

42

O caracterizare mai puin riguroas, dar mult mai intuitiv a caracterului serializabil este urmtoarea: Oricare ar fi dou tranzacii A i B dintr-o planificare a unui grup de tranzacii concurente, fie A precede logic pe B, fie B precede logic pe A. Faptul c "A precede logic pe B" nseamn c B poate vedea rezultatele execuiei tranzaciei A. Deci, dac considerm toate obiectele vzute de tranzacia A, atunci B vede toate aceste obiecte fie modificate deja de A, fie n forma n care erau nainte ca modificrile s se produc, dar niciodat ca un amestec de obiecte modificate i obiecte nemodificate. Teoria este, desigur, mult mai bogat (vezi de pild [OSZU91]) i specific mai multi algoritmi de verificare a criteriului pe care l-am enunat. Rezultatul cel mai important din perspectiv practic a acestei teorii este aa-numita "teorem a seriabilittii" (sau "a blocrii n dou faze"): Dac toate tranzaciile unui grup de tranzacii concurente sunt bine formate i respect protocolul de blocare n dou faze, atunci orice planificare legal este serializabil. Demonstraia nu este dificil (o variant se bazeaz pe graful de precedent al planificrii i se desfsoar prin reducere la absurd). Importante sunt ns condiiile: O tranzacie este "bine format" dac orice operaie a tranzaciei este acoperit de o blocare i toate blocrile sunt eliberate. O operaie (citire sau scriere) este "acoperit de o blocare" dac tranzacia deine o blocare suficient de puternic a obiectului asupra cruia se desfsoar operaia. O planificare este "legal" dac nu se desfsoar n condiiile unor blocri conflictuale. Un "protocol de blocare" const dintr-un set de restricii impuse ordinii n care tranzaciile concurente blocheaz i deblocheaz obiectele bazei de date. Protocolul de blocare n dou faze (two-phase locking) impune urmtoarele dou restricii: 1. nainte de a opera asupra oricrui obiect al bazei de date, o tranzacie trebuie s obin blocarea respectivului obiect. 2. Dup ce a eliberat o blocare, o tranzacie nu va mai ncerca niciodat s obtin noi blocri. Se observ cu usurin explicaia denumirii "n dou faze" (care n-are nimic n comun cu comiterea n dou faze): conform acestui protocol orice tranzacie trece mai nti printr-o faz de obinere a blocrilor, dup care trece ntr-o faz de eliberare a blocrilor.

43

O scurt discuie asupra acestui protocol se impune. n primul rnd trebuie spus c sarcina asigurrii respectrii acestui protocol revine Lock Manager-ului (desigur, dac sistemul lucreaz pe baza acestui protocol). Mai observm c protocolul prevede "eliberarea blocrilor". O regul de "bun sim" spune c un obiect trebuie blocat ct mai puin timp cu putin, pentru a permite i accesul altor tranzacii la acesta. Din pcate, implementarea acestui protocol n forma sa cea mai eficient din acest punct de vedere este extrem de dificil: LM trebuie s "tie" cnd o tranzacie a obinut toate blocrile i nu va mai avea nevoie de altele (pentru a identifica faza n care se afl); LM trebuie s tie dac tranzacia va mai avea nevoie de un obiect asupra cruia a efectuat o operaie, deci dac poate sau nu s-l elibereze (din acelai motiv al identificrii fazelor); n fine, apare problema extrem de dificil a "anulrii n cascad" a tranzaciilor: n cazul n care o tranzacie a fost anulat n faza a doua, este posibil ca unele date eliberate de aceasta au fost apoi blocate de alte tranzacii, caz n care aceste tranzacii trebuie la rndul lor anulate. Din cauza acestor dificulti, majoritatea sistemelor implementeaz o variant mai restrictiv a protocolului, n care toate eliberrile blocrilor unei tranzacii sunt amnate pn la terminarea tranzaciei (fie prin COMMIT fie prin ROLLBACK). Este deci rezonabil s considerm c blocrile obinute de o tranzacie sunt pstrate pn la terminarea acesteia, cu toate c n felul acesta intervalul de timp n care un obiect este blocat este de regul mai lung dect minimul necesar. Compromisul este i aici prezent: simplificarea mecanismelor implementate n Lock Manager compenseaz scderea nivelului de concuren prin blocri de mai lung durat. Exist ns situaii n care se poate admite un grad oarecare de interferen, caz n care nivelul concurentei poate fi crescut prin "relaxarea" protocolului de blocare (n spet prin admiterea unor condiii n care anumite blocri pot fi eliberate naintea terminrii tranzaciei). Observaie: Din cte tiu, toate sistemele relaionale majore implementeaz diverse forme ale protocolului de blocare n dou faze. Sistemele care utilizeaz doar blocri i deblocri explicite las implementarea acestui mecanism n seama proiectanilor de aplicaie. n oricare situaie, proiectanii sunt sftuii s nu lase controlul blocrii nici o clip n seama utilizatorilor finali, din motive lesne de nteles (sindromul "blocrii peste pauza de mas"). 10.3 Blocare ierarhic Dac pn acum am folosit n exemple doar blocri la nivel de articol, n cele ce urmeaz vom considera i blocri aplicate unor portiuni mai mari (pentru a nu complica expunerea, ne putem limita la nivel de tabel). Tehnica blocrii ierarhice se refer la sistemele care admit mai multe granulaii ale blocrii (vezi

44

caseta "Focus: Granulaie") i a fost introdus de Jim Gray i colaboratorii si nc din 1975. O descriere mai "didactic" poate fi consultat n [GRAY93]. Ideea de la care se pleac este c pentru o obine o blocare la nivel de articol (linie de tabel), o tranzacie trebuie s-i manifeste aceast intenie, cernd mai nti o blocare la nivel de tabel. n felul acesta se simplific procesul de detectare a unor cereri conflictuale de blocare la nivel de linie, deoarece ele trebuie nti s se manifeste la nivel de tabel. Protocolul bazat pe "intenii de blocare" (intent locking) introduce trei noi tipuri de blocare (la nivel de tabel), alturi de cele dou tipuri de blocri uzuale (S-lock i X-lock) care, aa cum am artat deja, au sens i la nivel de tabel. Avem astfel cinci tipuri de blocri pe care o tranzacie T le poate solicita la nivelul ntregii tabele R, prezentate n ordinea cresctoare a "triei" lor relative: IS - intent shared. Tranzacia T intenioneaz s blocheze pentru citire (S lock) anumite linii ale tabelei R, pentru a garanta stabilitatea acestora n timpul procesrilor pe care le va efectua. IX - intent exclusive. La fel ca IS, dar T s-ar putea s vrea s modifice anumite articole i deci s solicite blocarea exclusiv a acestora. S - shared. Este obinuita blocare partajat. T admite citiri concurente ale tabelei R, dar nu i scrieri. T nu va face nici o scriere la nivelul liniilor tabelei. SIX - shared intent exclusive. Combin S i IX. n plus fa de S, T s-ar putea s vrea s modifice anumite linii din R i, n consecin, s solicite blocarea exclusiv a acestora. X - exclusive. T nu admite citiri concurente n tabela R. T ar putea s actualizeze anumite linii ale tabelei R. Cteva observatii: a. Noiunea de "trie" a blocrii se refer la faptul c o cerere de blocare de un anumit tip care eueaz, va eua cu siguran pentru orice tip mai "tare". (vezi "Focus: blocri"). b. Tipurile IX i S sunt egale din punct de vedere al "triei". c. i aceste tipuri de blocri sunt n mod obinuit cerute n mod implicit. Cu toate acestea, sistemele care implementeaz aceste tipuri de blocare (DB2, OpenIngres) ofer de obicei i o instruciune de blocare explicit pentru aceste tipuri. d. Varianta pe care am prezentat-o este mult simplificat. De fapt blocrile se pot referi la orice granulaii i orice obiecte ale bazei de date (inclusiv indeci).

45

n fine, protocolul bazat pe intenii de blocare (intent locking protocol), impune dou reguli care mbin blocrile la nivel de tabel i de articol ntr-o combinaie care adesea s-a dovedit mai eficient n aplicatii: 1. nainte de a obine o blocare partajat (S) la nivel de linie, o tranzacie trebuie s obin o blocare de tip IS (sau mai tare) la nivelul ntregii tabele. 2. nainte de a obine o blocare de tip exclusiv (X) la nivel de linie, o tranzacie trebuie s obtin o blocare de tip IX sau mai tare la nivelul ntregii tabele. 11. Protocolul n dou faze 2-PL E interesant c doar punnd ncuietori n jurul acceselor la date nu e suficient. Ca s ne convingem, considerai tranzaciile T1 i T2 n forma n care exact fiecare acces este protejat, ca n exemplul urmtor pentru T2: Begin T2; lock(salariu, readLock); y := Read(salariu); unlock(salariu); y := y + 200; lock(salariu, writeLock); Write(salariu, y); unlock(salariu); End T2; E uor de observat c o astfel de ncuiere permite execuii neserializabile (chiar execuia indicat mai sus este posibil). Nu ajunge deci s ncuiem, trebuie s respectm un protocol de ncuiere. Adic un set de reguli pentru toat lumea. Cel mai simplu i mai des folosit protocol este cel n dou faze (two-phase locking; 2PL). Acest protocol se poate enuna astfel: n prima faz se pot numai obine ncuietori (adic se execut instruciuni lock i upgrade). n a doua faz se pot numai dealoca ncuietori (unlock sau degrade). Dac facem un grafic al numrului de ncuietori posedate de o tranzacie, el trebuie s arate cam ca n figura urmtoare: s aib o faz de cretere (growing phase) i una de descretere (shrinking phase).

growing shrinking ____

46

| numar de incuietori

/ \ | / | __/

\____ |

|/ \ 0-----------------------> timp Acest protocol garanteaz serializabilitatea. Este un exerciiu interesant s demonstrm acest lucru. Iat o schi a demonstraiei. S presupunem (prin absurd) c o serie de tranzacii T1, T2, ... Tn, care respect protocolul 2PL, au avut o execuie ne-serializabil. Asta nseamn c n graful lor de dependene exist un ciclu, T1 T2 ...Tn T1. Ce nseamn c avem un arc de la T1 la T2? nseamn c T1 a operat asupra unei valori nainte de T2, cu o operaie care nu comut cu cea a lui T2. Dar noi tim c T1 nu are voie s opereze asupra unei valori ne-ncuiate. Asta nseamn c T2 a ncuiat acea valoare dup ce T1 a descuiat-o. Arcul T2 T3 indic un lucru asemntor, i anume c T3 a ncuiat o valoare (nu necesar aceeai) dup ce T2 a descuiat-o. Din aproape n aproape obinem c, n fine, T1 a ncuiat o valoare dup ce T1 a descuiat o alt valoare, ceea ce este absurd. Concluzia iniial era deci greit. n concluzie 2PL garanteaz serializabilitate. S observm ca 2PL nu este acelai lucru cu serializabilitatea, ci c 2PL doar o implic. Din punctul de vedere al abordrii blocrilor exista doua tipuri de 2PL: 2PL - Cu Ateptare si 2PL Cu Restart. Primul tinde sa blocheze tranzacia care ntmpina un conflict la blocarea resurselor necesare , in timp ce al doilea tinde sa o restarteze. Un caz particular extrem al celui de-al doilea tip este algoritmul 2PL Fr Ateptare . Politica algoritmului 2PL Fr Ateptare consta in restartarea de fiecare data unei tranzacii care a ncercat blocarea unei resurse deinuta de ctre o alta tranzacie. Modelul din lucrarea de fata este bazat tocmai pe aceasta politica. In contrast cu acest model este politica de Ateptare Generala , in care o tranzacie ce ntmpina un conflict la blocarea unei resurse se blocheaz , exceptnd cazul apariiei unei blocri totale , cnd se renuna la una dintre tranzaciile implicate in blocare . Un astfel de mecanism va duce la o deteriorare a performantelor datorata blocrilor si anularilor tranzaciilor. In particular 2PL cu Ateptare Generala tinde spre un efect de avalan , in sensul ca blocarea

47

unei tranzacii produce mai departe alte blocri pariale sau totale de tranzacii , fenomen cunoscut sub denumirea de Data Contention Thrashing (limitare din punctul de vedere al accesului la date) . In principiu, pe msur ce MPL-ul (MultiProgramming Level = Nivelul de MultiProgramare, adic numrul total de tranzacii dintr-un sistem de baze de date) creste, throughput ul (rezultatele prelucrrilor) creste aproape liniar pentru nceput, se plafoneaz la un moment dat dup care scade brusc. Acest fenomen are ca rezultat o scdere drastica a performantelor sistemului de baze de date. La ora actuala tendina principala este de cretere a MPL-ului la valori cat mai mari posibile evitnd apariia acestui fenomen. In acest sens , algoritmii de control al concurentei orientai pe restart sau dovedit mai potrivii. Comportamentul de acaparare a resurselor al unei tranzacii depinde in principal de doi factori: Numrul de granule (entiti) de date deja blocate (pentru scriere Numrul de granule (entiti) de date deja blocate de ctre si/sau citire)de ctre alte tranzacii tranzacia in cauza, deoarece fiecare tranzacie necesita un set distinct de granule (entiti de date). Modelarea analitica a unui sistem real de baze de date este un lucru destul de complicat avnd in vedere spaiul foarte mare al strilor posibile ale unui sistem de baze de date. Printre problemele atinse de modelele analitice propuse pana in prezent pentru metode de Control al Concurentei Fr Ateptare se numra : acces uniform si neuniform la date, tranzacii de lungime fixa si variabila. Rezultatele obinute sunt sub forma unei analize a valorilor medii. Nu este prezentata o soluie pentru probabilitatea strilor staionare a tranzaciilor. Modelele stohastice aprute pana in prezent abordeaz doar o parte din structura unui sistem de baze de date distribuit fr a lua in considerare efectele strilor diferitelor tranzacii sau a numrului de granule (entiti) de date blocate de ctre o tranzacie.

48

In lucrarea de fata se va prezenta un model stohastic general de spaiu multidimensional al strilor pentru studiul performantelor algoritmului 2PL -Fr Ateptare. Studiul mediului de baze de date si al strilor tranzaciilor se bazeaz pe procese Markov. Modelul abordeaz accesul neuniform, blocarea pentru scriere a granulelor de date, blocarea pentru citire a granulelor de date si tranzacii mprite in clase. Analiza consta din urmtorii pai: rezolvarea probabilitii strilor staionare a sistemului, urmata de aflarea numrului mediu de tranzacii cu k blocri de granule de date, a numrului mediu total de blocri de granule de date deinute de toate tranzaciile, a numrului mediu de blocri de granule de date deinute de o tranzacie, a numrului mediu de blocri de citire respectiv scriere deinute de o tranzacie, a numrului mediu de granule blocate intr-o baza de date. Aceti parametrii ofer o imagine mai detaliata a mecanismelor tranzaciilor si a mediului unei baze de date. In cele din urma sunt calculai throughput-ul(randamentul) si rata de restartari, care sunt cei doi parametrii eseniali de performanta ai unui algoritm de acces la o baza de date distribuita. 12. 2PL strict Exist un dezavantaj al lui 2PL i o implementare care l evit. S considerm urmtorul scenariu: o tranzacie T1 ncuie o valoare , o modific i apoi o descuie. T2 vine la rnd, ncuie i citete . Dac acum T1 vrea s execute Abort, valoarea lui trebuie pus cum era nainte ca T1 s o fi modificat. Dar T2 a citit-o deja! Asta nseamn nimic altceva dect c dac T1 execut Abort, T2 trebuie s fie ``ucis'' de sistem, pentru a respecta proprietatea de izolare! E clar c lanul poate fi mai lung: T3 poate a citit la rndul ei , i atunci trebuie terminate (kill) i ea. O astfel de situaie foarte neplcut (pentru c o mulime de operaii trebuie ``terse'') se numete cascaded abort (abort n cascad). (O alt consecin neplcut este c T2 nu se poate termina nainte de T1, pentru c dac T2 face Commit iar T1 Abort am ncurcat-o, cci T2 a promis c valoarea lui este permanent, dar nu avea voie s-o citeasc! Deci T2 trebuie s atepte ca T1 s se termine.) Soluia este simpl: restrngi concurena, dar nu lai pe nimeni s vad ce-ai modificat. Nu descui nimic pn la sfrit, cnd descui totul dintr-o micare (de

49

exemplu folosind End Transaction, care elibereaz ncuietorile). Graficul ar arta atunci cam aa: growing shrinking ^ _________ | / | | / | | __/ | | / |terminare 0-----------------------> timp

numar de incuietori

13. Prototocolul send-on-demand Sistemele de baze de date distribuite au caracteristici unice n mediile de mare vitez. Cel mai important criteriu de studiere a performanelor ntr-o reea de mari dimensiuni este latenta de comunicaie (ntrzierile de propagare a semnalului). Succesul oricrui protocol n aceste medii depinde de modul n care acesta tie s ascund aceste ntrzieri. n aceast nou schem, elementele de date nu mai sunt limitate la un anumit calculator, n mod special. Fiecare calculator, ce face parte din BDD, ntreine o coad de pretenii, pentru fiecare element de date care este localizat n mod curent pe acel calculator. Coada de pretenii pentru un element de date conine o list a tranzaciilor (cu identificatoarele calculatoarelor unde este executat tranzacia) care cer acel element de date i de asemenea specific aciunea inclus n tranzacie asupra acelui element de date (citit/scris). Setul de operaii de acces, impreun cu marca timpului de sosire al tranzaciei T - TS(T) a fiecarei tranzacii care vine este transmis ctre toate calculatoarele din BDD. Un mesaj tipic de transmisie, trimis de un calculator ce proceseaz o tranzacie cu k elemente de date n setul sau de operaii de acces este dat mai jos:

50

ID-ul cal0063ulatorului care a initiat tranzactia

TS(T)

Alte informatii

D1 R/W Dk R/W

Setul de operaii de acces al tranzaciei este introdus n coada de pretenii, al unui calculator n ordinea marcilor de timp ale sosirii tranzaciei. Nici o aciune nu este luat pn cand nu este sigur c toate calculatoarele din BDD au primit aceast informaie. n acest punct, tranzacia este confirmat i durata pe care un calculator trebuie s-o atepte pn cnd o tranzacie e confirmat se numete durat de confirmare (B). O coad de pretenii, n orice moment de timp, conine un set de tranzacii confirmate i un set de tranzacii neconfirmate.

n figura de mai jos este descris o coad de pretenii pentru un element de date cu m tranzacii din care n sunt tranzacii confirmate:

Neconfirmate
Pretenii noi

Confirmate

Tm Tn+1

Tn T2 T1

Durata confirmrii unei tranzacii este un timp mai mare sau egal cu cel necesar trimiterii informaiei setului de operaii acces spre toate calculatoarele din BDD. Acest lucru asigur ca la fiecare calculator, coada de pretenii s aib intrri n ordine (n timp), i n acest fel nu pot aprea interblocri. La pornirea sistemului, toate elementele de date se afl pe calculatoare oarecare. Cand tranzaciile ncep s soseasc, cozile de pretenii ncep s se ocupe. Toate calculatoarele ii transmit elementele de date rezidente spre sistemul care a iniiat prima tranzacie confirmat, completnd cozile de pretenii respective. n timp ce coada de pretenii este transmis, alte tranzacii,

51

necesitnd acelai element de date, pot sosi n sistem. Informaii despre aceste tranzacii pot fi obinute din informaia de transmisie (vezi formatul unui mesaj de transmisie). Fiecare calculator care iniiaz o tranzacie ateapt pentru ca ntregul set de operaii de acces s ajung la locaia lui, termina procesarea tranzaciei i apoi transmite elementele de date la alte calculatoare care se afl la rnd n cozile de pretenii respective. Acest mecanism elimin necesitatea de deblocare a elementelor de date, fa de sistemele tradiionale, n care, pentru a se menine atomicitatea tranzaciilor, se implementeaz protocoale speciale de validare (commit). Noul algoritm are nevoie doar de un protocol de validare local. Atta timp ct fiecare calculator ntreine cozi de pretenii doar pentru acele elemente de date care rezid n mod curent pe acel calculator, necesitile de memorie nu sunt foarte mari.Fiecare calculator trebuie s aib alocat memorie necesar stocrii informaiei despre setul de operaii de acces al tranzaciilor confirmate. O tranzacie tipic de actualizare are un set de operaii de citire precum i un set de operaii de scriere. Astfel, o coad de pretenii tipic pentru un element de date are intrri de citire i intrri de scriere. Intrrile consecutive de citire pot fi procesate n paralel, n timp ce intrrile de scriere trebuiesc servite serial. De exemplu, considerand coada de pretenii a unui singur element de date D j, unde se afl dou intrri de scriere separate de cateva intrri de citire. Dup ce prima scriere a fost completat de calculatorul care deine (acum) copia scris a lui D j, se trimite mai departe versiunea actualizat a lui Dj ctre toate calculatoarele care au o intrare de citire n coada de pretenii, nainte de scrierea urmatoare. Copia scris actuala este trimis calculatorului care este responsabil pentru ultima intrare de citire inainte de a doua intrare de scriere. Dupa ce este terminat fiecare tranzacie care necesit citirea lui Dj, exist un mecanism de informare a calculatorului care vrea sa-l modifice pe Dj. Acest mecanism este realizat prin calculatoarele care-l citesc pe Dj care trimit cate un mesaj ctre calculatorul care ateapt sa-l scrie pe Dj; acesta ateapt momentul propice actualizrii i anume acela cnd s-a sfarit citirea lui Dj. Calculatorul care are

52

copia de scriere transmite aceast copie a lui Dj impreun cu mesajul i apoi actualizarea la acel calculator poate ncepe. Algoritmul send-on-demand poate fi rezumat in forma urmatoare : Toate calculatoarele actualizeaz cozile de pretenii, iar dac sunt responsabile de transmiterea unui fragment din baza de date, adaug informaia marcii de timp la elementul de date i apoi terge informaia despre tranzacia actualizat din cozile de pretenii prin verificarea marcii de timp. Calculatoarele care proceseaz actualizri transmit ntregul set de operaii de acces (setul de operaii de citire i setul de operaii de scriere) al actualizrii catre toate calculatoarele, ateapt evenimentele (a) sunt primite toate elementele de date din setul de operaii de acces i (b) mesajul completat a ajuns de la tranzaciile care dein o copie de citire a elementelor de date n setul lor de operaii de citire, execut actualizarea, trimite o copie a fiecarei actualizari (odat cu timpul la care s-a executat actualizarea) ctre calculatoarele respective responsabile pentru transmiterea lor, dac deine o copie de citire a elementului de date Dj, trimite o completare a mesajului ctre urmtoarea scriere n coada de pretenii pentru Dj, iar dac deine o copie de scriere a lui Dj, trimite o copie de citire a lui Dj ctre toate calculatoarele care au o intrare de citire n coada de pretenii nainte de scrierea urmtoare i trimite copia de scriere ctre urmatoarea scriere. Calculatoare care proceseaz interogri scaneaz canalele de transmisie pe care elementele de date sunt transmise, urmarind elementele de date din setul de operaii de acces al interogrii, citete doar acele copii care sunt consistente mutual prin verificarea informaiei mrcii de timp respective i execut interogarea. Aplicabilitate:

53

Din punct de vedere practic, algoritmii de tip send on demand in afara controlului concurential al accesului la date este intalnit in replicarile tranzactionale, de tip merge etc.

Concluzii: 1. 2. Din punct de vedere practic, cei mai utilizati algoritmii sunt algoritmii de tip 2-PL ; Performantele algoritmului de tip optimist sunt net superioare celui de blocare in cazul in care nu apare concurenta. Bibliografie: 1. SQL 2005 Books OnLine ; 2. Manuale curs Microsoft (curs 2779).

54