DBCC shrinkdatabase (Transact-SQL)

database_name | database_id | 0

A neve vagy azonosító az adatbázis, ami kell tömöríteni. Ha 0, az aktuális adatbázist.

A százalékos szabad hely, hogy maradjon az adatbázisban tömörítés után.

Tömörítése adatfájlok mozgatásával kiosztott lapokat a fájl végére helyett osztott lapok a fájlban. target_percent argumentum opcionális.

Szabad hely a végén az operációs rendszer fájl nem tért vissza, és nem változik a fizikai fájl méretét. Ezért, ha az argumentum megadva NOTRUNCATE, tömörítés adatfájlok kissé.

NOTRUNCATE érv csak az adatfájlokat. A naplófájlok nem érinti.

Ez kiválasztja az összes szabad helyet a végén az operációs rendszer fájlt, de nem mozdul oldalak egy fájlt. az adatok fájl mentésre kerül csak az utolsó kiosztott mértékben. target_percent érvelés figyelmen kívül hagyja, ha meg van adva egy érv TRUNCATEONLY.

TRUNCATEONLY érv csak az adatfájlokat. A naplófájlok nem érinti.

Elnyom minden információs üzenetek, amelyek súlyossági szintek 0-10.

Tömöríteni az összes adatot és a naplófájlok a megadott adatbázis, fuss DBCC SHRINKDATABASE. Tömöríteni egy adatfájlt, vagy jelentkezzen fájlt a megadott adatbázis, a parancs futtatásához DBCC SHRINKFILE.

DBCC SHRINKDATABASE műveleteket lehet állítani bármely szakaszában a folyamat, minden elvégzett munka van tárolva.

Az adatbázis mérete nem lehet kisebb, mint a minimális adatbázis mérete. A minimális méret - a méret megadott adatbázis létrehozása, illetve az utolsó méretet kifejezetten meg működését változás a fájl mérete, például egy DBCC SHRINKFILE vagy ALTER DATABASE. Például, ha az adatbázis létrehozása, amelynek mérete 10 MB, majd emelkedett 100 MB, akkor lehet nyomni csak 10 MB, akkor is, ha törli az összes adatot.

Működés DBCC SHRINKDATABASE megadása nélkül a paraméter NOTRUNCATE vagy TRUNCATEONLY egyenértékű DBCC SHRINKDATABASE műveletet a paraméter NOTRUNCATE elvégzése után DBCC SHRINKDATABASE a TRUNCATEONLY paraméterrel.

Összenyomható adatbázis nem lehet egyfelhasználós módban. Más felhasználók használhatják az adatbázisban, ha összenyomjuk. Ez vonatkozik a rendszer adatbázisok.

Lehetetlen tömöríteni az adatbázist idején azt alátámasztani. Ezzel szemben, akkor nem lehet létrehozni egy biztonsági másolatot az adatbázisról során zsugorodási működését.

Team munka DBCC SHRINKDATABASE

Utasítás DBCC SHRINKDATABASE zsugorodik adatfájlok egyesével, és a log fájlokat, mintha azok mind egy összefüggő log medence. Fájltömörítés mindig végzik a végén.

Tegyük fel, hogy létezik egy adatbázis nevű mydb. amelynek egyetlen adatfájlt és két log fájlokat. Minden adat log file, és a 10 MB, és az adatállományt tartalmaz adatokat 6MB.

Tegyük fel, hogy a mydb adatbázis adatfájl tartalma 7 MB adatot. Amikor megadja egy érv, amelynek értéke 30 target_percent megengedett tömörítés a fájl megjelenése 30 százaléka a teret. Azonban, amikor meghatározzák az értéke az érv target_percent adatfájlt 40 nem tömöríthető, mert alkatrész Database Engine nem tömöríti a képet egy kisebb méretű, mint a jelenlegi mérete által elfoglalt adatokat. Ez a helyzet lehet képviseli más módon: 40 százaléka a kívánt szabad hely + 70 százaléka a teljes adatállomány (7 MB 10 MB) nagyobb, mint 100 százalék. Mivel az összeg a kívánt oldható százalék, és a jelenlegi százalékos által elfoglalt adatfájlt meghaladja a 100 (10 százalék), bármilyen érték target_percent. ami nagyobb, mint 30, nem vezethet a tömörítés az adatállományban.

Az alkatrészek a naplófájl Database Engine használ target_percent érv kiszámításához a cél méret a teljes naplót. Ezért target_percent érv, hogy mennyi szabad hely a magazin a műtét után a kompresszió. Cél mérete az egész napló alakítjuk, majd a cél méret az egyes naplófájl.

