Helyreállítás az utolsó lehetséges időpontra: olyan katasztrófák után szokták használni, amely elpusztítja az adatközpontot. Ezt okozhatja média hiba, természeti katasztrófa, stb. Az alkalmazások teljesen elérhetetlenné válnak, amíg a helyreállítás be nem fejeződik. A sikeres helyreállításhoz a helyreállító folyamatnak képesnek kell lennie az adatbázis tartalmát a hiba előtti állapotra hozni. A helyreállító folyamatnak érvényes és teljes képmásolati mentést kell találnia és helyreállítania a képmásolatokat. A helyreállító folyamat az adatbázisnapló segítésével előregörget, azaz a mentés óta történt adatbázis-változtatásokat újraalkalmazza a képmásolatból helyreállított adatbázison. A 9-1-es ábrán ennek a helyreállításnak a lépéseit láthatjuk.
9-1. ábra – Helyreállítás az utolsó lehetséges időpontra
Ha az utolsó teljes képmásolat elveszett vagy megrongálódott, még lehetséges a helyreállítás, ha az előző képmásolat létezik. A helyreállítási folyamat egy korábbi teljes mentésről indul, alkalmazza az inkrementális másolatokat, aztán előregörgeti az archív adatbázisnapló-állományokat majd az aktív naplóállományt. Minél több naplót kell előregörgetni, annál több időt vesz igénybe a helyreállítás. Ha nem érhető el képmásolat, mint kezdési pont, meg lehet próbálni csak az adatbázisnapló alapján helyreállítani az adatbázist. Ha az adatokat betöltötték és a betöltés naplózva volt, a helyreállítás lehet egyszerűen a naplórekordok alkalmazása. Ezzel a típusú helyreállítással egy-egy adatbázis-objektumot is helyreállíthatunk.
Point-in-time (PIT) helyreállítás (adott időpontra): Általában alkalmazás szintű problémák kezelésére szolgál. A point-in-time helyreállítás minden olyan tranzakciónak a hatását eltávolítja, amely az adott időpont óta történt. A helyreállítási pontot egy aktuális dátummal és idővel adhatják meg. A point-in-time helyreállítás véghezviteléhez egy képmásolati mentés alapján kell helyreállítani az adatbázist és az adatbázisnapló alapján előregörgetni azt, azaz az adatbázisnapló használatával a változásokat alkalmazni. A naplórekordokat csak az adott időpontig kell feldolgozni. A 9-2-es ábra segítségével a point-in-time helyreállításnak a célját érthetjük meg.
9-2. ábra – Point-in-time helyreállítás
A sikeres point-in-time helyreállításhoz a helyreállító folyamatnak az adatbázis-tartalmat egy előző konzisztens pontban lévő állapotra kell tudnia hozni. A point-in-time helyreállítás kétféleképp történhet:
Visszatöltjük az adatbázisba a képmásolati mentést, majd az adatbázisnapló alapján előregörgetünk, azaz az adatbázisnapló használatával újraalkalmazzuk a változásokat. A naplórekordokat azonban csak a megadott helyreállítási időpontig kell feldolgozni.
Nem töltjük vissza a képmásolatot, helyette az adatbázisnapló alapján visszagörgetjük és eltávolítjuk azokat az adatbázis-változásokat, amelyek a helyreállítási pont után történtek.
Ha az adatbázis-kezelő rendszer támogatja a helyreállítás mindkét típusát, akkor az adatbázis-adminisztrátor választhat az megoldások közül. Érdemes arra alapoznia, hogy melyik megoldás megvalósítása esetén kevesebb a leállási idő. Ha sok változást kell eltávolítani, akkor a helyreállítás és előregörgetés kevesebb leállást vesz igénybe. Ha az eltávolítandó változások száma minimális, akkor az adatbázisnapló alapján történő visszagörgetés vesz kevesebb leállási időt igénybe. A point-in-time helyreállítás típusától függetlenül az adatbázis-adminisztrátornak egy helyreállítási pontot kell választania, amely egy olyan pontot reprezentál, ahol az adatok konzisztensek voltak. Ez a pont a korábban létrehozott konzisztenciapontok egyike lehet, hiszen ebben a pontban biztosított az adatintegritás, a hivatkozási integritás, és a tranzakciók integritása is. Meg kell határozni, hogy pontosan mi futott a hiba óta, amely miatt a helyreállítás történik. Az adatbázis-adminisztrátor megvizsgálja az ütemezett feladatokat, riportot készít az adatbázisnaplóból, és áttekinti a számítógép üzeneteit, hogy a hiba után futott folyamatokat meghatározza.
A point-in-time helyreállítással nem csak a teljes adatbázis tartalmát lehet egy adott időpillanatra helyreállítani, hanem csak bizonyos objektumokét is. Ebben az esetben azonban még körültekintőbben oda kell figyelni az adatbázis-objektumok függőségére, hiszen ha egy adatbázis-objektumot helyreállítunk, akkor a tőle függőeket is helyre kell állítani.
Tranzakció-helyreállítás: ide tartozik az a hagyományos helyreállítási típus is, amelyre akkor van szükség, amikor az adatbázis nem normál módon áll le. Ebben az esetben még lehetnek olyan tranzakciók, amelyeket már véglegesítettek, de a hozzájuk tartozó megváltozott adatok még nem kerültek az adatbázisba, azonban a tranzakció véglegesítésének a ténye már az adatbázisnaplóban van. Előfordulhat az is, hogy olyan adatok vannak az adatbázisban, amelyek olyan tranzakciók hatására módosultak, amelyeket még nem véglegesítettek. A tranzakció-helyreállításnak a hagyományos megközelítése az, hogy amikor az adatbázis újraindul, akkor egy helyreállító folyamat is újraindul, amely megvizsgálja az adatbázisnaplót és az adatbázis tartalmát, és a véglegesített tranzakcióhoz tartozó módosított adatokat az adatbázisba írja, a nem véglegesített tranzakcióhoz tartozó adatok módosítását pedig visszavonja. Ha nem hagyományos értelemben tekintünk a tranzakció-helyreállításra, akkor a tranzakció-helyreállítás alatt egy olyan alkalmazás-helyreállítást értünk, ahol egy bizonyos időtartamban történt tranzakciók hatásait eltávolítjuk az adatbázisból. Ez a helyreállítási típus nem adatbázis-objektumokra vonatkozik, hanem tranzakciókra. A tranzakció helyreállítás segítségével lehetővé válik a felhasználó számára az adatbázis bizonyos részeinek helyreállítása a felhasználó által megadott feltételekre alapozva. Ebben a környezetben a tranzakció a felhasználó által definiált nézete a folyamatnak. A legfontosabb feltétel, hogy a tranzakciók között, melyeket vissza próbálunk állítani és az adatbázis-kezelő rendszer többi tranzakciója között nem lehet korreláció. Például felhasználói szintű tranzakciók lehetnek: minden adatbázis módosítás, amelyet VALAKI userid-jű felhasználó hajtott végre szerda 11.50 óta; vagy minden adatbázis törlés, amelyet a FIZETES nevű alkalmazás tegnap 8.00 óta hajtott végre. Számos oka lehet, ami miatt a tranzakció-helyreállításra szükség van: a rendszerszoftverben hibák vannak, nem megfelelően tesztelt kód futott, valaki a feladatütemező szoftvert megváltoztatta, stb., vagy nincs is probléma, csak egy programot ugyanazokon az adatokon még egyszer kellene futtatni. Ha azonosítottuk a tranzakciót, amelyet helyre kell állítani, akkor három opció áll rendelkezésünkre:
point-in-time helyreállítás: Azonosítsunk minden olyan adatbázis-objektumot, amelyre az alkalmazás hatással volt, és végezzünk hagyományos point-in-time helyreállítást, hogy eltávolítsuk a tranzakciók hatását. Aztán manuálisan futtassuk újra az érvényes munkákat. Azaz nem SQL szkript segítségével, hanem ugyanazon a módon, ahogy először végre lett hajtva, például ugyanazokkal az értékekkel újrafuttatjuk az alkalmazásokat.
UNDO helyreállítás: csak a rossz tranzakció hatásait távolítjuk el. Egyszerű SQL alapú tranzakció helyreállítás, csak SQL utasításokat foglal magában. Az UNDO helyreállítás végrehajtásához az adatbázisnaplót kell végigvizsgálni a tranzakció azonosításához és egy anti-SQL utasításokat kell generálni: az INSERT-ből DELETE legyen, a DELETE-ből INSERT, az UPDATE-t fordítsuk meg. Ha az anti-SQL utasítások generálva vannak, SQL szkriptként lehet futtatni. Ehhez online adatbázis szükséges. Az UNDO helyreállítás alatt is történhet rendszerleállás és az UNDO tranzakció is hibázhat, amelyet egyszerűen visszagörgethetünk, mert SQL utasításokból áll. A 9-3-as ábrán az UNDO helyreállítás folyamatát figyelhetjük meg.
9-3. ábra – UNDO helyreállítás
REDO helyreállítás: minden tranzakciót eltávolítunk, amely egy adott időpont után történt és csak a jó tranzakciókat alkalmazzuk újra. A megmenteni kívánt tranzakcióhoz generálunk SQL-t. Egy szokásos point-in-time tranzakciót végzünk, hogy eltávolítsunk minden tranzakciót az adott időpontig, majd a jó tranzakciókat az SQL-szkript segítségével újraalkalmazzuk. A 9-4-es ábrán az REDO helyreállítás folyamatát figyelhetjük meg.
9-4. ábra – REDO helyreállítás
Ha a mentéshez és helyreállításhoz tároláskezelő szoftvert használunk, az adatbázis-objektumokhoz nem létezik önálló képmásolati mentés. Ebben az esetben a tároláskezelő szoftvert kell alkalmazni a helyreállítás végrehajtására. Az aktuális helyreállítási eljárás a használt tároláskezelő szoftver típusától függ, és attól hogy az az adatbázis-kezelő rendszer helyreállítási mechanizmusával hogyan dolgozik együtt.
Az offsite katasztrófa-helyreállítás a legritkább, de a legátfogóbb típusa az adatbázis-helyreállításnak. Egy offsite katasztrófa-helyreállítás akkor szükséges, ha egy természeti katasztrófa vagy valamilyen más baleset lehetetlenné teszi az elsődleges adatfeldolgozó központ működését. Ebben az esetben a teljes adatbázis-környezetet kell újra felállítani, és helyre kell állítani az adatbázis-kezelő rendszert, az adatbázis-objektumokat és az adatokat.
Eredetileg a helyreállítást katasztrófák és hardverhibák esetén kellett legtöbbször elvégezni, de ez ma már nem igaz. A helyreállításokat ma legtöbbször alkalmazásproblémák miatt kell végezni. Ma a rendszerleállásokat inkább a szoftver, mint a hardverhibák okozzák.
Valójában nagyon kevés adatbázis-adminisztrátornak kell a tesztek kivételével igazi katasztrófa-helyreállítást elvégeznie. Ma a médiahiba is ritka. A felhasználói hibák és az alkalmazáshibák a legáltalánosabb okai az adatbázis-helyreállításnak és így az elsődleges okai a rendszer elérhetetlenségének.
Szoftverproblémákat és szoftverhibákat olyan tranzakciók okoznak, melyek hibásak, vagy javításra szorulnak. Az adatbázis méretben és összetettségben általában nő, így a lehetőség is, hogy a rossz tranzakciók olyan adathibát okoznak, amelytől a cég üzleti folyamatai függenek. A tranzakció-helyreállítás válasz lehet az elérhetőségi problémákra, de sok esetben a tranzakció-helyreállítást nem lehet elvégezni vagy nem tanácsolható a végrehajtása. A végrehajtandó helyreállítás típusát, a adatbázis-adminisztrátor határozza meg. A döntést a következő kérdésekre adott válaszok segíthetik:
Tranzakció azonosítása: Minden problémás tranzakciót lehet azonosítani? A helyesen elvégzett munkát újra végre lehet hajtani?
Adatintegritás: Más módosította a sorokat, mióta a probléma történt? Ha igen, folyamatban van még a módosítás? Elérhető még minden szükséges adat? Azóta történt újraszervezések, betöltések, vagy sok adat törlése szükségessé teszik egy képmásolati mentés használatát? A helyreállítás okozza más adatok elvesztését? Ha igen, lehet azonosítani az elveszett adatokat valamilyen módon és újralétrehozni azokat?
Sebesség: Ha több technika érhető el, melyik a leggyorsabb? Szükséges inkrementális mentéseket használni? Mennyi adatbázisnapló szükséges a helyreállításhoz? Lehet bármit tenni a naplórekordok számának csökkentése érdekében, mint például a teljes, az inkrementális mentéseket és az adatbázisnaplót egyesíteni?
Elérhetőség: Milyen hamar érhető el ismét az alkalmazás? Elkerülhető az offline mód?
Káros hatás: A hiba mennyire hat az adatbázisra? Születtek döntések a rossz adatokra alapozva? Lehet a helyettesítő munkában bízni?
Ezeknek a kérdéseknek a segítségével valójában azt határozhatjuk meg, hogy mennyi a munka ára, azaz hogy meg lehet-e határozni, hogy mit kell újra elvégezni. Az a cél, hogy a helyreállítandó adatokat minél gyorsabban megtaláljuk, és a lehető legrövidebb helyreállítási mód segítségével helyreállítsuk azokat.
Sok tényező befolyásolhatja a helyreállítási folyamat időtartamát. A következő tényezők rövidíthetik meg az időtartamot:
Minél kisebb a komponensek mérete, amelyeket helyre kell állítani, annál rövidebb a helyreállítási folyamat. Általában minél kevesebbet kell elvégezni, annál gyorsabban megy.
Vegyük figyelembe az adatbázis-objektumok partícióit, és a partíciós szintek mentését és helyreállítását. Előfordulhat, hogy egy egész objektumra hatással levő hiba valójában egy-egy partícióra korlátozható.
Használjuk a lemezen lévő képmásolati mentéseket és archivált naplóállományokat. A lemezen lévő állományok elérése gyorsabb és a feldolgozáshoz nincs szükség a szalagok cseréjére várni. Gyorsabb, ha lemezt használunk szalag helyett a helyreállításnál. Ha szükséges, akkor a helyreállítás előtt inkább másoljuk fel a szalagról a lemezre a mentéseket és a naplóállományokat.
Teszteljük a képmásolati mentéseket, hogy érvényesek-e. Egy érvénytelen képmásolat használata meghosszabbítja a helyreállítási folyamatot.
A mentés és helyreállítás automatizálása eltávolítja a manuális hibákat, így csökkenti a leállás időtartamát.
Ha lehet, az adatbázistervet minél kevesebb függőséggel tervezzük meg. Az önálló adatbázis-objektumok a helyreállítást minimalizálhatják, mert kevesebb kapcsolódó adatbázis-objektumot szükséges egyszerre helyreállítani.
Médiahiba esetén általában az utolsó lehetséges időpontig történő helyreállítást használjuk. Médiahiba esetén a hibás médián található adatbázis-objektumokat nem lehet elérni vagy módosítani. Az adatbázis-adminisztrátor a médiahiba bekövetkezte előtti időpontra kell, hogy helyreállítson minden, az adott médián található adatbázis-objektumot.
Tranzakcióhiba esetén point-in-time helyreállítást vagy tranzakció-helyreállítást kell végezni. A tranzakció-helyreállítást leginkább hibás programfutás miatt alkalmazzuk. A nem megfelelő futásból származó adatbázis-változásokat el kell távolítani minden olyan adatbázis-objektumból, amelyre hatással volt.
Adatbázis-kezelő rendszerbeli hiba vagy alrendszer hiba után az utolsó lehetséges időpontra állítunk helyre. Az ilyen helyreállítás célja, hogy minden adatbázis-objektum adatát a hibapontot megelőző konzisztens állapotra állítsuk helyre.