DBCC ZSUGORÍTÁSFÁJL (Transact-SQL)

A következőkre vonatkozik:SQL Server Azure SQL Database Felügyelt Azure SQL-példány SQL-adatbázis a Microsoft Fabricben

Csökkenti az aktuális adatbázis megadott adat- vagy naplófájlméretét. Segítségével adatokat helyezhet át az egyik fájlból az ugyanabban a fájlcsoportban lévő többi fájlba, amely kiüríti a fájlt, és lehetővé teszi az adatbázis eltávolítását. A fájlokat a létrehozáskor a méreténél kisebbre zsugoríthatja, és visszaállíthatja a minimális fájlméretet az új értékre. Csak szükség esetén használja a DBCC SHRINKFILE fájlt.

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

DBCC SHRINKFILE   
(  
    { file_name | file_id }   
    { [ , EMPTYFILE ]   
    | [ [ , target_size ] [ , { 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 }

Érvek

file_name

A zsugoríteni kívánt fájl logikai neve.

file_id

A zsugorítani kívánt fájl azonosítószáma. Fájlazonosító lekéréséhez használja a FILE_IDEX rendszerfüggvényt, vagy kérje le a sys.database_files katalógusnézetet az aktuális adatbázisban.

target_size

A fájl új megabájtméretét képviselő egész szám. Ha nincs megadva vagy 0, DBCC SHRINKFILE csökkenti a fájllétrehozás méretét.

Az üres fájlok alapértelmezett méretét a DBCC SHRINKFILE <target_size>használatával csökkentheti. Ha például 5 MB-os fájlt hoz létre, majd 3 MB-ra zsugorítja a fájlt, amíg a fájl üres, az alapértelmezett fájlméret 3 MB lesz. Ez csak azokra az üres fájlokra vonatkozik, amelyek soha nem tartalmaztak adatokat.

Ez a beállítás a FILESTREAM fájlcsoporttárolók esetében nem támogatott.

Ha meg van adva, DBCC SHRINKFILE próbálja a fájlt target_size zsugorítani. A fájl felszabadítandó területén használt oldalakat a rendszer áthelyezi a fájl tárolt területeinek szabad területére. Egy 10 MB-os adatfájl esetén például egy DBCC SHRINKFILE művelet egy 8target_size az összes használt lapot a fájl utolsó 2 MB-jából áthelyezi a fájl első 8 MB-jának fel nem használt lapjaira. DBCC SHRINKFILE nem zsugorítja a fájlokat a szükséges tárolt adatméreten túl. Ha például 7 MB-ot használ egy 10 MB-os adatfájlból, egy 6-os DBCC SHRINKFILE rendelkező utasítás csak 7 MB-ra zsugorítja a fájlt, nem pedig 6 MB-ra.

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

ÜRES FÁJL

Az összes adat áttelepítése a megadott fájlból az ugyanabban a fájlcsoportban lévő többi fájlba. Más szóval, EMPTYFILE adatokat migrál egy megadott fájlból ugyanabban a fájlcsoportban lévő más fájlokba. EMPTYFILE biztosítja, hogy nem kerül új adat hozzáadásra a fájlhoz, annak ellenére, hogy a fájl nem írásvédett. Az ALTER DATABASE utasítással eltávolíthat egy fájlt. Ha az ALTER DATABASE utasítással módosítja a fájlméretet, a csak olvasható jelző alaphelyzetbe áll, és adatokat adhat hozzá.

A FILESTREAM fájlcsoporttárolók esetében a ALTER DATABASE nem távolíthat el egy fájlt, amíg a FILESTREAM szemétgyűjtő nem fut, és nem törölte az összes szükségtelen fájlcsoport-tárolófájlt, amelyet EMPTYFILE átmásolt egy másik tárolóba. További információért lásd: sp_filestream_force_garbage_collection. A FILESTREAM-tároló eltávolításával kapcsolatos információkért tekintse meg az ALTER DATABASE fájl- és fájlcsoportbeállítások megfelelő szakaszát (Transact-SQL)

EMPTYFILE nem támogatja az Azure SQL Database, Azure SQL Database Hyperscale vagy SQL adatbázis a Microsoft Fabric-ben.

NOTRUNCATE

Áthelyezi a lefoglalt lapokat az adatfájl végéről a fájl előlapján lévő nem áthelyezett lapokra target_percent megadásával vagy anélkül. 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 ha NOTRUNCATE van megadva, úgy tűnik, hogy a fájl nem zsugorodik.

NOTRUNCATE csak adatfájlokra alkalmazható. A naplófájlok nem érintettek.

Ez a beállítás a FILESTREAM fájlcsoporttárolók esetében nem támogatott.

TRUNCATEONLY

A fájl végén lévő összes szabad helyet felszabadítja az operációs rendszer számára, de nem végez lapáthelyezést a fájlon belül. Az adatfájl csak az utolsó lefoglalt kiterjedésig van csökkentve.

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

A TRUNCATEONLY beállítás nem helyezi át az adatokat a naplóállományban, de eltávolítja az inaktív virtuális naplófájlokat a naplóállomány végéről. Ez a beállítás a FILESTREAM fájlcsoporttárolók esetében nem támogatott.

NO_INFOMSGS

Letiltja az összes tájékoztató üzenetet.

WAIT_AT_LOW_PRIORITY zsugorítási műveletekkel

Vonatkozik a következőkre: SQL Server 2022 (16.x) és későbbi verziók, Azure SQL Database, Azure SQL Managed Instance, SQL database in Microsoft Fabric

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

Ez a funkció hasonló a WAIT_AT_LOW_PRIORITY lehetőséghez az online indexműveletekkel, néhány különbséggel.

Nem adhatja meg az ABORT_AFTER_WAIT NONE opciót.

VÁRAKOZÁS_ALACSONY_PRIORITÁSSAL

Alkalmazható: SQL Server (SQL Server 2022 (16.x) és újabb verziók), Azure SQL Database, valamint SQL adatbázis Microsoft Fabric-ben.

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 a sémamódosítási zárolást (Sch-M). Ha egy új zsugorítási művelet WAIT_AT_LOW_PRIORITY módban egy 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 ér el, és csendesen kilép.

Ha egy új zsugorítási művelet WAIT_AT_LOW_PRIORITY módban megkísérel zárolást szerezni egy hosszú ideig futó lekérdezés miatt, de nem sikerül, akkor a zsugorítási művelet alapértelmezés szerint 1 perc után időtúllép, és hibaüzenet nélkül megszakad. Ez akkor fordul elő, ha a zsugorítási művelet nem tudja beszerezni a Sch-M zárolást az egyidejű lekérdezés 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 ]

Alkalmazható: SQL Server (SQL Server 2022 (16.x) és újabb verziók), Azure SQL Database, SQL adatbázis Microsoft Fabric-ben.

ÖNMAGA

Lépjen ki a jelenleg végrehajtott zsugorítási fájlműveletből művelet nélkül.
blokkolók

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. A BLOCKERS beállításhoz a bejelentkezés során ALTER ANY CONNECTION jogosultság szükséges.

Eredményhalmaz

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

Oszlop neve	Leírás
`DbId`	A fájl adatbázis-azonosító száma, amelyet az adatbázis-motor megpróbált zsugorítani.
`FileId`	Annak a fájlnak a fájlazonosító száma, amelyet az adatbázismotor megpróbált zsugorítani.
`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 a szám egy fájl minimális 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ó.

Megjegyzések

DBCC SHRINKFILE az aktuális adatbázis fájljaira vonatkozik. Az aktuális adatbázis módosításáról további információt a USE (Transact-SQL) című témakörben talál.

Bármikor leállíthatja DBCC SHRINKFILE műveleteket, és a befejezett munka megmarad. Ha a EMPTYFILE paramétert használja, és megszakítja a műveletet, a fájl nincs megjelölve, hogy megakadályozza a további adatok hozzáadását.

Ha egy DBCC SHRINKFILE művelet meghiúsul, hiba lép fel.

Más felhasználók a fájlok zsugorítása során dolgozhatnak az adatbázisban; az adatbázisnak nem kell egyfelhasználós módban lennie. A rendszeradatbázisok zsugorításához nem kell egyfelhasználós módban futtatnia az SQL Server-példányt.

Ha WAIT_AT_LOW_PRIORITY van megadva, a zsugorítási művelet Sch-M zárolási kérése alacsony prioritással fog várni a parancs 1 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.

Ismert problémák

Vonatkozik a következőkre: SQL Server, Azure SQL Database, SQL database in Microsoft Fabric, Azure SQL Managed Instance, Azure Synapse Analytics Dedicated SQL pool

Jelenleg a LOB oszloptípusokat (varbinary(max), varchar(max) és nvarchar(max)) a tömörített oszlopcentrikus szegmensekben nem érinti DBCC SHRINKDATABASE az és DBCC SHRINKFILEa .

A DBCC SHRINKFILE 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 zsugorítási művelet mögött, és szintén blokkolva lesznek, ami tovább súlyosbítja ezt a párhuzamossá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) újdonsága, az alacsony prioritású zsugorítási várakozási funkció, úgy oldja meg ezt a problémát, hogy sémamódosítási zárolást alkalmaz WAIT_AT_LOW_PRIORITY módban. További információért lásd a zsugorítási műveleteket WAIT_AT_LOW_PRIORITY.

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.

Naplófájl zsugorítása

Naplófájlok esetén az adatbázismotor target_size használ a teljes napló célméretének kiszámításához. Ezért target_size a napló szabad területe a zsugorítási művelet után. A rendszer ezután lefordítja a teljes napló célméretét az egyes naplófájlok célméretére. DBCC SHRINKFILE megpróbálja az egyes fizikai naplófájlokat a célméretére zsugorítani. Ha azonban a logikai napló egy része a célméreten túl található 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 végrehajtása után DBCC SHRINKFILE használható a fennmaradó terület felszabadítására.

Mivel a naplófájlok csak a virtuális naplófájl határára zsugoríthatók, előfordulhat, hogy nem lehet a naplófájlt kisebbre zsugorítani, mint a virtuális naplófájl mérete, még akkor is, ha nem használják. Az adatbázismotor dinamikusan választja ki a virtuális fájl naplófájljának méretét a naplófájlok létrehozásakor vagy kiterjesztésekor.

Ajánlott eljárások

A fájlok zsugorításakor vegye figyelembe a következő információkat:

A zsugorítási művelet azután a leghatékonyabb, ha egy művelet, mint például egy tábla csonkítása vagy törlése, nagy mennyiségű nem használt területet hozott létre.
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 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 a töredezettség egy másik ok arra, hogy ne zsugorodjon újra az adatbázis.
Több fájlt egymás után zsugorítson ugyanabban az adatbázisban, ahelyett hogy egyszerre tenné. A rendszertáblákon való versengés blokkolást és késést okozhat.

Hibaelhárítás

Ez a szakasz a DBCC SHRINKFILE parancs futtatásakor előforduló problémák diagnosztizálására és javítására használható.

A fájl nem zsugorodik

Ha a fájlméret nem változik egy hibamentes zsugorítási művelet után, próbálja meg ellenőrizni, hogy a fájl rendelkezik-e megfelelő szabad területtel:

Futtassa a következő lekérdezést.

SELECT name
    , size / 128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS INT) / 128.0 AS AvailableSpaceInMB
FROM sys.database_files;

Futtassa a DBCC SQLPERF parancsot a tranzakciónaplóban használt terület visszaadásához.

A zsugorítási művelet nem csökkentheti tovább a fájlméretet, ha nincs elegendő szabad hely.

Általában ez a naplófájl, amely úgy tűnik, hogy nem zsugorodik, általában egy olyan naplófájl eredménye, amelyet nem csonkolt meg egy rendszeres tranzakciónapló biztonsági mentése. A napló csonkításához készítsen biztonsági másolatot a tranzakciónaplóról, majd futtassa újra a DBCC SHRINKFILE műveletet. Ha nincs szükség időponthoz kötött helyreállításra, fontolja meg a SIMPLE adatbázis-helyreállítási modellt.

A zsugorítási művelet le van tiltva

A sorverzióalapú elkülönítési szinten futó tranzakciók blokkolhatják a zsugorítási műveleteket. Ha például egy sorverzióalapú elkülönítési szinten futó nagy törlési művelet folyamatban van egy DBCC SHRINKDATABASE művelet végrehajtásakor, a zsugorítási művelet megvárja, amíg a törlés befejeződik a folytatás előtt. Ha ez a blokkolás történik, DBCC SHRINKFILE és DBCC SHRINKDATABASE műveletek tájékoztató üzenetet (5202 for SHRINKDATABASE és 5203 for SHRINKFILE) nyomtatnak az SQL Server hibanaplójába. Ezt az üzenetet az első órában öt percenként, majd óránként naplózza a rendszer. Például:

DBCC SHRINKFILE for file ID 1 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 az üzenet azt jelenti, hogy a 109-nél régebbi időbélyegeket tartalmazó pillanatkép-tranzakciók (az utolsó tranzakció, amelyet a zsugorítási művelet befejezett) blokkolják a zsugorítási műveletet. Azt is jelzi, hogy a transaction_sequence_num dinamikus felügyeleti nézet first_snapshot_sequence_numvagy oszlopai 15 értéket tartalmaznak. Ha a transaction_sequence_num vagy first_snapshot_sequence_num nézet oszlopa kisebb számot tartalmaz, mint egy zsugorítási művelet utolsó befejezett tranzakciója (109), 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.
Zárja le a zsugorítási műveletet. Ha a zsugorítási művelet véget ér, minden befejezett munka megmarad.
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. Adatfájl zsugorítása megadott célméretre

Az alábbi példa egy DataFile1 nevű adatfájl méretét 7 MB-ra csökkenti a UserDB felhasználói adatbázisban.

USE UserDB;
GO
DBCC SHRINKFILE (DataFile1, 7);
GO

B. Naplófájl zsugorítása egy megadott célméretre

Az alábbi példa a AdventureWorks2025 adatbázis naplófájljának 1 MB-ra zsugorítja. Annak érdekében, hogy a DBCC SHRINKFILE parancs zsugoríthassa a fájlt, először csonkolja a fájlt az adatbázis-helyreállítási modell EGYSZERŰ értékre állításával.

USE AdventureWorks2022;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE AdventureWorks2022
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (AdventureWorks2022_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE AdventureWorks2022
SET RECOVERY FULL;
GO

C. Adatfájl csonkálása

Az alábbi példa csonkolja az elsődleges adatfájlt a AdventureWorks2025 adatbázisban. A rendszer lekérdezi a sys.database_files katalógusnézetet az adatfájl file_id lekéréséhez.

USE AdventureWorks2022;
GO
SELECT file_id, name
FROM sys.database_files;
GO
DBCC SHRINKFILE (1, TRUNCATEONLY);

D. Fájl ürítése

Az alábbi példa egy fájl kiürítését mutatja be, hogy eltávolítható legyen az adatbázisból. Ebben a példában először létrejön egy adatfájl, amely adatokat tartalmaz.

USE AdventureWorks2022;
GO
-- Create a data file and assume it contains data.
ALTER DATABASE AdventureWorks2022
ADD FILE (
    NAME = Test1data,
    FILENAME = 'C:\t1data.ndf',
    SIZE = 5MB
    );
GO
-- Empty the data file.
DBCC SHRINKFILE (Test1data, EMPTYFILE);
GO
-- Remove the data file from the database.
ALTER DATABASE AdventureWorks2022
REMOVE FILE Test1data;
GO

E. Adatbázisfájl zsugorítása WAIT_AT_LOW_PRIORITY

Az alábbi példa egy adatfájl méretét próbálja 1 MB-ra csökkenteni az aktuális felhasználói adatbázisban. A sys.database_files katalógusnézetet lekérdezik, hogy megszerezzék az adatfájl file_id-jét, ebben a példában az file_id az 5. Ha egy percen belül nem érhető el zárolás, a zsugorítási művelet megszakad.

USE AdventureWorks2022;
GO

SELECT file_id, name
FROM sys.database_files;
GO

DBCC SHRINKFILE (5, 1) WITH WAIT_AT_LOW_PRIORITY (ABORT_AFTER_WAIT = SELF);

Visszajelzés

Hasznosnak találta ezt az oldalt?

Last updated on 2025-11-18