Gérer l'espace de fichier des bases de données dans Azure SQL Database

S’applique à :Azure SQL Database

Cet article décrit différents types d’espace de stockage pour les bases de données dans Azure SQL Database. Il se peut que vous deviez parfois gérer explicitement l’espace de fichiers alloué. Cet article comprend les étapes à suivre.

Vue d’ensemble

Certains schémas de charge de travail peuvent faire en sorte que l’espace alloué aux fichiers de données soit plus grand que l’espace utilisé. Cette condition survient lorsque l’espace utilisé augmente à cause de la croissance des données, mais que vous supprimez ou comprimez ensuite les données. L’espace alloué mais inutilisé n’est pas automatiquement récupéré car la récupération est gourmande en ressources et ralentirait la croissance future des fichiers.

Vous pourriez avoir besoin de réduire les fichiers de données et de récupérer de l’espace inutilisé dans les scénarios suivants :

• Permettre la croissance des données pour les bases de données dans un pool élastique lorsqu’un grand espace alloué à certaines bases de données du pool fait que le pool approche sa taille maximale.
• Permettre une diminution de la taille maximale d’une seule base de données ou d’un pool élastique.
• Changer la base de données ou un pool élastique vers un niveau avec une limite maximale de taille inférieure.
• Pour réduire les coûts de stockage lors de l’utilisation du niveau de service Hyperscale.

Surveiller l’utilisation de l’espace de stockage des fichiers

Les API Azure Resource Manager (ARM), y compris les métriques PowerShell get-metrics, rendent l’espace utilisé et alloué pour les bases de données et les pools élastiques.

Les vues système suivantes restituent également la taille de l’espace utilisé et alloué pour les bases de données et les pools élastiques :

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

Appréhender les types d’espace de stockage d’une base de données

Comprendre les quantités d’espace de stockage suivantes est importante pour gérer l’espace de fichier d’une base de données.

Le schéma suivant illustre la relation entre les différents types d’espace de stockage d’une base de données.

Interroger une base de données unique pour des informations relatives à l’espace de stockage des fichiers

Utilisez la requête suivante sur sys.database_files pour retourner la quantité d’espace de données allouée de la base de données et la quantité d’espace alloué non utilisé.

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

Appréhender les types d’espace de stockage d’un pool élastique

Comprendre les quantités d’espace de stockage suivantes est important pour gérer l’espace de fichiers d’un pool élastique.

Le message d’erreur « Le pool élastique a atteint sa limite de stockage » indique que les objets de la base de données occupent suffisamment d’espace pour atteindre la limite maximale de taille de stockage du pool élastique. Envisagez d’augmenter la limite de stockage, ou de libérer de l’espace de données comme décrit dans Récupérer l’espace alloué inutilisé.

Interroger un pool élastique pour des informations relatives à l’espace de stockage

Utilisez les requêtes suivantes pour déterminer les quantités d’espace de stockage pour un pool élastique.

Espace de données du pool élastique utilisé

Utilisez l’exemple de requête suivant pour retourner la quantité d’espace de données élastiques du pool utilisé. Modifie le paramètre de nom de la piscine élastique pour qu’il corresponde au nom de votre piscine.

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

Récupérer l’espace alloué non utilisé

Réduire les fichiers de données

Comme la réduction des fichiers de données peut affecter la performance de la base de données, Azure SQL Database ne réduit pas automatiquement les fichiers de données. Si nécessaire, vous pouvez réduire les fichiers de données à un moment de votre choix. Ne faites pas de la réduction une opération planifiée régulièrement. Envisagez plutôt de ne l’utiliser qu’après une réduction importante de la consommation d’espace utilisé.

Pour réduire les fichiers, utilisez soit DBCC SHRINKDATABASE, soit DBCC SHRINKFILE comme commandes T-SQL :

• DBCC SHRINKDATABASE réduit toutes les données et fichiers journaux d’une base de données avec une seule commande. La commande réduit un fichier de données à la fois, ce qui peut prendre beaucoup de temps pour les bases de données volumineuses. Elle permet également de réduire le fichier journal, ce qui est généralement inutile parce qu’Azure SQL Database réduit les fichiers journaux automatiquement si nécessaire.
• La commande DBCC SHRINKFILE prend en charge des scénarios plus avancés :
  • Elle peut cibler des fichiers individuels en fonction des besoins, au lieu de réduire tous les fichiers de la base de données.
  • Chaque commande DBCC SHRINKFILE peut s’exécuter en parallèle avec d’autres commandes DBCC SHRINKFILE afin de réduire la durée totale de l’opération de réduction, au prix d’une utilisation accrue des ressources et d’un risque plus élevé de bloquer temporairement les requêtes des utilisateurs et les commandes DBCC SHRINKFILE concurrentes.
  • Si la queue du fichier ne contient pas de données, vous pouvez réduire plus rapidement la taille du fichier allouée en spécifiant l’argument TRUNCATEONLY . TRUNCATEONLY Ne nécessite pas de déplacement des données dans le fichier, mais cela ne réduit pas non plus autant la taille allouée.
