Durabilité pour les tables Memory-Optimized

In-Memory OLTP offre une durabilité complète pour les tables optimisées en mémoire. Lorsqu’une transaction qui a changé une table optimisée en mémoire valide, SQL Server (comme pour les tables sur disque), garantit que les modifications sont permanentes (survivront à un redémarrage de la base de données), à condition que le stockage sous-jacent soit disponible. Il existe deux composants clés de durabilité : la journalisation des transactions et la persistance des modifications de données apportées au stockage sur disque.

Journal des transactions

Toutes les modifications apportées aux tables sur disque ou aux tables optimisées en mémoire durable sont capturées dans un ou plusieurs enregistrements du journal des transactions. Lorsqu’une transaction est validée, SQL Server écrit les enregistrements de journal associés à la transaction sur le disque avant de communiquer avec l’application ou la session utilisateur validée par la transaction. Cela garantit que les modifications apportées par la transaction sont durables. Le journal des transactions pour les tables mémoire optimisées est entièrement intégré au même flux de journaux 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 In-Memory OLTP peut augmenter considérablement le débit de transaction de votre charge de travail, vous devez vous assurer que le stockage du journal des transactions est configuré de manière appropriée pour gérer les exigences d’E/S accrues.

Fichiers de données et fichiers delta

Les données des tables mémoire optimisées sont stockées sous forme de lignes de données de forme libre liées via un ou plusieurs index en mémoire, en mémoire. Il n’existe aucune structure de page pour les lignes de données, telles que celles utilisées pour les tables sur disque. Lorsque l’application est prête à valider la transaction, l'In-Memory OLTP génère les enregistrements de journal de la transaction. La persistance des tables optimisées en mémoire est effectuée avec un ensemble de données et de fichiers delta à l’aide d’un thread d’arrière-plan. Les fichiers de données et delta se trouvent dans un ou plusieurs conteneurs (à l’aide du même mécanisme utilisé pour les données FILESTREAM). Ces conteneurs sont mappés à un nouveau type de groupe de fichiers, appelé groupe de fichiers à mémoire optimisée.

Les données sont écrites dans ces fichiers de manière strictement séquentielle, ce qui réduit la latence du disque pour les supports rotatifs. Vous pouvez utiliser plusieurs conteneurs sur différents disques pour distribuer l’activité d’E/S. Les fichiers de données et delta dans plusieurs conteneurs sur différents disques augmentent les performances de récupération lorsque les données sont lues à partir des fichiers de données et delta sur le disque, vers la mémoire.

Une application n’accède pas directement aux données et aux fichiers delta. Toutes les lectures et écritures de données utilisent des données en mémoire.

Fichier de données

Un fichier de données contient des lignes d’une ou plusieurs tables mémoire optimisées qui ont été insérées par plusieurs transactions dans le cadre des opérations INSERT ou UPDATE. Par exemple, une ligne peut provenir de la table mémoire optimisée T1 et la ligne suivante peut provenir de la table mémoire optimisée T2. Les lignes sont ajoutées au fichier de données dans l’ordre des transactions dans le journal des transactions, ce qui rend l’accès séquentiel aux données. Cela permet un meilleur débit d’E/S par rapport aux E/S aléatoires. Chaque fichier de données est dimensionné environ à 128 Mo pour les ordinateurs dont la mémoire est supérieure à 16 Go et 16 Mo pour les ordinateurs dont la taille est inférieure ou égale à 16 Go. Une fois le fichier de données plein, les lignes insérées par de 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 d’une plage de transactions disjointe mais contiguë. Par exemple, un fichier de données avec horodatage de validation de transaction dans la plage de (100, 200) contient toutes les lignes insérées par les transactions dont l’horodatage 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 horodatage 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 en tant que tuple d’opérations de suppression et d’insertion pour chaque ligne. Cela élimine les entrées/sorties aléatoires sur le fichier de données.

Fichier Delta

