Überwachen des In-Memory-OLTP-Speichers in Azure SQL-Datenbank

  • Artikel

Gilt für: Azure SQL-Datenbank

Bei In-Memory OLTP befinden sich Daten in speicheroptimierten Tabellen und Tabellenvariablen im In-Memory-OLTP-Speicher, der ein Teil des Datenbankspeichers ist, der für In-Memory-Daten reserviert ist.

Bestimmen, ob genügend In-Memory-OLTP-Speicherplatz für die Daten zur Verfügung steht

Bestimmen Sie die Speicherkapazitäten der verschiedenen Dienstziele. Jedes Dienstziel vom Typ „Premium“ und „Unternehmenskritisch“ verfügt über eine maximale In-Memory-OLTP-Speichergröße.

Das Einschätzen des Speicherbedarfs für eine speicheroptimierte Tabelle funktioniert für SQL Server genauso wie in Azure SQL-Datenbank. Prüfen Sie Geschätzte Speicheranforderungen.

Sowohl die Tabellen- und Tabellenvariablenzeilen als auch die Indizes werden in die Obergrenze eingerechnet. Darüber hinaus benötigt ALTER TABLE genügend Platz, um eine neue Version der gesamten Tabelle und ihrer Indizes zu erstellen.

Sobald die Obergrenze erreicht ist, können Einfüge- und Aktualisierungsvorgänge fehlschlagen. An diesem Punkt müssen Sie entweder Daten löschen, um Speicherplatz zurückzugewinnen, oder das Serviceziel Ihrer Datenbank oder Ihres Pools für elastische Datenbanken heraufsetzen. Weitere Informationen finden Sie unter Korrigieren von In-Memory-OLTP-Speichersituationen außerhalb des Arbeitsspeichers – Fehler 41823 und 41840.

Überwachen und benachrichtigen

Sie können die In-Memory OLTP-Speichernutzung als Prozentsatz der Speicherkapazität für das Serviceziel im Azure-Portal überwachen:

  1. Wählen Sie auf der Seite Übersicht Ihrer SQL-Datenbank das Diagramm auf der Seite Überwachung aus. Oder suchen Sie im Navigationsmenü auf der linken Seite nach Überwachung, und wählen Sie Metriken aus.
  2. Wählen Sie Metrik hinzufügen aus.
  3. Wählen Sie unter Basic die Metrik In-Memory-OLTP-Speicherprozent.
  4. Um einen Alarm hinzuzufügen, wählen Sie das Feld Ressourcenverwendung, um die Seite Metrik zu öffnen, und wählen Sie dann Neue Alarmregel. Folgen Sie den Anleitungen zum Erstellen einer Metrikwarnungsregel.

Oder verwenden Sie folgende Abfrage, um die In-Memory-Speicherverwendung anzuzeigen:

SELECT xtp_storage_percent 
FROM sys.dm_db_resource_stats
ORDER BY end_time DESC;

Beheben von Out-of-Memory-Fehlern mit In-Memory OLTP

Das Erreichen der In-Memory-OLTP-Speicherobergrenze in Ihrer Datenbank oder Ihrem elastischen Pool kann dazu führen, dass die INSERT, UPDATE, ALTER und CREATE-Anweisungen mit Fehler 41823 (für einzelne Datenbanken) oder Fehler 41840 (für elastische Pools) fehlschlagen. Beide Fehler führen zum Abbruch der aktiven Transaktion.

Die Fehler 41823 und 41840 geben an, dass die speicheroptimierten Tabellen und Tabellenvariablen in der Datenbank oder im elastischen Pool die maximale In-Memory-OLTP-Speichergröße erreicht haben.

Sie haben zwei Möglichkeiten zur Behebung dieser Fehler:

  • Löschen Sie Daten aus den speicheroptimierten Tabellen – Sie können die Daten beispielsweise in herkömmliche datenträgerbasierte Tabellen auslagern.
  • Führen Sie ein Upgrade des Dienstziels auf eine Dienstebene durch, die genügend In-Memory-OLTP-Speicher für die Daten bietet, die Sie in In-Memory-Tabellen und Tabellenvariablen speichern müssen.

Hinweis

In seltenen Fällen treten die Fehler 41823 und 41840 nur vorübergehend auf. In diesem Fällen steht genügend In-Memory-OLTP-Speicher zur Verfügung, und der Vorgang ist erfolgreich, wenn er erneut ausgeführt wird. Es empfiehlt sich daher, den insgesamt verfügbaren In-Memory OLTP-Speicher zu überwachen und den Vorgang beim erstmaligen Auftreten des Fehlers 41823 oder 41840 zu wiederholen. Weitere Informationen zur Wiederholungslogik finden Sie unter Konflikterkennung und Wiederholungslogik.

Überwachen mit DMVs

  • Indem Sie den Speicherverbrauch proaktiv überwachen, können Sie feststellen, wie der Speicherverbrauch steigt und wie viel Spielraum Sie bei den Ressourcenlimits noch haben. Identifizieren Sie, wie viel Arbeitsspeicher von den Objekten in der Datenbank oder Instanz beansprucht wird. Sie können die sys.dm_db_xtp_table_memory_stats oder sys.dm_os_memory_clerks DMVs benutzen.

    • Sie können die Arbeitsspeichernutzung für alle Benutzertabellen, Indizes und Systemobjekte ermitteln, indem Sie sys.dm_db_xtp_table_memory_stats abfragen:

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

    • Der von der In-Memory-OLTP-Engine und den speicheroptimierten Objekten belegte Arbeitsspeicher wird auf dieselbe Weise wie jeder andere Arbeitsspeicherconsumer innerhalb einer Datenbank verwaltet. Der gesamte von der In-Memory-OLTP-Engine belegte Arbeitsspeicher wird von Clerks des Typs MEMORYCLERK_XTP nachverfolgt. Verwenden Sie die folgende Abfrage, um den gesamten von der In-Memory-OLTP-Engine verwendeten Speicher zu ermitteln, einschließlich des Speichers, der für bestimmte Datenbanken reserviert ist.

      -- 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

  • Mit der dynamischen Verwaltungssicht sys.dm_os_out_of_memory_events erhalten Sie weitere Informationen zu Fehlern, bei denen der Speicher nicht ausreicht, in Azure SQL-Datenbank. Zum Beispiel:

    SELECT *
FROM sys.dm_os_out_of_memory_events
ORDER BY event_time DESC;

Zugehöriger Inhalt