Haladó biztonsági mentési és visszaállítási opciók, Windows pro
A mentési és visszaállítási műveletek ütemezésének módszerei sokak számára ismertek, ugyanez vonatkozik a BACKUP és a RESTORE parancsok használatára is. A legtöbb adatbázis-kezelő ismeri a gyakran használt parancsparamétereket, de kevesen ismerik a kevésbé ismert paraméterek előnyeit. Az ilyen paraméterek alkalmazását ebben a cikkben tárgyalja
IT infrastruktúra az Ön vállalkozása számára
A mentési és visszaállítási műveletek ütemezésének módszerei sokak számára ismertek, ugyanez vonatkozik a BACKUP és a RESTORE parancsok használatára is. A legtöbb adatbázis-kezelő ismeri a gyakran használt parancsparamétereket, de kevesen ismerik a kevésbé ismert paraméterek előnyeit. Az ilyen paraméterek alkalmazását ebben a cikkben tárgyalja.
A biztonsági mentés sértetlenségének ellenőrzése
Egyetértek azzal az állítással, hogy nincs mentés, amíg vissza nem áll. Sajnos az adatbázis-kezelők gyakran elfelejtik a biztonsági másolatok integritásának ellenőrzését. A különböző fórumok látogatóinak az adatvesztéssel való megbirkózás érdekében gyakran kiderül, hogy a mentések is sérültek.
Az oldal ellenőrzőösszegét minden alkalommal ellenőrizzük, amikor az adatfájl lapja feldolgozásra kerül a memóriába. Ez azonban nem garantálja az összes torzulás észlelését. Sok működő alkalmazás nem végzi el az összes elhelyezett oldal rendszeres olvasását az adatbázisban, ezt csak az integritás ellenőrzése és a teljes mentés során. Az ellenőrzések sértetlenségénél kiszámolják az oldalak ellenőrző összegeit. De alapértelmezés szerint a teljes és differenciális biztonsági másolatok nem végeznek ellenőrző ellenőrzéseket.
1. képernyő: üzenet hibaüzenettel kapcsolatos hiba miatt
Egyes adatbázis-kezelők más módon ellenőrizhetik a biztonsági másolat integritását: a VERIFYONLY paraméterrel rendelkező RESTORE parancs segítségével. Sajnos csak a fejlécet ellenőrzi, de nem a biztonsági adatokat. A RESTORE parancsot két paraméterrel kell használni: CHECKSUM és VERIFYONLY. Csak ebben az esetben a helyreállítási folyamat ismételten ellenőrzi az oldal összes ellenőrző összegét és a teljes mentést. Ne feledje, hogy nem tudja ellenőrizni a CHECKSUM paraméter nélkül létrehozott biztonsági oldalak ellenőrző összegeit.
Az adatvesztés csökkentése baleset esetén
Gyakran előfordul, hogy az adatbázis adminisztrátorának első lépése baleset esetén egy biztonsági rendszerre vált, vagy visszaállít egy biztonsági másolatot. Miután elindította a visszaállítási műveletet, a tranzakciós napló utolsó részének tárolási lehetősége visszavonhatatlanul elveszett. Ez egy biztonsági másolat a végleges naplófájlról: a naplórész, amely nem íródott a biztonsági mentéshez, log farknak nevezik.
Képernyő 2. A mentési hibaüzenet a hiányzó vagy sérült adatfájlok miatt
Növelje a mentési sebességet
A legtöbb adatbázis-kezelő nem gyanítja, hogy jelentősen javíthatja a biztonsági mentés sebességét. Számos előnnyel jár, többek között:
* Csökkenti a rendszerben lévő jelenlét időtartamát az I / O rendszeren (és potenciálisan - a processzoron a biztonsági másolatok tömörítésével kapcsolatos terhelés);
* csökkenti annak kockázatát, hogy a tranzakciós naplófájl a biztonsági mentés során keletkezett tranzakciós napló miatt nő, különösen, ha az adatbázis hosszú időn keresztül teljes mértékben biztonsági másolatot készít.
Csökkentett állásidő baleset után
A helyreállítási művelet egyik közös célja, hogy a lehető legkevesebb adatot helyreállítsa az állásidők csökkentése érdekében. A színpadi felújítás módszerének megjelenésével ez a feladat sokkal könnyebbé vált. További előny a szakaszos helyreállítás az online módban. Egy lépésenkénti művelet során az adatbázisnak csak egy része kerül visszaállításra, például egy oldal (a PAGE paraméter használatával) vagy egy fájl (a FÁJL paraméterrel). A lépésenkénti online helyreállítás újraszervezi az adatbázis egy részét, és az adatbázis többi része továbbra is elérhető. Ez azért lehetséges, mert az adatbázis részleges rendelkezésre áll.
Helyreállítása az egyik oldal használatával csak néhány rendszergazdák. Egy lehet visszaállítani az oldal, feltéve, hogy van egy módja annak, hogy helyreállítási oldalt az aktuális időt, kivéve a bit allokáció térképek működő egész adatbázist, és egyedi oldalak, mint például a boot és a fájl fejlécét (ugyanazok a korlátozások érvényesek az automatikus korrekció oldalak adatbázis tükrözés). Így meg kell adnunk a mentést a tranzakciós napló. Egyes oldalak (például azok, amelyek a metaadat-táblákat) nem lehet visszaállítani a működési mód, de sikeresen vissza önállóan.
Néha egy egész nagyon nagy adatbázist (VLDB) kell visszaállítania, de akkor is csökkentheti az adatbázis online áthelyezésének időtartamát, biztosítva a részleges adatbázisok hozzáférhetőségét és a növekményes online helyreállítást. Ebben az esetben az adatbázis egy töredéke visszaáll, és on-line kerül. Ennek eredményeképpen a felhasználóknak nem kell megvárniuk a teljes adatbázis helyreállítását.
Pont-in-time helyreállítás
Néha az adatbázist vissza kell állítani egy bizonyos, nem utolsó pillanatra. Példa: egyes adatok törlésre kerültek, és az adatbázist az adat törlése előtt létrehozott napló biztonsági másolatával vissza kell állítani. Ha ismeri a törlés idejét, egyszerűen használja a STOPAT paramétert úgy, hogy a naplófájl-helyreállítás ne haladja meg a megadott időtartamot.
Alternatív megközelítés a megjelölt tranzakciók használata. Ebben az esetben speciális jegyzékek jönnek létre a tranzakciós naplóban. például:
Később ez az ismert pont az adatbázis helyreállítására használható. A STOPATMARK paraméter segítségével visszaállíthatja a "to" adatbázist, beleértve a címkézett tranzakciót is. Ha vissza kell állítania az "előtt", de a címkézett tranzakció nélkül, használja a STOPBEFOREMARK paramétert.
Ha alkalmazni szeretné ezeket a beállításokat, ismernie kell a folyóiratcímke nevét. Ha nem írták be kézzel, megtalálhatók az msdb logmarkthistorikus táblájában (az msdb adatbázis biztonsági másolatának másik oka). Ha a logmarkthistorikus tábla adatai elvesztek, nehéz megtalálni a folyóiratcímkék nevét. Ehhez harmadik féltől származó vagy nem dokumentált naplózási és naplózási parancsokat kell használnia.
Ha egy naplócímke ismétlődően használatos, akkor az AFTER paraméter használatával meg kell adni egy leállítási időt. Ellenkező esetben a leállítás az első címkén történik, amely megegyezik a RESTORE utasításban megadott névvel.
Megszakított helyreállítási művelet újraindítása
A RESTART a RESTORE parancs egyik kevéssé ismert paramétere. Ezzel megszakíthatja a megszakított visszaállítási műveletet. A visszaállítási műveletek rendszeresen írnak ellenőrzési pontok fájlját, amely jelzi, hogy a helyreállítás milyen ponttal történt. Az ellenőrzési pontok fájlai (amelyek nincsenek kapcsolatban az adatbázis szokásos vezérlőpontjával) az \ InstanceName \ MSSQL \ Backup mappában tárolódnak.
Az ellenőrzőpontfájl a következő feltételekkel frissül:
* Zérus adatbázisfájl létrehozása és kitöltése befejeződött;
* Minden biztonsági adatkészletet feldolgoznak;
* Az ismétlődési szakasz a helyreállítás alatt befejeződik.
Ha az ellenőrzőpontfájl létezik, és a WITH RESTART paramétert használják, a már végrehajtott lépések kihagyásra kerülnek. Ha a RENDSZER BEÁLLÍTÁSA és az ellenőrzőpont fájl hiányzik, akkor a 3. képernyőn megjelenő üzenet jelenik meg.
3. képernyő: Hibaüzenet: nincs ellenőrző pont észlelve
A leghasznosabb paraméter
Gyakran megkérdezem, hogy a kevéssé ismert biztonsági és helyreállítási lehetőségek közül melyik a leghasznosabb. A teljesítmény hatalmas nyereséget nyerhet az I / O pufferek konfigurálásával a BUFFERCOUNT és a MAXTRANSFERSIZE paraméterekkel. Az egyoldalas és lépésenkénti helyreállításnak köszönhetően a PAGE és a PARTIAL paraméterek segítségével a baleset utáni leállások jelentősen csökkentek. De ha egy paramétert kellett megadnom, a NO_TRUNCATE-ot választottam a napló végső részének biztonsági mentéséhez. Ez az egyetlen módja annak, hogy a balesetet megelőző helyreállítást végezzen, ha az adatfájlok nem állnak rendelkezésre.
Ossza meg az anyagot kollégákkal és barátokkal