• Pour plus d’informations sur ces commandes de réduction, consultez DBCC SHRINKDATABASE et DBCC SHRINKFILE.

Exécutez les exemples suivants tout en étant connecté à la base de données utilisateur cible, et non à la master base de données.

Pour utiliser DBCC SHRINKDATABASE pour réduire l’ensemble des données et des fichiers journaux dans une base de données spécifique :

DBCC SHRINKDATABASE (N'database_name');

Une base de données peut avoir un ou plusieurs fichiers de données, créés automatiquement au fur et à mesure que les données augmentent. Pour déterminer la disposition des fichiers de votre base de données, y compris la taille utilisée et allouée de chaque fichier, interrogez la sys.database_files vue catalogue en utilisant le script d’exemple suivant :

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

Pour réduire un seul fichier, utilisez la DBCC SHRINKFILE commande, par exemple :

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

Réduire le fichier journal de transactions

Contrairement aux fichiers de données, Azure SQL Database réduit automatiquement le fichier journal de transactions afin d’éviter une utilisation excessive de l’espace, qui peut entraîner des erreurs d’insuffisance d’espace. Dans la plupart des cas, vous n’avez pas besoin de réduire le fichier journal des transactions.

Dans les niveaux de service Premium et Business Critique, si le journal de transactions devient grand, il peut contribuer significativement à la consommation locale de stockage vers la limite maximale locale. Si la consommation de stockage local est proche de la limite, vous pouvez choisir de réduire le journal des transactions en utilisant la DBCC SHRINKFILE commande comme montré dans l’exemple suivant. Cela libère le stockage local dès la fin de la commande, sans attendre l’opération de réduction automatique périodique.

Exécutez l’exemple suivant tout en étant connecté à la base de données utilisateur cible, et non à la master base de données.

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

Réduction automatique

Comme alternative à la réduction manuelle des fichiers de données, la réduction automatique peut être activée pour une base de données. Cependant, la réduction automatique peut être moins efficace pour récupérer de l’espace de fichiers que DBCC SHRINKDATABASE et DBCC SHRINKFILE.

Par défaut, la réduction automatique est désactivée, ce qui est recommandé pour la plupart des bases de données. Si l’activation de l’auto-réduction devient nécessaire, il est recommandé de le désactiver une fois les objectifs de gestion de l’espace atteints, plutôt que de le maintenir activé de façon permanente. Pour plus d’informations, consultez Considérations relatives à AUTO_SHRINK.

Par exemple, l’auto-réduction peut être utile si un pool élastique contient de nombreuses bases de données qui subissent en continu une croissance et une réduction significatives de l’espace utilisé, ce qui fait que le pool approche de sa limite maximale de taille. Ce scénario n’est pas courant.

L’option de réduction automatique de la base de données n’a aucun effet dans les bases de données Hyperscale.

Pour activer la réduction automatique, exécutez la commande suivante en étant connecté à votre base de données (et non à la base de données master).

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

Pour plus d’informations sur cette commande, consultez les options de DATABASE SET.

Maintenance des index après réduction

Après la fin d’une opération de réduction, les indices peuvent devenir fragmentés. Pour la plupart des charges de travail sur les plateformes modernes, la fragmentation de l’index n’a probablement pas d’impact sur les performances. Pour les charges de travail utilisant de grands scans d’index, la fragmentation peut réduire le débit d’E/S en lecture. Si une dégradation des performances survient après la fin de l’opération de réduction, envisagez la maintenance des indices pour reconstruire ou réorganiser les indices. Les reconstructions d’index nécessitent de l’espace libre dans la base de données, ce qui peut entraîner une augmentation de l’espace alloué, contrebalançant ainsi l’effet d’un réducteur.

Pour plus d’informations sur la maintenance des index, consultez Optimiser la maintenance des index pour améliorer les performances des requêtes et réduire la consommation des ressources.