Chaque fichier de données est associé à un fichier delta qui a la même plage de transactions et suit les lignes supprimées insérées par les transactions dans la plage de transactions. Ce fichier de données et de delta est appelé Paire de Fichiers de Point de Contrôle (CFP), 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 les transactions de la plage (100, 200). Comme les fichiers de données, le fichier delta est accessible séquentiellement.

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 {inserting_tx_id, row_id, deleting_tx_id } référence et suit l’ordre de journal transactionnel des opérations de suppression ou de mise à jour d’origine.

Alimentation des fichiers de données et fichiers delta

Les données et les fichiers delta sont renseignés par un thread d’arrière-plan appelé point de contrôle hors connexion. Ce thread lit les enregistrements du journal des transactions générés par des transactions validées sur des tables mémoire optimisées et ajoute des informations sur les lignes insérées et supprimées dans les fichiers delta et de données appropriés. Contrairement aux tables sur disque où les pages de données/d’index sont vidées avec des E/S aléatoires lorsque le point de contrôle est terminé, la persistance de la table optimisée en mémoire est une opération en arrière-plan continue. Plusieurs fichiers delta sont accessibles, car une transaction peut supprimer ou mettre à jour n’importe quelle ligne 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 ci-dessous. Toutes les 4 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ès aux fichiers de données et fichiers delta

Les paires de fichiers de données et delta sont accessibles lorsque les opérations suivantes se produisent.

Thread de point de contrôle hors connexion Ce thread ajoute des insertions et supprime des lignes de données optimisées en mémoire, aux paires de fichiers delta et de données correspondantes.

Opération de fusion L’opération fusionne une ou plusieurs paires de données et de fichiers delta et crée une paire de données et de fichiers delta.

Lors de la récupération en cas d’incident lorsque SQL Server est redémarré ou que la base de données est renvoyée en ligne, les données optimisées en mémoire sont remplies à l’aide des paires de données et de fichiers delta. Le fichier delta agit comme un filtre pour les lignes supprimées lors de la lecture des lignes du fichier de données correspondant. Étant donné que chaque paire de données et de fichiers delta est indépendante, ces fichiers sont chargés en parallèle pour réduire le temps nécessaire pour remplir les données en mémoire. 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.

Lors de l’opération de restauration, les fichiers de point de contrôle OLTP In-Memory sont créés à partir de la sauvegarde de base de données, puis une ou plusieurs sauvegardes du journal des transactions sont appliquées. Comme pour la récupération après incident, le moteur OLTP In-Memory charge des données en mémoire en parallèle, afin de réduire l’impact sur le temps de remise en état.

Fusion des fichiers de 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 delta et de données (également appelées paires de fichiers de point de contrôle ou CFP). Les fichiers de données stockent les lignes insérées et les fichiers delta font référence à des lignes supprimées. Lors de l'exécution d'une charge de travail OLTP, à mesure que les opérations DML mettent à jour, insèrent et suppriment des lignes, de nouveaux CFPs sont créés pour persister les nouvelles lignes, et la référence aux lignes supprimées est ajoutée aux fichiers delta.

Les métadonnées de tous les fournisseurs de services de stockage précédemment fermés et actuellement actifs sont stockées dans une structure de tableau interne appelée tableau de stockage. Il s’agit d’un tableau fini (8 192 entrées) de PFC. Les entrées du tableau de stockage sont classées par plage de transactions. Les CFPs dans la matrice de stockage (ainsi que la fin du journal) représentent tout l'état requis sur disque pour récupérer une base de données avec des tables mémoire-optimisées.

Au fil du temps, avec les opérations DML, le nombre de CFPs augmente, ce qui entraîne l'atteinte de la capacité maximale du tableau de stockage, ce qui présente les défis suivants :

• Lignes supprimées. Les lignes supprimées restent dans le fichier de données, mais sont marquées comme supprimées dans le fichier delta correspondant. Ces lignes ne sont plus nécessaires et seront supprimées du stockage. Si les lignes supprimées n’ont pas été supprimées des CFP, elles utiliseraient inutilement de l’espace et rendraient le temps de récupération plus lent.

