Adatbázisok fájlterületének kezelése az Azure SQL Database-ben

A következőkre vonatkozik:Azure SQL Database

Azure SQL Database
felügyelt Azure SQL-példány

Ez a cikk az Azure SQL Database-beli adatbázisok különböző típusú tárhelyeit ismerteti. Előfordulhat, hogy neked kell kifejezetten kezelned a kijelölt fájlteret. Ez a cikk tartalmazza a lépéseket, amelyekkel ezt megvalósíthatjuk.

Áttekintés

Bizonyos munkaterhelési minták miatt az adatfájlokhoz különített hely nagyobbá válik, mint a használt tér. Ez az állapot akkor fordul elő, amikor a használt hely az adatnövekedés miatt nő, de később töröljük vagy tömöröd az adatokat. A kijelölt, de kihasználatlan területet nem nyerik vissza automatikusan, mert a feltöltés erőforrásigényes, és lassítaná a jövőbeni fájlnövekedést.

Az alábbi esetekben lehet, hogy zsugorítanod kell az adatfájlokat és visszaszerezned a kihasználatlan helyet:

Az adatbázisok adatmennyiségének növekedését lehetővé teszi egy rugalmas készletben, amikor a készlet egyes adatbázisai számára lefoglalt nagy tárterület miatt a készlet megközelíti a maximális méretét.
Lehetővé tenni egyetlen adatbázis vagy rugalmas pool maximális méretének csökkentését.
Az adatbázis vagy egy rugalmas pool átalakítása egy olyan szintre, amelynek alacsonyabb maximális méretkorlátja van.
A tárolási költségek csökkentése a hiperskálázás szolgáltatási szint használatakor.

Vigyázat

Ne tekintse a zsugorítási műveleteket 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.

A fájlterület használatának monitorozása

Azure Resource Manager (ARM) API-k, beleértve a PowerShell get-metrikákat, visszaadják az adatbázisok és rugalmas poolok használt és kijelölt helyét.

Az alábbi rendszernézetek visszaadják az adatbázisok és rugalmas medencék használt és elkülönített helyének méretét is:

Az adatbázis tárhelytípusainak ismertetése

Az adatbázis fájlterületének kezeléséhez fontos a következő tárterület-mennyiségek ismerete.

Adatbázis mennyisége	Definíció	Megjegyzések
használt adatterület	Az adatok tárolására használt tér.	A felhasznált terület általában nő (csökken) a beszúrásokon (törléseken). Bizonyos esetekben a felhasznált terület nem változik a beszúrások és törlések esetében a műveletben érintett adatok mennyiségétől és mintázatától, valamint a töredezettségtől függően. Ha például minden adatoldalról töröl egy sort, az nem feltétlenül csökkenti a felhasznált területet.
lefoglalt adatterület	Az adatfájlok által elfoglalt tárolóhely.	A kijelölt hely mennyisége automatikusan nő, de törlés után soha nem csökken automatikusan. Ez a viselkedés biztosítja, hogy a jövőbeli beillesztések gyorsabbak legyenek, mivel nem kell helyet áthelyezni.
Adatterület lefoglalva, de nem használt	A lefoglalt adattér és a felhasznált adattér közötti különbség.	Ez a mennyiség az adatbázis-adatfájlok zsugorításával visszanyerhető szabad terület maximális mennyiségét jelöli.
adat maximális mérete	A maximális hely, amely az adatok tárolására használható.	A lefoglalt adatterület nem haladhatja meg a maximális adatméretet.

Az alábbi ábra az adatbázis különböző tárolási típusai közötti kapcsolatot szemlélteti.

diagram, amely bemutatja az adatbázis-mennyiség táblában lévő különbség adatbázis-térfogalmainak méretét.

Egyetlen adatbázis lekérdezése fájltérinformációkhoz

A sys.database_files következő lekérdezésével adja vissza a lefoglalt adatbázis-fájlterületet és a lefoglalt fel nem használt területet.

-- Connect to a user database
SELECT file_id,
       type_desc,
       CAST (FILEPROPERTY(name, 'SpaceUsed') AS DECIMAL (19, 4)) * 8 / 1024. AS space_used_mb,
       CAST (size / 128.0 - CAST (FILEPROPERTY(name, 'SpaceUsed') AS INT) / 128.0 AS DECIMAL (19, 4)) AS space_unused_mb,
       CAST (size AS DECIMAL (19, 4)) * 8 / 1024. AS space_allocated_mb,
       CAST (max_size AS DECIMAL (19, 4)) * 8 / 1024. AS max_size_mb
