O tranzacție este un grup de operații secvențiale cu o bază de date , care este o unitate logică de lucru cu date. O tranzacție poate fi fie finalizată cu succes, respectând integritatea datelor și independent de alte tranzacții concurente, fie deloc finalizată, caz în care nu ar trebui să aibă efect. Tranzacțiile sunt procesate de sisteme tranzacționale , în cursul cărora este creat un istoric al tranzacțiilor .
Distingeți tranzacțiile secvențiale (normale), paralele și distribuite . Tranzacțiile distribuite implică utilizarea a mai mult de un sistem tranzacțional și necesită o logică mult mai complexă (de exemplu, confirmare în două faze - un protocol de confirmare a tranzacției în două faze ). De asemenea, unele sisteme implementează tranzacții autonome , sau sub-tranzacții, care sunt o parte autonomă a tranzacției-mamă.
Exemplu: trebuie să transferați din contul bancar numărul 5 în contul numărul 7 suma de 10 unități monetare. Acest lucru poate fi realizat, de exemplu, prin următoarea secvență de acțiuni:
Aceste acțiuni reprezintă o unitate logică de lucru „transferând sumă între conturi” și, prin urmare, reprezintă o tranzacție. Dacă această tranzacție este întreruptă, de exemplu, la mijloc și nu anulează toate modificările, este ușor să lăsați proprietarul contului numărul 5 fără 10 unități, în timp ce proprietarul contului numărul 7 nu le va primi.
Unul dintre cele mai comune seturi de cerințe pentru tranzacții și sisteme tranzacționale este setul ACID (Atomicity, Consistency, Isolation, Durability). Cerințele ACID au fost formulate în principal la sfârșitul anilor 1970 de Jim Gray [1] . În același timp, există sisteme specializate cu proprietăți tranzacționale slăbite [2] .
În mod ideal, tranzacțiile diferiților utilizatori ar trebui să fie efectuate în așa fel încât să se creeze iluzia că utilizatorul tranzacției curente este singurul. Cu toate acestea, în realitate, din motive de performanță și pentru a îndeplini unele sarcini speciale, DBMS oferă diferite niveluri de izolare a tranzacțiilor.
Nivelurile sunt descrise în ordinea creșterii izolării tranzacțiilor și, în consecință, a fiabilității lucrului cu date.
Cu cât nivelul de izolare este mai mare, cu atât sunt necesare mai multe resurse pentru a-l asigura. În consecință, creșterea izolării poate duce la o scădere a vitezei tranzacțiilor paralele, care este „plata” pentru creșterea fiabilității.
În SGBD, nivelul de izolare a tranzacțiilor poate fi selectat atât pentru toate tranzacțiile simultan, cât și pentru o anumită tranzacție. În mod implicit, majoritatea bazelor de date utilizează nivelul 1 (Read Committed). Nivelul 0 este utilizat în primul rând pentru urmărirea modificărilor în tranzacțiile de lungă durată sau pentru citirea datelor care se modifică rar. Nivelurile 2 și 3 sunt utilizate pentru cerințe sporite pentru izolarea tranzacțiilor.
Implementarea completă a nivelurilor de izolare și a proprietăților ACID nu este o sarcină trivială. Procesarea datelor primite duce la o mulțime de mici modificări, inclusiv actualizarea atât a tabelelor în sine, cât și a indicilor. Aceste modificări pot eșua potențial: epuizarea spațiului pe disc, operațiunea durează prea mult (timeout), etc. Sistemul trebuie să returneze corect baza de date la starea de dinaintea tranzacției în caz de eșec.
SGBD-urile comerciale timpurii (cum ar fi DB2 IBM ) foloseau exclusiv blocarea accesului la date pentru a oferi proprietăți ACID. Dar un număr mare de încuietori duce la o scădere semnificativă a performanței. Există două familii populare de soluții la această problemă care reduc blocarea:
În ambele cazuri, toate informațiile care sunt actualizate trebuie să fie blocate. În funcție de nivelul de izolare și de implementare , blocările de scriere sunt de asemenea plasate pe informațiile care au fost citite de tranzacție.
Cu înregistrarea proactivă , utilizată în Sybase și MS SQL Server înainte de versiunea 2005, toate modificările sunt scrise în jurnal și numai după finalizarea cu succes - în baza de date. Acest lucru permite SGBD-ului să revină la o stare de funcționare după o prăbușire neașteptată a sistemului. Paginile umbră conțin copii ale acelor pagini de bază de date la începutul tranzacției în care apar modificări. Aceste copii sunt activate la finalizarea cu succes. În timp ce paginile umbră sunt mai ușor de implementat, înregistrarea proactivă este mai eficientă [4] .
Dezvoltarea în continuare a tehnologiilor de gestionare a bazelor de date a condus la apariția tehnologiilor fără blocuri. Ideea controlului concurenței folosind controlul concurenței bazat pe marca temporală a fost dezvoltată și a condus la apariția unei arhitecturi MVCC cu mai multe versiuni . Aceste tehnologii nu necesită înregistrarea modificărilor sau pagini umbră. Arhitectura implementată în Oracle 7.x și mai târziu scrie versiuni mai vechi ale paginilor într-un segment special de rollback, dar acestea sunt încă lizibile. Dacă tranzacția, la citire, lovește o pagină a cărei amprentă temporală este mai nouă decât începutul citirii, datele sunt preluate din segmentul rollback (adică se folosește versiunea „veche”). Pentru a sprijini această activitate, se păstrează un jurnal de tranzacții, dar spre deosebire de „jurnalul proactiv”, acesta nu conține date. Lucrul cu acesta constă în trei pași logici:
Jurnalul de tranzacții, în combinație cu segmentul rollback (zona care stochează o copie a tuturor datelor care se modifică în timpul tranzacției), garantează integritatea datelor. În cazul unei eșecuri, se lansează o procedură de recuperare care analizează înregistrările sale individuale după cum urmează:
Firebird nu are deloc un jurnal de modificări sau un segment de rollback, dar implementează MVCC prin scrierea de noi versiuni de rânduri de tabel direct în spațiul de date activ. La fel face MS SQL 2005. Teoretic, acest lucru oferă eficiență maximă atunci când se lucrează cu date în paralel, dar prețul este nevoia de „colectare a gunoiului”, adică eliminarea versiunilor vechi și care nu mai sunt necesare ale datelor.
Procesarea tranzacțiilor are ca scop menținerea unui sistem informatic (de obicei, o bază de date sau unele sisteme de fișiere moderne ) într-o stare cunoscută, consecventă, asigurându-se că orice operațiuni care au loc pe sistem sunt interdependente și fie toate finalizate cu succes, fie complet și anulate cu succes. [5]
De exemplu, luați în considerare o tranzacție bancară tipică care implică mutarea a 700 USD din contul de economii al unui client în contul curent al unui client. Această tranzacție este o singură tranzacție pentru bancă, dar include cel puțin două tranzacții separate în termeni informatici: 700 USD sunt creditați în contul de depozit și 700 USD sunt creditați în contul curent. Dacă tranzacțiile de debit au succes și tranzacțiile de credit nu sunt (sau invers), registrele băncii nu vor avea sold la sfârșitul zilei. Prin urmare, trebuie să existe o modalitate de a se asigura că ambele operațiuni fie reușesc, fie eșuează, astfel încât să nu existe niciodată inconsecvență în baza de date a băncii în ansamblu. Procesarea tranzacțiilor este concepută pentru a oferi acest lucru.
Procesarea tranzacțiilor permite ca mai multe tranzacții separate să fie conectate automat împreună ca o singură tranzacție indivizibilă. Sistemele de procesare a tranzacțiilor asigură fie că toate operațiunile dintr-o tranzacție sunt finalizate fără erori, fie că nici una dintre ele. Dacă unele dintre operațiuni sunt finalizate, dar cu erori, iar altele fără, sistemul de procesare a tranzacțiilor indică „rularea înapoi” a tuturor tranzacțiilor tranzacției (inclusiv cele reușite), ceea ce înseamnă ștergerea tuturor urmelor operațiunii și restabilirea sistemului la un stare cunoscută consecventă care a fost înainte de începerea procesului de tranzacție. Dacă toate operațiunile tranzacției sunt finalizate cu succes, atunci tranzacția este comisă în sistem și toate modificările din baza de date devin „permanente” ( commise ); tranzacțiile nu pot fi anulate dacă au fost deja efectuate.
Procesarea tranzacțiilor protejează împotriva erorilor hardware și software care pot lăsa o tranzacție finalizată parțial, cu sistemul lăsat într-o stare necunoscută, inconsistentă. Dacă un sistem informatic eșuează în mijlocul unei tranzacții, procesarea tranzacției asigură că toate tranzacțiile din orice tranzacție necommitată (adică nu sunt procesate complet) sunt anulate.
Tranzacțiile sunt aranjate în ordine cronologică strictă. Dacă tranzacția N+1 intenționează să atingă aceeași parte a bazei de date ca și tranzacția N, tranzacția N+1 nu începe până când nu are loc tranzacția N. Înainte de orice tranzacție, toate celelalte tranzacții care afectează aceeași parte a sistemului trebuie de asemenea finalizate; nu pot exista „găuri” în succesiunea tranzacțiilor anterioare. [6] [5]
Principiile de bază ale tuturor sistemelor de procesare a tranzacțiilor sunt aceleași. Cu toate acestea, terminologia poate varia de la un sistem de procesare a tranzacțiilor la altul, iar termenii utilizați mai jos nu sunt neapărat universali. [7]
Rollback ( ing. rollback )Sistemele de procesare a tranzacțiilor asigură integritatea bazei de date prin înregistrarea stării intermediare a bazei de date înainte ca aceasta să fie schimbată și apoi folosind aceste înregistrări pentru a restaura baza de date la o stare cunoscută dacă tranzacția nu poate fi efectuată. De exemplu, copiile informațiilor dintr-o bază de date înainte ca acestea să fie modificate de o tranzacție sunt făcute de sistem înainte de tranzacție, care poate face orice modificări (uneori numite înainte de imagine ). Dacă orice parte a tranzacției eșuează înainte de a fi comisă, aceste copii sunt folosite pentru a restabili baza de date la starea în care se afla înainte de începerea tranzacției ( Rollback ). [6]
Run ( ing. rollforward )De asemenea, puteți păstra un jurnal separat al tuturor modificărilor bazei de date (uneori numit după imagini ); acest lucru nu necesită o rollback a operațiunilor eșuate, dar este util pentru actualizarea bazei de date în cazul unei eșecuri a bazei de date, motiv pentru care unele sisteme de procesare a tranzacțiilor oferă această caracteristică. Dacă baza de date eșuează complet, aceasta trebuie restaurată din ultima copie de rezervă. Backup-urile nu vor reflecta operațiunile efectuate după ce au fost create. Cu toate acestea, odată ce baza de date a fost restaurată, jurnalul după imagini poate fi aplicat bazei de date ( rollforward ) pentru a o actualiza. Orice tranzacție care este în desfășurare în momentul eșecului poate fi anulată. Rezultatul este o bază de date într-o stare consecventă cunoscută care include rezultatele tuturor tranzacțiilor efectuate până la punctul de eșec. [6]
Blocare reciprocă ( ing. blocaje )În unele cazuri, două tranzacții pot încerca, în timpul procesării lor, să acceseze aceeași parte a bazei de date în același timp, într-un mod care să împiedice finalizarea lor. De exemplu, tranzacția A poate accesa partea X a bazei de date, iar tranzacția B poate accesa partea Y a bazei de date. Dacă, în acest moment, tranzacția A încearcă să acceseze partea Y a bazei de date în timp ce tranzacția B încearcă să acceseze partea X, apare o situație de blocaj și nicio tranzacție nu poate continua. Sistemele de procesare a tranzacțiilor sunt concepute pentru a detecta astfel de situații. În mod obișnuit, ambele tranzacții sunt anulate și anulate, apoi sunt pornite automat într-o ordine diferită, astfel încât blocajul să nu reapară. Sau, uneori, doar una dintre tranzacțiile blocate este anulată, anulată și reîncercată automat după o scurtă întârziere.
Blocajele pot apărea între trei sau mai multe tranzacții. Cu cât sunt mai multe tranzacții conectate, cu atât sunt mai greu de detectat. Sistemele de procesare a tranzacțiilor au impus chiar și o limită practică a blocajelor pe care le pot detecta.
| Bază de date | |
|---|---|
| Concepte |
|
| Obiecte |
|
| Chei | |
| SQL |
|
| Componente | |