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. Bár nem gyakori, ez a cikk olyan lépéseket tartalmaz, amelyek akkor végezhetők el, ha a lefoglalt fájlterületet explicit módon kell kezelni.

Áttekintés

Az Azure SQL Database-ben vannak olyan számítási feladatok, amelyekben az adatbázisok alapjául szolgáló adatfájlok kiosztása nagyobb lehet, mint a használt adatlapok száma. Ez a feltétel akkor fordulhat elő, ha a felhasznált terület növekszik, és az adatok később törlődnek. Ennek az az oka, hogy a lefoglalt fájlterület nem lesz automatikusan visszanyerve az adatok törlésekor.

A következő forgatókönyvekben szükség lehet a fájlterület használatának monitorozására és az adatfájlok zsugorítására:

• Lehetővé teszi az adatnövekedést egy rugalmas készletben, amikor az adatbázisokhoz lefoglalt fájlterület eléri a készlet maximális méretét.
• A single adatbázis vagy rugalmas készlet maximális méretének csökkentésének engedélyezése.
• Lehetővé teszi egyetlen adatbázis vagy rugalmas készlet módosítását egy másik szolgáltatási szintre vagy teljesítményszintre alacsonyabb maximális mérettel.

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.

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

Az alábbi API-kban megjelenített tárterület-metrikák többsége csak a használt adatlapok méretét méri:

• Azure Resource Manager-alapú API-k metrikákhoz, beleértve a PowerShell get-metrics

Az alábbi API-k azonban az adatbázisokhoz és rugalmas készletekhez lefoglalt terület méretét is mérik:

• T-SQL: sys.resource_stats
• T-SQL: sys.elastic_pool_resource_stats

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 adatbázisadatok tárolására használt terület.	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ájá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 adatbázisadatok tárolására rendelkezésre álló formázott fájlterület mennyisége.	A lefoglalt terület mennyisége automatikusan nő, de a törlés után soha nem csökken. Ez a viselkedés biztosítja, hogy a jövőbeli beszúrások gyorsabbak legyenek, mivel a helyet nem kell újraformálni.
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	Az adatbázisadatok tárolására használható maximális terület.	A lefoglalt adatterület nem nőhet meg az adat maximális méretén.

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

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. A lekérdezés eredményének egységei MB-ban vannak.

-- 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

A rugalmas készlet fájlterületének kezeléséhez fontos a következő tárterület-mennyiségek ismerete.

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észletben lévő összes adatbázis által lefoglalt adattér összegzése.
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.	A rugalmas készlet számára lefoglalt terület nem haladhatja meg a rugalmas készlet maximális méretét. Ha ez a feltétel jelentkezik, akkor az adatbázis-adatfájlok zsugorításával visszaigényelhető a nem használt terület.

Jegyzet

A "A rugalmas készlet elérte a tárterületkorlátot" hibaüzenet azt jelzi, hogy az adatbázis-objektumok elegendő helyet használnak fel a rugalmas készlet tárterületkorlátjának teljesítéséhez. Fontolja meg a tárhelykorlát növelését, vagy rövid távú megoldásként szabadítson fel adatterületet az Használaton kívüli lefoglalt terület visszanyerése mintái segítségével. Tisztában kell lennie az adatbázisfájlok zsugorításának lehetséges negatív teljesítménybeli hatásával is. Lásd az index karbantartását zsugorítás után.

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

Az alábbi lekérdezések segítségével meghatározhatja a rugalmas készlet tárterület-mennyiségét.

Felhasznált rugalmas készlet adatterület

Módosítsa a következő lekérdezést a felhasznált rugalmas készlet adatterületének visszaadásához. A lekérdezés eredményének egységei MB-ban vannak.

-- Connect to master
-- Elastic pool data space used in MB  
SELECT TOP 1 avg_storage_percent / 100.0 * elastic_pool_storage_limit_mb AS ElasticPoolDataSpaceUsedInMB
FROM sys.elastic_pool_resource_stats
WHERE elastic_pool_name = 'ep1'
ORDER BY end_time DESC;

Kiosztott rugalmas készlet adatterülete és kihasználatlan lefoglalt terület

