Surveiller le stockage OLTP en mémoire dans Azure SQL Database

S’applique à : Azure SQL Database

Avec OLTP en mémoire, les données des tables et des variables de table optimisées en mémoire résident dans le stockage OLTP en mémoire, qui est une partie de la mémoire de base de données mise de côté pour les données en mémoire.

• Les bases de données et les pools élastiques des niveaux de service Premium (DTU) et Business Critical (vCore) prennent en charge In-Memory OLTP.
• Le niveau de service Hyperscale prend en charge un sous-ensemble d’objets OLTP en mémoire, mais n’inclut pas les tables optimisées en mémoire. Pour plus d’informations, consultez Limitations d’hyperscale.

Déterminer si la taille des données est adaptée à la capacité de stockage en mémoire OLTP

Déterminez les limites maximales de stockage des différents objectifs de service. Chaque objectif de service Premium et critique pour l'entreprise dispose d’une taille de stockage OLTP en mémoire maximale.

• Limites de ressources basées sur des unités DTU - Base de données unique
• Limites de ressources basées sur des unités DTU - Pools élastiques
• Limites de modèle de ressources basées sur des vCore : base de données unique
• Limites de ressources basées sur des vCore : pools élastiques

L’estimation de la mémoire requise pour une table à mémoire optimisée s’effectue de la même façon pour SQL Server que dans Azure SQL Database. Passez en revue Estimer les besoins en mémoire.

La table et les lignes de variable de table, ainsi que les index, sont pris en compte dans le plafond. En outre, les instructions ALTER TABLE ont besoin de suffisamment de mémoire pour créer une version de la table entière et de ses index.

Une fois que ce plafond est atteint, des opérations d’insertion et de mise à jour peuvent commencer à échouer. À ce stade, vous devez soit supprimer des données pour récupérer de la mémoire, soit augmenter l'objectif de service de votre base de données ou de votre pool élastique. Pour plus d’informations, consultez Corriger les situations de stockage OLTP en mémoire insuffisant : erreurs 41823 et 41840.

Surveiller et alerter

Vous pouvez surveiller l'utilisation du stockage In-Memory OLTP en pourcentage du plafond de stockage pour l'objectif de service dans le portail Azure :

1. Dans la page Vue d’ensemble de votre base de données SQL, sélectionnez le graphique dans la page Surveillance . Dans le menu de navigation de gauche, recherchez Supervision, puis sélectionnez Métriques.
2. Sélectionnez Ajouter une métrique.
3. Sous De base, sélectionnez la métrique OLTP en mémoire Stockage pourcentage.
4. Pour ajouter une alerte, sélectionnez dans la zone Utilisation des ressources pour ouvrir la page Métrique , puis sélectionnez Nouvelle règle d’alerte. Suivez ces instructions pour créer une règle d’alerte de l’intégrité de la ressource.

Vous pouvez également utiliser la requête suivante pour afficher l’utilisation du stockage en mémoire :

SELECT xtp_storage_percent 
FROM sys.dm_db_resource_stats
ORDER BY end_time DESC;

Résoudre les erreurs de mémoire insuffisante avec OLTP en mémoire

Atteindre le plafond de stockage In-Memory OLTP dans votre base de données ou votre pool élastique peut entraîner l'échec des instructions INSERT, UPDATE, ALTER et CREATE avec l'erreur 41823 (pour les bases de données uniques) ou l'erreur 41840 (pour les pools élastiques). Les deux erreurs provoquent l’abandon de la transaction active.

Les erreurs 41823 et 41840 indiquent que la taille des tables et des variables de table optimisées pour la mémoire dans la base de données ou le pool élastique a atteint la taille de stockage maximale In-Memory OLTP.

Pour résoudre ces erreurs, il faut soit :

• supprimer des données des tables à mémoire optimisée, en déchargeant potentiellement les données vers des tables traditionnelles sur disque ;
• Passez à un objectif de service doté d'une capacité de stockage In-Memory OLTP suffisante pour les données que vous devez conserver dans des tables et des variables de table optimisées pour la mémoire.

Analyser avec des vues de gestion dynamique (DMV)

• En surveillant la consommation de mémoire de manière proactive, vous pouvez déterminer l'augmentation de la consommation de mémoire et la marge de manœuvre qui vous reste pour respecter les limites de ressources. Identifiez la quantité de mémoire consommée par les objets dans votre base de données ou dans votre instance. Vous pouvez utiliser les DMV sys.dm_db_xtp_table_memory_stats ou sys.dm_os_memory_clerks.

  • Déterminez la quantité de mémoire pour toutes les tables utilisateur, index et objets système en interrogeant sys.dm_db_xtp_table_memory_stats :

    SELECT object_name(object_id) AS [Name], *
    FROM sys.dm_db_xtp_table_memory_stats;
    

  • La mémoire allouée au moteur In-Memory OLTP et aux objets à mémoire optimisée est gérée de la même manière que les autres consommateurs de mémoire au sein d'une base de données. Les clercs de mémoire de type MEMORYCLERK_XTP représentent la totalité de la mémoire allouée au moteur In-Memory OLTP. Utilisez la requête suivante pour trouver toute la mémoire utilisée par le moteur In-Memory OLTP, y compris la mémoire dédiée à des bases de données spécifiques.

    -- This DMV accounts for all memory used by the In-Memory OLTP engine
    SELECT [type], [name]
         , memory_node_id  
         , pages_kb/1024. AS pages_MB
    FROM sys.dm_os_memory_clerks 
    WHERE [type] LIKE '%xtp%';
    

    type                 name       memory_node_id pages_MB  
    -------------------- ---------- -------------- --------------------  
    MEMORYCLERK_XTP      Default    0              18  
    MEMORYCLERK_XTP      DB_ID_5    0              1358  
    MEMORYCLERK_XTP      Default    64             0  
    

• Vous pouvez également obtenir plus d’informations sur les erreurs de mémoire insuffisante dans Azure SQL Database avec la vue de gestion dynamique sys.dm_os_out_of_memory_events. Par exemple :

  SELECT *
  FROM sys.dm_os_out_of_memory_events
  ORDER BY event_time DESC;
  

Contenu connexe

• Superviser les performances de Microsoft Azure SQL Database avec des vues de gestion dynamique