Partage via

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

  • Article

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 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). L’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

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

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

Diagramme du processus de récupération actuel.

  • 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 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 :

Diagramme du processus de récupération ADR.

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

  • 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 les caractéristiques suivantes :

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

L’ADR n’est pas pris en charge dans les bases de données à l’aide de la mise en miroir de bases de données, une fonctionnalité de haute disponibilité plus ancienne et déconseillée.

Meilleures pratiques pour l’ADR

  • Évitez les transactions longues et 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. 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 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.

  • 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, isolez le magasin de versions persistantes dans un groupe de fichiers sur un stockage de niveau supérieur, comme un disque SSD haut de gamme, un disque SSD avancé ou une mémoire persistante (PMEM), parfois appelée mémoire de classe de stockage (SCM). Pour plus d’informations, consultez Changer l’emplacement du magasin de versions persistantes pour 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éallocation de pages PVS en arrière-plan améliore les performances de l’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 un nettoyage lent de PVS, consultez Comment surveiller et 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