FROM sys.database_files;

A rugalmas készlet tárterület-típusainak megismerése

Az alábbi tárolótér mennyiségek megértése fontos egy rugalmas pool fájlterének kezeléséhez.

Rugalmas készletmennyiség	Definíció	Megjegyzések
használt adatterület	A rugalmas készletben lévő összes adatbázis által használt adattér összegzése.
lefoglalt adatterület	A rugalmas készlet összes adatbázisában található adatfájlok által elfoglalt tárterület összege.
Adatterület lefoglalva, de nem használt	A rugalmas készletben lévő összes adatbázis által lefoglalt és felhasznált adattér közötti különbség.	Ez a mennyiség az adatbázis-adatfájlok zsugorításával visszanyerhető rugalmas készlet számára lefoglalt maximális területet jelöli.
adat maximális mérete	Az a maximális adatterület, amelyet egy rugalmas készlet az összes adatbázisához használ.	Az elasztikus medence számára kijelölt hely nem haladhatja meg az elasztikus medence maximális méretét. Ha ez a feltétel bekövetkezik, akkor az adatfájlok zsugorításával visszanyerhető a lefoglalt, de fel nem használt terület.

A "Az elasztikus pool elérte a tárolási határát" hibaüzenet azt jelzi, hogy az adatbázis objektumok elegendő helyet foglalnak el ahhoz, hogy megfeleljenek az elasztikus pool maximális tárolóméret-korlátának. Fontold meg a tárhelykorlát növelését, vagy szabadíts fel tárhelyet a A lefoglalt, nem használt terület visszanyerése című részben leírtak szerint.

Rugalmas készlet lekérdezése a tárterület adataihoz

Az alábbi lekérdezéseket használja az elasztikus pool tárolóhely mennyiségének meghatározására.

Felhasznált rugalmas készlet adatterület

Használd az alábbi példa lekérdezést, hogy visszaadja a használt rugalmas pool adattér mennyiségét. Módosítsd az elasztikus pool név paramétert, hogy illeszkedjen a poolod nevéhez.

-- Connect to master
SELECT TOP (1) avg_storage_percent / 100.0 * elastic_pool_storage_limit_mb AS elastic_pool_space_used_mb,
               avg_allocated_storage_percent / 100.0 * elastic_pool_storage_limit_mb AS elastic_pool_space_allocated_mb,
               elastic_pool_storage_limit_mb AS elastic_pool_maximum_size_mb
FROM sys.elastic_pool_resource_stats
WHERE elastic_pool_name = 'ep1'
ORDER BY end_time DESC;

Fel nem használt lefoglalt terület visszaigénylése

Fontos

A zsugorítási műveletek erőforrásokat fogyasztanak, és működés közben befolyásolhatják az adatbázis teljesítményét. Ha lehetséges, használd a shrink rendszert alacsony használat időszakában.

Adatfájlok zsugorítása

Mivel az adatfájlok zsugorítása befolyásolhatja az adatbázis teljesítményét, az Azure SQL Database nem zsugorítja automatikusan az adatfájlokat. Ha szükséges, az adatfájlokat a saját választott időpontban zsugoríthatod. Ne tedd a zsugorítást rendszeresen ütemezett műveletté. Ehelyett érdemes csak a használt helyigény jelentős csökkenése után használni.

Borravaló

Ne pazarold számítási erőforrásokat és időt az adatfájlok csökkentésére, ha a szokásos alkalmazási terhelés miatt a fájlok ismét ugyanarra a méretre nőnek.

Fájlok zsugorításához használj vagy DBCC SHRINKDATABASEDBCC SHRINKFILE T-SQL parancsokat:

DBCC SHRINKDATABASE egyetlen parancsgal összeszűkíti az adatbázisban található összes adatot és naplófájlt. A parancs egyszerre egy adatfájlt zsugorítja, ami hosszabb időt vehet igénybe a nagyobb adatbázisok esetében. Emellett zsugorítja a naplófájlokat, ami általában szükségtelen, mivel az Azure SQL Database szükség szerint automatikusan zsugorítja a naplófájlokat.
DBCC SHRINKFILE parancs speciálisabb forgatókönyveket támogat:
- Szükség szerint meg tudja célozni az egyes fájlokat, nem pedig az adatbázis összes fájljának zsugorítását.
- Minden DBCC SHRINKFILE parancs párhuzamosan futtatható más DBCC SHRINKFILE parancsokkal a zsugorítási művelet teljes idejének csökkentése érdekében, nagyobb erőforrás-felhasználás árán, valamint annak nagyobb esélyével, hogy ideiglenesen blokkolja a felhasználói lekérdezéseket és az egyidejű DBCC SHRINKFILE parancsokat.
- Ha a fájl vége nem tartalmaz adatokat, gyorsabban csökkentheted a kijelölt fájlméretet az argumentus megadásával TRUNCATEONLY . TRUNCATEONLY Nem igényel adatmozgást a fájlon belül, de a kijelölt méretet sem csökkenti annyira.
További információ ezekről a zsugorítási parancsokról: DBCC SHRINKDATABASE és DBCC SHRINKFILE.

Az alábbi példákat akkor futtathatod le, ha a célfelhasználó adatbázishoz vagy csatlakoztatva, nem az adatbázishoz master .

Az DBCC SHRINKDATABASE használata egy adott adatbázis összes adatának és naplófájljának zsugorításához:

DBCC SHRINKDATABASE (N'database_name');

Egy adatbázisban lehet egy vagy több adatfájl, amelyeket automatikusan hoznak létre az adatok növekedésével. Az adatbázis fájlelrendezésének meghatározásához, beleértve a használt és kiosztott fájlokat is, kérdezze le a sys.database_files katalógus nézetet a következő példaszkripttel:

-- Review file properties, including the file_id and name values to use in shrink commands
SELECT file_id,
       name,
       CAST (FILEPROPERTY(name, 'SpaceUsed') AS BIGINT) * 8 / 1024. AS space_used_mb,
       CAST (size AS BIGINT) * 8 / 1024. AS space_allocated_mb,
       CAST (max_size AS BIGINT) * 8 / 1024. AS max_file_size_mb
FROM sys.database_files
WHERE type_desc IN ('ROWS', 'LOG');

Egy fájl zsugorításához használd a DBCC SHRINKFILE parancsot, például:

-- Shrink database data file named 'data_0` by removing all unused at the end of the file, if any.
DBCC SHRINKFILE ('data_0', TRUNCATEONLY);

A tranzakciós naplófájl csökkentése

Az adatfájloktól eltérően az Azure SQL Database automatikusan zsugorítja a tranzakciónapló-fájlokat, hogy elkerülje a túlzott helyhasználatot, amely helykihasználtsági hibákhoz vezethet. A legtöbb esetben nem kell csökkentenie a tranzakció naplófájlját.

A Premium és Business Critical szolgáltatási szinteken, ha a tranzakciónapló nagyra nő, jelentősen hozzájárulhat a helyi tárolás fogyasztásához a maximális helyi tároló korlát felé. Ha a helyi tároló fogyasztása közel van a határhoz, választhatod a tranzakciónapló csökkentését a DBCC SHRINKFILE következő példában látható parancs segítségével. Ez a parancs befejeződése után azonnal felszabadítja a helyi tárolót, anélkül, hogy várnia kell az automatikus automatikus zsugorítási műveletre.

A következő példát akkor futtathatod le, ha a célfelhasználó adatbázisához vagy csatlakoztatva, nem az adatbázishoz master .

-- Shrink the database log file (always file_id 2), by removing all unused space at the end of the file, if any.
DBCC SHRINKFILE (2, TRUNCATEONLY);

Automatikus kicsinyítés

Az adatfájlok manuális zsugorításának alternatívaként az automatikus zsugorodás engedélyezhető egy adatbázishoz. Az automatikus zsugorodás azonban kevésbé lehet hatékony a fájlterület visszanyerésében, mint DBCC SHRINKDATABASE és DBCC SHRINKFILE.

Alapértelmezés szerint az automatikus zsugorodás le van tiltva, ami a legtöbb adatbázis esetében ajánlott. Ha szükségessé válik az automatikus csökkentés engedélyezése, javasolt letiltani, miután a tárhelykezelési célok megvalósultak, ahelyett, hogy tartósan engedélyezve maradna. További információért lásd a AUTO_SHRINK meggondolásait.

