1. rész

Beállítás mentés MS SQL. ez az egyik első dolog, ami eszembe jut, ha az tükrözze a következményeit a termelési veszteséget adatbázisok. Gyakran előfordul, hogy sok rendszergazda, hogy megoldja ezt a problémát kezdődik az első találkozás az SQL Server Management Studio (SSMS) és Transact SQL nyelv (T-SQL). Ez a kiadvány, úgy döntöttünk, hogy indul egy cikksorozatot szentelt a tipikus hibák és tévedések. Nem fogjuk leírni, hogyan kell elvégezni a következő lépéseket az elmentett konfigurációt, és elsősorban a fontos pontokat, amelyeket általában elhanyagolt, azzal az eredménnyel, hogy megfosztja az összes beállítás mentés MS SQL.

Tévhit: Azt kell csak beállítani mentést ...

Tehát általában gondolnak azok, akik először szembesülnek ezzel a kérdéssel. Azonban minden nem olyan egyszerű, mint amilyennek látszik első pillantásra. Itt van egy minimális problémák listáját, hogy meg kell érteni:

  1. Mi a mentési stratégia?
  2. Mi az a modell adatbázis helyreállítását, és melyik modellt választani?
  3. Hol jobb, hogy a mentést a fájlokat és hogyan kell ellenőrizni őket?
  4. Több mennyi ideig tárolja a mentéseket?
  5. Hogyan hozzunk létre egy rendszeres ellenőrzése az adatbázis integritását SQL Server?
  6. Hogyan hozzunk létre e-mail értesítést a hibák?

Szinte minden kérdésben saját hibalista és a modell hibákat.

Hiba: Válassza ki a megfelelő stratégia biztonsági mentési és helyreállítási

mentési és helyreállítási stratégia határozza meg az adatbázis helyreállítási modell, gyakorisága backup (teljes, különbözeti és tranzakciós napló) és a mélysége tárolására mentést. A stratégia tulajdonképpen meghatározza, hogy milyen maximális az időre elveszíti adatok meghibásodása esetén, és milyen hosszú a helyreállítási kerül végrehajtásra. Más szóval, az ütemezési stratégiát kell vezérelnie információk fontosságát és súlyát a következményeket, ha elvesztek meghibásodása esetén, valamint az elfogadható sebesség átállást. Nagyon gyakran, annak érdekében, hogy ne zavarja, kiválasztotta a legegyszerűbb stratégia, míg az adatok elvesztését, akár rövid időn belül tele van súlyos következményekkel járhat a vállalkozás számára.

Meg kell jegyezni, hogy az SQL Server lehetővé teszi, hogy visszaszerezze az adatbázisban, nem csak akkor, amikor a teljes mentés (backup), hanem bármely más időpontban jött létre. Ehhez az SQL Server ügyleti jegyzőkönyv az a mechanizmus. A mechanizmus egyszerű - összes kérelmet Adatok módosítása, amely fogadja az SQL Server, rögzítik a tranzakciós napló. Ugyanakkor a magazin rendszeresen biztonsági másolatot. Ez úgy történik, gyorsan és gond nélkül a felhasználók számára. A meghibásodás esetén visszanyerjük a teljes lánc viszont: az első, teljes biztonsági másolatot az adatbázisról, majd jelentkezzen mentést. Ennek eredményeként az adatbázis helyreáll idején a mentés az utolsó ügylet napló.

Modell adatbázis helyreállítását az egyik legfontosabb tulajdonsága, amely meghatározza, hogy a tranzakciós napló megmarad. Így a teljes helyreállítási modell, a tranzakciós napló megmarad, és ez automatikusan csonkolt egy egyszerű modell szerint.

Hiba: A teljes gyógyulás nélküli modell a tranzakciós napló

Hibák minimalizálása, ha létrehozunk egy szolgáltatási politika a QMB sablon automatikusan beállítja a megfelelő adatbázis modell.

Tévhit: A teljes felépülés modellje kevésbé termelékeny, mint egy egyszerű

Néhány említésre méltó teljesítmény közötti különbség a teljes és egyszerű helyreállítási modell nem. Azt kell mondani, hogy az írt adatok a tranzakciós napló bármely hasznosítási modell. Azonban, ha a Simple helyreállítási modell, a log fájl automatikusan csonka.

Hiba: Nem sikerült létrehozni egy adminisztrátor értesítést

Beállítás mentés MS SQL akkor nem történhet meg, amíg a bejelentést úgy vannak kialakítva (általában e-mailben). Azt hiszem, mindenki tudja, hogy a rendszergazda azonnal ellenőrizze az esetleges hibákat mentési műveletek, különben az egész dolog egy tartalék nincs értelme. Végtére is, az a tény, hogy a biztonsági másolat, nem jelenti, hogy működni fog holnap. Ennek oka lehet sok: elfogy a lemezterület, megváltoztatni a szabályokat a könyvtár, stb A mi gyakorlatban, ez egy teszt, hogy ha a rendszergazda az az összeomlás pillanatában úgy találta, hogy a mentés működő adatbázis már néhány hónap nem jött létre.

Meg kell említeni egy kellemetlen pillanat: egy értesítést, hogy küld egy szabályos alkatrész-adatbázisában Mail nem tartalmaz információt a hibáról. Ezért, miután megkapja azt, annak érdekében, hogy megértsék a súlyosságát a hibák, az adminisztrátornak nézni minden alkalommal SQL Server naplók. Sajnos az idő múlásával, sok rendszergazda már nem hagyhatja figyelmen kívül a hibákat, és reagál rájuk. A törvény szerint a műfaj ilyenkor bázis repülni a pokolba.