Bestandsruimte voor databases beheren in Azure SQL Database

van toepassing op:Azure SQL Database-

In dit artikel worden verschillende typen opslagruimte voor databases in Azure SQL Database beschreven. Je moet soms expliciet de toegewezen bestandsruimte beheren. Dit artikel bevat de stappen om dit te doen.

Overzicht

Bepaalde werklastpatronen kunnen ervoor zorgen dat de aan databestanden toegewezen ruimte groter wordt dan de gebruikte ruimte. Deze aandoening doet zich voor wanneer de gebruikte ruimte toeneemt door datagroei, maar je later data verwijdert of comprimeert. De toegewezen maar ongebruikte ruimte wordt niet automatisch teruggewonnen omdat terugwinning veel middelen vereist en de groei van toekomstige bestanden zou vertragen.

Je moet mogelijk databestanden verkleinen en ongebruikte ruimte terugwinnen in de volgende scenario's:

• Om datagroei voor databases in een elastische pool mogelijk te maken wanneer een grote toegewezen ruimte voor sommige databases in de pool ervoor zorgt dat de pool zijn maximale grootte nadert.
• Om een verkleining van de maximale grootte van een enkele database of elastische pool mogelijk te maken.
• Om de database of een elastische pool te veranderen naar een laag met een lagere maximale groottelimiet.
• Om opslagkosten te verlagen bij het gebruik van de Hyperscale-servicelaag.

Gebruik van bestandsruimte bewaken

Azure Resource Manager (ARM) API's, inclusief PowerShell get-metrics, geven de gebruikte en toegewezen ruimte terug voor databases en elastic pools.

De volgende systeemweergaven geven ook de grootte van gebruikte en toegewezen ruimte voor databases en elastische pools terug:

• sys.resource_stats
• sys.elastic_pool_resource_stats
• sys.dm_elastic_pool_resource_stats

Inzicht in typen opslagruimte voor een database

Inzicht in de volgende opslagruimten is belangrijk voor het beheren van de bestandsruimte van een database.

In het volgende diagram ziet u de relatie tussen de verschillende typen opslagruimte voor een database.

Een query uitvoeren op één database voor informatie over de bestandsruimte

Gebruik de volgende query op sys.database_files om de hoeveelheid toegewezen databasebestandsruimte en de toegewezen hoeveelheid ongebruikte ruimte te retourneren.

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

Begrip van soorten opslagruimte voor een elastische pool

Het begrijpen van de volgende opslagruimtehoeveelheden is belangrijk voor het beheren van de bestandsruimte van een elastische pool.

De foutmelding "De elastische pool heeft zijn opslaglimiet bereikt" geeft aan dat de databaseobjecten voldoende ruimte innemen om aan de maximale limiet van de maximale opslaggrootte van de elastische pool te voldoen. Overweeg het verhogen van de opslaglimiet, of maak dataruimte vrij zoals beschreven in Reclaim unused assigned space.

Een query uitvoeren op een elastische pool voor informatie over opslagruimte

Gebruik de volgende queries om opslagruimtehoeveelheden voor een elastische pool te bepalen.

Gebruikte elastische poolgegevensruimte

Gebruik de volgende voorbeeldquery om de hoeveelheid elastische pooldataruimte terug te geven die is gebruikt. Pas de parameter van de naam van de elastische pool aan zodat deze overeenkomt met de naam van je pool.

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

Ongebruikte toegewezen ruimte vrijmaken

Gegevensbestanden verkleinen

Omdat het verkleinen van databestanden de prestaties van de database kan beïnvloeden, verkleint Azure SQL Database niet automatisch databestanden. Indien nodig kun je databestanden op een gewenst moment verkleinen. Plan shrink niet als een regelmatig terugkerende bewerking. Overweeg het in plaats daarvan pas te gebruiken na een grote vermindering van het gebruikte ruimteverbruik.