• Tableau de stockage complet. Lorsqu’il y a 8 000 entrées dans le tableau de stockage allouées (192 entrées du tableau sont réservées aux fusions existantes pour concurrencer ou pour vous permettre d’effectuer des fusions manuelles), aucune nouvelle transaction DML ne peut être exécutée sur des tables mémoire optimisées durables. Seules les opérations de point de contrôle et de fusion sont autorisées à consommer les entrées restantes. Cela garantit que les transactions DML ne remplissent pas le tableau et que certaines entrées du tableau sont réservées pour fusionner des fichiers existants et récupérer de l’espace dans le tableau.

• Surcharge de manipulation du tableau de stockage. Les processus internes recherchent le tableau de stockage pour obtenir des opérations telles que la recherche du fichier delta pour ajouter des informations sur une ligne supprimée. Le coût de ces opérations augmente avec le nombre d’entrées.

Pour éviter ces inefficacités, les anciennes FFC fermées sont fusionnées, en fonction d’une stratégie de fusion décrite ci-dessous, de sorte que le tableau de stockage est compacté pour représenter le même ensemble de données, avec un nombre réduit de cfPs.

La taille totale en mémoire de toutes les tables durables d’une base de données ne doit pas dépasser 250 Go. Les tables durables qui utilisent jusqu’à 250 Go de mémoire, en supposant que les opérations d’insertion, de suppression et de mise à jour nécessitent en moyenne 500 Go d’espace de stockage. 4 000 paires de fichiers de données et de fichiers delta dans le groupe de fichiers à mémoire optimisée sont nécessaires pour prendre en charge les 500 Go d’espace de stockage.

Les pics à court terme dans l’activité de base de données peuvent entraîner un décalage des opérations de point de contrôle et de fusion, ce qui augmente le nombre de paires de fichiers delta et de données requises. Pour prendre en charge les pics d’augmentations à court terme dans l’activité de base de données, le système de stockage peut allouer jusqu’à 8 000 paires de données et de fichiers delta jusqu’à un total de 1 To de stockage. Lorsque cette limite est atteinte, aucune nouvelle transaction n’est autorisée sur la base de données jusqu’à ce que les opérations de point de contrôle se rattrapent. Si la taille des tables durables en mémoire dépasse 250 Go pendant de longues périodes, il est possible d’atteindre la limite de 8 000 paires de fichiers.

L’opération de fusion prend comme entrée une ou plusieurs adresses DEP fermées adjacentes (appelées source de fusion) en fonction d’une stratégie de fusion définie en interne et produit un cfp résultant, appelé cible de fusion. Les entrées de chaque fichier delta des CFP source sont utilisées pour filtrer les lignes du fichier de données correspondant afin de retirer les lignes de données qui ne sont pas nécessaires. Les lignes restantes dans les fournisseurs de services de configuration source sont consolidées dans un seul cfp cible. Une fois la fusion terminée, le CFP cible de fusion résultant remplace les cfPs sources (sources de fusion). Les fournisseurs de services de fusion source passent par une phase de transition avant qu’ils ne soient supprimés du stockage.

Dans l’exemple ci-dessous, le groupe de fichiers de table à mémoire optimisée contient quatre paires de données et de fichiers delta au timestamp 500 contenant les données des transactions précédentes. Par exemple, les lignes du premier fichier de données correspondent aux transactions dont l’horodatage est supérieur à 100 et inférieur ou égal à 200 ; également représenté comme (100, 200]. Les deuxième et troisième fichiers de données sont affichés comme étant inférieurs à 50 % complets après avoir comptabilisé les lignes marquées comme supprimées. L’opération de fusion combine ces deux cfPs et crée un nouveau CFP contenant des transactions avec horodatage supérieur à 200 et inférieur ou égal à 400, qui est la plage combinée de ces deux cfPs. Vous voyez un autre CFP avec une plage de données (500, 600] et un fichier delta non vide pour la plage de transactions (200, 400]. Cela montre que l'opération de fusion peut être exécutée simultanément avec l'activité transactionnelle, y compris la suppression de lignes supplémentaires des CFPs sources.

Un thread d’arrière-plan évalue toutes les FFC fermées à l’aide d’une stratégie de fusion, puis lance une ou plusieurs demandes de fusion pour les fournisseurs de services de configuration éligibles. 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 régulièrement et également lorsqu’un point de contrôle est fermé.

Stratégie de fusion SQL Server 2014 (12.x)