Módosítsa az alábbi példákat, hogy visszaadjon egy táblát, amely felsorolja a teljes lefoglalt területet és a nem használt területet egy rugalmas készletben lévő adatbázisokhoz. A tábla a legnagyobb kihasználatlan területtel rendelkező adatbázisokból rendeli az adatbázisokat a legkisebb kihasználatlan területhez. A lekérdezés eredményének egységei MB-ban vannak.

Összegezze a lekérdezési eredményeket a pool minden adatbázisára, hogy meghatározza a rugalmas adatbáziskészlethez lefoglalt teljes területet. A rugalmas készlet lefoglalt területe nem haladhatja meg a rugalmas készlet maximális méretét.

Fontos

2024. február 29-én a PowerShell Azure Resource Manager (AzureRM) modult elavulttá nyilvánították. Minden jövőbeli fejlesztésnek az Az.Sql modult kell használnia. Javasoljuk a felhasználóknak, hogy migráljanak az AzureRM-ből az Az PowerShell-modulba a folyamatos támogatás és frissítések biztosítása érdekében. Az AzureRM-modult a továbbiakban nem tartjuk karban vagy támogatjuk. Az Az PowerShell-modulban és az AzureRM-modulokban található parancsok argumentumai lényegében azonosak. További információ a kompatibilitásukról: Az új Az PowerShell-modul bemutatása.

A PowerShell-szkripthez SQL Server PowerShell-modul szükséges. További információ: SQL Server PowerShell-modul.

A következő PowerShell-szkript a következő lépéseket hajtja végre:

1. Változók deklarálása. Cserélje le ezeket az értékeket a sajátjaival.
2. A rugalmas készletben lévő adatbázisok listájának lekérése.
3. A rugalmas készletben lévő összes adatbázishoz lekérheti a teljes lefoglalt területet MB-ban, valamint a lefoglalt, de nem használt területet MB-ban.
4. Az adatbázisok csökkenő sorrendben jelennek meg a fel nem használt lefoglalt terület alapján.

$resourceGroupName = "<resourceGroupName>"
$serverName = "<serverName>"
$poolName = "<poolName>"
$userName = "<userName>"
$password = "<password>"

