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

S’applique à : SQL Server 2019 (15.x) et versions ultérieures d’Azure SQL Database Azure SQL Managed InstanceSQL database dans Microsoft Fabric

La récupération accélérée de base de données (ADR) améliore la disponibilité de la base de données, en particulier en présence de transactions de longue durée, en redessinant le 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). 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.

Remarque

ADR est toujours activé dans Azure SQL Database, Azure SQL Managed Instance et SQL Database dans Fabric.

Cet article fournit 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 guide de gestion et d’architecture du journal des transactions SQL Server et vue d’ensemble de la restauration et de la récupération (SQL Server).

Vue d’ensemble

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 de longue durée n’affectent pas le temps de récupération global, ce qui permet une récupération de base de données rapide et cohérente, quel que soit le nombre de transactions actives dans le système ou leur taille.

• Annulation instantanée des transactions

  La restauration des transactions est instantanée, quel que soit le moment où la transaction a été active ou le nombre de mises à jour effectuées.

• Troncation agressive du journal

  Le journal des transactions est tronqué de manière agressive, même en présence de transactions de longue durée actives, ce qui l’empêche de croître hors de contrôle.

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

Sans ADR, la récupération de base de données suit le modèle de récupération ARIES et se compose de trois phases, qui sont illustrées et expliquées plus en détail dans le diagramme suivant :

• 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 restauration par progression

  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.

• Phase d’annulation

  Pour chaque transaction active au moment de l’incident, le moteur de base de données traverse le journal vers l’arrière, 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 a été active.

  Le temps de récupération du moteur de base de données à 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 de l’incident. 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 croître 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

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

• Réduisez l’espace du journal des transactions requis, 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 élevé, ADR obtient une récupération rapide de base de données en mettant en version toutes les modifications de base de données physiques et en annulant uniquement les opérations non modifiées, qui sont limitées et peuvent être annulées presque 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 ADR a les mêmes trois phases que le processus de récupération traditionnel. La façon dont ces phases fonctionnent avec ADR est illustrée 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 restauration par progression

  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). Le rétablissement est une opération rapide, car il peut uniquement être nécessaire de traiter quelques enregistrements à partir 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).

• Phase d’annulation

  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 au lieu du magasin de versions traditionnel dans 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.

• Rétablissement 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.
  • Persistant 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.

• Nettoyeur

  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

L’ADR est particulièrement utile pour les charges de travail qui ont :

• Transactions longues.
• Les 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 (par exemple, à partir d’un redémarrage inattendu du service ou d’une restauration manuelle des transactions).

Meilleures pratiques pour ADR

• Évitez les transactions longues inutiles. Bien que l’ADR accélère la récupération de base de données même avec des transactions longues, ces transactions peuvent retarder le nettoyage de version et augmenter la taille du PVS.

• Évitez les transactions volumineuses qui incluent des opérations DDL. ADR utilise le mécanisme SLOG (Secondary Log Stream) pour suivre les opérations DDL utilisées dans la récupération. SLOG est utilisé uniquement 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 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. Pour contourner ce problème, 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 nettoyeur PVS et réduit les performances ADR. Les abandons peuvent provenir d’un taux élevé de blocages, de clés en double, de violations de contraintes ou de délais d’expiration de requête. 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.

• Vérifiez qu’il y a suffisamment d’espace dans la base de données pour tenir compte de l’utilisation de PVS. Si la base de données n’a pas suffisamment de place pour que PVS augmente, ADR risque de ne pas générer de versions, ce qui entraîne l’échec des instructions DML.

• Quand 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 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.

  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 des 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, isolez le magasin de versions PVS sur un groupe de fichiers sur un stockage de niveau supérieur, tel que ssd haut de gamme ou SSD avancé ou mémoire persistante (PMEM), parfois appelé mémoire de classe de stockage (SCM). Pour plus d’informations, consultez Modifier l’emplacement du PVS en un autre groupe de fichiers.

• Pour SQL Server, surveillez le journal des erreurs pour les entrées de type PreallocatePVS. Si des entrées PreallocatePVS sont présentes, vous devrez peut-être augmenter la capacité du ADR de préallouer des pages à l’aide d’une tâche en arrière-plan. La préaffectation de pages PVS en arrière-plan améliore les performances ADR en réduisant les allocations PVS de premier plan plus coûteuses. Vous pouvez utiliser la configuration du serveur ADR Preallocation Factor pour augmenter ce montant. Pour plus d’informations, consultez Configuration du serveur : Facteur de préallocation ADR.

• Pour SQL Server 2022 (16.x) et versions ultérieures, envisagez d’activer le nettoyage PVS multithread si les performances de nettoyage à thread unique sont insuffisantes. Pour plus d’informations, consultez Configuration du serveur : NOMBRE de threads de nettoyage ADR.

• Si vous observez des problèmes tels que l’utilisation élevée de l’espace de base de données par PVS ou le nettoyage PVS lent, consultez Résoudre les problèmes de récupération de base de données accélérée.

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.

Contenu connexe

• Gérer la récupération de base de données accélérée
• Résoudre les problèmes de la récupération de base de données accélérée