Például az automatikus zsugorítás hasznos lehet, ha egy rugalmas pool sok adatbázist tartalmaz, amelyek folyamatosan jelentős növekedést és használati területcsökkenést tapasztalnak, így a pool közelíti a maximális mérethatárt. Ez a forgatókönyv nem gyakori.

Az automatikus adatbázis-zsugorítás opció nem működik hiperskálázású adatbázisokban.

Az automatikus zsugorítás engedélyezéséhez hajtsa végre a következő parancsot, miközben csatlakozik az adatbázishoz (nem a master adatbázishoz).

-- Enable auto-shrink for the current database.
ALTER DATABASE CURRENT
    SET AUTO_SHRINK ON;

A parancsról további információt a DATABASE SET beállításaicímű témakörben talál.

Zsugorítás utáni indexkarbantartás

Miután egy zsugorítási művelet befejeződik, az indexek töredezettek lehetnek. A legtöbb munkaterhelésnél modern platformokon az index fragmentáció valószínűleg nem befolyásolja a teljesítményt. Olyan munkaterheléseknél, amelyek nagy index-vizsgálatot használnak, a fragmentáció csökkentheti az olvasási I/O áteresztőképességet. Ha teljesítményromlás a zsugorítás befejezése után történik, fontolja meg az indexfenntartást az indexek újraépítésére vagy átszervezésére. Az index újraépítése szabad helyet igényel az adatbázisban, így a kijelölt hely növekedését okozhatja, ellensúlyozva a zsugorítás hatását.

További információ az indexkarbantartásról: Indexkarbantartás optimalizálása a lekérdezési teljesítmény javítása és az erőforrás-felhasználás csökkentése.

Nagyméretű adatbázisok zsugorítása

Ha egy adatbázisban a kijelölt hely több száz gigabájtban vagy annál nagyobb, a zsugorítás hosszú időbe telhet. A zsugorítási műveletek órákat, napokat vagy heteket is igénybe vehetnek többterabaytos adatbázisokban. Ez a rész a folyamatoptimalizálásokat és a legjobb gyakorlatokat írja le, amelyek hatékonyabbá és kevésbé hatásossá teszik az alkalmazási munkaterhelésre.

Borravaló

A ShrinkDriver egy PowerShell szkript, amely automatizálja és egyszerűsíti a zsugorítási folyamatot nagy adatbázisok esetében, így azt 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.

A területhasználat alapkonfigurációinak rögzítése

A zsugorítás megkezdése előtt rögzítse az aktuálisan használt és lefoglalt területet az egyes adatbázisfájlokban a következő területhasználati lekérdezés végrehajtásával:

SELECT file_id,
       CAST (FILEPROPERTY(name, 'SpaceUsed') AS BIGINT) * 8 / 1024. AS space_used_mb,
       CAST (size AS BIGINT) * 8 / 1024. AS space_allocated_mb,
       CAST (max_size AS BIGINT) * 8 / 1024. AS max_size_mb
FROM sys.database_files
WHERE type_desc = 'ROWS';

A zsugorítás befejezése után ismét végrehajthatja ezt a lekérdezést, és összehasonlíthatja az eredményt a kezdeti alapkonfigurációval.

Rövidíts adatfájlokat gyors, de korlátozott nyereségért

Ha gyorsan szeretnéd csökkenteni a kijelölt helyet, fontold meg a DBCC SHRINKFILETRUNCATEONLY paraméterrel való végrehajtást. Ha a fájl végén van elkülönített, de kihasználatlan hely, a művelet gyorsan eltávolítja azt a helyet, adatmozgás nélkül.

Azonban ne használd a TRUNCATEONLY elemet, ha a célod a kiosztott hely csökkentésének maximalizálása. Ennek eléréséhez végig kell futtatnod a teljes zsugorítási folyamatot, ahogy azt ebben a szakaszban később leírjuk. Mivel ez a folyamat a végén csonkolja a fájlokat, egy külön TRUNCATEONLY zsugorításnak nincs előnye.

A következő példaparancs lerövidíti a 4-es fájlazonosítót:

DBCC SHRINKFILE (4, TRUNCATEONLY);