Om bestanden te verkleinen, gebruik je een van de volgende T-SQL-opdrachten: DBCC SHRINKDATABASE of DBCC SHRINKFILE

• DBCC SHRINKDATABASE verkleint alle data en logbestanden in een database met één enkel commando. De opdracht verkleint één gegevensbestand tegelijk, wat lang kan duren voor grotere databases. Azure SQL Database verkleint ook het logboekbestand , wat meestal niet nodig is omdat het logboekbestanden automatisch verkleint als dat nodig is.
• DBCC SHRINKFILE opdracht ondersteunt geavanceerdere scenario's:
  • Het kan naar behoefte zijn gericht op afzonderlijke bestanden in plaats van alle bestanden in de database te verkleinen.
  • Elk DBCC SHRINKFILE commando kan parallel met andere DBCC SHRINKFILE commando's draaien om de totale krimptijd te verkorten, ten koste van een hoger resourceverbruik en een grotere kans op tijdelijk blokkeren van gebruikersqueries en gelijktijdige DBCC SHRINKFILE commando's.
  • Als de staart van het bestand geen data bevat, kun je de toegewezen bestandsgrootte sneller verkleinen door het TRUNCATEONLY argument te specificeren. TRUNCATEONLY Het vereist geen gegevensbeweging binnen het bestand, maar het vermindert de toegewezen grootte ook minder.
• Zie DBCC SHRINKDATABASE en DBCC SHRINKFILEvoor meer informatie over deze opdrachten voor verkleinen.

Voer de volgende voorbeelden uit terwijl je verbonden bent met de doelgebruikersdatabase, niet met de master database.

Als u DBCC SHRINKDATABASE wilt gebruiken om alle gegevens en logboekbestanden in een bepaalde database te verkleinen:

DBCC SHRINKDATABASE (N'database_name');

Een database kan één of meer databestanden bevatten, die automatisch worden aangemaakt naarmate de data groeit. Om de bestandsindeling van je database te bepalen, inclusief de gebruikte en toegewezen grootte van elk bestand, raadpleeg je de sys.database_files catalogusweergave met behulp van het volgende voorbeeldscript:

-- 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');

Om een enkel bestand te verkleinen, gebruik je bijvoorbeeld het DBCC SHRINKFILE commando:

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

Transactielogboekbestand verkleinen

In tegenstelling tot gegevensbestanden verkleint Azure SQL Database het transactielogboekbestand automatisch om overmatig ruimtegebruik te voorkomen dat tot fouten met onvoldoende ruimte kan leiden. In de meeste gevallen hoeft u het transactielogboekbestand niet te verkleinen.

In de Premium- en Business Critical-servicelagen kan het transactielogboek, als het groot wordt, aanzienlijk bijdragen aan het lokale opslagverbruik richting de maximale lokale opslaglimiet . Als het lokale opslagverbruik dicht bij de limiet ligt, kun je ervoor kiezen om het transactielog te verkleinen met het DBCC SHRINKFILE commando zoals in het volgende voorbeeld wordt getoond. Hiermee wordt lokale opslag vrijgegeven zodra de opdracht is voltooid, zonder te wachten op de periodieke automatische verkleiningsbewerking.

Voer het volgende voorbeeld uit terwijl je verbonden bent met de doelgebruikersdatabase, niet met de master database.

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

Automatisch verkleinen

Als alternatief voor het handmatig verkleinen van gegevensbestanden kan automatisch verkleinen worden ingeschakeld voor een database. Automatisch verkleinen kan echter minder effectief zijn bij het vrijmaken van bestandsruimte dan DBCC SHRINKDATABASE en DBCC SHRINKFILE.

Automatisch verkleinen is standaard uitgeschakeld. Dit wordt aanbevolen voor de meeste databases. Als het nodig wordt om auto-shrink in te schakelen, wordt aanbevolen dit uit te schakelen zodra de ruimtebeheerdoelen zijn bereikt, in plaats van het permanent ingeschakeld te houden. Zie Overwegingen voor AUTO_SHRINKvoor meer informatie.

