Megosztás a következőn keresztül:

DBCC SHRINKDATABASE (Transact-SQL) – Adatbázis zsugorítási parancs (Transact-SQL)

A következőkre vonatkozik:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsSQL-adatbázis a Microsoft Fabricben

Csökkenti a megadott adatbázisban lévő adatok és naplófájlok méretét.

Jegyzet

A zsugorítási műveletek nem tekinthetők rendszeres karbantartási műveletnek. A rendszeres, ismétlődő üzleti műveletek miatt növekvő adat- és naplófájlok nem igényelnek zsugorítási műveleteket.

Transact-SQL szintaxis konvenciók

Szintaxis

Az SQL Server szintaxisa:

DBCC SHRINKDATABASE   
( database_name | database_id | 0   
     [ , target_percent ]   
     [ , { NOTRUNCATE | TRUNCATEONLY } ]   
)  
[ WITH 

    {     
         [ WAIT_AT_LOW_PRIORITY 
            [ ( 
                  <wait_at_low_priority_option_list>
             )] 
         ] 
         
         [ , NO_INFOMSGS]
    }
]

< wait_at_low_priority_option_list > ::=  
    <wait_at_low_priority_option>
    | <wait_at_low_priority_option_list> , <wait_at_low_priority_option>

< wait_at_low_priority_option > ::=
  ABORT_AFTER_WAIT = { SELF | BLOCKERS }

Az Azure Synapse Analytics szintaxisa:

DBCC SHRINKDATABASE
( database_name
     [ , target_percent ]
)
[ WITH NO_INFOMSGS ]

Érvek

| database_namedatabase_id | 0

A zsugorolandó adatbázis neve vagy azonosítója. A 0 az aktuális adatbázis használatát határozza meg.

target_percent

Az adatbázisfájlban a zsugorítási művelet befejezése után megmaradó szabad terület százalékos aránya.

Ha target_percent van megadva TRUNCATEONLY, előfordulhat, hogy a fájl végén szabad terület nem jelenik meg.

NOTRUNCATE

Áthelyezi a hozzárendelt lapokat a fájl végéről a fájl elején lévő nem hozzárendelt lapokra. Ez a művelet tömöríti az adatokat a fájlban. target_percent nem kötelező. Az Azure Synapse Analytics nem támogatja ezt a lehetőséget.

A fájl végén lévő szabad terület nem kerül vissza az operációs rendszerbe, és a fájl fizikai mérete nem változik. Ezért úgy tűnik, hogy az adatbázis nem zsugorodik NOTRUNCATEmegadásakor.

NOTRUNCATE csak adatfájlokra alkalmazható. NOTRUNCATE nincs hatással a naplófájlra.

TRUNCATEONLY

A fájl végén található összes szabad helyet felszabadítja az operációs rendszer számára. Nem helyez át lapokat a fájlon belül. Az adatfájl csak az utoljára hozzárendelt kiterjedésig zsugorodik. Az Azure Synapse Analytics nem támogatja ezt a lehetőséget.

Ha target_percent van megadva TRUNCATEONLY, előfordulhat, hogy a fájl végén szabad terület nem jelenik meg.

NO_INFOMSGS nélkül

Letiltja a 0 és 10 közötti súlyossági szintű információs üzeneteket.

várakozás alacsony prioritással zsugorítási műveletekkel

A következőkre vonatkozik: SQL Server 2022 (16.x) és újabb verziók, Azure SQL Database, Felügyelt Azure SQL-példány

Az alacsony prioritású várakozási funkció csökkenti a zárolási konfliktust. További információ: A DBCC SHRINKDATABASE egyidejűségi problémáinak ismertetése.

Ez a funkció hasonló a WAIT_AT_LOW_PRIORITY használatához az online indexműveletek során, néhány különbséggel.

  • Nem adható meg ABORT_AFTER_WAIT opció NONE.

VÁRAKOZÁS_ALACSONY_PRIORITÁSON