# get list of databases in elastic pool
$databasesInPool = Get-AzSqlElasticPoolDatabase -ResourceGroupName $resourceGroupName `
    -ServerName $serverName -ElasticPoolName $poolName
$databaseStorageMetrics = @()

# for each database in the elastic pool, get the total allocated space in MB and the allocated but unused space in MB
foreach ($database in $databasesInPool) {
    $sqlCommand = "SELECT DB_NAME() as DatabaseName, `
    SUM(size/128.0) AS DatabaseDataSpaceAllocatedInMB, `
    SUM(size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0) AS DatabaseDataSpaceAllocatedUnusedInMB `
    FROM sys.database_files `
    GROUP BY type_desc `
    HAVING type_desc = 'ROWS'"
    $serverFqdn = "tcp:" + $serverName + ".database.windows.net,1433"
    $databaseStorageMetrics = $databaseStorageMetrics + 
        (Invoke-Sqlcmd -ServerInstance $serverFqdn -Database $database.DatabaseName `
            -Username $userName -Password $password -Query $sqlCommand)
}

# display databases in descending order of unused allocated space
Write-Output "`n" "ElasticPoolName: $poolName"
Write-Output $databaseStorageMetrics | Sort -Property DatabaseDataSpaceAllocatedUnusedInMB -Descending | Format-Table

Az alábbi képernyőkép egy példa a szkript kimenetére:

Rugalmas készletadatok maximális mérete

Módosítsa a következő T-SQL-lekérdezést az utolsó rögzített rugalmas készletadatok maximális méretének visszaadásához. A lekérdezés eredményének egységei MB-ban vannak.

-- Connect to master
-- Elastic pools max size in MB
SELECT TOP 1 elastic_pool_storage_limit_mb AS ElasticPoolMaxSizeInMB
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 parancsok futás közben befolyásolják az adatbázis teljesítményét, és ha lehetséges, alacsony használatú időszakokban kell futtatni.

Adatfájlok zsugorítása

Az adatbázis teljesítményére gyakorolt lehetséges hatás miatt az Azure SQL Database nem zsugorítja automatikusan az adatfájlokat. Azonban az ügyfelek önkiszolgáló módon, az általuk választott időpontban zsugoríthatják az adatfájlokat. A zsugorítás nem lehet rendszeresen ütemezett művelet, hanem egyszeri esemény, válaszul az adatfájlok kihasználtságának jelentős csökkentésére.

Borravaló

Ne pazaroljon időt az adatfájlok zsugorítására, ha a normál alkalmazásterhelés miatt a fájlok ismét ugyanarra a lefoglalt méretre nőnek. A fájlnövekedési események negatívan befolyásolhatják az alkalmazás teljesítményét.

Az Azure SQL Database-ben a fájlok zsugorításához DBCC SHRINKDATABASE vagy DBCC SHRINKFILE parancsokat használhat:

• DBCC SHRINKDATABASE egyetlen paranccsal zsugorítja az adatbázis összes adatát és naplófájljait. 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, hogy egyszerre több fájlt zsugorítsen, és csökkentse a zsugorodás teljes idejét, a magasabb erőforrás-használat és a felhasználói lekérdezések blokkolásának nagyobb esélye mellett, ha a zsugorítás során hajtják végre őket.
    • Több adatfájl egyidejű zsugorításával gyorsabban végezheti el a zsugorítási műveletet. Ha egyidejű adatfájl-zsugorítást használ, megfigyelheti, hogy az egyik zsugorítási kérést egy másik blokkolja.
  • Ha a fájl farka nem tartalmaz adatokat, a TRUNCATEONLY argumentum megadásával gyorsabban csökkentheti a lefoglalt fájl méretét. TRUNCATEONLY nem igényel adatáthelyezést a fájlon belül.
• További információ ezekről a zsugorítási parancsokról: DBCC SHRINKDATABASE és DBCC SHRINKFILE.

Az alábbi példákat a célfelhasználói adatbázishoz való csatlakozáskor kell végrehajtani, nem a master adatbázishoz.

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

-- Shrink database data space allocated.
DBCC SHRINKDATABASE (N'database_name');

Az Azure SQL Database-ben előfordulhat, hogy egy adatbázis egy vagy több adatfájllal rendelkezik, amelyek az adatok növekedésével automatikusan létrejönnek. Az adatbázis fájlelrendezésének meghatározásához, beleértve az egyes fájlok használt és lefoglalt méretét, az alábbi példaszkripttel kérdezheti le a sys.database_files katalógusnézetet:

-- Review file properties, including file_id and name values to reference 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');

A zsugorítást csak az DBCC SHRINKFILE paranccsal hajthatja végre, 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);
GO

Vegye figyelembe az adatbázisfájlok zsugorításának lehetséges negatív teljesítményét. További információért lásd: Indexkarbantartás zsugorítás után.

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.

Prémium és üzleti szempontból kritikus szolgáltatási szinteken, ha a tranzakciónapló nagy méretűvé válik, jelentősen hozzájárulhat a helyi tárterület-használathoz a maximális helyi tárolási korlát felé. Ha a helyi tárterület-felhasználás megközelíti a korlátot, az ügyfelek dönthetnek úgy, hogy a DBCC SHRINKFILE paranccsal csökkentik a tranzakciónaplót az alábbi példában látható módon. 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.

Az alábbi példát a célfelhasználói adatbázishoz való csatlakozáskor kell végrehajtani, nem pedig a master adatbázishoz.

-- 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 zsugorítás engedélyezése, javasoljuk, hogy a helykezelési célok elérése után tiltsa le, ahelyett, hogy véglegesen engedélyezve lenne. További információért lásd a AUTO_SHRINK meggondolásait.

Az automatikus zsugorodás például akkor lehet hasznos, ha egy rugalmas készlet sok olyan adatbázist tartalmaz, amelyek jelentős növekedést és a felhasznált terület csökkenését tapasztalják, ami miatt a készlet eléri a maximális méretkorlátot. Ez a forgatókönyv nem gyakori.

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

Ha az adatfájlokon végzett zsugorítási művelet befejeződött, az indexek töredezetté válhatnak. A töredezettség csökkenti az olvasásI/O-átviteli sebességet bizonyos számítási feladatok, például a nagy vizsgálatokat használó lekérdezések esetében. Ha a teljesítménycsökkenés a zsugorítási művelet befejezése után következik be, fontolja meg az indexkarbantartást az indexek újraépítéséhez. Ne feledje, hogy az index-újraépítések szabad helyet igényelnek az adatbázisban, ezért a lefoglalt terület növekedhet, ami ellensúlyozza a zsugorodá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 az adatbázis lefoglalt területe több száz gigabájt vagy nagyobb, a zsugorodás jelentős időt igényelhet, gyakran órákban vagy napokban mérve több terabájtos adatbázisok esetében. Vannak olyan folyamatoptimalizálások és ajánlott eljárások, amelyek segítségével hatékonyabbá és kevésbé befolyásolhatóvá teheti ezt a folyamatot az alkalmazás számítási feladatai számára.

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.