Miután minden adatfájlhoz elfuttattad ezt a parancsot, futtasd újra a helyhasználati lekérdezést, hogy lásd, ha van kikötött hely csökkenése. Az adatbázis számára kijelölt helyet is megtekintheted az Azure portálban.

Indexlap sűrűségének kiértékelése

Opcionális, de ajánlott lépésként határozzuk meg az adatbázis indexeinek átlagos oldalsűrűségét. Ugyanannyi adat esetén a zsugorítási műveletek gyorsabban végződnek, ha magas az oldalsűrűség, mert az egyes fájlokon belül kevesebb oldalt mozgatnak. Ha egyes indexek esetében alacsony az oldalsűrűség, érdemes lehet karbantartást végezni ezeken az indexeken, hogy növelje az oldalsűrűséget az adatfájlok zsugorítása előtt. A nagyobb oldalsűrűség lehetővé teszi, hogy a zsugorítási művelet nagyobb mértékben csökkentse a lefoglalt tárolóterületet.

Az adatbázis összes indexe oldalsűrűségének meghatározásához használja az alábbi lekérdezést. Az oldalsűrűség a avg_page_space_used_in_percent oszlopban van megadva.

SELECT OBJECT_SCHEMA_NAME(ips.object_id) AS schema_name,
       OBJECT_NAME(ips.object_id) AS object_name,
       i.name AS index_name,
       i.type_desc AS index_type,
       ips.avg_page_space_used_in_percent,
       ips.avg_fragmentation_in_percent,
       ips.page_count,
       ips.alloc_unit_type_desc,
       ips.ghost_record_count
FROM sys.dm_db_index_physical_stats(DB_ID(), DEFAULT, DEFAULT, DEFAULT, 'SAMPLED') AS ips
     INNER JOIN sys.indexes AS i
         ON ips.object_id = i.object_id
        AND ips.index_id = i.index_id
ORDER BY page_count DESC;

Ha vannak olyan indexek, amelyek oldalszáma magas (a page_count oszlopban jelzettek szerint), és oldalsűrűségük 60–70%-nál alacsonyabb, érdemes megfontolni ezen indexek újraépítését vagy átszervezését az adatfájlok zsugorítása előtt.

Nagyobb adatbázisok esetén az oldalsűrűséget meghatározó lekérdezés végrehajtása hosszú időt vehet igénybe. A nagy indexek újraépítése vagy átrendezése szintén jelentős időt és erőforrás-használatot igényel. A zsugorítás előtti indexkarbantartás azonban csökkentheti a zsugorodás időtartamát, és nagyobb helymegtakarítást érhet el.

Ha több, alacsony lapsűrűségű index van, előfordulhat, hogy több adatbázis-munkamenetben párhuzamosan újraépítheti őket a folyamat felgyorsítása érdekében. Azonban ügyelj rá, hogy ezzel nem közelíted meg az adatbázis-erőforrás-korlátokat. Hagyjon elegendő erőforrás-fejteret az esetleg futó alkalmazás-számítási feladatokhoz. Figyeld a erőforrás-fogyasztást (CPU, Data IO, Log IO) a Azure portálon vagy a sys.dm_db_resource_stats nézet segítségével. Csak akkor indítson további indexelési műveleteket, ha az erőforrás-kihasználtság ezen dimenziók mindegyikén jóval 100% alatt marad.

Példa index újraépítési parancsra

A következő példaparancs az ALTER INDEX utasítást használja az index újraépítésére és az oldalsűrűség növelésére:

ALTER INDEX [index_name] ON [schema_name].[table_name]
REBUILD WITH (
    FILLFACTOR = 100, MAXDOP = 8, ONLINE = ON (
        WAIT_AT_LOW_PRIORITY (MAX_DURATION = 5 MINUTES, ABORT_AFTER_WAIT = NONE)),
    RESUMABLE = ON
);

Ez a parancs online és újrakezdhető index-újraépítést kezdeményez. Ez a művelet lehetővé teszi, hogy az egyidejű számítási feladatok továbbra is használják a táblát, amíg az újraépítés folyamatban van, és lehetővé teszi az újraépítés folytatását, ha bármilyen okból megszakad. Az ilyen típusú újraépítés azonban lassabb, mint egy offline újraépítés, amely letiltja a táblához való hozzáférést. Ha az újraépítés során más számítási feladatoknak nem kell hozzáférnie a táblához, állítsa be a ONLINE és RESUMABLE beállításokat OFF és távolítsa el a WAIT_AT_LOW_PRIORITY záradékot.