Auto-shrink kan bijvoorbeeld nuttig zijn als een elastische pool veel databases bevat die continu een aanzienlijke groei en vermindering van de gebruikte ruimte ervaren, waardoor de pool zijn maximale groottelimiet nadert. Dit scenario is niet gebruikelijk.

De optie voor automatisch verkleinen van de database heeft geen effect in Hyperscale-databases.

Als u automatisch verkleinen wilt inschakelen, voert u de volgende opdracht uit terwijl u verbinding hebt met uw database (niet de master-database).

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

Zie DATABASE SET-optiesvoor meer informatie over deze opdracht.

Indexonderhoud na verkleinen

Nadat een verkleiningsoperatie is voltooid, kunnen indexen gefragmenteerd raken. Voor de meeste workloads op moderne platforms zal indexfragmentatie waarschijnlijk geen invloed hebben op de prestaties. Voor workloads die grote indexscans gebruiken, kan fragmentatie de lees-I/O-doorvoer verminderen. Als de prestatiedegradatie optreedt nadat de shrink-operatie is voltooid, overweeg dan indexonderhoud om indexen opnieuw op te bouwen of te reorganiseren. Indexherbouwingen vereisen vrije ruimte in de database, waardoor de toegewezen ruimte kan toenemen, wat het effect van een krimp tegengaat.

Zie Indexonderhoud optimaliseren om de queryprestaties te verbeteren en het resourceverbruik te verminderenvoor meer informatie over indexonderhoud.

Grote databases verkleinen

Wanneer de toegewezen ruimte in een database honderden gigabytes of hoger is, kan krimpen lang duren. Verkleiningsoperaties kunnen uren, dagen of weken beslaan voor databases van meerdere terabytes. Deze sectie beschrijft procesoptimalisaties en best practices die dit proces efficiënter maken en minder impactvol voor applicatieworkloads.

Basislijn voor ruimtegebruik vastleggen

Voordat u begint met verkleinen, legt u de huidige gebruikte en toegewezen ruimte in elk databasebestand vast door de volgende query voor ruimtegebruik uit te voeren:

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

Zodra het verkleinen is voltooid, kunt u deze query opnieuw uitvoeren en het resultaat vergelijken met de eerste basislijn.

Kort databestanden af voor een snelle maar beperkte versterking

Als je de toegewezen ruimte snel wat wilt verkleinen, overweeg dan om DBCC SHRINKFILE uit te voeren met de parameter TRUNCATEONLY. Als er aan het einde van het bestand nog steeds toegewezen maar ongebruikte ruimte is, verwijdert de bewerking die ruimte snel en zonder enige dataverplaatsing.

Gebruik het echter niet TRUNCATEONLY als je doel is om de vermindering van de toegewezen ruimte te maximaliseren. Om dat doel te bereiken, moet je het volledige krimpproces uitvoeren zoals later in deze sectie beschreven. Omdat dat proces bestanden aan het einde afkort, heeft een aparte shrink met TRUNCATEONLY geen voordeel.

Het volgende voorbeeldcommando kortst bestands-ID 4 af:

DBCC SHRINKFILE (4, TRUNCATEONLY);

Nadat je dit commando voor elk databestand hebt uitgevoerd, voer je de opslagzoekopdracht opnieuw uit om de vermindering van toegewezen ruimte te zien, indien aanwezig. Je kunt ook de toegewezen ruimte voor de database bekijken in het Azure-portaal.

Indexpaginadichtheid evalueren

Als optionele maar aanbevolen stap bepaal je de gemiddelde paginadichtheid voor indexen in de database. Voor dezelfde hoeveelheid data zijn verkleiningsoperaties sneller afgerond als de paginadichtheid hoog is, omdat de bewerking minder pagina's binnen elk bestand verplaatst. Als de paginadichtheid laag is voor sommige indexen, kunt u overwegen om onderhoud uit te voeren op deze indexen om de paginadichtheid te verhogen voordat u gegevensbestanden verkleint. Een hogere paginadichtheid maakt het mogelijk dat shrink een diepere vermindering van de toegewezen opslagruimte bereikt.