Utasítás DBCC SHRINKDATABASE megpróbálja összezsugorodik azonnal, minden egyes fizikai log fájlt a cél méret. Ha nem része a logikai log nem kerül a virtuális log fájlokat, amelyek mérete meghaladja a cél méret a log fájlt, a fájl sikeresen csonka és DBCC SHRINKDATABASE nyilatkozat nélkül befejeződik az üzeneteket. Azonban, ha része a logikai napló tárolja a virtuális naplók túl a megadott méretű, a Database Engine felszabadítja annyi helyet, mint lehetséges, majd létrehoz egy tájékoztató üzenet. Jelentés leírja a lépéseket meg kell tennie, hogy mozog a logikai log ki a virtuális naplók végén a fájlt. Miután az összes akció DBCC SHRINKDATABASE nyilatkozatot lehet használni, hogy kiszabadítsa a fennmaradó helyet. További információért lásd. Szakasza a tranzakciós napló tömörítés.

Mivel a log fájl lehet zsugorodott csak egy virtuális log fájlt határ log fájl tömörítési a mérete kisebb, mint a méret a virtuális log fájlt, ez lehetetlen, akkor is, ha nem használják. A méret a virtuális log fájlt választjuk dinamikusan a Database Engine létrehozásakor vagy kiterjesztése log fájlokat. További információ a virtuális log fájlokat, lásd. Lásd Transaction Log Fizikai architektúra.

A legmegfelelőbb módszer

Kérjük, vegye figyelembe a következő információkat, ha tervez adatbázis tömörítés.

• A legnagyobb hatással a kompressziós üzemeltetés érhető el, ha azt használják a műtét után, amely megteremti a sok elvesztegetett hely, például a csonkolt és eltávolítása után a táblázat
  
• a legtöbb adatbázis igényel némi szabad hely a szokásos napi műveleteket. Ha az adatbázis tömörítés van végrehajtva rendszeresen, de ismét növekszik a méret, ami azt jelenti, hogy a kibocsátás a kompressziós hely szükséges a rendszeres műveleteket. Ebben az esetben a rendszeres adatbázis tömörítés nincs hatással;
  
• zsugorodik művelet nem őrzi meg a töredezettség állapotának indexek az adatbázisban, és mint általában, nagyobb mértékű fragmentáció. Ez a másik oka annak, hogy nem szükséges, hogy a kompakt az adatbázist rendszeresen;
  
• nem kell telepíteni adatbázis paraméter értéke AUTO_SHRINK ON ok nélkül.
  

hibaelhárítás

Compression műveleteket lehet blokkolni a tranzakció izolációs szint futó verzión alapuló ellenőrzési vonalak. Például, ha közben folyamatosan eltávolítjuk művelet fut szinten a szigetelés, változaton alapul ellenőrzési vonalak futó művelet DBCC ZSUGORODÓ DATABASE, kompressziós művelet várják a befejezése a törlési művelet. Ebben az esetben a művelet DBCC SHRINKFILE és DBCC SHRINKDATABASE kiadási információs üzenetet (5202 és 5203 az SHRINKDATABASE az SHRINKFILE) a hiba log SQL Server 5 percenként az első órában, majd egy üzenetet óránként. Például a hiba napló tartalmazza a következő hibaüzenet jelenik meg:

Ez azt jelenti, hogy a zsugorodási művelet blokkolta ügylet pillanatfelvétel, amelyek időpecsétje régebbi, mint a védjegy 109 képviselő az utolsó tranzakció befejeződik a tömörítési művelet. Ez is azt mutatja, hogy az oszlopokat transaction_sequence_num first_snapshot_sequence_num dinamikus vezetés képviseletét sys.dm_tran_active_snapshot_database_transactions tartalmaznak száma 15. Ha az oszlopok vagy transaction_sequence_num first_snapshot_sequence_num bevezetése tartalmaznak száma kevesebb, mint az előző lépésben végrehajtott művelet tömörítés (109), a tömörítési művelet várni kell végezniük ezeket a tranzakciókat.

A probléma megoldásához kövesse az alábbi lépéseket:

• A tranzakció befejezése blokkoló tömörítési művelet.
  
• Fejezze be a zsugorodási működését. Minden elvégzett munka mentésre kerül.
  
• Míg tömörítési művelet vár a blokkoló ügyletek nem kell semmit.