Durabilité pour les tables mémoire optimisées

S'applique à :SQL Server

OLTP en mémoire fournit la durabilité complète pour les tables optimisées en mémoire. Lorsqu’une transaction qui a modifié une table optimisée en mémoire valide, SQL Server (comme pour les tables sur disque), garantit que les modifications sont permanentes (elles survivent à un redémarrage de base de données), à condition que le stockage sous-jacent soit disponible. Il existe deux composantes clés de durabilité : l'enregistrement des transactions et la conservation des modifications de données dans un stockage sur disque.

Pour plus d’informations sur les éventuelles limitations de taille des tables durables, consultez Estimation des besoins en mémoire pour les tables optimisées pour la mémoire.

Journal des transactions

Toutes les modifications apportées aux tables sur disque ou aux tables optimisées en mémoire durables sont capturées dans un ou plusieurs enregistrements de journaux des transactions. Lorsqu'une transaction est validée, SQL Server écrit les enregistrements de journal associés à la transaction sur le disque avant d'indiquer à l'application ou à la session utilisateur que la transaction a été validée. Cela garantit que les modifications apportées par la transaction sont durables. Le journal des transactions pour les tables optimisées en mémoire est entièrement intégré au même flux du journal utilisé par les tables sur disque. Cette intégration permet aux opérations existantes de sauvegarde, de récupération et de restauration du journal des transactions de continuer à fonctionner sans nécessiter d’étapes supplémentaires. Toutefois, étant donné que l'OLTP en mémoire peut augmenter considérablement le débit des transactions de votre charge de travail, les E/S de journal peuvent devenir un goulot d’étranglement des performances. Pour prendre en charge cette augmentation de débit, vérifiez que le sous-système d’E/S du journal peut gérer la charge accrue.

Fichiers de données et delta

Les données des tables optimisées en mémoire sont stockées en tant que lignes de données de forme libre dans une structure de données de segment de mémoire qui sont liées via un ou plusieurs index en mémoire. Il n'existe aucune structure de page pour les lignes de données, par exemple celles utilisées pour les tables sur disque. Pour la persistance à long terme et pour permettre la troncation du journal de transactions, les opérations sur les tables optimisées en mémoire sont conservées dans un jeu de fichiers de données et delta. Ces fichiers sont générés selon le journal des transactions, à l’aide d’un processus asynchrone en arrière-plan. Les fichiers de données et les fichiers delta se trouvent dans un ou plusieurs conteneurs (utilisant le même mécanisme que celui utilisé pour les données FILESTREAM). Ces conteneurs font partie d’un groupe de fichiers optimisé en mémoire.

Les données sont écrites dans ces fichiers et générées de façon séquentielle stricte, ce qui réduit la latence sur le disque pour les supports rotatifs. Utilisez plusieurs conteneurs sur différents disques pour distribuer l'activité d'E/S. Les fichiers de données et les fichiers delta dans plusieurs conteneurs sur différents disques augmentent les performances de restauration/récupération de la base de données lorsque les données sont lues depuis ces fichiers sur le disque et chargées en mémoire.

Les transactions utilisateur n’accèdent pas directement aux données et aux fichiers delta. Toutes les opérations de lecture et d’écriture de données utilisent des structures de données en mémoire.

Fichier de données

Un fichier de données contient des lignes provenant d'une ou de plusieurs tables mémoire optimisées qui ont été insérées par plusieurs transactions dans le cadre d'opérations INSERT ou UPDATE. Par exemple, une ligne peut provenir de la table mémoire optimisée t1 et la ligne suivante de la table mémoire optimisée t2. Les lignes sont ajoutées au fichier de données dans l'ordre des transactions du journal des transactions, ce qui permet un accès séquentiel aux données. Ceci permet un meilleur ordre de grandeur pour le débit des E/S, par rapport à des E/S aléatoires.

Une fois que le fichier de données est plein, les lignes insérées par les nouvelles transactions sont stockées dans un autre fichier de données. Au fil du temps, les lignes des tables optimisées en mémoire durable sont stockées dans un de plusieurs fichiers de données et chaque fichier de données contenant des lignes forme une plage de transactions disjointe mais contiguë. Par exemple, un fichier de données dont l'horodateur de validation de transaction est dans une plage de (100, 200) contient toutes les lignes insérées par les transactions dont l'horodateur de validation est supérieur à 100 et inférieur ou égal à 200. L’horodatage de validation est un nombre monotoniquement croissant affecté à une transaction lorsqu’il est prêt à valider. Chaque transaction a un horodateur de validation unique.

Lorsqu’une ligne est supprimée ou mise à jour, la ligne n’est pas supprimée ou modifiée sur place dans le fichier de données, mais les lignes supprimées sont suivies dans un autre type de fichier : le fichier delta. Les opérations de mise à jour sont traitées comme un tuple d'opérations de suppression et d'insertion pour chaque ligne. Cela supprime les E/S aléatoires dans le fichier de données.

Taille : chaque fichier de données a une taille d’environ 128 Mo pour les ordinateurs avec une capacité de mémoire supérieure à 16 Go, et à 16 Mo pour les ordinateurs avec une capacité de mémoire inférieure ou égale à 16 Go. Dans SQL Server 2016 (13.x), SQL Server peut utiliser le mode de point de contrôle de grande taille s’il juge le sous-système de stockage assez rapide. En mode de point de contrôle de grande taille, les fichiers de données sont dimensionnés à 1 Go. Cela permet une plus grande efficacité du sous-système de stockage pour les charges de travail à débit élevé.

Fichier delta

Chaque fichier de données est couplé à un fichier delta ayant la même plage de transactions et effectue le suivi des lignes supprimées insérées par les transactions dans cette plage. Ces fichiers de données et delta sont appelés Paire de fichiers de point de contrôle (PFP), et c'est l'unité d'allocation et de désallocation, ainsi que l'unité utilisée pour les opérations de fusion. Par exemple, un fichier delta correspondant à la plage de transactions (100, 200) stocke les lignes supprimées qui ont été insérées par des transactions dans la plage (100, 200). Comme pour les fichiers de données, le fichier delta est accessible de manière séquentielle.

Lorsqu’une ligne est supprimée, la ligne n’est pas supprimée du fichier de données, mais une référence à la ligne est ajoutée au fichier delta associé à la plage de transactions où cette ligne de données a été insérée. Étant donné que la ligne à supprimer existe déjà dans le fichier de données, le fichier delta stocke uniquement les informations de référence sur {inserting_tx_id, row_id, deleting_tx_id} et suit l'ordre des opérations de suppression ou de mise à jour d'origine du journal des transactions.

Taille : chaque fichier delta a une taille d’environ 16 Mo pour les ordinateurs avec une capacité de mémoire supérieure à 16 Go, et à 1 Mo pour les ordinateurs avec une capacité de mémoire inférieure ou égale à 16 Go. Démarrage de SQL Server 2016 (13.x), SQL Server peut utiliser le mode de point de contrôle de grande taille s’il juge le sous-système de stockage assez rapide. En mode de point de contrôle de grande taille, les fichiers delta sont dimensionnés à 128 Mo.

Remplir les fichiers de données et les fichiers delta

Les fichiers de données et delta sont remplis en fonction des enregistrements du journal des transactions générés par les transactions validées sur les tables optimisées en mémoire ; des informations concernant les lignes insérées et supprimées sont ajoutées dans les fichiers de données et delta appropriés. Contrairement aux tables sur disque où les pages de données/index sont vidées avec des E/S aléatoires lorsque le point de contrôle est effectué, la persistance de la table optimisée en mémoire est une opération en arrière-plan continue. Plusieurs fichiers delta sont accédés car une transaction peut supprimer ou mettre à jour toute ligne ayant été insérée par une transaction précédente. Les informations de suppression sont toujours ajoutées à la fin du fichier delta. Par exemple, une transaction avec un horodatage de validation de 600 insère une nouvelle ligne et supprime les lignes insérées par les transactions avec un horodatage de validation de 150, 250 et 450, comme illustré dans l’image suivante. Les quatre opérations d’E/S de fichier (trois pour les lignes supprimées et 1 pour les lignes nouvellement insérées) sont des opérations d’ajout uniquement aux fichiers delta et de données correspondants.