Ha egy zsugorítási parancsot WAIT_AT_LOW_PRIORITY módban hajt végre, a várakozási zsugorítási művelet nem blokkolja a sémastabilitást (Sch-S) igénylő új lekérdezéseket, amíg a zsugorítási művelet nem várakozik, és el nem kezdi a végrehajtást. A zsugorítási művelet akkor hajtódik végre, amikor képes megszerezni egy sémamódosítási zárolást (Sch-M). Ha egy új zsugorítási művelet WAIT_AT_LOW_PRIORITY módban hosszú ideig futó lekérdezés miatt nem tud zárolást szerezni, akkor a zsugorítási művelet alapértelmezés szerint 1 perc elteltével időtúllép, és hiba nélkül kilép.

Ha egy új zsugorítási művelet WAIT_AT_LOW_PRIORITY módban hosszú ideig futó lekérdezés miatt nem tud zárolást szerezni, a zsugorítási művelet alapértelmezés szerint 1 perc elteltével időtúllépést okoz, és hiba nélkül kilép. Ez akkor fordul elő, ha a zsugorítási művelet nem tudja beszerezni a Sch-M zárolást az egyidejű lekérdezések vagy Sch-S zárolást tartalmazó lekérdezések miatt. Időtúllépés esetén a rendszer a 49516-os hibát küldi el az SQL Server hibanaplójába, például: Msg 49516, Level 16, State 1, Line 134 Shrink timeout waiting to acquire schema modify lock in WLP mode to process IAM pageID 1:2865 on database ID 5. Próbálkozzon újra a zsugorítási művelettel WAIT_AT_LOW_PRIORITY módban.

ABORT_AFTER_WAIT = [ SELF | BLOKKOLÓK ]

  • SAJÁT

    SELF az alapértelmezett beállítás. Lépjen ki a jelenleg végrehajtott zsugorított adatbázisműveletből művelet nélkül.

  • BLOKKOLÓK

    Tiltsa le az összes olyan felhasználói tranzakciót, amely blokkolja a zsugorító adatbázis-műveletet, hogy a művelet folytatódhat. A BLOCKERS beállításhoz a bejelentkezéshez ALTER ANY CONNECTION engedély szükséges.

Eredményhalmaz

Az alábbi táblázat az eredményhalmaz oszlopait ismerteti.

Oszlop neve Leírás
DbId Annak a fájlnak az adatbázis-azonosítószáma, amelyet az adatbázismotor megpróbált zsugorítani.
FileId A fájlazonosító száma annak a fájlnak, amelyet az adatbázismotor megpróbált kicsinyíteni.
CurrentSize A fájl jelenleg elfoglalt 8 KB-os lapjainak száma.
MinimumSize A fájl legalább 8 KB-os oldalainak száma. Ez az érték egy fájl minimális méretének vagy eredetileg létrehozott méretének felel meg.
UsedPages A fájl által jelenleg használt 8 KB-os lapok száma.
EstimatedPages Azon 8 KB-os oldalak száma, amelyekre az adatbázismotor becslése szerint a fájl le lehet zsugorítható.

Jegyzet

Az adatbázismotor nem jeleníti meg azoknak a fájloknak a sorait, amelyek nem zsugorodottak.

Megjegyzések

Egy adott adatbázis összes adatának és naplófájljának zsugorításához hajtsa végre a DBCC SHRINKDATABASE parancsot. Ha egy adott adatbázishoz egyszerre egy adatot vagy naplófájlt szeretne zsugoríteni, hajtsa végre a DBCC SHRINKFILE parancsot.

Ha meg szeretné tekinteni az adatbázis szabad (nem foglalt) területének aktuális mennyiségét, futtassa a sp_spaceused.

DBCC SHRINKDATABASE műveletek a folyamat bármely pontján leállíthatók, és a befejezett munka megmarad.

Az adatbázis nem lehet kisebb, mint az adatbázis konfigurált minimális mérete. Az adatbázis eredeti létrehozásakor meg kell adnia a minimális méretet. Vagy a minimális méret lehet az utolsó, kifejezetten beállított méret egy fájlméret-módosítási művelettel. Az olyan műveletek, mint a DBCC SHRINKFILE vagy a ALTER DATABASE, példák a fájlméret-módosítási műveletekre.

Fontolja meg, hogy egy adatbázis eredetileg 10 MB méretű. Ezután 100 MB-ra nő. Az adatbázis legkisebb mérete 10 MB lehet, még akkor is, ha az adatbázis összes adatát törölték.

