van egy kis backup history itt.

itt van egy kis biztonsági mentési előzmény.

az SQL Server minden biztonsági mentés előzményeit nyomon követi. Ezeket az adatokat az MSDB adatbázisban tárolja. Ez egy rendszeradatbázis, és alapértelmezés szerint a rendszeradatbázisaink a C meghajtón vannak tárolva, hacsak a telepítés során másként nem rendelkezik.

ez néhány különböző módon veszélyt jelent:

A C meghajtó feltöltődhet, ami az MSDB írásait meghiúsítja. A rendszermeghajtó gyakrabban töltődik fel, mint gondolná – a gondatlan felhasználók hatalmas fájlokat töltenek le az asztalukra (a rendszermeghajtón találhatók), vagy a Windows frissítések sok fájlt töltenek le a rendszermeghajtón lévő ideiglenes mappába.

az MSDB növekedhet a C meghajtó kitöltéséhez, ami a Windows meghibásodását okozhatja. Azokban az esetekben, amikor nagyon gyakran készítünk tranzakciónapló-mentéseket nagyszámú adatbázisról, és soha nem töröljük az MSDB-t, ez az adatbázis elég nagy lehet ahhoz, hogy veszélyeztesse a kis C meghajtókat. Amikor a C meghajtó megtelik, a Windows keményen meghibásodik.

a rendszermeghajtó gyakran lassú. Az SQL Server régi verzióiban a rendszeradatbázisok nem voltak jól indexelve. Kombinálja ezt a lassú helyi meghajtókkal, és van egy receptünk a lassú MSDB hozzáféréshez. Az egyik esetben az éjszakai biztonsági mentés során az idő 2/3-át csak az MSDB frissítésével töltötték!

a Felügyeleti eszközök nem hatékonyan lekérdezhetik az MSDB-t. Láttunk olyan eseteket, amikor a harmadik fél szerverfigyelő eszközei folyamatosan ellenőrizték az MSDB-t, hogy megbizonyosodjanak arról, hogy minden adatbázis biztonsági másolatot készít, de lekérdezéseik nem használtak indexeket. Ezek a lekérdezések lehetnek a leglassabbak a szerveren.

az SQL Server sp_Blitz parancsfájl ezen része ellenőrzi, hogy van-e 60 napnál régebbi msdb biztonsági mentési előzmény. Ez önmagában nem jelent problémát – érdemes hosszú biztonsági mentési előzményeket tartani ott, csak a teljesítményátviteli jelentések készítése érdekében–, de fontolja meg az adatok Excelbe vagy kedvenc jelentési eszközébe történő áthelyezését, ahelyett, hogy minden alkalommal megütné az MSDB-t.

vissza az sp_Blitz oldalra, vagy tegyen fel nekünk kérdéseket

hogyan lehet megtisztítani a túlterhelt MSDB biztonsági mentési előzményeket

fontolja meg a 60 napnál régebbi adatok MSDB biztonsági mentési előzményeinek törlését. Meg tudod csinálni ezt egy pár különböző módon:

  • létrehozhat egy karbantartási tervet, amely rendszeresen futtatja az Előzmények tisztítási feladatát.
  • létrehozhat egy egyszerű SQL Server Agent feladatot, amely rendszeresen futtatja az sp_delete_backuphistory programot (futtathatja az sp_purge_jobhistory programot is, ha szeretné, hogy megfeleljen a maintenance plan követés funkciójának).

bontsa ki a Maintenance Plan követési csomópontot az SSMS-ben, kattintson a jobb gombbal, és válassza az “új Maintenance Plan követés” lehetőséget…”

2015-04-10_14-20-46

válassza ki a karbantartási tisztítási feladatot az eszköztár ablakából (vegye figyelembe, hogy néha ez az ablak balra rejtve marad az SSMS Object Explorer alatt:

2015-04-10_14-21-26

a befejezéshez kattintson duplán a feladatra, válassza ki a kívánt Tisztítás típusát, valamint azt, hogy mennyi adatot szeretne megőrizni. Néha két feladatot hozok létre, mert kevésbé érdekelnek az ügynöki feladatok előzményei és a karbantartási terv előzményei, mint a biztonsági mentések, és általában azt akarom, hogy a biztonsági mentési előzmények megfeleljenek az adatmegőrzési irányelveimnek.

2015-04-10_14-22-03

Akárhogy is, ha a szervernek nagy a története, ennek a lépésnek az első futtatása hosszú időt vesz igénybe. Ahogy Brent megjegyezte az MSDB szűk keresztmetszet cikkében, előfordulhat, hogy szélsőséges intézkedéseket kell alkalmaznia, mint például a rendszeradatbázis idegen kulcsainak megváltoztatása, csak azért, hogy a törlések megtörténjenek.

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé.