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.

Ne tekintsd a zsugorítás üzemeltetését 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_name | database_id | 0 }

Az adatbázis nevét vagy azonosítóját zsugorítani kell. 0 érték az aktuális adatbázist jelöli.

target_percent

A zsugorítási művelet befejezése után az adatbázis fájlban hagyható szabad hely százaléka.

Ha megadod target_percent , TRUNCATEONLYa zsugorítási művelet nem feltétlenül enged szabad helyet a fájl végén.

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 vonatkozik. 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 megadod target_percent , TRUNCATEONLYa zsugorítási művelet nem feltétlenül enged szabad helyet a fájl végén.

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

Alkalmazható: SQL Server 2022 (16.x) és újabb verziók, Azure SQL Database, Azure SQL Managed Instance, SQL database in Microsoft Fabric

Az alacsony prioritású várakozás csökkenti a zár elleni konfliktust a zsugorítás során. 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 lehet megadni ABORT_AFTER_WAIT az opciót NONE.
• Nem állíthatod be az MAX_DURATION opciót. A zsugorítási műveletnél az alacsony prioritású zár időkorlátja mindig egy perc.

VÁRAKOZÁS_ALACSONY_PRIORITÁSON

Amikor egy zsugorítási parancsot üzemmódban WAIT_AT_LOW_PRIORITY hajtanak végre, az Index Allocation Map (IAM) oldalakon a séma stabilitást (Sch-S) igénylő lekérdezések nem blokkolódnak a zsugorítás művelet által. Azonban a zsugorítási művelet blokkolható egy Sch-S IAM oldalon lévő zárolással. A shrink csak akkor hajt végre, ha képes elérni egy séma módosítási zárolást (Sch-M) egy szükséges IAM oldalon.

Ha egy zsugorítási művelet módban WAIT_AT_LOW_PRIORITY nem tudja elérni ezt a zárolást egy hosszú ideig tartó lekérdezés Sch-S miatt, akkor a zsugorítási művelet időlejár 49516 hibával, 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.

{ ABORT_AFTER_WAIT = [ ÖNMAGUNK | BLOKKOLÓK ] }

• SELF

  SELF az alapértelmezett beállítás. Lépj ki a jelenleg végrehajtott zsugorítási adatbázis műveletből további lépés nélkül.

• BLOCKERS

  Tiltsa le az összes olyan felhasználói tranzakciót, amely letiltja a zsugorítási fájlműveletet, hogy a művelet folytatható legyen. Az BLOCKERS opció megköveteli, hogy a bejelentkezés jogosult legyen az ALTER ANY CONNECTION or KILL DATABASE CONNECTION engedély.

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

A Database Engine nem jelenít meg sorokat azoknak a fájloknak, amelyek nincsenek összezsugorítva.

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.

Megadhatod az NOTRUNCATE opciót vagy TRUNCATEONLY az opciót, amikor futtatod DBCC SHRINKDATABASE. Ha egyik opciót sem adod meg, az eredmény ugyanaz, mint ha egy DBCC SHRINKDATABASE műveletet futtatsz - NOTRUNCATE val, majd futtatsz DBCC SHRINKDATABASE egy műveletet -vel TRUNCATEONLY.

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.

Az Azure Synapse SQL poolokban kerüld a shrink parancs futtatását, mert ez egy I/O intenzív művelet, amely lekapcsolhatja a dedikált SQL poolodat (korábban SQL DW). Ez a parancs befolyásolja az adatraktári pillanatképek költségét is.

Ismert problémák

Apply to: SQL Server, Azure SQL Database, Azure SQL Managed Instance, Azure Synapse Analytics dedicated SQL pool

• Az SQL Server 2022 (16.x) és korábbi verziókban a LOB oszloptípusok (varbinary(max),varchar(max) és nvarchar(max)) által használt oldalak tömörített columnstore szegmensekben nem mozgathatók DBCC SHRINKDATABASE és DBCC SHRINKFILEáltal. További információ: Az oszlopcentrikus indexek újdonságai.

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 két naplófájl és egy adatfájl van egy adatbázisban, amelynek neve mydb. 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 a fájl célmérete a zsugorítás után. Ha target_percent-vel megadod DBCC SHRINKDATABASE a Database Engine, a célméretet úgy számolja, hogy a fájlban a zsugorítás után target_percent szabad hely.

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. Ha a logikai napló egyetlen része sem marad a virtuális naplókban a naplófájl célmérete túl, DBCC SHRINKDATABASE sikeresen levágja a fájlt, és üzenet nélkül fejeződik be. 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 leírja azokat a műveleteket, amelyek a logikus naplót a fájl végén lévő virtuális naplókból való eltávolításra irányítják. Az akciók lefuttatása után használd DBCC SHRINKDATABASE fel a maradék hely felszabadítására.

Egy naplófájlt csak virtuális naplófájl határra lehet zsugorítani. Ezért nem lehetséges egy naplófájlt egy virtuális naplófájl méreténél kisebb méretűre zsugorítani. A Database Engine dinamikusan választja meg a virtuális naplófájl méretét a naplófájlok létrehozásakor vagy bővítésekor.

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

A zsugorítási adatbázis és a fájl zsugorítási parancsok párhuzamos problémákat okozhatnak, különösen aktív karbantartás esetén, például az indexek újraépítése vagy forgalmas OLTP környezetekben.

Például egy felhasználói lekérdezés egy séma stabilitási (Sch-S) zárat kaphat egy Index Allocation Map (IAM) oldalon, és megtarthatja a befejezésig. Rendszeres használat során a hely visszafoglalása esetén a zsugorítási adatbázis és a zsugorítási fájlműveletek sémamódosítási (Sch-M) zárolást igényelnek IAM oldalak mozgatásakor vagy törlésekor, ami blokkolja a Sch-S felhasználói lekérdezésekhez szükséges zárolásokat. Ennek eredményeként a hosszú távú lekérdezések blokkolhatják a zsugorítási műveletet. Ez a viselkedés azt is jelenti, hogy bármely új lekérdezés, amely zárolást Sch-S igényel egy IAM oldalon, sorba állhat a zsugorítási művelet mögé, ami tovább súlyosbítja ezt a párhuzamos problémát.

Az SQL Server 2022-ben (16.x) bemutatták, és a zsugorítási műveletekhez szükséges alacsony prioritású várakozás funkciót a módban az IAM oldalakon WAIT_AT_LOW_PRIORITY a séma módosítás zárolással oldja meg. További információért lásd: WAIT_AT_LOW_PRIORITY a zsugorítási műveletekhez.

További információért a Sch-S zárolásokról Sch-M lásd: Tranzakciós zárolás és sorverziós útmutató.

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ázis megvan némi szabad helyet a rendszeres napi működéshez. Ha ismételten zsugorítasz egy adatbázis-fájlt, és azt veszed észre, hogy az adatbázis mérete ismét nő, ez a növekedés azt jelzi, hogy a rendszeres műveletek szabad helyet igényelnek. Ilyen esetekben az adatbázis fájl ismételt zsugorítása kontraproduktív. A fájlnövekedés, amely szükséges az új hely kijelöléséhez a zsugorítás után, hátráltathatja a teljesítményt.

• A zsugorítási művelet nem őrzi meg az adatbázisban lévő indexek fragmentációs állapotát, és növelheti az index fragmentációját, ami csökkentheti az olvasási I/O áteresztőképességet nagy skenneléssel végzett lekérdezéseknél.

• Ha nincs konkrét követelménye, ne válassza az AUTO_SHRINK adatbázis opciót ON.

• Ha egy nagy adatbázis adatfájljait kell csökkenteni, fontold meg a ShrinkDriver PowerShell szkriptjét. A skript automatizálja és egyszerűsíti a zsugorítási folyamatot, így egyetlen, megfigyelhető és folytatható műveletté alakítja. A szkript párhuzamosan zsugorít több fájlt, megszakítás esetén újra próbálkozik, és részletes állapotjelentéseket ad futtatás közben.

Hibaelhárítás

A sorverzióalapú elkülönítési szinten futó tranzakciók blokkolhatják a zsugorítási műveleteket. Például akkor futsz DBCC SHRINKDATABASE , amikor egy nagy törlési művelet zajlik egy sorverziós alapú izolációs szint alatt. Ebben az esetben a zsugorítási művelet megvárja, amíg a törlés befejeződik, mielőtt a fájlokat összezsugorítja. 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 utána minden órában megjelenik az SQL Server hibanaplójába. 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 idősebb időbélyegű snapshot tranzakciók blokkolják a zsugorítási műveletet. Ez a tranzakció az utolsó tranzakció, amelyet a zsugorítási művelet befejezett. Ez azt is jelzi, hogy transaction_sequence_numa sys.dm_tran_active_snapshot_database_transactions dinamikus menedzsment nézetben az or first_snapshot_sequence_num oszlopok értéke 15. 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 az alábbiak egyikét teheted:

• 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

A cikkben szereplő kódminták a AdventureWorks2025 vagy AdventureWorksDW2025 mintaadatbázist használják, amelyet a Microsoft SQL Server-minták és közösségi projektek kezdőlapjáról tölthet le.

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 (AdventureWorks2025, TRUNCATEONLY);

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

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

D. Zsugoríts egy adatbázist 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 ([AdventureWorks2025], 20) WITH WAIT_AT_LOW_PRIORITY (ABORT_AFTER_WAIT = SELF);

Kapcsolódó tartalom

• Adatbázis zsugorítása
• Fájl zsugorítása
• DBCC ZSUGORÍTÁSFÁJL (Transact-SQL)
• Az SQL Server automatikus és automatikus szabályozási beállításainak szempontjai
• Adatbázisfájlok és fájlcsoportok
• sys.databases (Transact-SQL)
• sys.database_files (Transact-SQL)
• ALTER DATABASE (Transact-SQL)
• Adatbázisok fájlterületének kezelése az Azure SQL Database-ben