Adja meg a NOTRUNCATE vagy a TRUNCATEONLY lehetőséget DBCC SHRINKDATABASEfuttatásakor. Ha nem teszed meg, az eredmény ugyanaz, mintha DBCC SHRINKDATABASE műveletet futtatnál NOTRUNCATE-gyel, amelyet ezt követően egy DBCC SHRINKDATABASE művelet futtatása követne a TRUNCATEONLY-mal.

A zsugorodott adatbázisnak nem kell egyfelhasználós módban lennie. Más felhasználók is dolgozhatnak az adatbázisban, ha az le van zsugorítva, beleértve a rendszeradatbázisokat is.

Az adatbázis biztonsági mentése közben nem zsugoríthatja az adatbázist. Ezzel szemben nem készíthet biztonsági másolatot az adatbázisokról, amíg az adatbázis zsugorítása folyamatban van.

Ha WAIT_AT_LOW_PRIORITY van megadva, a zsugorítási művelet Sch-M zárolási kérése alacsony prioritással várja a parancs egy percig történő végrehajtásakor. Ha a művelet az időtartamig le van tiltva, a rendszer végrehajtja a megadott ABORT_AFTER_WAIT műveletet.

Az Azure Synapse SQL-készletekben nem ajánlott zsugorítási parancsot futtatni, mivel ez egy I/O-igényes művelet, és offline állapotba helyezheti a dedikált SQL-készletet (korábbi nevén SQL DW). Ezen kívül, a parancs futtatása után költségvonzata lesz az adattárház-pillanatképeknek.

Ismert problémák

A következőkre vonatkozik: SQL Server, Azure SQL Database, Felügyelt Azure SQL-példány, dedikált Azure Synapse Analytics SQL-készlet

  • Jelenleg a tömörített oszlopcentrikus szegmensekben a LOB-adattípusokat (varbinary(max), varchar(max) és nvarchar(max)) használó oszlopokat nem érinti DBCC SHRINKDATABASE az és DBCC SHRINKFILEa .

A DBCC SHRINKDATABASE működése

DBCC SHRINKDATABASE fájlonként zsugorítja az adatfájlokat, de úgy zsugorítja a naplófájlokat, mintha az összes naplófájl egy összefüggő naplókészletben lenne. A fájlok mindig a végétől kezdve zsugorulnak.

Tegyük fel, hogy rendelkezik néhány naplófájllal, egy adatfájllal és egy mydbnevű adatbázissal. Az adatok és naplófájlok mindegyike 10 MB, az adatfájl pedig 6 MB adatot tartalmaz. Az adatbázismotor kiszámítja az egyes fájlok célméretét. Ez az érték az a méret, amelyre a fájlt le kell zsugoríteni. Ha DBCC SHRINKDATABASEa target_percent van megadva, az adatbázismotor a célméretet úgy számítja ki, hogy az target_percent a fájlban a zsugorodás után szabad hely legyen.

Ha például 25-ös target_percent ad meg a zsugorításhoz mydb, az adatbázismotor kiszámítja az adatfájl célméretét 8 MB-ra (6 MB adat és 2 MB szabad terület). Ezért az adatbázismotor az adatfájl utolsó 2 MB-járól az adatfájl első 8 MB-jának szabad területére helyezi át az adatokat, majd csökkenti a fájlt.

Tegyük fel, hogy a mydb adatfájlja 7 MB adatot tartalmaz. A 30-target_percent megadásával ez az adatfájl a 30 szabad százalékos értékre zsugorítható. A 40-es target_percent megadása azonban nem csökkenti az adatfájl méretét, mivel nem hozható létre elegendő szabad terület az adatfájl aktuális teljes méretében.

Erre a problémára másképpen is gondolhat: 40 százalék szabad terület + 70 százalék teljes adatfájl (10 MB-ból 7 MB) több mint 100 százalék. A 30-nál nagyobb target_percent nem zsugorítja az adatfájlt. Nem zsugorodik, mert az a százalék, amennyit szabadon szeretne hagyni, plusz az adatfájl által elfoglalt százalék együtt meghaladja a 100%-ot.

Naplófájlok esetén az adatbázismotor target_percent használ a teljes napló célméretének kiszámításához. Ezért target_percent a zsugorítási művelet után a naplóban lévő szabad terület mennyisége. A teljes napló célmérete ezután az egyes naplófájlok célméretére lesz lefordítva.