Az indexkarbantartásról további információt az Indexkarbantartás optimalizálása a lekérdezési teljesítmény javítása és az erőforrás-felhasználás csökkentésecímű témakörben talál.

Indexek átalakítása zsugorítás előtt

Az indexek összeállítása zsugorítás előtt jelentősen gyorsabbá teheti a zsugorítási műveletet két helyzetben.

Ha az adatbázis megfelel az alábbi kritériumoknak:
- Számos adatfájl van (több mint 10).
- Az adatbázisban nagy számú tábla található (több száz vagy annál több), amelyek együtt nagy teret használnak (több száz gigabájt vagy annál több).
- Néhány táblázatból nagy mennyiségű adat törlődik.
Ilyen adatbázisoknál az indexek átszervezése azokon a táblázatokon (ahol adatokat töröltél) rövidíti a hosszú ideig tartó zsugorítási folyamatot.
Ha az adatbázis tartalmazza:
- Nagy objektum (LOB) adattípusok, mint például varchar(max),nvarchar(max), varbinary(max),xml vagy hasonló adattípusok, amelyeket az LOB_DATA allokációs egységben tárolnak.
- Nagy sorok egy ROW_OVERFLOW_DATA foglalási egységben tárolva.
- Oszlopcentrikus indexek.
Hogy gyorsabban fusson a shrink és több helyet szabadítson fel ebben a helyzetben, mindenképp foglald be a LOB_COMPACTION záradékot az indexek átszervezésekor. A zsugorodás előtti LOB tömörítés ajánlott minden olyan indexhez, amely LOB oszlopokat vagy nagy sorokat tartalmaz.

Az oszlopcentrikus indexek újraszervezése vagy újraépítése az összezsugorítás előtt hasonlóan növelheti az összezsugorítás sebességét és hatékonyságát.

A következő példa egy parancsot mutat egy index újraszervezésére és LOB tömörítés végrehajtására:

ALTER INDEX [index_name] ON [schema_name].[table_name]
REORGANIZE WITH(LOB_COMPACTION = ON);

Több adatfájl zsugorodása párhuzamosan

Egy zsugorítási művelet, amely adatátvitelt igényel, hosszú ideig tartó folyamat. Ha az adatbázis több adatfájllal rendelkezik, felgyorsíthatja a folyamatot több adatfájl párhuzamos zsugorításával. Nyisson meg több adatbázis-munkamenetet, és használja DBCC SHRINKFILE az egyes munkameneteken egy másik file_id értékkel. Az indexek korábbi újraépítéséhez hasonlóan minden új párhuzamos zsugorítási parancs indítása előtt győződjön meg arról, hogy elegendő erőforrás-kezelőtér (CPU, Adat IO, Napló IO) áll rendelkezésre.

A következő példaparancs zsugorítja a 4-es fájlazonosítót, megpróbálva csökkenteni a kijelölt méretet 52 000 MB-ra:

DBCC SHRINKFILE (4, 52000);

A fájl számára a rendelkezésre álló hely minimalizálása érdekében hajtsuk végre az utasítást a cél méret megadása nélkül:

DBCC SHRINKFILE (4);

Ha túl sok párhuzamos zsugorítási műveletet indítasz, magas erőforrás-felhasználást és zárolódást tapasztalhatsz a zsugorítási műveletek között. A legtöbb esetben az optimális párhuzamos zsugorítási műveletek száma négy és nyolc között van.

Zsugorítás lépésekben

Ha egy zsugorítási művelet váratlanul megáll (például tervezett vagy nem tervezett karbantartás miatt), egy munkaterhelés elkezdheti használni a zsugorítás által felszabadított helyet, mielőtt a zsugorítás lerövidíti a fájlt, így elveszítve az eddig elért előrehaladás egy részét. Mivel a shrink gyakran hosszú ideig tart, nagyobb az esély a megszakításra.

Ennek elkerülése érdekében minden fájlt kisebb, fokozatos lépésekben zsugoríts. A DBCC SHRINKFILE parancsban állítsuk be azt a célpontot, amely kisebb, mint a fájl aktuális kijelölt helye, de nagyobb, mint az a használt tér, amit az alap térhasználati lekérdezés visszaad.