Réduire les grandes bases de données

Lorsque l’espace alloué dans une base de données est de centaines de gigaoctets ou plus, la réduction peut prendre beaucoup de temps. Les opérations de réduction peuvent durer des heures, des jours ou des semaines pour des bases de données de plusieurs téraoctets. Cette section décrit les optimisations des processus et les meilleures pratiques qui rendent ce processus plus efficace et moins impactant les charges de travail applicatives.

Capturer une base de référence de l’utilisation de l’espace

Avant de commencer la réduction, capturez l’espace utilisé et alloué actuel dans chaque fichier de base de données en exécutant la requête d’utilisation d’espace suivante :

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

Une fois que la réduction est terminée, vous pouvez réexécuter cette requête et comparer le résultat à la base de référence initiale.

Raccourcir les fichiers de données pour un gain rapide mais limité

Si vous souhaitez obtenir rapidement une réduction de l’espace alloué, envisagez d’exécuter DBCC SHRINKFILE avec le TRUNCATEONLY paramètre. S’il y a de l’espace alloué mais inutilisé à la fin du fichier, l’opération retire cet espace rapidement et sans aucun mouvement de données.

Cependant, ne l’utilisez TRUNCATEONLY pas si votre objectif est de maximiser la réduction de l’espace alloué. Pour atteindre cet objectif, vous devez effectuer le processus de réduction complète décrit plus loin dans cette section. Parce que ce processus tronque les fichiers en fin de fichier, une réduction distincte avec TRUNCATEONLY n’offre aucun avantage.

L’exemple de commande suivant tronque l’ID de fichier 4 :

DBCC SHRINKFILE (4, TRUNCATEONLY);

Après avoir lancé cette commande pour chaque fichier de données, relancez la requête d’utilisation de l’espace pour voir la réduction de l’espace alloué, si elle y en a. Vous pouvez également consulter l’espace alloué pour la base de données dans le portail Azure.

Évaluer la densité des pages d’index

En tant qu’étape optionnelle mais recommandée, déterminez la densité moyenne de pages pour les index dans la base de données. Pour la même quantité de données, les opérations de réduction se terminent plus rapidement si la densité de pages est élevée, car l’opération déplace moins de pages dans chaque fichier. Si la densité des pages est faible pour certains index, effectuez une maintenance sur ces index pour augmenter la densité des pages avant de réduire les fichiers de données. Une densité de pages plus élevée permet à l’opération de réduction de diminuer davantage l’espace de stockage alloué.

Pour déterminer la densité des pages de tous les index de la base de données, utilisez la requête suivante. La densité des pages est signalée dans la colonne 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;

S’il existe des index avec un nombre élevé de pages (comme indiqué dans la page_count colonne) dont la densité de pages est inférieure à 60-70%, envisagez de reconstruire ou de réorganiser ces index avant de réduire les fichiers de données.

Pour les bases de données plus volumineuses, la requête permettant de déterminer la densité de page peut prendre beaucoup de temps. La reconstruction ou la réorganisation d’index volumineux nécessite également un temps et une utilisation des ressources considérables. Toutefois, la maintenance des index avant la réduction peut réduire la durée de réduction et réaliser des économies d’espace plus élevées.

Si vous avez plusieurs index avec une faible densité de page, vous pourrez peut-être les reconstruire en parallèle sur plusieurs sessions de base de données pour accélérer le processus. Cependant, assurez-vous de ne pas approcher les limites des ressources de la base de données en procédant ainsi. Laissez suffisamment d’espace de ressources pour les charges de travail d’application qui peuvent être en cours d’exécution. Surveillez la consommation de ressources (CPU, Data Io, Log Io) via le portail Azure ou en utilisant la vue sys.dm_db_resource_stats. Commencer des opérations d’indexation supplémentaires uniquement si l’utilisation des ressources sur chacune de ces dimensions reste sensiblement inférieure à 100%.

Exemple de commande de reconstruction de l’index

La commande d’exemple suivante utilise l’instruction ALTER INDEX pour reconstruire un index et augmenter sa densité de pages :

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

Cette commande lance une reconstruction d’index en ligne et reprenable. Cette opération permet aux charges de travail simultanées de continuer à utiliser la table pendant que la reconstruction est en cours et vous permet de reprendre la reconstruction si elle est interrompue pour une raison quelconque. Toutefois, ce type de reconstruction est plus lent qu’une reconstruction hors connexion, qui bloque l’accès à la table. Si aucune autre charge de travail n’a besoin d’accéder à la table pendant la reconstruction, définissez les options ONLINE et RESUMABLE sur OFF pour supprimer la clause WAIT_AT_LOW_PRIORITY.

