Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
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 akkor használd DBCC SHRINKFILE , ha szükséges, mert a zsugorítás hosszú ideig tartó és erőforrásigényes művelet.
Jegyzet
Ne kezeld a zsugorítási műveleteket rendszeres karbantartásnak. 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 fájl logikus neve, hogy zsugorítsam.
file_id
A fájl azonosító (ID) száma, amit össze kell zsugorítani. 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 beállítod a target_size-t0 vagy nem jelöled meg, DBCC SHRINKFILE a fájl a létrehozási méretére csökken.
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 megadod target_size , TRUNCATEONLYDBCC SHRINKFILE lehet, hogy nem szabadít szabad helyet a fájl végén.
Ü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. A ALTER DATABASE nyilatkozattal eltávolíthatsz egy fájlt. Ha a ALTER DATABASE mondatot használod a fájlméret megváltoztatására, az csak olvasható zászló visszaáll, és adat hozzáadható.
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 konténer eltávolításáról információért lásd a ALTER DATABASE Fájl- és Fájlcsoport Opciók megfelelő szakaszát
EMPTYFILEnem támogatott az Azure SQL Database, Azure SQL Database Hyperscale vagy SQL database 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.
Ez az TRUNCATEONLY opció nem mozgatja át az információt a naplóban, de eltávolítja az inaktív virtuális naplófájlokat (VLF-eket) a naplófájl 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
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óért lásd: A DBCC SHRINKFILE párhuzamos problémák megérté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 lehet megadni az
ABORT_AFTER_WAITopciótNONE. - Nem állíthatod be az
MAX_DURATIONopció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ÁSSAL
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 ] }
Alkalmazható: SQL Server (SQL Server 2022 (16.x) és újabb verziók), Azure SQL Database, SQL adatbázis Microsoft Fabric-ben.
SELFSELFaz alapértelmezett beállítás. Lépj ki a jelenleg végrehajtott zsugorítási fájl műveletből további lépés nélkül.BLOCKERSTiltsa 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
BLOCKERSopció megköveteli, hogy a bejelentkezés jogosult legyen azALTER ANY CONNECTIONorKILL DATABASE CONNECTIONengedély.
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. További információért a jelenlegi adatbázis megváltoztatásáról lásd: HASZNÁ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.
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.
Ismert problémák
Apply to: SQL Server, Azure SQL Database, SQL database in Microsoft Fabric, Azure SQL Managed Instance, Azure Synapse Analytics dedicated SQL pool
- Az SQL Server 2025 (17.x) előtti SQL Server verziókban a nagy objektum (LOB) oszloptípusok (varbinary(max), varchar(max) és nvarchar(max)) által tömörített oszloptároló szegmensekben használt oldalakat nem lehet és
DBCC SHRINKFILEáltal mozgatniDBCC SHRINKDATABASE. További információ: Az oszlopcentrikus indexek újdonságai.
A DBCC SHRINKFILE egyidejűségi problémáinak ismertetése
A shrink database és shrink file parancsok párhuzamos problémákat okozhatnak, különösen aktív karbantartás esetén, például indexek újraépítése vagy forgalmas online tranzakciófeldolgozási (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 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ött, 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 a zsugorítási műveleteket WAIT_AT_LOW_PRIORITY.
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ó.
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. 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 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
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áld meg a következő lépéseket ellenőrizni, hogy a fájlban van-e elegendő szabad hely:
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;Ha szeretnéd csökkenteni a tranzakciónapló fájlt, használd a sys.dm_db_log_space_usage dinamikus menedzsment nézetet (DMV), hogy lásd, mennyi helyet használsz a tranzakciónaplóban.
A zsugorítás művelet nem tudja tovább csökkenteni a fájlméretet, ha nincs elég szabad hely.
Egy gyakori oka annak, hogy egy tranzakciónapló fájl nem zsugorodik, a rendszeres tranzakciónaplók hiánya. 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 nem szükséges az időbeli helyreállítás, érdemes a Recovery modelleket (SQL Server) fontolóra venni, hogy elkerüld a naplófájlok növekedését.
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 a következő lépések egyikét végezze:
- 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
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. 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. Ahhoz, hogy a DBCC SHRINKFILE parancs a fájl zsugorítására először lerövidítjük a fájlt úgy, hogy az adatbázis-helyreállítási modellt a -re állítjuk.SIMPLE
USE AdventureWorks2025;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE AdventureWorks2025
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (AdventureWorks2025_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE AdventureWorks2025
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 AdventureWorks2025;
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 AdventureWorks2025;
GO
-- Create a data file and assume it contains data.
ALTER DATABASE AdventureWorks2025
ADD FILE (NAME = Test1data, FILENAME = 'C:\t1data.ndf', SIZE = 5 MB);
GO
-- Empty the data file.
DBCC SHRINKFILE (Test1data, EMPTYFILE);
GO
-- Remove the data file from the database.
ALTER DATABASE AdventureWorks2025
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 AdventureWorks2025;
GO
SELECT file_id,
name
FROM sys.database_files;
GO
DBCC SHRINKFILE (5, 1) WITH WAIT_AT_LOW_PRIORITY (ABORT_AFTER_WAIT = SELF);
Kapcsolódó tartalom
- Adatbázis zsugorítása
- Fájl zsugorítása
- DBCC SHRINKDATABASE (Transact-SQL)
- Az SQL Server automatikus és automatikus szabályozási beállításainak szempontjai
- Adatbázisfájlok és fájlcsoportok
- sys.database_files (Transact-SQL)
- sys.databases (Transact-SQL)
- FILE_ID (Transact-SQL)
- ALTER DATABASE (Transact-SQL)
- Adatbázisok fájlterületének kezelése az Azure SQL Database-ben