SQL Server 2014 (12.x) implémente la stratégie de fusion suivante :

• Une fusion est planifiée si 2 cfPs consécutifs ou plus peuvent être consolidés, après avoir comptabilisé les lignes supprimées, de sorte que les lignes résultantes peuvent s’adapter à 1 CFP de taille idéale. La taille idéale de CFP est déterminée comme suit :

  • Si un ordinateur a moins ou égal à 16 Go de mémoire, le fichier de données est de 16 Mo et le fichier delta est de 1 Mo.

  • Si un ordinateur a plus de 16 Go de mémoire, le fichier de données est de 128 Mo et le fichier delta est de 16 Mo.

• Un seul CFP peut être fusionné automatiquement si le fichier de données dépasse 256 Mo et plus de la moitié des lignes sont supprimées. Un fichier de données peut augmenter de plus de 128 Mo 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 idéale, car une transaction ne peut pas s’étendre sur plusieurs cfPs.

Voici quelques exemples qui montrent les cfPs qui seront fusionnés sous la stratégie de fusion :

Tous les CFPs ayant de l'espace disponible ne sont pas forcément éligibles pour être fusionnés. Par exemple, si deux CFP adjacents sont complets à 60%, ils ne répondront pas aux critères de fusion et chacun de ces CFP aura 40% de stockage inutilisé. Dans le pire des cas, tous les CFP seront remplis à 50%, ce qui représente une utilisation de stockage de seulement 50%. Même si les lignes supprimées sont toujours présentes dans le stockage parce que les CFPs ne sont pas éligibles à la fusion, elles ont peut-être déjà été retirées de la mémoire par le ramassage de mémoire en mémoire. La gestion du stockage et de la mémoire est indépendante de la gestion de la collecte des déchets. Le stockage pris par les CFP actifs (tous les CFP ne sont pas mis à jour) peut être jusqu'à deux fois plus grand que la taille des tables durables en mémoire.

Si nécessaire, une fusion manuelle peut être effectuée explicitement en appelant sys.sp_xtp_merge_checkpoint_files (Transact-SQL).

Cycle de vie d’un CFP

Les CPFs passent par plusieurs états avant de pouvoir être désalloués. À tout moment, les CFP se trouvent dans l’une des phases suivantes : PRÉCRÉÉ, EN CONSTRUCTION, ACTIF, CIBLE DE FUSION, SOURCE FUSIONNÉE, REQUIS POUR SAUVEGARDE/HA, EN TRANSITION VERS LA TOMBE et TOMBE. Pour obtenir une description de ces phases, consultez sys.dm_db_xtp_checkpoint_files (Transact-SQL).

Après avoir pris en compte le stockage pris par les fournisseurs de solutions cloud dans différents états, le stockage global pris par des tables optimisées en mémoire durable peut être beaucoup plus élevé que 2 fois la taille des tables en mémoire. La DMV sys.dm_db_xtp_checkpoint_files (Transact-SQL) peut être interrogée pour répertorier tous les cfPs dans le groupe de fichiers à mémoire optimisée, y compris leur phase. La transition des CFPs de l’état MERGE SOURCE vers l'état TOMBSTONE, et finalement vers la collecte des déchets, peut nécessiter jusqu'à cinq points de contrôle, chacun suivi d’une sauvegarde du journal des transactions, si la base de données est configurée pour un modèle de récupération complet ou en journalisation en bloc.

Vous pouvez forcer manuellement le point de contrôle suivi de la sauvegarde du journal pour accélérer le nettoyage de mémoire, mais cela ajoutera alors 5 CFPs vides (5 paires de fichiers données/delta avec un fichier de données de taille 128 Mo chacun). 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 assurent la transition fluide des CFP à travers ces phases sans nécessiter d’intervention manuelle. L’impact du processus de ramasse-miettes est que les bases de données avec des tables optimisées pour la mémoire peuvent avoir une taille de stockage supérieure par rapport à leur taille en mémoire. Il n’est pas rare que les CFPs soient jusqu’à quatre fois plus grandes que les tables optimisées en mémoire durables.

Voir aussi

Création et gestion du stockage pour les objets Memory-Optimized