Récupération de base de données accélérée

S’applique à : SQL Server 2019 (15.x) et versions ultérieures Azure SQL Database Instance Gérée Azure SQL Base de données SQL dans Microsoft Fabric

La récupération de base de données accélérée améliore la disponibilité des bases de données, notamment en présence de transactions longues, grâce à une reconception du processus de récupération du moteur de base de données.

ADR a été introduit dans SQL Server 2019 (15.x) et amélioré dans SQL Server 2022 (16.x) et SQL Server 2025 (17.x). ADR est également disponible dans Azure SQL Database, Azure SQL Managed Instance, Azure Synapse Analytics (pool SQL dédié uniquement) et la base de données SQL dans Microsoft Fabric.

Note

L’ADR est toujours activé dans Azure SQL Database, Azure SQL Managed Instance et dans la base de données SQL dans Fabric.

Cet article offre une vue d’ensemble de l’ADR. Pour travailler avec ADR, passez en revue Gérer la récupération de base de données accélérée.

Pour plus d’informations sur la récupération du journal des transactions et de la base de données, consultez le Guide de gestion et d’architecture du journal des transactions SQL Server, ainsi que Vue d’ensemble de la restauration et de la récupération (SQL Server).

Overview

Les principaux avantages de la récupération de base de données accélérée sont les suivants :

Récupération de base de données rapide et cohérente

Les transactions longues n’ont pas d’impact sur le temps de récupération global, ce qui permet une récupération rapide et cohérente des bases de données, quel que soit le nombre de transactions actives dans le système ou la taille de ces transactions.
Annulation instantanée des transactions

L’annulation des transactions est instantanée, quelle que soit la durée d’activité de la transaction ou le nombre de mises à jour effectuées.
Troncation agressive du journal

Le journal des transactions est tronqué de façon agressive, même en présence de transactions longues, ce qui l’empêche de croître hors de contrôle.

Processus de récupération de base de données traditionnel

Sans l’ADR, la récupération de base de données suit le modèle de récupération ARIES et comporte trois phases, qui sont illustrées dans le schéma suivant et expliquées ensuite de façon plus détaillée :

Phase d’analyse

Le moteur de base de données effectue une analyse progressive du journal des transactions depuis le début du dernier point de contrôle réussi (ou du numéro de séquence de journal de page le plus ancien (LSN)) jusqu’à la fin, afin de déterminer l’état de chaque transaction au moment de l'arrêt du moteur.
Phase de réexécution

Le moteur de base de données effectue une analyse en avant du journal des transactions, en commençant par la transaction non validée la plus ancienne jusqu'à la fin. Ce processus rétablit toutes les opérations validées pour restaurer la base de données à son état au moment de l’incident.
Annuler la phase

Pour chaque transaction qui était active au moment du plantage, le moteur de base de données parcourt le journal vers l’arrière, en annulant les opérations effectuées par cette transaction.
Avec le processus de récupération de base de données traditionnel, la récupération après un incident peut prendre beaucoup de temps si une transaction longue était active.

Le temps nécessaire au moteur de base de données pour effectuer une récupération à partir d’un redémarrage inattendu est (à peu près) proportionnel à la taille de la transaction active la plus longue dans le système au moment du plantage. La récupération nécessite l’annulation de toutes les transactions incomplètes. Le temps nécessaire est proportionnel au travail effectué par la transaction et à la durée pendant laquelle elle a été active.
L’annulation ou la restauration d'une transaction volumineuse peut prendre beaucoup de temps, car elle utilise la même phase de récupération d'annulation que celle décrite précédemment.
Le moteur de base de données ne peut pas tronquer le journal des transactions lorsqu’il existe des transactions longues, car leurs enregistrements de journal correspondants sont nécessaires pour les processus de récupération et de restauration. Par conséquent, le journal des transactions peut devenir très volumineux et consommer beaucoup d’espace de stockage.

Le processus de récupération de base de données accélérée

L’ADR résout les problèmes précédents liés au modèle de récupération traditionnel en remaniant complètement le processus de récupération du moteur de base de données pour :

Rendre le temps de récupération constant puisqu'il n'est plus nécessaire de parcourir le journal des transactions depuis le début de la plus ancienne transaction active. Avec ADR, le journal des transactions est traité uniquement à partir du dernier point de contrôle réussi (ou du LSN de la page sale la plus ancienne). Par conséquent, le temps de récupération n’est pas affecté par les transactions de longue durée et est généralement instantané.
Minimiser l’espace nécessaire au journal des transactions, car il n’est plus nécessaire de conserver le journal pour l’ensemble de la transaction. Ainsi, le journal des transactions peut être tronqué de façon agressive à mesure que des points de contrôle et des sauvegardes se produisent.