DBCC SHRINKDATABASE megpróbálja az egyes fizikai naplófájlokat a célméretére zsugorítani. Tegyük fel, hogy a logikai napló egyetlen része sem marad a virtuális naplókban a naplófájl célméretén túl. Ezután a fájl sikeresen csonkul, és DBCC SHRINKDATABASE üzenet nélkül befejeződik. Ha azonban a logikai napló egy része a célméreten túl marad a virtuális naplókban, az adatbázismotor a lehető legtöbb helyet szabadít fel, majd tájékoztató üzenetet küld. Az üzenet azt ismerteti, hogy milyen műveletek szükségesek a logikai naplónak a fájl végén található virtuális naplókból való áthelyezéséhez. A műveletek futtatása után DBCC SHRINKDATABASE használható a fennmaradó terület felszabadítására.

A naplófájlok csak a virtuális naplófájlok határvonalára zsugorhatók. Ezért lehet, hogy nem lehetséges a naplófájlok méretét kisebbre csökkenteni, mint a virtuális naplófájlok mérete. Előfordulhat, hogy még akkor sem, ha nincs használatban. A virtuális naplófájl méretét az adatbázismotor dinamikusan választja ki a naplófájlok létrehozásakor vagy kiterjesztésekor.

A DBCC SHRINKDATABASE egyidejűségi problémáinak ismertetése

Az adatbázis zsugorítása és a fájlparancsok zsugorítása egyidejűségi problémákhoz vezethet, különösen az aktív karbantartás, például az indexek újraépítése vagy a forgalmas OLTP-környezetek esetén. Amikor az alkalmazás lekérdezéseket hajt végre adatbázistáblákon, ezek a lekérdezések egy sémastabilitási zárolást (Sch-S) szereznek be és tartanak fenn, amíg a lekérdezések befejezik a műveleteket. Amikor a rendszeres használat során megpróbál helyet visszanyerni, az adatbázis zsugorítása és a fájlműveletek zsugorítása jelenleg sémamódosítási zárolást (Sch-M) igényel az Indexlefoglalási térkép (IAM) lapok áthelyezésekor vagy törlésekor, ami blokkolja a felhasználói lekérdezések által igényelt Sch-S zárolásokat. Ennek eredményeképpen a hosszan futó lekérdezések blokkolják a zsugorítási műveletet, amíg a lekérdezések befejeződnek. Ez azt jelenti, hogy az Sch-S zárolást igénylő új lekérdezések is várólistára kerülnek a várakozási zsugorítási művelet mögött, és szintén blokkolva lesznek, ami tovább súlyosbítja ezt az egyidejűségi problémát. Ez jelentősen befolyásolhatja az alkalmazás lekérdezési teljesítményét, és nehézségeket okozhat az adatbázisfájlok zsugorításához szükséges karbantartás elvégzése során is. Az SQL Server 2022 (16.x) verziójában bevezetett alacsony prioritású várakozási (WLP) funkció a zsugorítás során úgy oldja meg ezt a problémát, hogy sémamódosítási zárolást használ WAIT_AT_LOW_PRIORITY módban. További információért lásd: WAIT_AT_LOW_PRIORITY a zsugorítási műveletekhez.

A Sch-S és Sch-M zárolásokról további információt a tranzakciózárolási és a sorverzió-verziószámozási útmutatóban talál.

Ajánlott eljárások

Az adatbázis zsugorításakor vegye figyelembe az alábbi információkat:

  • A zsugorítási művelet akkor a leghatékonyabb, ha egy olyan művelet után hajtják végre, amely nem használt területet hoz létre, például egy csonkolási művelet vagy tábla ledobás művelet után.
  • A legtöbb adatbázishoz szükség van némi szabad területre a napi rendszeres műveletekhez. Ha ismétlődően zsugorít egy adatbázisfájlt, és azt észleli, hogy az adatbázis mérete ismét nő, ez azt jelzi, hogy a normál műveletekhez szabad terület szükséges. Ezekben az esetekben az adatbázisfájl ismételt zsugorítása felesleges művelet. Az adatbázisfájl növekedéséhez szükséges automatikus növekedési események akadályozzák a teljesítményt.
  • A zsugorítási művelet nem őrzi meg az adatbázis indexeinek töredezettségi állapotát, és általában bizonyos mértékig növeli a töredezettséget. Ez az eredmény egy másik ok arra, hogy ne zsugorítja újra az adatbázist.
  • Ha nincs konkrét követelménye, ne állítsa be a AUTO_SHRINK adatbázis beállítását ON értékre.

