Restauration et récupération des tables Memory-Optimized

Le mécanisme de base pour récupérer ou restaurer une base de données avec des tables mémoire optimisées est similaire aux bases de données avec uniquement des tables sur disque. Toutefois, contrairement aux tables basées sur disque, les tables optimisées en mémoire doivent être chargées en mémoire avant que la base de données soit disponible pour l’accès utilisateur. Cela ajoute une nouvelle étape dans la récupération de base de données. Les étapes modifiées de la récupération de base de données sont modifiées comme suit :

Lorsque SQL Server redémarre, chaque base de données passe par une phase de récupération qui se compose des trois phases suivantes :

1. Phase d’analyse. Au cours de cette phase, une passe est effectuée sur les journaux de transactions actifs pour détecter les transactions validées et non validées. Le In-Memory moteur OLTP identifie le point de contrôle pour charger et précharger ses entrées de journal de table système. Il traitera également certains enregistrements du journal d’allocation de fichiers.

2. Phase de rétablissement. Cette phase s’exécute simultanément sur des tables optimisées en mémoire et sur disque.

   Pour les tables sur disque, la base de données est déplacée vers le point actuel dans le temps et acquiert des verrous pris par des transactions non validées.

   Pour les tables optimisées pour la mémoire, les données provenant des paires de fichiers de données et de delta sont chargées en mémoire, puis les données sont mises à jour avec le journal des transactions actif, sur la base du dernier point de contrôle durable.

   Une fois les opérations ci-dessus effectuées sur des tables optimisées en mémoire et sur disque, la base de données est disponible pour l’accès.

3. Phase de retour en arrière. Dans cette phase, les transactions non validées sont annulées.

Le chargement de tables optimisées en mémoire peut affecter les performances de l’objectif de temps de récupération (RTO). Pour améliorer le temps de chargement des données optimisées en mémoire à partir de données et de fichiers delta, le moteur OLTP In-Memory charge les fichiers de données/delta en parallèle comme suit :

• Création d’un filtre de carte delta. Les fichiers Delta stockent les références aux lignes supprimées. Un thread par conteneur lit les fichiers delta et crée un filtre de carte delta. (Un groupe de fichiers de données à mémoire optimisée peut avoir un ou plusieurs conteneurs.)

• Diffuser en continu les fichiers de données. Une fois le filtre delta-map créé, les fichiers de données sont lus en utilisant autant de threads qu’il existe de processeurs logiques. Chaque thread lisant le fichier de données lit les lignes de données, vérifie la carte delta associée et insère uniquement la ligne dans la table si cette ligne n’a pas été marquée comme supprimée. Cette partie de la récupération peut être liée au processeur dans certains cas, comme indiqué ci-dessous.

Les tables optimisées en mémoire peuvent généralement être chargées en mémoire à la vitesse d’E/S, mais dans certaines situations, le chargement des lignes de données en mémoire peut être plus lent. Les cas spécifiques sont les suivants :

• Un faible nombre de buckets pour l’index de hachage peut entraîner des collisions excessives, ce qui ralentit les insertions de lignes de données. Cela entraîne généralement une utilisation très élevée du processeur tout au long, et en particulier vers la fin de la récupération. Si vous avez configuré correctement l’index de hachage, il ne doit pas avoir d’impact sur le temps de récupération.

• Les tables à mémoire optimisée avec un ou plusieurs index non cluster, contrairement à un index de hachage dont le nombre de compartiments est dimensionné au moment de la création, les index non cluster augmentent dynamiquement, ce qui entraîne une utilisation élevée du processeur.

Restauration d’une base de données avec des tables mémoire optimisées

Vous savez que vous avez suffisamment de mémoire sur le serveur pour restaurer une base de données, mais il est nécessaire que la mémoire nécessaire par la base de données soit prise en compte dans le cadre d’un pool de ressources existant. Vous savez que vous ne pouvez pas créer la liaison au pool de ressources avant l’existence de la base de données, de sorte que vous effectuez la restauration WITH NORECOVERY. Cela entraîne la restauration de l’image disque de la base de données et la création de la base de données, mais aucune In-Memory mémoire OLTP n’est consommée, car la base de données n’est pas mise en ligne.

À ce stade, vous pouvez créer la liaison du pool de ressources à la base de données, puis utiliser "RESTORE WITH RECOVERY" pour rendre la base de données restaurée disponible en ligne. Étant donné que la liaison est en place avant la mise en ligne de la base de données, la consommation de mémoire OLTP de son In-Memory est correctement prise en compte. Cela nécessite la restauration de la base de données une seule fois. La première commande RESTORE est une commande informationnelle qui lit uniquement l’en-tête de sauvegarde, et la dernière commande déclenche simplement la récupération sans restaurer réellement de bits.

Voir aussi

Sauvegarde, restauration et récupération de tables Memory-Optimized