Például, ha a 4. fájlazonosító számára kijelölt hely 200 000 MB, és ezt 100 000 MB-ra szeretnénk csökkenteni, először beállíthatod a célt 180 000 MB-ra:

DBCC SHRINKFILE (4, 180000);

Miután ez a parancs csökkenti a kijelölt méretet 180 000 MB-ra, újra futtathatod a shrink rendszert, először 160 000 MB-ra, majd 140 000 MB-ra állítva a célt, és tovább csökkentheted, amíg a fájl el nem éri a kívánt méretet.

A fájlok fokozatosan zsugorítása tovább tarthat, de csökkenti a teljes fájl ismétlődő zsugorításának kockázatát egy váratlan megszakítás miatt.

Kiindulópontként használj egy 10-20 gigabájtos növekedést. A léptéket szükség szerint az adott helyzetnek megfelelően módosíthatod. Nagyobb lépések gyorsabban fejezhetik be a fájlzsugorítást, a kisebb lépések csökkentik a haladás elvesztésének kockázatát, ha a zsugorítás megszakad.

Zsugorítási műveletek monitorozása

Az összes egyidejűleg futó shrink munkamenet előrehaladásának figyeléséhez használja a következő lekérdezést:

SELECT command,
       percent_complete,
       status,
       wait_resource,
       session_id,
       wait_type,
       blocking_session_id,
       cpu_time,
       reads,
       writes,
       CAST (((DATEDIFF(s, start_time, GETDATE())) / 3600) AS VARCHAR) + ' hour(s), '
               + CAST ((DATEDIFF(s, start_time, GETDATE()) % 3600) / 60 AS VARCHAR) + 'min, '
               + CAST ((DATEDIFF(s, start_time, GETDATE()) % 60) AS VARCHAR) + ' sec'
           AS running_time
FROM sys.dm_exec_requests AS r
     LEFT OUTER JOIN sys.databases AS d
         ON r.database_id = d.database_id
WHERE r.command IN ('DbccSpaceReclaim', 'DbccFilesCompact', 'DbccLOBCompact', 'DBCC');

Jegyzet

A zsugorítás előrehaladása nem lineáris lehet, és az oszlopban lévő érték percent_complete hosszú időre változatlan maradhat, még akkor is, ha a zsugorítás még folyamatban van. Ha ugyanazon session_id esetén a lekérdezés két futtatása között nő a(z) cpu_time, reads vagy writes értéke, az azt jelenti, hogy a shrink továbbra is halad.

Amikor a zsugorítás sikeresen befejezi az összes adatfájlt, futtasd újra a helyhasználati lekérdezést (vagy ellenőrizd az Azure portált), hogy lásd a kijelölt tárolóméret csökkenését. Ha még mindig nagy a különbség a használt és a kijelölt hely között, akkor építsd újra vagy rendezd át az indexeket. Egy index újjáépítése ideiglenesen növelheti a kijelölt helyet. Az indexek újraépítése után azonban az adatfájlok ismételt zsugorítása gyakran a lefoglalt terület nagyobb mértékű csökkenését eredményezi.

Átmeneti hibák a zsugorodás során

Időnként egy zsugorítási parancs hibákkal bukhat el, például időtúllépések vagy holtpontok. Ezek a hibák gyakran átmenetiek, és nem fordulnak elő újra, ha ugyanazt a parancsot ismételjük. Ha a zsugorítás hibával leáll, az addig elért előrehaladást megőrzi. Futtassa újra ugyanazt a zsugorítási parancsot a fájl további zsugorításához.

A ShrinkDriver PowerShell szkript automatikusan próbálja újra a zsugorítást, ha átmeneti hiba jelentkezik. Ezt a szkriptet használd a nagy adatbázisok zsugorítására.

Az alábbi példa T-SQL szkript bemutatja, hogyan lehet egyetlen fájl számára újrapróbálkozási ciklusban futtatni a shrink-et. A ciklus automatikusan újra megpróbálja végrehajtani a műveletet, legfeljebb egy beállítható számú alkalommal, ha időtúllépési hiba vagy holtponti hiba lép fel. Ez a visszapróbálási megközelítés sok más hibára is alkalmazható, amelyek zsugorítás során előfordulhatnak.