Adatfájlok csonkálása

Javasoljuk, hogy először hajtsa végre a zsugorítást minden adatfájlhoz a TRUNCATEONLY paraméterrel. Így, ha a fájl végén van lefoglalt, de nem használt terület, a rendszer gyorsan és adatátvitel nélkül eltávolítja azt. Az alábbi mintaparancs a 4-es azonosítójú adatfájlt csonkolja.

DBCC SHRINKFILE (4, TRUNCATEONLY);

Ha ezt a parancsot minden adatfájlhoz végrehajtja, újrafuttathatja a területhasználati lekérdezést, hogy láthassa a lefoglalt terület csökkenését, ha van ilyen. Az azure portalon megtekintheti az adatbázis lefoglalt területét is.

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

Ha az adatfájlok csonkolása nem eredményezte a lefoglalt terület megfelelő csökkenését, akkor az adatfájlokat csökkentenie kell. Nem kötelező, de ajánlott lépésként azonban először meg kell határoznia az adatbázis indexeinek átlagos oldalsűrűségét. Azonos mennyiségű adat esetén a zsugorítási műveletek gyorsabban befejeződnek, ha az oldalsűrűség magas, mivel kevesebb oldalt kell áthelyeznie. 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 lapsűrűség lehetővé teszi a lefoglalt tárterület mélyebb csökkentését.

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, amelyeknek az oldalsűrűsége 60–70%alatt van, érdemes újraépíteni vagy átrendezni ezeket az indexeket 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. Ezzel azonban győződjön meg arról, hogy nem közelíti meg az adatbázis erőforráskorlátait. Hagyjon elegendő erőforrás-fejteret az esetleg futó alkalmazás-számítási feladatokhoz. Az azure portalon vagy a sys.dm_db_resource_stats nézet használatával monitorozza az erőforrás-felhasználást (CPU, Adat IO, Napló IO). Csak akkor kezdjen további párhuzamos újraépítéseket, ha az egyes dimenziók erőforrás-kihasználtsága lényegesen alacsonyabb, mint 100%. Ha a CPU, adat-IO vagy napló-IO kihasználtsága 100%, növelheti az adatbázist, hogy több processzormaggal rendelkezzen, és növelje az IO átviteli sebességét.

Mintaindex újraépítési parancsa

Az alábbi mintaparancs egy index újraépítéséhez és az oldalsűrűség növeléséhez a ALTER INDEX utasítás használatával:

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.

Zsugorítás előtt tömörítse a LOB-adatokat

A zsugorítás hosszabb időt is igénybe vehet, ha az adatbázis a következőket tartalmazza:

• LOB adattípusok, például varchar(max), nvarchar(max), varbinary(max), xml vagy hasonló adattípusok, amelyeket a foglalási LOB_DATA egység tárol.
• Nagy sorok egy ROW_OVERFLOW_DATA foglalási egységben tárolva.
• Oszlopcentrikus indexek.

A zsugorítás gyorsítása és több hely optimalizálása érdekében először végezze el az indexek újraszervezését, beleértve a LOB tömörítést is. A zsugorodás előtti LOB tömörítés ajánlott minden olyan indexhez, amely LOB oszlopokat vagy nagy sorokat tartalmaz. Például:

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

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.

Több adatfájl zsugorítása

Ahogy korábban már említettük, az adatáthelyezéssel való zsugorodás egy hosszú ideig futó 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.

Az alábbi mintaparancs 4-es file_id méretre zsugorítja az adatfájlt, és 52 000 MB-ra próbálja csökkenteni a lefoglalt méretet a fájlban lévő oldalak áthelyezésével:

DBCC SHRINKFILE (4, 52000);

Ha a lehető legkisebbre szeretné csökkenteni a fájl lefoglalt területét, a célméret megadása nélkül hajtsa végre az utasítást:

DBCC SHRINKFILE (4);

