Înregistrarea modificărilor este o caracteristică DBMS care stochează informațiile necesare pentru a restabili baza de date la o stare anterioară consecventă în cazul unor erori logice sau fizice.
În cel mai simplu caz, înregistrarea modificărilor constă în scrierea secvenţială în memoria externă a tuturor modificărilor efectuate în baza de date. Sunt înregistrate următoarele informații:
Informațiile generate în acest fel se numesc jurnalul modificărilor bazei de date . Jurnalul conține semne de început și de sfârșit ale tranzacției și semne de acceptare a punctelor de control (vezi mai jos).
Într -un SGBD cu scriere înapoi , blocurile de date din memorie externă sunt etichetate cu numărul de secvență al ultimei modificări care a fost efectuată pe acel bloc de date. În cazul unei defecțiuni a sistemului, acest marcaj vă permite să aflați ce versiune a blocului de date a reușit să ajungă în memoria externă.
Un SGBD cu write-back efectuează periodic puncte de control. În timpul acestui proces, toate datele nescrise sunt transferate în memoria externă și un semn de acceptare a punctului de control este scris în jurnal. După aceea, conținutul jurnalului scris înainte de punctul de control poate fi șters.
Jurnalul de modificări nu poate fi scris direct în memoria externă, ci acumulat în memoria operațională. Dacă tranzacția este confirmată, DBMS așteaptă ca restul jurnalului să fie scris în memoria externă. Astfel, se garantează că toate datele introduse după semnalul de confirmare vor fi transferate în memoria externă, fără a aștepta rescrierea tuturor blocurilor modificate din memoria cache a discului . SGBD așteaptă ca restul jurnalului să fie scris în același mod atunci când efectuează un punct de control.
În cazul unei eșecuri logice sau a unui semnal de derulare pentru o tranzacție , jurnalul este scanat înapoi și toate înregistrările tranzacției anulate sunt preluate din jurnal până la începutul tranzacției. Conform informațiilor extrase, sunt efectuate acțiuni care anulează acțiunile tranzacției, iar intrările de compensare sunt scrise în jurnal . Acest proces se numește rollback .
În cazul unei defecțiuni fizice , dacă nici jurnalul, nici baza de date în sine nu sunt deteriorate, atunci procesul de rollforward este efectuat . Jurnalul este scanat în direcția înainte, începând de la punctul de control anterior. Toate înregistrările sunt preluate din jurnal până la sfârșitul jurnalului. Informațiile preluate din jurnal sunt introduse în blocuri de date din memorie externă care au un număr de modificare mai mic decât cel înregistrat în jurnal. Dacă rularea eșuează din nou, scanarea jurnalului va reporni de la început, dar recuperarea va continua de fapt de unde a rămas.
Pentru a crește toleranța la erori , DBMS poate scrie mai multe copii identice ale jurnalului de modificări în același timp. Dacă, în cazul unei erori, una dintre copiile jurnalului devine indisponibilă, SGBD va restaura baza de date utilizând oricare dintre copiile disponibile. Această strategie se numește changelog multiplexare .
De regulă, jurnalul de modificări este mai întâi suprascris, de îndată ce spațiul de memorie extern alocat pentru acesta se epuizează. Acest lucru vă permite să restaurați baza de date la o stare actualizată și consecventă, dar numai dacă baza de date în sine nu este pierdută, chiar dacă nu este la zi.
Cu toate acestea, în unele sisteme informatice, recuperarea trebuie garantată chiar dacă întreaga bază de date este pierdută. În astfel de sisteme, baza de date este copiată periodic , iar jurnalul de modificări este împărțit în segmente succesive și arhivat. Înainte de începerea copiei de rezervă, se realizează un punct de control și jurnalul este împărțit în segmente scrise înainte și după începerea copiei de rezervă. La sfârșitul procesului de backup, toate jurnalele de modificări scrise înainte de începerea copiei de rezervă sunt șterse. Astfel, cu o copie de rezervă și cu toate jurnalele de modificări arhivate de la efectuarea copiei de rezervă, baza de date poate fi restaurată la o stare actualizată chiar dacă toate blocurile de date au fost pierdute.
Nu toate SGBD-urile reale urmează schema clasică de implementare a jurnalului de modificări, în parte din motive de eficiență.
Oracle Database folosește două tipuri de jurnal de modificări: un jurnal de refacere online ciclic ( redo log ) și un redo log arhivat ( archive log ), în care înregistrările din primul jurnal sunt transferate atunci când primul trece printr-un ciclu complet. Ambele jurnalele sunt scrise pe medii permanente, datele despre operațiune intră în jurnalul online în momentul înainte ca datele să fie transferate pe medii nevolatile, jurnalul de arhivă funcționează numai într-un mod special de suport pentru arhivarea jurnalului bazei de date ( archivelog ). Informațiile din jurnalele de modificări nu sunt folosite pentru a anula tranzacția, ci sunt folosite pentru recuperare. Procesul de restaurare este efectuat de administrator folosind o copie de rezervă a bazei de date și o aplicație secvențială de arhivare și refacere a jurnalelor.
Informațiile rollback ( undo log ) sunt grupate în segmente rollback menținute de un tip special de tablespace . Aceste date sunt, de asemenea, redo logged, ceea ce înseamnă că sunt protejate în același mod ca și alte date din baza de date. În cazul unei rollback , jurnalul este utilizat pentru a restabili înregistrarea tranzacției modificate. În plus, informațiile din jurnalul de refacere sunt folosite pentru a menține integritatea citirii pentru a oferi acces la instantaneul datelor luate în momentul preluării [1] .
În DBMS Informix, jurnalul de modificări este un spațiu pe disc împărțit în părți numite fișiere jurnal de tranzacții (aceste fișiere nu au nicio legătură cu fișierele din sistemul de fișiere) sau jurnal logic . Dacă modificările sunt scrise în acest jurnal, depinde dacă baza de date se află în modul neînregistrat în jurnal, în jurnal în tampon sau în jurnal fără tampon. Toate modificările merg mai întâi în tampoanele logice de jurnal, apoi sunt eliminate în jurnalul de tranzacții, în funcție de modul de înregistrare a bazei de date.
Pentru recuperare în caz de eșec, așa-numitul. jurnalul fizic în care sunt copiate imaginile paginii înainte de a fi modificate. În cazul unei defecțiuni a serverului, datele necommitate vor fi restaurate în timpul pornirii.
| Bază de date | |
|---|---|
| Concepte |
|
| Obiecte |
|
| Chei | |
| SQL |
|
| Componente | |