Pour en savoir plus sur la maintenance des index, consultez Optimiser la maintenance des index pour améliorer les performances des requêtes et réduire la consommation des ressources.

Réorganiser les index avant de réduire

Réorganiser les indices avant de réduire peut rendre l’opération de réduction significativement plus rapide dans deux scénarios.

1. Si la base de données correspond à tous les critères suivants :

   • Il contient un grand nombre de fichiers de données (plus de 10).
   • Il dispose d’un grand nombre de tables dans la base de données (plusieurs centaines ou plus), occupant collectivement une grande quantité d’espace (des centaines de gigaoctets ou plus).
   • Une grande quantité de données est supprimée de certaines tables.

   Pour ces bases de données, réorganiser les index sur les tables où vous avez supprimé les données raccourcit une phase longue du processus de réduction.

2. Si la base de données contient :

   • Des types de données grand objet (LOB) tels que varchar(max),nvarchar(max), varbinary(max),xml ou des types de données similaires stockés dans l’unité d’allocation LOB_DATA .
   • Lignes volumineuses stockées dans une unité d’allocation ROW_OVERFLOW_DATA .
   • Index Columnstore.

   Pour accélérer la réduction et libérer plus d’espace dans ce scénario, assurez-vous d’inclure la LOB_COMPACTION clause lors de la réorganisation des indices. Le compactage de LOB avant la réduction est recommandé pour tous les index qui contiennent des colonnes LOB ou des lignes volumineuses.

   Réorganiser ou reconstruire des index columnstore avant la réduction peut également augmenter la rapidité et l'efficacité de cette dernière.

L’exemple suivant montre une commande pour réorganiser un index et effectuer la compactation LOB :

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

Réduire plusieurs fichiers de données en parallèle

Une opération de réduction nécessitant un transfert de données est un processus de longue durée. Si la base de données contient plusieurs fichiers de données, vous pouvez accélérer le processus en réduisant plusieurs fichiers de données en parallèle. Ouvrez plusieurs sessions de base de données et utilisez-la DBCC SHRINKFILE sur chaque session avec une valeur différente file_id . Tout comme avec la reconstruction des index vue précédemment, assurez-vous d’avoir suffisamment de marge de ressources (processeur, E/S de données, E/S de journal) avant de commencer chaque nouvelle commande de réduction parallèle.

La commande d’exemple suivante réduit l’ID de fichier 4, tentant de réduire sa taille allouée à 52 000 Mo :

DBCC SHRINKFILE (4, 52000);

Pour réduire au minimum l’espace alloué au fichier au minimum, exécutez l’instruction sans spécifier la taille cible :

DBCC SHRINKFILE (4);

Si vous lancez trop d’opérations de réduction menées en parallèle, vous pourriez observer une forte utilisation des ressources et des contentions de verrouillage entre les opérations de réduction. Dans la plupart des scénarios, le nombre optimal d’opérations de rétrécissement parallèle se situe entre quatre et huit.

Réduction par étapes progressives

Si une opération de réduction s’arrête de manière inattendue (par exemple, à cause d’une maintenance planifiée ou non planifiée), une charge de travail peut commencer à utiliser l’espace libéré par la réduction avant que la réduction ne tronque le fichier, perdant ainsi une partie de la réduction de progression réalisée jusqu’à présent. Comme l’opération de réduction prend souvent beaucoup de temps, le risque d’interruption est plus élevé.

Pour éviter ce problème, réduisez chaque fichier en étapes plus petites et progressives. Dans la DBCC SHRINKFILE commande, définissez la cible plus petite que l’espace actuellement alloué pour le fichier, mais plus grande que l’espace utilisé renvoyé par la requête d’utilisation de l’espace de base .

Par exemple, si l’espace alloué pour l’ID de fichier 4 est de 200 000 Mo, et que vous souhaitez le réduire à 100 000 Mo, vous pouvez d’abord fixer l’objectif à 180 000 Mo :

DBCC SHRINKFILE (4, 180000);

Après que cette commande ait réduit la taille allouée à 180 000 Mo, vous pouvez lancer à nouveau le rétrécir, en fixant d’abord la cible à 160 000 Mo, puis à 140 000 Mo, et continuer à réduire la cible jusqu’à ce que le fichier atteigne la taille souhaitée.