Hibaelhárítás

Egy sorverzióalapú elkülönítési szinten futó tranzakció akadályozhatja a zsugorítási műveleteket,. Egy sorverzióalapú elkülönítési szinten futó nagy törlési művelet például folyamatban van egy DBCC SHRINKDATABASE művelet végrehajtásakor. Ebben az esetben a zsugorítási művelet megvárja, amíg a törlési művelet befejeződik, mielőtt zsugorítja a fájlokat. Ha a zsugorítási művelet várakozik, DBCC SHRINKFILE és DBCC SHRINKDATABASE műveletek tájékoztató üzenetet nyomtatnak (5202 SHRINKDATABASE és 5203 SHRINKFILEesetén). Ez az üzenet az ELSŐ órában öt percenként, majd a következő óránként megjelenik az SQL Server hibanaplójában. Ha például a hibanapló a következő hibaüzenetet tartalmazza:

DBCC SHRINKDATABASE for database ID 9 is waiting for the snapshot
transaction with timestamp 15 and other snapshot transactions linked to
timestamp 15 or with timestamps older than 109 to finish.

Ez a hiba azt jelenti, hogy a 109-nél régebbi időbélyegekkel rendelkező pillanatkép-tranzakciók blokkolják a zsugorítási műveletet. Ez a tranzakció az utolsó tranzakció, amelyet a zsugorítási művelet befejezett. Azt is jelzi, hogy a transaction_sequence_num dinamikus felügyeleti nézet first_snapshot_sequence_num vagy oszlopai 15 értéket tartalmaznak. A nézet transaction_sequence_num vagy first_snapshot_sequence_num oszlopa olyan számot tartalmazhat, amely kisebb, mint a zsugorítási művelettel végrehajtott utolsó tranzakció (109). Ha igen, a zsugorítási művelet megvárja a tranzakciók befejezését.

A probléma megoldásához hajtsa végre az alábbi feladatok egyikét:

  • Fejezd be a zsugorítási műveletet blokkoló tranzakciót.
  • Fejezze be a zsugorítási műveletet. Minden befejezett munka megőrződött.
  • Ne tegyen semmit, és hagyja, hogy a zsugorítási művelet megvárja a blokkoló tranzakció befejezését.

Engedélyek

A sysadmin rögzített kiszolgálói szerepkörben vagy a db_owner rögzített adatbázis-szerepkörben való tagság szükséges.

Példák

Egy. Adatbázis zsugorítása és a szabad terület százalékos arányának megadása

Az alábbi példa csökkenti a UserDB felhasználói adatbázisban lévő adatok és naplófájlok méretét, hogy 10 százalékos szabad helyet biztosíthasson az adatbázisban.

DBCC SHRINKDATABASE (UserDB, 10);
GO

B. Adatbázis csonkálása

Az alábbi példa a AdventureWorks2025 mintaadatbázisban lévő adatokat és naplófájlokat az utolsó hozzárendelt mértékre zsugorítja.

DBCC SHRINKDATABASE (AdventureWorks2022, TRUNCATEONLY);

C. Azure Synapse Analytics-adatbázis zsugorítása

DBCC SHRINKDATABASE (database_A);
DBCC SHRINKDATABASE (database_B, 10);

D. Adatbázis kicsinyítése WAIT_AT_LOW_PRIORITY

Az alábbi példa megpróbálja csökkenteni a AdventureWorks2025 adatbázis adatainak és naplófájljainak méretét, hogy 20% szabad helyet biztosíthasson az adatbázisban. Ha egy percen belül nem érhető el zárolás, a zsugorítási művelet megszakad.

DBCC SHRINKDATABASE ([AdventureWorks2022], 20) WITH WAIT_AT_LOW_PRIORITY (ABORT_AFTER_WAIT = SELF);

Kapcsolódó tartalom

  • Last updated on