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

  • Artikel

Gilt für:Azure SQL-Datenbank

Bei der Verwendung von In-Memory-OLTP befinden sich die Daten der speicheroptimierten Tabellen und Tabellenvariablen im In-Memory-OLTP-Speicher.

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

Bestimmen Sie die Speicherkapazitäten der verschiedenen Dienstebenen. Jede Dienstebene 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. Nehmen Sie sich einige Minuten Zeit, um den Artikel Schätzen der Arbeitsspeicheranforderungen speicheroptimierter Tabellen zu lesen.

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

Sobald diese Grenze überschritten ist, können Einfüge- und Aktualisierungsvorgänge fehlschlagen. An diesem Punkt müssen Sie entweder Daten löschen, um Speicherplatz freizugeben, oder die Dienstebene bzw. Computegröße für Ihre Datenbank upgraden. Weitere Informationen finden Sie unter Korrigieren von In-Memory-OLTP-Speichersituationen außerhalb des Arbeitsspeichers – Fehler 41823 und 41840.

Überwachung und Warnung

Sie können die Nutzung von In-Memory-Speicher als Prozentsatz der Speicherkapazität für Ihre Computegröße 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;

Behandeln von Situationen mit zu wenig In-Memory-OLTP-Speicher: Fehler 41823 und 41840

Bei Erreichen der Obergrenze des In-Memory-OLTP-Speichers in Ihrer Datenbank tritt bei INSERT-, UPDATE-, ALTER- und CREATE-Vorgängen der Fehler 41823 (Einzeldatenbanken) bzw. der Fehler 41840 (Pools für elastische Datenbanken) auf. 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 Pool die maximale In-Memory-OLTP-Speichergröße erreicht haben.

Beheben Sie den Fehler mit einer der folgenden Methoden:

  • 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 auf eine Dienstebene durch, die genügend In-Memory-Speicher für die Daten bietet, die Sie in In-Memory-Tabellen 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 regelmäßig ü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. Zum Beispiel die DMVs sys.dm_db_xtp_table_memory_stats oder sys.dm_os_memory_clerks.

    • 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 Arbeitsspeicherclerk des Typs MEMORYCLERK_XTP nachverfolgt. Verwenden Sie die folgende Abfrage auf sys.dm_os_memory_clerks, 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 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