Accéder aux données et aux fichiers delta

Les paires de fichiers de données et de fichiers delta sont accessibles lorsque les événements suivants se produisent.

Employés de point de contrôle hors ligne

Ce thread applique les modifications apportées aux lignes de données optimisées en mémoire (insertions et suppressions) dans les paires de fichiers de données et delta correspondantes. SQL Server 2014 (12.x) possède un worker de point de contrôle hors connexion. SQL Server 2016 (13.x) et versions ultérieures disposent de plusieurs agents de point de contrôle.

Opération de fusion

L'opération fusionne une ou plusieurs paires de fichiers de données et delta afin de créer une nouvelle paire de fichiers de données et delta.

Pendant une récupération sur incident

Lorsque SQL Server redémarre ou que la base de données est remise en ligne, les données mémoire optimisées sont remplies en utilisant les paires de fichiers de données et delta. Le fichier delta filtre les lignes supprimées lors de la lecture des lignes à partir du fichier de données correspondant. Dans la mesure où chaque paire de fichier de données et de fichier delta est indépendante, ces fichiers sont chargés en parallèle pour réduire le temps de chargement en mémoire des données. Une fois les données chargées en mémoire, le moteur OLTP In-Memory applique les enregistrements du journal des transactions actifs non encore couverts par les fichiers de point de contrôle afin que les données optimisées en mémoire soient terminées.

Pendant une opération de restauration

Les fichiers de point de contrôle de l'OLTP en mémoire sont créés à partir de la sauvegarde de base de données, puis une ou plusieurs sauvegardes de journal de transactions sont appliquées. Comme avec la récupération d’incident, le moteur OLTP In-Memory charge les données en mémoire en parallèle, afin de réduire l’effet sur le temps de récupération.

Fusionner des données et des fichiers delta

Les données des tables mémoire optimisées sont stockées dans une ou plusieurs paires de fichiers de données et delta (également appelées une paire de fichiers de point de contrôle, ou CFP). Les fichiers de données stockent les lignes insérées et les fichiers delta référencent les lignes supprimées. Pendant l'exécution d'une charge de travail OLTP, lorsque les opérations DML mettent à jour, insèrent et suppriment des lignes, de nouvelles paires de fichiers de point de contrôle sont créées pour rendre les nouvelles lignes persistantes, et la référence aux lignes supprimées est ajoutée aux fichiers delta.

Au fil du temps, avec les opérations DML, le nombre de fichiers de données et delta augmente, ce qui entraîne une augmentation de l’utilisation de l’espace disque et une augmentation du temps de récupération.

Pour éviter ces inefficacités, les fichiers de données et de fichiers delta fermés plus anciens sont fusionnés, en fonction d’une stratégie de fusion décrite plus loin dans cet article, de sorte que le tableau de stockage est compacté pour représenter le même jeu de données, avec un nombre réduit de fichiers.

L’opération de fusion prend comme entrée une ou plusieurs paires de fichiers de point de contrôle fermé adjacents (CFPs), qui sont des paires de fichiers de données et delta (appelées source de fusion) basées sur une stratégie de fusion définie en interne, et produit un cfp résultant, appelé cible de fusion. Les entrées dans chaque fichier delta des cfPs sources sont utilisées pour filtrer les lignes du fichier de données correspondant pour supprimer les lignes de données qui ne sont pas nécessaires. Les lignes restantes dans les paires de fichiers de point de contrôle sources sont consolidées dans une paire de fichiers de point de contrôle cible. Une fois la fusion terminée, le CFP cible de fusion résultant remplace les CFP sources de fusion. Les CFPs de fusion source passent par une phase de transition avant d'être supprimés du stockage.

