Überwachen des In-Memory-OLTP-Speichers in Azure SQL-Datenbank
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.
- Datenbanken mit dem Tarif „Premium (DTU)“ und „Unternehmenskritisch (virtuelle Kerne)“ unterstützten In-Memory-OLTP-Tabellen.
- Hyperscale unterstützt eine Teilmenge von In-Memory-OLTP-Objekten, umfasst jedoch keine speicheroptimierten Tabellen. Weitere Informationen finden Sie unter Einschränkungen von Hyperscale.
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.
- DTU-basierte Ressourcenlimits – Einzeldatenbank
- DTU-basierte Ressourcenlimits – Pools für elastische Datenbanken
- V-Kern-basierte Ressourceneinschränkungen – Einzeldatenbanken
- V-Kern-basierte Ressourceneinschränkungen – Pool für elastische Datenbanken
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:
- 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.
- Wählen Sie Metrik hinzufügen aus.
- Wählen Sie unter Basic die Metrik In-Memory-OLTP-Speicherprozent.
- 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;