Ha egy számítási feladat párhuzamosan fut a zsugorítással, előfordulhat, hogy a zsugorítással felszabadított tárterületet kezdi használni, mielőtt a zsugorítás befejeződne, és csonkolja a fájlt. Ebben az esetben a zsugorítás nem tudja csökkenteni a megadott cél számára lefoglalt területet.

A probléma elkerülése érdekében kisebb lépésekben zsugorítja az egyes fájlokat. DBCC SHRINKFILE A parancsban állítsa be a fájl aktuális lefoglalt területénél valamivel kisebb célhelyet az alapterület-használati lekérdezés eredményeinek megfelelően. Ha például a 4-es file_id fájl lefoglalt területe 200 000 MB, és 100 000 MB-ra szeretné csökkenteni, a célértéket először 170 000 MB-ra állíthatja be:

DBCC SHRINKFILE (4, 170000);

Ez a parancs csonkolja a fájlt, és 170 000 MB-ra csökkentette a lefoglalt méretet. Ezután megismételheti ezt a parancsot, először 140 000 MB-ra, majd 110 000 MB-ra állítja a célhelyet, és így tovább, amíg a fájl a kívánt méretre nem zsugorodik. Ha a parancs végrehajtásra kerül, de a fájl nem csonkolódik, használjon kisebb lépéseket, például 15 000 MB-ot a 30 000 MB helyett.

Az egyidejűleg futó zsugorodási munkamenetek zsugorítási folyamatá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,
       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 JOIN sys.databases AS d
ON r.database_id = d.database_id
WHERE r.command IN ('DbccSpaceReclaim','DbccFilesCompact','DbccLOBCompact','DBCC');

Jegyzet

A zsugorítási folyamat nemlineáris lehet, és előfordulhat, hogy a percent_complete oszlop értéke hosszú ideig változatlan marad, annak ellenére, hogy a zsugorítás még folyamatban van.

Miután a zsugorítás befejeződött az összes adatfájl esetében, futtassa újra a területhasználati lekérdezést (vagy ellenőrizze az Azure Portalon), hogy megállapíthassa a lefoglalt tárterület méretének csökkenését. Ha továbbra is nagy a különbség a felhasznált terület és a lefoglalt terület között, építsd újra az indexeket. Az indexek újraépítése átmenetileg tovább növelheti a lefoglalt területet. Az adatfájlok újraméretezése azonban az indexek újraépítése után a lefoglalt terület mélyebb csökkenését eredményezi.

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

Időnként a zsugorítási parancsok különböző hibákkal, például időtúllépésekkel és holtpontokkal meghiúsulhatnak. Ezek a hibák általában átmenetiek, és nem fordulnak elő újra, ha ugyanaz a parancs ismétlődik. Ha a zsugorítás hiba miatt meghiúsul, az eddig elért előrehaladás megmarad. Futtassa újra ugyanazt a zsugorítási parancsot a fájl további zsugorításához.

Az alábbi példaszkript bemutatja, hogyan lehet kicsinyítést futtatni egy újrapróbálkozási ciklusban. A ciklus automatikusan újra megpróbálja a műveletet egy konfigurálható számú alkalommal, amikor időtúllépési vagy holtponti hiba történik. Ez az újrapróbálkozási módszer számos más, a zsugorodás során előforduló hibára alkalmazható.

DECLARE @RetryCount int = 3; -- adjust to configure desired number of retries
DECLARE @Delay 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őtúllépések és holtpontok mellett a zsugorodás bizonyos ismert problémák miatt hibákba ütközhet.

A visszaadott hibák és a hibaelhárítási lépések a következők:

• Hibaszám: 49503, hibaüzenet: %.*ls: Oldal %d:%d nem helyezhető át, mert az egy soron kívüli állandó verziótár oldal. Az oldal visszatartásának oka: %ls. Oldal visszatartási időbélyeg: %I64d.

Ez a hiba akkor fordul elő, ha hosszú ideig futó aktív tranzakciók sorverziókat generáltak az állandó verziótárban (PVS). A Zsugorítás nem tudja áthelyezni a sorverziókat tartalmazó oldalakat.