Dans l’exemple suivant, le groupe de fichiers de table à mémoire optimisée contient quatre paires de données et de fichiers delta à l’horodatage 500 contenant les données des transactions précédentes. Par exemple, les lignes du premier fichier de données correspondent aux transactions avec un horodateur supérieur à 100 et inférieur ou égal à 200 ; alternativement représenté comme (100, 200]. Le deuxième et le troisième fichiers de données affichent un taux de remplissage inférieur à 50 % après prise en compte des lignes marquées comme supprimées. L'opération de fusion associe ces deux paires de fichiers de point de contrôle et crée une paire de fichiers de point de contrôle contenant des transactions avec un horodateur supérieur à 200 et inférieur ou égal à 400, qui est la plage combinée de ces deux paires de fichiers de point de contrôle. Vous voyez une autre paire de fichiers de point de contrôle avec une plage (500, 600] et un fichier delta non vide pour la plage de transactions (200, 400] indique que l'opération de fusion peut être effectuée en même temps que l'activité transactionnelle comprenant la suppression de plus de lignes des paires de fichiers de point de contrôle source.

Un thread d'arrière-plan évalue toutes les paires de fichiers de point de contrôle fermées à l'aide d'une stratégie de fusion, puis initie une ou plusieurs demandes de fusion pour les paires de fichiers de point de contrôle qualifiées. Ces demandes de fusion sont traitées par le thread de point de contrôle hors connexion. L'évaluation de la stratégie de fusion est effectuée périodiquement et lorsqu'un point de contrôle est fermé.

Stratégie de fusion SQL Server

SQL Server implémente la stratégie de fusion suivante :

• Une fusion est planifiée si deux ou plusieurs cfPs consécutifs peuvent être consolidés, après avoir pris en compte les lignes supprimées, de sorte que les lignes résultantes peuvent s’adapter à un seul CFP de taille cible. La taille cible des fichiers de données et delta correspond au dimensionnement d’origine, comme décrit précédemment.

• Une seule paire de fichiers de point de contrôle peut être fusionnée automatiquement si le fichier de données dépasse le double de la taille cible et que plus de la moitié des lignes sont supprimées. Un fichier de données peut croître plus grand que la taille cible si, par exemple, une transaction unique ou plusieurs transactions simultanées insère ou met à jour une grande quantité de données, forçant le fichier de données à augmenter au-delà de sa taille cible, car une transaction ne peut pas s’étendre sur plusieurs cfPs.

Voici quelques exemples qui montrent que les CFP doivent être fusionnés sous la politique de fusion :

Toutes les paires de fichiers de point de contrôle avec de l'espace disponible ne sont pas qualifiées pour la fusion. Par exemple, si deux CFP adjacentes sont pleines à 60%, elles ne peuvent pas être fusionnées et chacune de ces CFP a 40% de stockage inutilisé. Dans le pire des cas, toutes les CFP sont pleines à 50 %, ce qui représente une utilisation du stockage de seulement 50 %. Même si les lignes supprimées peuvent exister dans le stockage parce que les CFPs ne sont pas éligibles pour la fusion, les lignes supprimées ont peut-être déjà été retirées de la mémoire par la gestion de la mémoire en temps réel. La gestion du stockage et de la mémoire est indépendante du garbage collection. Le stockage pris par les CFP actifs (tous les CFP ne sont pas mis à jour) peut être jusqu’à deux fois la taille des tables durables dans la mémoire.

Cycle de vie d’un CFP

Les fichiers CFP traversent plusieurs états avant de pouvoir être libérés. Les points de contrôle de base de données et les sauvegardes du journal sont indispensables au passage des fichiers par les différentes phases et au nettoyage final des fichiers superflus. Pour obtenir une description de ces phases, consultez sys.dm_db_xtp_checkpoint_files.

Vous pouvez forcer manuellement le point de contrôle suivi de la sauvegarde du journal pour accélérer le garbage collection. Dans les scénarios de production, les points de contrôle automatiques et les sauvegardes de journaux effectuées dans le cadre de la stratégie de sauvegarde permettent aux PFC de traverser ces phases en toute transparence sans nécessiter d’intervention manuelle. L’effet du processus de collecte des objets inutilisés est que les bases de données comportant des tables optimisées pour la mémoire peuvent avoir une plus grande taille de stockage par rapport à leur taille en mémoire. Si les sauvegardes de point de contrôle et de journal ne se produisent pas, l’empreinte sur disque des fichiers de point de contrôle continue de croître.

Contenu connexe

• Créer et gérer le stockage pour les objets à mémoire optimisée