Partage via

Gérer la récupération de base de données accélérée

  • Article

s’applique à : SQL Server 2019 (15.x) et versions ultérieures

Cet article vous apprend à activer et désactiver récupération de base de données accélérée (ADR) avec Transact-SQL (T-SQL) dans SQL Server 2019 (15.x) et versions ultérieures, ainsi que la façon de modifier le groupe de fichiers de magasin de versions persistantes (PVS) utilisé par ADR.

Remarque

Dans Azure SQL Database, Azure SQL Managed Instance et SQL Database dans Microsoft Fabric, la récupération de base de données accélérée (ADR) est toujours activée. Si vous observez des problèmes, tels que l’utilisation élevée du stockage par PVS ou le nettoyage ADR lent, consultez Résoudre les problèmes de récupération de base de données accélérée ou contacter support Azure.

Qui doit envisager d’utiliser la récupération de base de données accélérée ?

De nombreux clients trouvent la récupération accélérée de base de données (ADR) une technologie précieuse pour améliorer le temps de récupération de la base de données.

Si vos charges de travail de base de données rencontrent fréquemment les scénarios suivants, vous pouvez tirer parti de l’ADR :

  • Transactions de longue durée qu'on ne peut éviter. Par exemple, dans les cas où les transactions à exécution longue risquent d’être restaurées, l’ADR peut vous aider.
  • Les transactions actives qui entraînent l’augmentation significative du journal des transactions.
  • Récupération de base de données longue qui a un impact sur la disponibilité de la base de données (par exemple, après un redémarrage inattendu de SQL Server ou une restauration manuelle des transactions).

L’ADR n’est pas recommandée pour les scénarios suivants :

  • Les bases de données utilisant la mise en miroir de bases de données ne sont pas prises en charge.
  • Si votre application utilise un volume élevé de modifications individuelles de lignes dans des transactions individuelles, votre charge de travail peut ne pas être optimale pour ADR. Envisagez de traiter les modifications par lot dans les instructions à plusieurs lignes, dans la cas où cela est possible, et évitez un volume élevé de petites transactions DML.

Activer ADR

ADR est désactivé par défaut et disponible à partir de SQL Server 2019 (15.x).

Utilisez la commande Transact-SQL (T-SQL) suivante pour activer ADR :

ALTER DATABASE [<db_name>] SET ACCELERATED_DATABASE_RECOVERY = ON;

Un verrou de base de données exclusif est nécessaire pour activer ou désactiver ADR. Cela signifie que la commande ALTER DATABASE est bloquée jusqu’à ce que toutes les sessions actives soient supprimées, et que toutes les nouvelles sessions attendent derrière la commande ALTER DATABASE. S’il est important d’effectuer l’opération et de supprimer le verrou, vous pouvez utiliser la clause d’arrêt, WITH ROLLBACK [IMMEDIATE | AFTER {number} SECONDS | NO_WAIT] pour abandonner les sessions actives dans la base de données. Pour plus d’informations, consultez les options de ALTER DATABASE SET .

Désactiver ADR

Utilisez la commande T-SQL suivante pour désactiver ADR :

ALTER DATABASE [<db_name>] SET ACCELERATED_DATABASE_RECOVERY = OFF;
GO

Même après la désactivation de l’ADR, il peut y avoir des versions stockées dans PVS dont le système a toujours besoin pour une restauration logique jusqu’à ce que toutes les transactions actives se terminent.

Modifier le groupe de fichiers PVS

Par défaut, les données de magasin de versions persistantes (PVS) se situent sur le groupe de fichiers PRIMARY. Vous pouvez déplacer PVS vers un autre groupe de fichiers si nécessaire. Par exemple, il peut nécessiter plus d’espace ou un stockage plus rapide.

Pour modifier l’emplacement du PVS en un autre groupe de fichiers, procédez comme suit :

  1. Créez le groupe de fichiers pour PVS et ajoutez au moins un fichier de données à ce groupe de fichiers. Par exemple :

    ALTER DATABASE [<db_name>] ADD FILEGROUP [VersionStoreFG];