Réduire les fichiers par incréments peut prendre plus de temps, mais cela réduit le risque de réduction répétée pour l’ensemble du fichier à cause d’une interruption inattendue.

Pour commencer, utilisez un incrément de 10 à 20 gigaoctets. Vous pouvez ajuster l’incrément selon votre scénario. Des incréments plus importants peuvent vous permettre de finir la réduction des fichiers plus rapidement, des incréments plus petits réduisent le risque de perdre la progression si le retrait est interrompu.

Surveiller les opérations de réduction

Pour suivre la progression de la réduction pour toutes les sessions de réduction exécutées simultanément, utilisez la requête suivante :

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

Lorsque l’opération de réduction s’est terminée avec succès pour tous les fichiers de données, relancez la requête d’utilisation de l’espace disque (ou vérifiez dans le portail Azure) pour constater la réduction de la taille de stockage allouée obtenue. S’il y a encore une grande différence entre l’espace utilisé et l’espace alloué, reconstruisez ou réorganisez les index. Une reconstruction de l’index pourrait temporairement augmenter l’espace alloué. Cependant, réduire à nouveau les fichiers de données après la reconstruction des index entraîne souvent une réduction plus profonde de l’espace alloué.

Erreurs temporaires lors de la réduction

Parfois, une commande de réduction peut échouer avec des erreurs telles que des délais d’attente ou des blocages. Ces erreurs sont souvent éphémères et ne se reproduisent pas si vous répétez la même commande. Si le réducteur échoue à cause d’une erreur, il conserve les progrès réalisés jusqu’à présent. Réexécutez la même commande shrink pour continuer à réduire le fichier.

Le script PowerShell ShrinkDriver réessaie automatiquement de réduire lorsqu’une erreur transitoire survient. Utilisez ce script pour réduire les grandes bases de données.

L’exemple suivant de script T-SQL montre comment exécuter le réduction pour un seul fichier dans une boucle de réessayage. La boucle réessaie automatiquement l’opération jusqu’à un nombre configurable de fois lorsqu’une erreur de délai ou un blocage survient. Cette approche de nouvelle tentative s’applique à de nombreuses autres erreurs susceptibles de se produire lors de la réduction.

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

En plus des délais d’expiration et des interblocages, la réduction peut rencontrer des erreurs dues à certains problèmes connus.

Examinez les erreurs et les étapes d’atténuation dans les sections suivantes.

Numéro d’erreur 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.

Cette erreur survient lorsque des transactions actives de longue durée génèrent des versions de lignes dans le magasin de versions persistant (PVS). L’opération de réduction ne peut pas déplacer les pages contenant des versions de ligne.

Pour atténuer cette erreur, attendez la fin des transactions de longue durée. Sinon, identifiez et terminez les transactions en cours prolongé, mais cette action peut affecter votre application si elle ne gère pas correctement les échecs de transaction.

Pour plus d’informations sur la résolution des problèmes de retard du nettoyage PVS susceptibles d’affecter l’opération de réduction, consultez Surveiller et résoudre les problèmes de récupération accélérée de la base de données.

Erreur numéro 5223

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

Cette erreur peut survenir lors d’opérations de maintenance d’index en cours telles que ALTER INDEX. Réessayez la commande de réduction une fois ces opérations terminées.

Si cette erreur persiste, il se peut que vous deviez reconstruire l’indice associé. Pour rechercher l’index à reconstruire, exécutez la requête suivante dans la même base de données où vous avez exécuté la commande de réduction :

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;

Avant d’exécuter cette requête, remplacez les <file_id> placeholders et <page_id> par les valeurs réelles du message d’erreur. Par exemple, si le message est : Empty page 1:62669 could not be deallocated, alors <file_id> est 1 et <page_id> est 62669.

Reconstruisez l’index identifié par la requête, puis réessayez la commande de réduction.

Erreur numéro 5201

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

Cette erreur signifie que le fichier de données ne peut pas être réduit davantage. Vous pouvez passer au fichier de données suivant.

Contenu connexe

• Limites de ressources pour des bases de données uniques suivant le modèle d’achat vCore
• Limites de ressources pour des bases de données uniques suivant le modèle d’achat DTU - Azure SQL Database
• Limites de ressources pour les pools élastiques suivant le modèle d’achat vCore
• Limites de ressources pour des pools élastiques suivant le modèle d’achat DTU