A képmásolati mentés a mentési és helyreállítási terv alapkomponense. Ha hiba történik, és sérül az adatintegritás, akkor az adatok mentési képmásolatát lehet használni az adatbázis helyreállításához.
Az adatbázis mentése az adatok egy konzisztens másolatát jelenti, amelyet a COPY segédprogram outputja ad. A segédprogram adatbázis-kezelő rendszerenként más és más, lehet BACKUP, COPY, DUMP, és EXPORT. Néhány adatbázis-kezelő rendszer natív operációs rendszerbeli állományrendszer-parancsot használ az adatok mentésére.
Csak naprakész és pontos képmásolati mentésekből lehet az adatbázist helyreállítani. Ehhez az adatbázis-adminisztrátornak a mentések tervezésénél két alapvető dologról kell döntenie: milyen gyakran végezzen képmásolati mentést, és hány mentési generációt tartson meg.
Az adatbázis mentésének a gyakoriságát két fontos tényező befolyásolja. Az egyik az, hogy az adatbázis-adminisztrátornak úgy kell meghatároznia a mentések gyakoriságát, hogy a mentési folyamatok ne akadályozzák a napi üzleti munkát. A másik szempont pedig az, hogy ha hiba történik a rendszerben, akkor a helyreállításra fordítandó idő minél kevesebb legyen. Hiszen amíg a helyreállítás nem történik meg, addig az adatbázist nem lehet használni. Ekkor pedig a cégünk nem tudja ellátni a tevékenységét.
Az adatbázis-adminisztrátornak a mentési generációkból legalább kettőt meg kell tartania. Ennek az az oka, hogy ha az egyik mentési generáció megsérül és használhatatlanná válik, akkor még az adatbázisunk egy másik, esetleg régebbi mentési generáció alapján helyre lehessen állítani. Ha régebbi mentési generációt használunk a helyreállításra, akkor szükség lesz az azóta bekövetkező módosításokat tartalmazó naplóra is, hogy a helyreállított adatbázis a lehető legutóbbi időpillanatbeli állapotot tartalmazza.
Az adatbázis konzisztens, naprakész helyreállításához a legtöbb esetben az adatbázisnaplóra is szükség van. Az adatbázis-adminisztrátornak a mentés tervezése során nem szabad elfeledkeznie az adatbázisnapló megfelelő mentéséről sem.
A teljes mentés azt jelenti, hogy az adatbázis minden objektumát, és azoknak a teljes adattartalmát képmásolati állományba vagy állományokba menti az adatbázis-kezelő rendszer. Az inkrementális mentés ezzel szemben csak azokat az adatváltozásokat tartalmazza, amelyek az utolsó mentés óta történtek.
Az inkrementális mentés előnye, hogy sokszor gyorsabb lehet, és kevesebb helyet foglalhat a lemezen vagy a szalagon. A hátránya, hogy a helyreállítás az inkrementális mentés alapján sokkal lassabb, mivel egy sor akár többször is változhatott mielőtt az utolsó érték előállt.
Néhány adatbázis-kezelő rendszernek van olyan eszköze, amelynek a segítségével elemezni lehet, hogy melyik mentést érdemes választani az adott esetben: a teljes vagy az inkrementális mentést. Ha ez az opció nem érhető el, akkor az adatbázis-adminisztrátor csak a saját tapasztalataira és ismereteire hagyatkozhat.
Általában az inkrementális mentés akkor javasolható, ha az adatbázisban kevés változás történt vagy ha az adatbázis rendelkezésre állása elsődleges az üzlet szempontjából. Azonban ha az adatblokkoknak a 30-40%-a vagy több módosult, akkor már teljes mentés javasolt.
Kis adatbázisok esetén a teljes mentés a javasolt. Egy adatbázis kicsinek tekinthető, ha még nem érte el a 100GB méretet. Azonban ez az érték a technika fejlődése miatt az idővel növekszik.
A 8-1-es ábrán egy adatbázis mentéseit láthatjuk. Pénteken végeztek egy teljes mentést, majd a munkával töltött napok után inkrementális mentéseket végeztek az adatbázison.
8-1. ábra – Adatbázismentés
Ha az adatbázis-kezelő rendszer támogatja az inkrementális mentést, akkor lehet, hogy az inkrementális mentések egyesítést is támogatja. Az egyesítés során a rendszer a teljes mentést egyesíti az inkrementális mentésekkel, és létrehoz egy új teljes mentést.
Az egyesítés nincs hatással az adatbázis teljesítményére, hiszen elvégezhető az adatbázis működésétől függetlenül.
Az egyesített teljes mentés létrehozásával a helyreállítás időtartamát rövidíthetjük le.
A képmásolati mentés adatbázis, táblatér- vagy táblaszinten történik. Azaz olyan objektumokat mentünk, amelyek adatokat tárolnak. A támogatott szint az adatbázis-kezelő rendszertől függ. Általában az adatbázis-kezelő rendszer minél szemcsézettebb vezérlést biztosít az adatbázis-objektumok mentéséhez, annál könnyebb hatékonyan megvalósítani egy használható mentési-helyreállítási stratégiát. Finomabb szemcsézettség esetén könnyebb különböző adatbázis-objektumokhoz különböző mentési ütemezést megvalósítani. A ritkán vagy egyáltalán nem változó adatainkat ritkán kell menteni, esetleg csak hetente vagy havonta. Azonban a dinamikus, gyakran változó adatokat akár naponta vagy óránként is menthetjük.
Az indexeket az adatok alapján az adatbázis-kezelő rendszer újra fel tudja építeni. Ezért kézenfekvő a kérdés, hogy kell-e az indexeket menteni.
A legtöbb adatbázis-kezelő rendszer támogatja az indexek mentését, sőt van olyan adatbázis-kezelő rendszer, amelynél az indexeket is menteni kell. Más adatbázis-kezelő rendszereknél viszont az adatbázis-adminisztrátor döntheti el, hogy szükséges-e egy indexet menteni.
Ha az index is mentve van, akkor az adatbázis-adminisztrátor a helyreállításnál választhat, hogy visszaállítja azt, vagy újraépíti a visszaállított adatok alapján.
Azt, hogy az adatbázis-adminisztrátor hogyan dönt egy index mentéséről, és a későbbi helyreállításáról, befolyásolhatja, hogy a mentett indexnek mennyi tárterületre lesz szüksége, illetve ha az index nincs mentve, akkor mennyi időbe telik újragenerálni azt. A nagyobb táblák indexeinek az újragenerálása olyan sok időt vehet igénybe, hogy inkább megéri menteni, és helyreállítani, annak ellenére, hogy sok helyet foglalnak. Ugyanez a helyzet a multimédiás adatok indexelésével is.
Ha az indexek mentését és helyreállítását végezzük, figyeljünk oda, hogy a mentett adatoknak a mentett indexek megfeleljenek. Ha nem felelnek meg egymásnak, akkor helyreállítás után elérhetetlenek lehetnek az adataink vagy a lekérdezések hibás vagy érvénytelen eredményeket adhatnak.
Az adatbázis mentésének az a legegyszerűbb módja, hogy leállítjuk az adatbázist, lementjük, majd újra elindítjuk. Azonban ebben az esetben a felhasználók számára az adatbázis nem érhető el.
Azonban ma már a legtöbb adatbázis-kezelő rendszer ismeri azt a mentési technikát, amellyel az adatbázis mentése alatt az adatbázis elérhető marad. Ebben az esetben a mentésben az adatbázisnaplónak lesz nagy szerepe. Hiszen mentés közben a mentés alatt lévő objektumok adattartalma módosulhat, ami azt eredményezi, hogy a kapott mentés nem lesz konzisztens. A konzisztencia biztosításához az adatbázisnaplóra lesz szükség. A naplóban megtalálhatjuk a mentés elkezdése óta történt változásokat. A mentés után az adatbázis-adminisztrátornak gondoskodnia kell arról, hogy a szükséges adatbázisnapló is mentve legyen.
Néhány adatbázis-kezelő rendszer használja a forró mentés és hideg mentés kifejezéseket, amely a mentés alatti párhuzamos elérésekre utal. A forrónál az adatbázis online marad, a hidegnél le kell állítani a releváns állományokat.
Az adatbázis-kezelő rendszer kapacitásától függően a forró mentés problémásabb lehet, mert:
sokkal komplexebb megvalósítani
nagyobb a processzor és az input/output műveletek igénye a mentés alatt
archiválni kell a naplót
az adatbázis-adminisztrátornak esetleg szkripteket kell írnia
alapos tesztelést igényel, hogy biztosak lehessünk, hogy a mentés valóban alkalmas a helyreállításra
A forró mentésnek a helyreállításnál is van hátránya, mert az adatbázis-kezelő rendszernek az adatbázisnaplóban található bejegyzéseket újra végre kell hajtania, ezáltal a helyreállítás időtartama megnő.
Néhány adatbázis-kezelő rendszernek a mentési-helyreállítási segédprogramja képes arra, hogy egy naprakész, konzisztens képmásolati mentést készítsen a meglévő képmásolati mentés és az adatbázisnapló egyesítésével. Hasonlóan, mint az inkrementális képmásolatok egyesítésénél.
Létezik olyan mentési technika is, amely a felhasználóknak csak azt engedi meg, hogy a mentés alatt lévő adatbázis-objektumokat olvassák. Ez gyorsabb mentést biztosít, mint azok a technikák, ahol a párhuzamos írás is engedélyezve van, és a mentésünk a napló nélkül is konzisztens lesz.
Az adatbázis-adminisztrátornak ismernie kell az adatbázis-kezelő rendszer mentési eszközének működését. A párhuzamos elérés tekintetében a megfelelő mentési stratégia kidolgozásához a következőket kell figyelembe venni:
A párhuzamos elérések és módosítások szükségessége a mentési folyamat alatt.
A mentési folyamatra szánható idő mennyisége és a párhuzamos elérések hatása az adatok mentésének gyorsaságára.
A helyreállítási segédprogram sebessége.
Helyreállításkor az adatbázisnaplók elérésének szükségessége.
A mentési terv elkészítésekor bizonyosodjunk meg arról, hogy a mentési terv alapján az adatbázis-objektumok mentésekor konzisztens helyreállítási pontot hozunk létre, és, hogy minden, az adatbázis-objektumokkal kapcsolatban álló objektum mentésre kerül. Ez jelenti az alkalmazásokhoz szükséges kapcsolatokat, a hivatkozási megszorításokat és a triggereket is. Helyreállításkor minden objektumot ugyanahhoz a mentési időponthoz tartozó pontra kell visszaállítani. Ha egy korábbi mentést használunk, akkor minden objektumnak az adott időpontbeli verziója szükséges.
Az adatbázis-kezelő rendszer QUIESCE nevű segédprogramot biztosíthat, amelyet arra használhatunk, hogy egy adatobjektumnak az adott időpillanatban lévő konzisztens állapotát menthetjük ki. A QUIESCE segédprogram megállítja az adatbázis-objektumokra vonatkozó módosítási kéréseket, hogy biztosítsa a konzisztenciát és mentse az adatbázisnaplóba a konzisztenciapontot.
Ha az adatbázis-kezelő rendszer nem támogatja a QUIESCE opciót, más módon kell biztosítani a konzisztens pontot a helyreállításhoz. Pl. tehetjük az adatbázis-objektumot csak olvasható állapotba, vagy offline állapotba.
Az adatbázis-adminisztrátornak a lehető leggyakrabban konzisztenciapontot kell készítenie. De a következő esetekben mindenképp ajánlott ezt megtenni:
Az aktív napló archiválása előtt: Ha valamikor elveszítenénk az aktív naplót és az archív naplót kellene a helyreállításkor használni, akkor az archív naplót csak az utolsó konzisztenciapontig használhatnánk. Ha ez után használnánk, inkonzisztens adatokat kapnánk.
Egymáshoz kapcsolódó adatbázis-objektumok mentése előtt, azaz például kapcsolódó adatbázistáblák mentése előtt. Ez biztosítja, hogy a képmásolati mentések minden kapcsolódó adatbázis-objektuma konzisztens egymással.
Rögtön, miután egy képmásolati mentés elkészült. Így a mentés elkészültével egy jó helyreállítási pontot hozunk létre. Akkor érdemes, ha a mentés az online adatbázis működése közben történt.
Azonnal, mielőtt súlyos adatbázisbeli módosítást hajtanánk végre. Ha a módosítás közben hiba történik, a helyreállítás a konzisztens állapotig, az előző konzisztenciapontig történhet. Így elkerülhető a képmásolati mentés a módosítás előtt.
Csöndes időszakban: sok tevékenység esetén a konzisztenciapont létrehozása akadályozza a tevékenységeket. Ha az adatbázis-objektumokat nem módosítják, könnyebben lehet konzisztenciapontot létrehozni.
Az adatbázis-kezelő rendszer minden adatbázis-változást egy naplóállományba naplóz, amelyet hívnak tranzakciónaplónak vagy adatbázisnaplónak is. A naplórekordok minden SQL DML utasításhoz elkészülnek. Az adatbázisnapló alapján vissza lehet keresni, újra végre lehet hajtani, illetve vissza lehet vonni az adatbázison történt változások hatását.
Az idővel és az adatbázis-változások növekedésével az adatbázisnapló méretben növekedni fog. Azt az adatbázisnapló-állományt, amelyet az adatbázis-kezelő rendszer aktuálisan ír, úgy is hívjuk, hogy aktív napló. Ha az aktív adatbázisnapló betelik, naplóváltás történik, azaz egy új naplóállományt kezd el írni az adatbázis-kezelő rendszer. Ekkor a régi, betelt naplóállományt az adatbázis-kezelő rendszer archiválja. A naplóállományokról bővebben az Adat- és tároláskezelés című fejezetben olvashatunk.
Egy adatbázisnapló-állomány archiválása naplóváltáskor történik, amikor az aktív naplót bezárjuk. A régi aktív naplóállomány tartalma nem törlődni fog, hanem az adatbázis-kezelő rendszer a tartalmát az archív naplóállományba másolja. Közben pedig az adatbázisban történő változások az új aktív naplóállományba kerülnek.
A 8-2-es ábrán a naplóváltáshoz kapcsolódó naplóarchiválási folyamatot láthatjuk.
8-2. ábra – Naplóarchiválás
A napló archiválása esetén előfordulhat olyan eset, hogy hamarabb lesz szükség az adott naplóállományra, mint ahogy az archiválva lett. Azaz az adatbázis-kezelő rendszer nem tud írni aktív naplóállományt, mert a ciklusban soron következő naplóállomány még nincs archiválva és nem lehet törölni a tartalmát. Ebben az esetben az adatbázis-kezelő rendszer nem hajtja végre az adatbázisbeli módosításokat, amíg a soron következő naplóállomány törölve nem lesz.
Az adatbázis-adminisztrátor a napló archiválásának automatikus megvalósítását az adatbázis-kezelő rendszer paramétereivel vezérelheti. A legtöbb adatbázis-kezelő rendszer esetén az adatbázis-adminisztrátor egy parancs segítségével kézzel is kérheti a napló archiválását.
A helyreállítást, illetve a hibák miatti leállás megelőzését az is támogatja, hogy ha az aktív adatbázisnapló-állományból több, teljesen egyforma példány létezik, amelyeket az adatbázis-kezelő rendszer párhuzamosan ír. Ezeket a naplópéldányokat az adatbázis-adminisztrátor több lemezen helyezi el. Az adatbázis elérhetetlenné válik, ha nem tudja írni a naplót, hiszen az adatbázisbeli módosításokat nem tudja hova írni. Azonban több naplópéldány esetén, ha az egyik lemez sérül, akkor az adatbázis még elérhető marad, amíg a több példányból még egyet tud írni az adatbázis-kezelő rendszer. Az aktív adatbázisnaplóból mindig legalább két példányt kell biztosítani.
Egyensúlyozni kell két szempont között: elég gyakran kell képmásolati mentéseket készíteni, de a cég napi üzleti munkáját ez nem zavarhatja. Az adatbázis-adminisztrátornak ezt az adatbázis-kezelő rendszer kapacitására és használati feltételeire kell alapoznia.
A mentés ütemezéséhez elemezni kell az adatbázisunkat, a következő kérdésekkel:
Mennyire használják az adatot egy nap?
Milyen gyakran változik az adat?
Mennyire kritikus az adat a cég életében?
Könnyen újra létre lehet hozni az adatot?
Milyen típusú elérés szükséges az adatokhoz? 24/7 órás elérés szükséges?
Mi a költsége annak, ha az adat nem érhető el?
Mennyi a pénzértéke annak, ha a rendszer egy percig áll?
Általánosságban a kritikus adatokat gyakrabban kell menteni, mint a nem kritikusakat, és a dinamikus, gyakran változó adatokat gyakrabban kell menteni, mint a statikusakat. De mindez függ az adott adatbázistól és az adott cégtől.
A gyakori képmásolati mentés azért szükséges, hogy ha az adatbázisban hiba lép fel, akkor a helyreállításhoz szükséges idő a lehető legrövidebb legyen. Azaz hiba esetén a lehető legkevesebb ideig legyen elérhetetlen a rendszer.
A helyreállításhoz szükséges időtartamnak az egyik legmeghatározóbb tényezője az, hogy a helyreállításhoz szükséges naplót mennyi idő alatt lehet feldolgozni.
A helyreállításhoz szükséges időtartamot a következő tényezők határozzák meg:
a szükséges mentési állományok megkeresése, beleérte azt is, hogy ha szalagos egységen vannak tárolva, akkor a szükséges szalagokat csatolni kell
a teljes képmásolati mentések feldolgozása
ha vannak, akkor az inkrementális mentés feldolgozása
majd az archivált és az aktív adatbázis-naplórekordok feldolgozása
Ezek közül a tényezők közül a legidőigényesebb az adatbázis-naplórekordok feldolgozása lehet. Minél több idő telt el az utolsó mentés óta, annál több változás történt, annál több ideig tart ezeket a változásokat újra végrehajtani az adatbázisban. Ha régi mentésünk van, előfordulhat, hogy a feldolgozandó naplóállományok összmérete nagyobb lesz, mint a teljes adatbázisunk mérete. Ennek elkerülésére szükséges a gyakori mentés.
Ezért általában elmondhatjuk, hogy minél gyakrabban készítünk képmásolati mentést, annál rövidebb ideig tart a helyreállítás. A képmásolati mentés készítéséhez szükséges idő összegét ki kell egyensúlyozni a mentési folyamat alatt történő párhuzamos feldolgozás szükségességével.
Nagyon ritkán kell az adatbázis-kezelő rendszerhez tartozó állományokat menteni. Ezek az állományok jelentik a rendszerkatalógust, könyvtár-objektumokat, konfigurációs állományokat, rendszerkönyvtárakat, szalagkezelő könyvtárakat, programokhoz forrás és futtatható állományok könyvtárát.
Akkor lehet rá szükség, amikor eszköz vagy emberi hiba történik, vagy frissítéskor fellépő problémák megoldásakor.
Az adatbázis-kezelő rendszer állományainak a megfelelő mentését és helyreállítását is tervezni kell.
Az adatbázis-kezelő rendszer UNLOAD segédprogramját használhatjuk logikai mentés készítésére. A következő esetekben lehet hasznos, ha van logikai mentésünk:
adatbázis-objektum vagy táblabeli sor helyreállítása esetén: ha egy táblát valaki eldob, vagy egy pár sort töröl egy adatbázistáblából, akkor ezeket a fizikai mentésből nehéz visszaállítani. Egy logikai mentéssel a hiányzó adatokat egyszerűen visszatölthetjük a táblába.
az adatbázis-kezelő rendszer verzió frissítése esetén: lehet, hogy egyszerűbb logikai mentést végezni és azt visszatölteni az új verzióba, mint a meglévő adatstruktúrát konvertálni.
heterogén adatbázis migráció esetén: A különböző platformokon a fizikai struktúrák különbözhetnek. Pl. Oracle Linux-on vagy Unix-on. Egyszerűbb logikai mentést végezni és azt betölteni az új rendszerbe.
adatmozgatás esetén: ha adatokat mozgatunk egy adatbázisból más adatbázisba, vagy a cégen belül több adatbázisba.
A logikai mentés az adatbázis online állapotában elvégezhető. A párhuzamos adatelérés a teljesítményre hatással lehet. A logikai mentésnél az adatbázis-adminisztrátornak az adatintegritásra figyelnie kell.
Ebben az esetben az adatbázis-kezelő rendszer vezérlésén kívül történik a mentés. A mentés előtt bizonyosodjunk meg arról, hogy a menteni kívánt objektumok közül egyiket sem lehet írni, vagy állítsuk le az objektumot esetleg tegyük csak olvasható állapotba. A mentés után indítsuk el vagy tegyük írható-olvasható állapotba.
Az eszköz használata előtt ismerjük meg az eszköz működését, mert pl. van olyan tároláskezelő mentési mód, amelyik megnyitott állományt nem ment.
Helyreállításkor mindig azt a tároláskezelőt kell használni, amelyikkel mentettünk.
Ha egyszer a mentési-helyreállítási stratégiát megalkottuk, és a mentés ennek megfelelően van megvalósítva, akkor a mentési rendszer sokáig fut az adatbázis-adminisztrátor beavatkozás nélkül. Idővel a dolgokat azonban elfelejtjük, az adatbázis-adminisztrátori személyzet változik, és ha az adatbázis-adminisztrátornak az adatbázist helyre kell állítani, akkor tudnia kell, hogy ezt hogyan tegye. Ezért az adatbázis-adminisztrátornak megfelelően dokumentálnia és tesztelnie kell a mentési-helyreállítási stratégiát, és annak a megvalósítását, az eljárásokat.
Nagyon fontos, hogy a helyreállítás tesztelve legyen minden lehetséges hiba esetén: médiahiba, példányhiba, alkalmazáshiba, stb. Legyünk biztosak, hogy mindent helyre tudunk állítani.
A mentési-helyreállítási stratégia elkészítésénél vegyük figyelembe a következő vezérelveket, hogy biztosítani tudjuk a helyreállítható környezetet:
Legyen legalább két másolatunk minden képmásolati mentésből, hogy elkerüljük a helyreállíthatatlan állapotot, amelyet például egy médiahiba okozhat. A két másolatot két különböző helyen tároljuk.
Koordináljuk a helyi mentési-helyreállítási stratégiánkat a katasztrófa mentési-helyreállítási stratégiánkkal. Sok mentési segédprogram párhuzamosan készíti el a helyi és a távoli mentést.
Tartsunk meg legalább kettő generációt a képmásolati mentésekből az egyes adatbázis-objektumokhoz. Ha a legújabb képmásolat hibás, akkor visszatérhetünk egy előző másolathoz.
A képmásolati mentést készítsük lemezre, majd migráljuk szalagra, amely felgyorsíthatja a mentés folyamatát. Nemcsak azért, mert a lemez gyorsabb, mint a szalag, hanem mert nem kell arra várni, hogy a szalagot kézzel kicseréljék.
A mentéseket tömöríthetjük is, hogy csökkentsük a mentéshez szükséges szalagok számát.
Legyünk biztosak, hogy a mentési-helyreállítási tervünk tartalmazza a rendszer-katalógusbeli adatbázis-objektumokat is.
Biztosítsuk, hogy a mentési folyamat újraindítható legyen. Például ha a mentési folyamat 3 órát vesz igénybe és 2 óra 30 percnél megszakad, akkor az újraindításnál már csak fél óra kell, hogy befejezze, egyébként ha nincs újraindítás, akkor újabb 3 óra.
Miután a mentés elkészült egy adatbázis-kezelő rendszerbeli eszközzel bizonyosodjunk meg a mentés helyességéről, azaz hogy a képmásolatok pontosak, érvényesek.
Az alkalmazások által használt, de nem az adatbázisban tárolt adatokat ugyancsak ugyanabban az időben kell menteni.
Biztosítani kell, hogy helyreállítási célra az adatbázisnapló is mentve legyen, illetve az aktív napló elérhető legyen.
Egyéb, a mentéssel kapcsolatos tanácsok:
Ha a rendszerünket átszervezzük, érdemes utána teljes mentést végezni. Egyébként helyreállítás esetén az átszervezéskor keletkezett rengeteg adatbázisbeli változást a napló alapján újra végre kell hajtani, ami sok időt és erőforrást emésztene fel.
Ha adatbázis-naplózás nélkül töltünk adatokat az adatbázisba, akkor utána mentést kell végezni. Ha nem végzünk mentést, hiba esetén a betöltött adataink el fognak veszni, hiszen adatbázis-napló nem készült róluk.
Point-in-time helyreállítás után is végezzünk teljes mentést.
Általában is elmondható, hogy ha az adatbázis-kezelő rendszerben naplózás nélküli változások történnek, akkor mindig a teljes mentés javasolt.