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 Instance SQL 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 durables, grâce à une reconception du processus de récupération du moteur de base de données SQL.

ADR a été introduit dans SQL Server 2019 (15.x) et amélioré dans SQL Server 2022 (16.x). La récupération de base de données accélérée est également disponible pour les bases de données dans Azure SQL Database, Azure SQL Managed Instance et Azure Synapse SQL. ADR est activée par défaut dans SQL Database et SQL Managed Instance et ne peut pas être désactivée. Pour plus d’informations sur la règle ADR dans Azure SQL, consultez Récupération de base de données accélérée dans Azure SQL.

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

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

  Avec ADR, les transactions durables 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

  Avec la récupération de base de données accélérée, 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

  Avec la récupération de base de données accélérée, 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.

Le processus de récupération de base de données actuel

Sans la récupération de base de données accélérée, la récupération de base de données dans SQL Server suit le modèle de récupération ARIES et se compose de trois phases, qui sont illustrées dans le diagramme suivant et expliquées plus en détail après celui-ci.

• Phase d’analyse

  SQL Server effectue une analyse vers l’avant du journal des transactions à partir du début du dernier point de contrôle réussi (ou du LSN de la page de modifications la plus ancienne) jusqu’à la fin, pour déterminer l’état de chaque transaction au moment de l’arrêt de SQL Server.

• Phase de restauration par progression

  SQL Server effectue une analyse vers l’avant du journal des transactions, de la transaction non validée la plus ancienne jusqu’à la fin, pour ramener la base de données à l’état où elle se trouvait au moment du plantage en réeffectuant toutes les opérations validées.

• Phase d’annulation

  Pour chaque transaction qui était active au moment du plantage, SQL Server parcourt le journal à rebours, annulant les opérations effectuées par cette transaction.

En vertu de cette conception, 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. Ainsi, le processus de récupération SQL Server peut prendre beaucoup de temps en présence de transactions longues (comme des grosses opérations d’insertion en bloc ou des opérations de création d’index sur une grande table).

En outre, l'annulation, ou la restauration, d'une transaction volumineuse basée sur cette conception peut également durer longtemps, parce qu'elle utilise la même phase de restauration d'annulation que celle décrite précédemment.

De plus, le moteur de base de données ne peut pas tronquer le journal des transactions lorsqu'il existe des transactions durables, car leurs enregistrements correspondants dans le journal sont nécessaires pour les processus de récupération et d'annulation. Par conséquent, certains journaux de transactions deviennent très grands et consomment de grandes quantités d’espace disque.

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

L'ADR résout les problèmes ci-dessus via une reconception complète du processus de récupération du moteur de base de données pour :