Gebruik de volgende query om de paginadichtheid voor alle indexen in de database te bepalen. Paginadichtheid wordt gerapporteerd in de kolom avg_page_space_used_in_percent.

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;

Als er indexen zijn met een hoog paginaaantal (zoals gerapporteerd in de page_count kolom) met een paginadichtheid van lager dan 60-70%, overweeg dan deze indexen te herbouwen of te reorganiseren voordat je databestanden verkleint.

Voor grotere databases kan het lang duren voordat de query de paginadichtheid bepaalt. Voor het herbouwen of opnieuw ordenen van grote indexen is ook veel tijd en resourcegebruik vereist. Echter, indexonderhoud vóór het verkleinen kan de verkleiningsduur verminderen en meer ruimte besparen.

Als er meerdere indexen met lage paginadichtheid zijn, kunt u deze mogelijk parallel herbouwen op meerdere databasesessies om het proces te versnellen. Zorg er echter voor dat je daarmee niet de limieten van databaseresources nadert. Laat voldoende resourcehoofdruimte over voor toepassingsworkloads die mogelijk worden uitgevoerd. Monitor het resourceverbruik (CPU, Data IO, Log IO) in het Azure portaal of door gebruik te maken van de sys.dm_db_resource_stats weergave. Start extra indexoperaties alleen als het gebruik van middelen op elk van deze dimensies aanzienlijk lager blijft dan 100%.

Voorbeeld van een index rebuild-commando

Het volgende voorbeeldcommando gebruikt de ALTER INDEX-instructie om een index te herbouwen en de paginadichtheid te verhogen:

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

Met deze opdracht wordt een online en hervatbare index opnieuw opgebouwd. Met deze bewerking kunnen gelijktijdige workloads de tabel blijven gebruiken terwijl de herbouwbewerking wordt uitgevoerd en kunt u de herbouw hervatten als deze om welke reden dan ook wordt onderbroken. Dit type herbouw is echter langzamer dan een offline herbouwing, waardoor de toegang tot de tabel wordt geblokkeerd. Als er tijdens het opnieuw opbouwen geen andere workloads toegang nodig hebben tot de tabel, stelt u de ONLINE- en RESUMABLE-opties in op OFF en verwijdert u de WAIT_AT_LOW_PRIORITY-component.

Zie Indexonderhoud optimaliseren om de queryprestaties te verbeteren en het resourceverbruik te verminderenvoor meer informatie over indexonderhoud.

Reorganiseer indexen vóór krimp

Het herorganiseren van indexen vóór krimpen kan de krimpoperatie in twee scenario's aanzienlijk sneller maken.

1. Als de database aan alle volgende criteria voldoet:

   • Het bevat een groot aantal databestanden (meer dan 10).
   • Het heeft een groot aantal tabellen in de database (enkele honderden of meer), die samen veel ruimte gebruiken (honderden gigabytes of meer).
   • Een grote hoeveelheid data wordt uit sommige tabellen verwijderd.

   Voor dergelijke databases verkort het opnieuw organiseren van indexen op de tabellen waaruit u gegevens hebt verwijderd een langdurige fase in het shrinkproces.

2. Als de database bevat:

   • Grote objecten (LOB) datatypes zoals varchar(max),nvarchar(max),varbinary(max),xml of vergelijkbare datatypes opgeslagen in de LOB_DATA allocatie-eenheid.
   • Grote rijen opgeslagen in een ROW_OVERFLOW_DATA.
   • Columnstore-indexen.

   Om shrink sneller te laten draaien en meer ruimte vrij te maken in dit scenario, zorg ervoor dat je de LOB_COMPACTION clausule toevoegt wanneer je indexen reorganiseert. LOB-compressie voordat de gegevens worden verkleind, wordt aanbevolen voor alle indexen die LOB-kolommen of grote rijen bevatten.

   Het opnieuw ordenen of herbouwen van columnstore-indexen voordat het verkleinproces plaatsvindt, kan op vergelijkbare wijze de snelheid en effectiviteit van het verkleinproces verhogen.