À un niveau plus général, la récupération de base de données accélérée permet de récupérer rapidement la base de données en gérant des versions pour toutes les modifications physiques de la base de données et en annulant seulement les opérations non versionnées, qui sont limitées et peuvent être annulées quasi instantanément. Les transactions qui étaient actives au moment d’un plantage sont marquées comme abandonnées, et les versions générées par ces transactions peuvent donc être ignorées par les requêtes utilisateur simultanées.

Le processus de récupération de base de données accélérée a les trois mêmes phases que le processus de récupération traditionnel. Le fonctionnement de ces phases avec la récupération de base de données accélérée est illustré dans le diagramme suivant :

Phase d’analyse

Le processus reste identique au modèle de récupération traditionnel avec l’ajout de la reconstruction du flux de journal secondaire (SLOG) et la copie des enregistrements de journal pour les opérations non versionnées.
Phase de réexécution

Divisée en deux sous-phases
- Sous-phase 1
  
  Refaire à partir de SLOG (depuis la plus ancienne transaction non validée jusqu'au dernier point de contrôle). La restauration par progression est une opération rapide, car elle ne doit traiter que quelques enregistrements du SLOG.
- Sous-phase 2
  
  La reprise à partir du journal des transactions commence au dernier point de contrôle réussi (plutôt qu'à partir de la transaction non validée la plus ancienne).
Annuler la phase

La phase d’annulation avec ADR se termine presque instantanément, utilisant SLOG pour annuler les opérations non versionnées et le magasin de versions persistantes (PVS) qui utilise un rétablissement logique pour effectuer une annulation au niveau des lignes, basée sur les versions.

Pour obtenir une explication de la récupération accélérée de la base de données, regardez cette vidéo de huit minutes :

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

Les quatre composants principaux de la récupération de base de données accélérée sont les suivants :

stockage des versions persistantes (PVS)

Le magasin de versions persistantes (PVS) est un mécanisme de moteur de base de données permettant de conserver les versions de lignes dans la base de données elle-même plutôt que dans le magasin de versions traditionnel de la base de données tempdb. Le magasin de versions persistantes permet l’isolation des ressources et améliore la disponibilité des bases de données secondaires accessibles en lecture.

PVS stocke les versions de ligne directement sur les pages de données en cours de modification ou dans une table système distincte. Pour plus d'informations, voir Espace utilisé par le magasin de versions persistantes (PVS).
Retour logique

Le rétablissement logique est le processus asynchrone responsable de l’exécution de l’annulation basée sur la version au niveau des lignes, qui fournit l’annulation instantanée des transactions et l’annulation pour toutes les opérations versionnées.
- Effectue le suivi de toutes les transactions abandonnées
- Effectue une annulation en utilisant le magasin de versions persistantes pour toutes les transactions utilisateur
- Libère tous les verrous immédiatement après l’abandon de la transaction
SLOG

Le SLOG est un flux de journal en mémoire secondaire qui stocke les enregistrements de journal pour les opérations non versionnées (comme l'invalidation du cache de métadonnées, les acquisitions de verrou, etc.). Le sLog présente les caractéristiques suivantes :
- Il est de faible volume et en mémoire.
- Persisté sur le disque pendant le processus de point de contrôle
- Il est tronqué régulièrement à mesure que les transactions sont validées.
- Accélère la restauration et l'annulation en traitant uniquement les opérations sans version
- Il permet la troncation agressive du journal des transactions en conservant seulement les enregistrements nécessaires du journal.
Cleaner

Le nettoyeur est le processus asynchrone qui sort de veille régulièrement et nettoie les versions de lignes obsolètes du PVS.

Charges de travail qui tirent parti de l’ADR

ADR bénéficie à la plupart des charges de travail en améliorant la disponibilité de la base de données, et est particulièrement bénéfique pour les charges de travail qui ont :

Transactions longues durées
Transactions actives qui entraînent l’augmentation significative du journal des transactions.
Longues périodes d'indisponibilité de la base de données en raison d'une récupération longue durée (par exemple en cas de redémarrage inattendu du service ou d'annulation manuelle d'une transaction).

Les avantages de l’ADR nécessitent un stockage de version et un traitement supplémentaire, ce qui peut entraîner une surcharge de performances pour certaines charges de travail. Par exemple, avec des charges de travail nécessitant beaucoup d’écriture qui génèrent de nombreuses versions de lignes, les pages de données peuvent être fractionnées plus souvent pour prendre en charge les versions en ligne . Étant donné que toutes les versions de ligne sont journalisées, la quantité de journal des transactions générée peut également augmenter.

Pour la plupart des charges de travail, la surcharge de performances de l'ADR va de non détectable à mineure. Dans une stratégie de gestion de base de données optimale, vous équilibrez les avantages de l’ADR par rapport à la surcharge potentielle des performances.

ADR n'est pas pris en charge dans les bases de données utilisant la mise en miroir de base de données , une ancienne fonctionnalité de haute disponibilité qui est maintenant déconseillée.

Bonnes pratiques en matière de MARC

Évitez les transactions longues et inutiles. Bien que l’ADR accélère la récupération de bases de données même avec des transactions longues, ces transactions peuvent retarder le nettoyage de version et augmenter la taille PVS.
Évitez les transactions volumineuses qui incluent des opérations DDL. L’ADR utilise le mécanisme SLOG (Secondary Log Stream) pour suivre les opérations DDL utilisées dans la récupération. Le SLOG n’est utilisé que pendant que la transaction est active. SLOG est mis en point de contrôle, donc éviter les transactions volumineuses qui utilisent SLOG peut aider les performances globales. Ces scénarios peuvent entraîner une plus grande utilisation de l’espace par le SLOG.
- De nombreuses opérations DDL sont exécutées dans une transaction. Par exemple, dans une seule transaction, la création et la suppression rapides de tables temporaires.
- Une table comporte un très grand nombre de partitions/index qui sont modifiés. Par exemple, une opération de DROP TABLE sur une telle table nécessiterait une allocation importante de mémoire SLOG, ce qui retarderait la troncation du journal des transactions et ralentirait les opérations d'annulation/réexécution. En guise de solution, supprimez les index individuellement et progressivement, puis supprimez la table.
Pour plus d’informations sur SLOG, consultez les Composants de Récupération ADR .
Empêchez ou réduisez les transactions abandonnées inutiles. Un taux d’abandon élevé des transactions exerce une pression sur le processus de nettoyage PVS et réduit les performances ADR. Les abandons peuvent provenir d’un taux élevé d’interblocages, de clés en double, de violations de contraintes, de délais d’expiration de requête ou d’autres exceptions. La DMV sys.dm_tran_aborted_transactions affiche toutes les transactions abandonnées sur l’instance du moteur de base de données. La colonne nested_abort indique que la transaction a été validée, mais qu’il existe des sections annulées (points de reprise ou transactions imbriquées) qui peuvent également retarder le processus de nettoyage PVS.
Assurez-vous que la base de données dispose de suffisamment d’espace pour l’utilisation du magasin de versions persistantes (PVS). Si la base de données n’a pas suffisamment de place pour que le PVS augmente, l’ADR risque de ne pas générer de versions, ce qui entraîne l’échec des instructions DML.
Quand l’ADR est activé avec des charges de travail nécessitant beaucoup d’écriture, le taux de génération du journal des transactions peut augmenter considérablement, car les versions de lignes écrites dans le PVS sont journalisées. Cela peut augmenter la taille des sauvegardes de journal des transactions.
Lorsque vous utilisez la réplication transactionnelle , la réplication d'instantanés ou la capture de données modifiées (CDC) , le comportement agressif de troncation du journal de l'ADR est désactivé pour permettre au lecteur de journal de collecter les modifications du journal des transactions. Assurez-vous que le journal des transactions est suffisamment volumineux.

Si vous utilisez CDC ou un flux de modification dans Azure SQL Database, vous devrez peut-être augmenter votre niveau de service ou votre taille de calcul pour vous assurer que suffisamment d’espace de journal de transactions est disponible pour les besoins de toutes vos charges de travail. De même, dans Azure SQL Managed Instance, vous devrez peut-être augmenter la taille de stockage maximale de votre instance.
Pour SQL Server, lorsque le stockage hiérarchisé des performances est disponible, envisagez de placer le groupe de fichiers PVS sur un stockage de niveau supérieur. Pour plus d’informations, consultez Modifier le groupe de fichiers PVS.
À partir de SQL Server 2022 (16.x), envisagez d’activer le nettoyage PVS multithread si les performances du nettoyeur à thread unique sont insuffisantes. Pour plus d’informations, consultez Configuration du serveur : NOMBRE de threads de nettoyage ADR.
À compter de SQL Server 2025 (17.x), si vous activez ADR dans tempdb, vous devrez peut-être allouer de l’espace supplémentaire pour les données PVS dans les tempdb fichiers de données. La taille des PVS dans tempdb peut être surveillée de la même façon que dans une base de données utilisateur.
Si vous observez des problèmes tels qu'une utilisation élevée de l'espace de base de données par PVS ou un lent nettoyage de PVS, consultez pour la surveillance et la résolution des problèmes liés à la récupération accélérée de base de données.

Améliorations de l’ADR dans SQL Server 2025

ADR dans tempdb

À compter de SQL Server 2025 (17.x), ADR peut être activé dans la base de données tempdb.

Sans ADR, et même avec une journalisation minimale utilisée dans tempdb, les transactions impliquant des objets tels que des tables temporaires, des variables de table ou des tables non temporaires créées peuvent tempdb être affectées par une restauration longue et une utilisation élevée du journal des transactions. L’épuisement de l’espace du journal des tempdb transactions peut entraîner des interruptions importantes et des temps d’arrêt d’application.

SQL Server 2025 (17.x) offre la restauration instantanée des transactions et les avantages de la troncature agressive du journal pour les charges de travail utilisant des transactions dans tempdb.

Pour activer ADR dans tempdb, consultez Activer ADR.

Améliorations de l’ADR dans SQL Server 2022

Plusieurs améliorations ont été apportées pour optimiser le stockage du magasin PVS (Persistent Version Store) et accroître la scalabilité globale. Pour plus d’informations sur les nouvelles fonctionnalités de SQL Server 2022 (16.x), consultez Nouveautés de SQL Server 2022.

Les mêmes améliorations sont également disponibles dans Azure SQL Database, Azure SQL Managed Instance, Azure Synapse Analytics (pool SQL dédié uniquement) et la base de données SQL dans Microsoft Fabric.

Nettoyage des transactions utilisateur

Nettoyer les pages qui ne peuvent pas être nettoyées par le processus normal à cause d’un échec d’acquisition de verrou.

Cette fonctionnalité permet aux transactions utilisateur d'exécuter le nettoyage sur les pages qui n'ont pas pu être traitées par le processus de nettoyage normal en raison de conflits de verrouillage au niveau de la table. Cette amélioration permet de s'assurer que le processus de nettoyage ADR n'échoue pas indéfiniment parce que les charges de travail utilisateur ne peuvent pas acquérir de verrous au niveau de la table.
Réduire l'empreinte mémoire pour le traqueur de pages PVS

Cette amélioration effectue le suivi des pages PVS à l'échelle de l'étendue, afin de réduire l'empreinte mémoire nécessaire à la gestion des pages versionnées.
Améliorations du nettoyeur PVS

Le nettoyeur PVS a amélioré l’efficacité du nettoyage des versions de données afin d'améliorer le suivi et l'enregistrement par le moteur de base de données des versions de lignes pour les transactions annulées. Cela entraîne des améliorations de l’utilisation de la mémoire et du stockage.
magasin de versions persistantes au niveau des transactions (PVS)

Cette amélioration permet à ADR de nettoyer les versions qui appartiennent à des transactions validées, que des transactions aient été abandonnées ou non dans le système. Avec cette amélioration, les pages PVS peuvent être libérées, même si le nettoyage ne peut pas terminer un balayage réussi pour découper la carte de transactions abandonnée.

Le résultat de cette amélioration est que la croissance de PVS est réduite, même si le nettoyage de PVS est lent ou échoue.
Nettoyage de version multithread

Dans SQL Server 2019 (15.x), le processus de nettoyage est un thread unique au sein d’une instance du moteur de base de données.

À partir de SQL Server 2022 (16.x), le nettoyage de versions multithreadé est pris en charge. Cela permet à plusieurs bases de données sur la même instance du moteur de base de données d’être nettoyées en parallèle, ou une base de données unique doit être nettoyée plus rapidement. Pour plus d’informations, consultez Configuration du serveur : NOMBRE de threads de nettoyage ADR.

Un nouvel événement étendu, tx_mtvc2_sweep_stats, a été ajouté pour la surveillance du nettoyeur de version multithread de ADR PVS.

Rétroaction

Cette page vous a-t-elle été utile ?

Last updated on 2025-11-26