GO

ALTER DATABASE [<db_name>]
ADD FILE
(
   NAME = N'VersionStoreFG',
   FILENAME = N'E:\DATA\VersionStore.ndf',
   SIZE = 8192 MB,
   FILEGROWTH = 64 MB
)
TO FILEGROUP [VersionStoreFG];

  2. Désactivez ADR avec la commande T-SQL suivante :

    ALTER DATABASE [<db_name>] SET ACCELERATED_DATABASE_RECOVERY = OFF;
GO

  3. Attendez que toutes les versions stockées dans PVS soient supprimées.

    Pour activer ADR à l’aide d’un nouvel emplacement PVS, vérifiez d’abord que toutes les informations de version ont été vidées de l’emplacement PVS précédent. Vous pouvez forcer l'exécution du nettoyage avec la procédure stockée sys.sp_persistent_version_cleanup :

    EXEC sys.sp_persistent_version_cleanup [<db_name>];

    La procédure stockée sys.sp_persistent_version_cleanup est synchrone, ce qui signifie qu’elle n’est pas terminée tant que toutes les informations de version ne sont pas nettoyées à partir du PVS actuel. Une fois l’opération terminée, vous pouvez vérifier que les informations de version sont supprimées en interrogeant sys.dm_tran_persistent_version_store_stats et en examinant la valeur de persistent_version_store_size_kb, comme l’exemple suivant :

    SELECT DB_NAME(database_id),
       persistent_version_store_size_kb
FROM sys.dm_tran_persistent_version_store_stats
WHERE database_id = [MyDatabaseID];

    Lorsque la valeur de persistent_version_store_size_kb est 0, vous pouvez réactiver la fonctionnalité ADR, avec le PVS dans le nouveau groupe de fichiers.

  4. Activez ADR et spécifiez le nouvel emplacement PVS avec la commande T-SQL suivante :

    ALTER DATABASE [<db_name>] SET ACCELERATED_DATABASE_RECOVERY = ON
(PERSISTENT_VERSION_STORE_FILEGROUP = [VersionStoreFG]);

Surveiller la taille du PVS

Une fois que vous avez activé ADR sur une base de données, surveillez la taille du magasin de versions persistantes (PVS) et les performances de nettoyage PVS. Vous pouvez surveiller l’intégrité de PVS à l’aide des méthodes décrites dans Résoudre les problèmes de récupération de base de données accélérée.

Si vous avez une charge de travail avec un volume élevé d’instructions DML (INSERT, UPDATE, DELETE, MERGE), comme l'OLTP à haut volume, cela peut nécessiter une période de repos ou de récupération pour que le processus de nettoyage PVS puisse récupérer de l’espace. En règle générale, les cycles d’opération métier permettent cette période, mais dans certains scénarios, vous pouvez lancer manuellement le processus de nettoyage PVS pour tirer parti des modèles d’activité d’application.

  • Pour activer manuellement le processus de nettoyage PVS entre les charges de travail ou pendant les fenêtres de maintenance, utilisez la procédure stockée sys.sp_persistent_version_cleanup.

  • Si le processus de nettoyage PVS est en cours d’exécution pendant une longue période, vous pouvez constater que le nombre de transactions abandonnées augmente, ce qui entraîne également l’augmentation de la taille du PVS. Utilisez la sys.dm_tran_aborted_transactions DMV pour signaler le nombre de transactions abandonnées et utilisez sys.dm_tran_persistent_version_store_stats pour signaler les heures de début/de fin du nettoyage, ainsi que la taille pvS.

  • Les charges de travail présentant des requêtes longues utilisant l'isolation SNAPSHOT, ou l'isolation READ COMMITTED lorsque l’option de base de données READ_COMMITTED_SNAPSHOT (RCSI) est activée peuvent retarder le nettoyage PVS pour toutes les bases de données sur une instance de moteur de base de données, ce qui entraîne une augmentation de la taille de PVS. Pour plus d’informations, consultez la section sur les longues analyses d’instantanés actives dans Résoudre les problèmes de récupération de base de données accélérée.

Contenu connexe