• Rendre la durée de la récupération constante/instantanée en évitant d’avoir à parcourir le journal à partir de/vers le début de la transaction active la plus ancienne. Avec la récupération de base de données accélérée, le journal des transactions est traité seulement à partir du dernier point de contrôle réussi (ou du LSN de la page de modifications la plus ancienne). Ainsi, le temps de récupération n'affecte pas les transactions durables.
• Minimiser l'espace requis pour journal des transactions puisqu'il n'est plus nécessaire de traiter 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 logiques, 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 actuel. 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 le même qu'aujourd'hui, avec l'ajout de la reconstruction du SLOG (flux de journaux système) 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

    Restauration par progression à partir de sLog (de la transaction non validée la plus ancienne 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 restauration par progression à partir du journal des transactions commence au dernier point de contrôle (au lieu de la transaction non validée la plus ancienne).

• Phase d’annulation

  Avec l'ADR, la phase d'annulation se termine quasi instantanément via l'utilisation du SLOG pour annuler les opérations non versionnées, et le magasin de versions persistantes avec la restauration logique pour effectuer les annulations basées sur la version au niveau des lignes.

Vous pouvez également regarder cette vidéo de huit minutes qui explique la récupération de base de données accélérée :

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 :

• Magasin de versions persistantes

  Le magasin de versions persistantes est un mécanisme du moteur de base de données permettant de conserver les versions des lignes générées dans la base de données elle-même, et non pas dans le magasin de versions tempdb traditionnelle. Le magasin de versions persistantes permet l’isolation des ressources et améliore la disponibilité des bases de données secondaires accessibles en lecture. Il existe un thread PVS par instance dans SQL Server 2019 (15.x). À compter de SQL Server 2022 (16.x), SQL Server dispose d'un thread de nettoyage PVS par base de données.

• 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.
  • Il est conservé sur disque en étant sérialisé pendant le processus de point de contrôle.
  • Il est tronqué régulièrement à mesure que les transactions sont validées.
  • Il accélère les opérations de restauration par progression et d'annulation en ne traitant que les opérations non versionnées.
  • 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.

Améliorations de l'ADR dans SQL Server 2022 (16.x)

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 (16.x).

• Nettoyage des transactions utilisateur

  Effacez les pages qui n'ont pas pu être nettoyées par le processus normal en raison d'un échec de verrouillage.

  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éduction de l’empreinte mémoire pour le suivi de page PVS

  Cette amélioration suit les pages de magasin de versions persistantes (PVS) au niveau de l’étendue, afin de réduire l’empreinte mémoire nécessaire pour maintenir les pages de versions gérées.

• Améliorations de la récupération de données accélérées (ADR)

  Le nettoyage de récupération de données accélérée (ADR) a amélioré l’efficacité du nettoyage des versions pour améliorer la façon dont SQL Server effectue le suivi et les enregistrements des versions abandonnées d’une page, ce qui entraîne des améliorations de la mémoire et de la capacité.

• Magasin de versions persistant au niveau de la transaction (PVS)

  Cette amélioration permet à ADR de nettoyer les versions appartenant aux transactions validées indépendamment de l’abandon des transactions dans le système. Avec cette amélioration, les pages du magasin de versions persistantes (PVS) peuvent être libérées, même si le nettoyage ne peut pas effectuer avec succès un balayage afin de découper la carte de la transaction abandonnée.

  Le résultat de cette amélioration est une croissance réduite du magasin de versions persistant (PVS), même si le nettoyage ADR est lent ou échoue.

• Nettoyage de version multithread

  Dans SQL Server 2019 (15.x), le processus de nettoyage est un thread unique dans une instance SQL.

  À compter de SQL Server 2022 (16.x), ce processus utilise un nettoyage de version multithread. Cela permet de nettoyer en parallèle plusieurs bases de données dans la même instance de SQL Server. Cette amélioration est précieuse lorsque vous disposez de plusieurs bases de données volumineuses.

  Pour ajuster le nombre de threads afin d'assurer la scalabilité du nettoyage de la version, définissez ADR Cleaner Thread Count à sp_configure. Le nombre de threads est plafonné au nombre de cœurs de l'instance.

  Nous vous recommandons d'utiliser autant de threads de nettoyage ADR que vous avez de bases de données. Par exemple, si vous configurez ADR Cleaner Thread Count à 4 sur une instance SQL Server avec deux bases de données, le nettoyeur ADR n'allouera toujours qu'un thread par base de données, laissant les deux threads restants inactifs.

  L'exemple ci-dessous modifie le nombre de threads à 4 :

  EXEC sp_configure 'ADR Cleaner Thread Count', '4';
  RECONFIGURE WITH OVERRIDE; 
  

• Nouvel événement étendu

  Un nouvel événement étendu, tx_mtvc2_sweep_stats, a été ajouté pour la télémétrie sur le nettoyeur de la version multithread de l'ADR PVS.

Meilleures pratiques et conseils

Pour obtenir des conseils sur les charges de travail qui sont recommandées ou non pour l'ADR, consultez Gérer la récupération de la base de données accélérée.

Important

Dans Azure SQL Database, les transactions inactives (transactions qui n'ont pas écrit dans le journal des transactions pendant six heures) sont automatiquement arrêtées pour libérer des ressources.

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
• Récupération de base de données accélérée dans Azure SQL