Het volgende voorbeeld toont een commando om een index te reorganiseren en LOB-verdichting uit te voeren:

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

Verklein meerdere databestanden parallel

Een krimpoperatie die gegevensverplaatsing vereist, is een langlopend proces. Als de database meerdere gegevensbestanden heeft, kunt u het proces versnellen door meerdere gegevensbestanden parallel te verkleinen. Open meerdere databasesessies en gebruik DBCC SHRINKFILE voor elke sessie met een andere file_id waarde. Net als bij het opnieuw opbouwen van indexen moet u ervoor zorgen dat u voldoende ruimte hebt voor resources (CPU, Data IO, Log IO) voordat u elke nieuwe parallelle verkleiningsopdracht start.

Het volgende voorbeeldcommando verkleint bestands-ID 4 en probeert de toegewezen grootte te verkleinen tot 52.000 MB:

DBCC SHRINKFILE (4, 52000);

Om de toegewezen ruimte voor het bestand tot het minimum te beperken, voer je de instructie uit zonder de doelgrootte op te geven:

DBCC SHRINKFILE (4);

Als je te veel parallelle krimpoperaties start, kun je een hoog resourcegebruik en lockconflicten tussen krimpoperaties waarnemen. Voor de meeste scenario's ligt het optimale aantal parallelle krimpoperaties tussen de vier en acht.

Verkleinen in kleine stappen

Als een verkleiningsoperatie onverwacht stopt (bijvoorbeeld door gepland of ongepland onderhoud), kan een werklast de ruimte die door verkleinen is vrijgemaakt gaan gebruiken voordat verkleinen het bestand afsnijdt, waardoor een deel van de tot dan toe gemaakte voortgang verloren gaat. Omdat shrink vaak lang duurt, is de kans op een onderbreking groter.

Om dit probleem te voorkomen, verklein je elk bestand in kleinere, incrementele stappen. Stel in het commando DBCC SHRINKFILE het doel in dat kleiner is dan de huidige toegewezen ruimte voor het bestand, maar groter dan de gebruikte ruimte die de basisruimtegebruiksquery teruggeeft.

Als bijvoorbeeld de toegewezen ruimte voor bestands-ID 4 200.000 MB is en je wilt deze verkleinen tot 100.000 MB, kun je eerst het doel instellen op 180.000 MB:

DBCC SHRINKFILE (4, 180000);

Nadat dit commando de toegewezen grootte heeft teruggebracht tot 180.000 MB, kun je opnieuw verkleinen uitvoeren, waarbij je het doel eerst op 160.000 MB zet, daarna op 140.000 MB, en het doel blijft verkleinen totdat het bestand de gewenste grootte bereikt.

Het verkleinen van bestanden in stappen kan langer duren, maar het vermindert het risico dat de verkleining voor het hele bestand herhaald wordt door een onverwachte onderbreking.

Als uitgangspunt gebruik je een increment in het bereik van 10-20 gigabyte. Je kunt de increment aanpassen naar behoefte voor jouw situatie. Grotere stappen kunnen je in staat stellen om het bestand sneller te voltooien, kleinere stappen verkleinen het risico op verlies van voortgang als het verkleinen wordt onderbroken.

Verkleiningsbewerkingen controleren

Om de voortgang van het verkleinen te monitoren voor alle gelijktijdig lopende verkleinsessies, gebruik je de volgende query:

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');