DECLARE @RetryCount AS INT = 3; -- adjust to configure desired number of retries
DECLARE @Delay AS CHAR (12);

-- Retry loop
WHILE @RetryCount >= 0
BEGIN
    BEGIN TRY
        DBCC SHRINKFILE (1); -- adjust file_id and other shrink parameters

        -- Exit retry loop on successful execution
        SELECT @RetryCount = -1;

    END TRY
    BEGIN CATCH
        -- Retry for the declared number of times without raising
        -- an error if deadlocked or timed out waiting for a lock
        IF ERROR_NUMBER() IN (1205, 49516) AND @RetryCount > 0
        BEGIN
            SELECT @RetryCount -= 1;

            PRINT CONCAT('Retry at ', SYSUTCDATETIME());

            -- Wait for a random period of time between 1 and 10 seconds before retrying
            SELECT @Delay = '00:00:0' + CAST (CAST (1 + RAND() * 8.999 AS DECIMAL (5, 3)) AS VARCHAR (5));

            WAITFOR DELAY @Delay;

        END
        ELSE -- Raise error and exit loop
        BEGIN
            SELECT @RetryCount = -1;

            THROW;

        END
    END CATCH
END

Az időkorlátok és a holtpontok mellett a zsugorítás bizonyos ismert problémák miatt hibákba is ütközhet.

Tekintse át a hibákat és az enyhítő lépéseket a következő szakaszokban.

49503-as hibaszám

%.*ls: Page %d:%d could not be moved because it is an off-row persistent version store page. Page holdup reason: %ls. Page holdup timestamp: %I64d.

Ez a hiba akkor fordul elő, amikor hosszú ideig futó aktív tranzakciók sorverziókat generálnak a tartós verzióraktárban (PVS). A Shrink nem tudja áthelyezni azokat az oldalakat, amelyek sorverziókat tartalmaznak.

Ennek a hibának a mérséklése érdekében várd meg a hosszú ideig futó tranzakciók befejezését. Alternatívaként azonosítsd és fejezd ki a hosszú ideig futó tranzakciókat, de ez a művelet hatással lehet az alkalmazásra, ha nem kezeli a tranzakcióhibákat gondosan.

A zsugorítást esetleg befolyásoló PVS-tisztítási késések hibaelhárításával kapcsolatos további információkért lásd: A gyorsított adatbázis-helyreállítás monitorozása és hibaelhárítása.

5223-as hibaszám

%.*ls: Empty page %d:%d could not be deallocated.

Ez a hiba folyamatban lévő indexkarbantartási műveletek során fordulhat elő, például ALTER INDEX. A műveletek befejezése után próbálkozzon újra a zsugorítási paranccsal.

Ha ez a hiba továbbra is fennáll, lehet, hogy újra kell építened a hozzá tartozó indexet. Az újraépítendő index megkereséséhez hajtsa végre a következő lekérdezést ugyanabban az adatbázisban, ahol a zsugorítási parancsot futtatta:

SELECT OBJECT_SCHEMA_NAME(pg.object_id) AS schema_name,
       OBJECT_NAME(pg.object_id) AS object_name,
       i.name AS index_name,
       p.partition_number
FROM sys.dm_db_page_info(DB_ID(), <file_id>, <page_id>, default) AS pg
INNER JOIN sys.indexes AS i
ON pg.object_id = i.object_id
   AND
   pg.index_id = i.index_id
INNER JOIN sys.partitions AS p
ON pg.partition_id = p.partition_id;

A lekérdezés végrehajtása előtt cseréld le a <file_id> és <page_id> helyjelzőt a hibaüzenet tényleges értékeire. Például, ha az üzenet: Empty page 1:62669 could not be deallocated, akkor <file_id> és 1<page_id> .62669

Építse újra a lekérdezés által azonosított indexet, és próbálkozzon újra a zsugorítási paranccsal.

5201-es hibaszám

DBCC SHRINKDATABASE: File ID %d of database ID %d was skipped because the file does not have enough free space to reclaim.

Ez a hiba azt jelenti, hogy az adatfájlt nem lehet tovább zsugorítani. Továbbléphet a következő adatfájlra.

Visszajelzés

Hasznosnak találta ezt az oldalt?

Last updated on 2026-07-24