A enyhítés érdekében meg kell várnia, amíg a hosszú ideig futó tranzakciók befejeződnek. Azt is megteheti, hogy azonosítja és leállítja a hosszú ideig futó tranzakciókat, de ez hatással lehet az alkalmazásra, ha nem kezeli a tranzakciós hibákat. A hosszú ideig futó tranzakciók keresésének egyik módja, ha az alábbi lekérdezést futtatja abban az adatbázisban, ahol a zsugorítási parancsot futtatta:

-- Transactions sorted by duration
SELECT st.session_id,
       dt.database_transaction_begin_time,
       DATEDIFF(second, dt.database_transaction_begin_time, CURRENT_TIMESTAMP) AS transaction_duration_seconds,
       dt.database_transaction_log_bytes_used,
       dt.database_transaction_log_bytes_reserved,
       st.is_user_transaction,
       st.open_transaction_count,
       ib.event_type,
       ib.parameters,
       ib.event_info
FROM sys.dm_tran_database_transactions AS dt
INNER JOIN sys.dm_tran_session_transactions AS st
ON dt.transaction_id = st.transaction_id
OUTER APPLY sys.dm_exec_input_buffer(st.session_id, default) AS ib
WHERE dt.database_id = DB_ID()
ORDER BY transaction_duration_seconds DESC;

A tranzakciót a KILL paranccsal és a lekérdezés eredményéből származó társított session_id érték megadásával fejezheti be:

KILL 4242; -- replace 4242 with the session_id value from query results

Vigyázat

A tranzakció megszüntetése negatív hatással lehet a számítási feladatokra.

A hosszú ideig futó tranzakciók befejeződése után egy belső háttérfeladat törli a már nem szükséges sorverziókat. A PVS-méret monitorozásával felmérheti a törlés folyamatát az alábbi lekérdezéssel. Futtassa a lekérdezést abban az adatbázisban, ahol a zsugorítási parancsot futtatta:

SELECT pvss.persistent_version_store_size_kb / 1024. / 1024 AS persistent_version_store_size_gb,
       pvss.online_index_version_store_size_kb / 1024. / 1024 AS online_index_version_store_size_gb,
       pvss.current_aborted_transaction_count,
       pvss.aborted_version_cleaner_start_time,
       pvss.aborted_version_cleaner_end_time,
       dt.database_transaction_begin_time AS oldest_transaction_begin_time,
       asdt.session_id AS active_transaction_session_id,
       asdt.elapsed_time_seconds AS active_transaction_elapsed_time_seconds
FROM sys.dm_tran_persistent_version_store_stats AS pvss
LEFT JOIN sys.dm_tran_database_transactions AS dt
ON pvss.oldest_active_transaction_id = dt.transaction_id
   AND
   pvss.database_id = dt.database_id
LEFT JOIN sys.dm_tran_active_snapshot_database_transactions AS asdt
ON pvss.min_transaction_timestamp = asdt.transaction_sequence_num
   OR
   pvss.online_index_min_transaction_timestamp = asdt.transaction_sequence_num
WHERE pvss.database_id = DB_ID();

Ha a persistent_version_store_size_gb oszlopban jelentett PVS-méret jelentősen csökkent az eredeti méretéhez képest, az újrafuttatás sikerrel járhat.

• Hibaszám: 5223, hibaüzenet: %.*ls: Üres lap %d:%d nem sikerült felszabadítani.

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

Ha a hiba továbbra is fennáll, előfordulhat, hogy a társított indexet újra kell felépíteni. 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élje le a <file_id> és <page_id> helyőrzőket a kapott hibaüzenet tényleges értékeire. Ha például az üzenet Üres oldal 1:62669 nem vonható vissza, akkor <file_id>1 és <page_id>62669.

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

• Hibaszám: 5201, hibaüzenet: DBCC SHRINKDATABASE: Az adatbázis-azonosító %d %d fájlazonosítója ki lett hagyva, mert a fájl nem rendelkezik elegendő szabad területtel a visszaigényléshez.

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

Kapcsolódó tartalom

További információ az adatbázis maximális méretéről:

• Azure SQL Database vCore alapú vásárlási modell korlátai egyetlen adatbázis esetén
• DTU-alapú vásárlási modellt használó önálló adatbázisok erőforráskorlátai
• Azure SQL Database vCore-alapú vásárlási modellhez tartozó korlátok rugalmas erőforrás-készletekhez
• Rugalmas készletek erőforráskorlátai a DTU-alapú vásárlási modellnek az alapján