Wanneer de verkleining voor alle databestanden succesvol is voltooid, voer je de opslagzoekopdracht opnieuw uit (of controleer je in het Azure-portaal) om de resulterende vermindering van de toegewezen opslaggrootte te zien. Als er nog steeds een groot verschil is tussen gebruikte en toegewezen ruimte, bouw dan indexen opnieuw op of reorganiseer ze opnieuw. Een indexherbouw kan tijdelijk de toegewezen ruimte vergroten. Het opnieuw verkleinen van databestanden na het herbouwen van indexen leidt echter vaak tot een diepere vermindering van de toegewezen ruimte.

Tijdelijke fouten tijdens verkleinen

Soms kan een shrink-commando falen met fouten zoals timeouts en deadlocks. Deze fouten zijn vaak tijdelijk en komen niet meer voor als je hetzelfde commando herhaalt. Als shrink faalt door een fout, behoudt het de tot nu toe geboekte voortgang. Voer dezelfde opdracht voor verkleinen opnieuw uit om door te gaan met het verkleinen van het bestand.

Het ShrinkDriver PowerShell-script probeert automatisch opnieuw te verkleinen wanneer er een tijdelijke fout optreedt. Gebruik dit script om grote databases te verkleinen.

Het volgende voorbeeld van een T-SQL-script laat zien hoe je verkleinen voor één bestand in een hertelingslus kunt uitvoeren. De lus probeert de bewerking automatisch opnieuw uit te voeren, maximaal een configureerbaar aantal keren, wanneer er een time-outfout of een deadlockfout optreedt. Deze herprobeermethode geldt voor veel andere fouten die kunnen optreden tijdens krimp.

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

Naast time-outs en deadlocks kan shrink ook fouten ondervinden door bepaalde bekende problemen.

Bekijk de fouten en mitigatiestappen in de volgende secties.

Foutnummer 49503

%.*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.

Deze fout doet zich voor wanneer lang lopende actieve transacties rijversies genereren in de persistent version store (PVS). Shrink kan de pagina's met rijversies niet verplaatsen.

Om deze fout te beperken, wacht je tot de lang lopende transacties zijn voltooid. Of identificeer en beëindig langlopende transacties, maar deze actie kan je applicatie beïnvloeden als deze transactiefouten niet soepel afhandelt.

Voor meer informatie over het oplossen van problemen met vertragingen bij het opschonen van PVS die het verkleinen kunnen beïnvloeden, raadpleeg Versneld databaseherstel bewaken en problemen oplossen.

Foutnummer 5223

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

Deze fout kan optreden tijdens lopende indexonderhoudsoperaties zoals ALTER INDEX. Voer de opdracht Verkleinen opnieuw uit nadat deze bewerkingen zijn voltooid.

Als deze fout blijft bestaan, moet je mogelijk de bijbehorende index opnieuw opbouwen. Voer de volgende query uit in dezelfde database waarin u de opdracht verkleinen hebt uitgevoerd om de index te vinden die opnieuw moet worden opgebouwd:

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;

Vervang voordat je deze query uitvoert, de <file_id> en <page_id> plaatsvervangers door de daadwerkelijke waarden uit het foutbericht. Bijvoorbeeld, als het bericht is: Empty page 1:62669 could not be deallocated, dan <file_id> is 1 en <page_id> is 62669.

Bouw de index die door de query is geïdentificeerd opnieuw op en probeer de opdracht Verkleinen opnieuw uit te voeren.

Foutnummer 5201

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

Deze fout betekent dat het databestand niet verder kan worden verkleind. U kunt verdergaan met het volgende gegevensbestand.

Verwante inhoud

• Resourcelimieten voor individuele databases met gebruikmaking van het vCore-aankoopmodel
• resourcelimieten voor individuele databases met behulp van het DTU-aankoopmodel - Azure SQL Database
• Resourcelimieten voor elastische pools met behulp van het vCore-aankoopmodel
• Resourcelimieten voor elastische pools met gebruikmaking van het DTU-aankoopmodel