Freigeben über

Diagnose zur Problembehandlung bei SQL-Hyperscale

  • Artikel

Gilt für:Azure SQL-Datenbank

Um Leistungsprobleme in einer Hyperscale-Datenbank zu beheben, sind die allgemeinen SQL-Leistungsoptimierungsmethoden der Ausgangspunkt jeder Leistungsuntersuchung. Allerdings müssen angesichts der verteilten Architektur von Hyperscale unter Umständen zusätzliche Diagnosen herangezogen werden. In diesem Artikel werden Hyperscale-spezifische Diagnosedaten beschrieben.

Reduzierte Wartezeiten bei Protokollraten

Jede Datenbank und jeder Pool für elastische Datenbanken in Azure SQL-Datenbank verwaltet die Protokollgenerierungsrate über Protokollratengovernance. In Hyperscale wird der Grenzwert für die Protokollratensteuerung unabhängig von der Berechnungsgröße auf 105 MB/s festgelegt. Dieser Wert wird in primary_max_log_rate in der Spalte verfügbar gemacht.

Manchmal muss die Protokollgenerierungsrate für das primäre Computereplikat reduziert werden, um die Wiederherstellbarkeits-SLAs aufrechtzuerhalten. Das kann beispielsweise passieren, wenn ein Seitenserver oder ein anderes Computereplikat mit der Anwendung neuer Protokolldatensätze vom Protokolldienst erheblich im Rückstand ist. Wenn sich keine Hyperscale-Komponenten dahinter befinden, ermöglicht es der Regulierungsmechanismus der Protokollrate, dass die Protokollgenerierungsrate 100 MB/s erreicht. Dies ist die effektive maximale Protokollgenerierungsrate in allen Hyperscale-Computegrößen.

Hinweis

Die Protokollgenerierungsrate von 150 MiB/s ist als aktivierbare Previewfunktion für Premium-Serien und arbeitsspeicheroptimierte Premium-Serien verfügbar. Weitere Informationen und eine Anleitung zum Aktivieren der Erhöhung auf 150 MiB/s finden Sie unter Blog: Hyperscale-Erweiterungen im November 2024.

Die folgenden Wartetypen erscheinen in sys.dm_os_wait_stats, wenn die Protokollrate reduziert wird:

Wartetyp Grund
RBIO_RG_STORAGE Verzögerte Protokollnutzung durch einen Seitenserver
RBIO_RG_DESTAGE Verzögerte Protokollnutzung durch den langfristigen Protokollspeicher
RBIO_RG_REPLICA Verzögerte Protokollnutzung durch ein sekundäres Hochverfügbarkeitsreplikat oder ein benanntes Replikat
RBIO_RG_GEOREPLICA Verzögerte Protokollnutzung durch ein geosekundäres Replikat
RBIO_RG_DESTAGE Verzögerte Protokollnutzung durch den Protokolldienst
RBIO_RG_LOCALDESTAGE Verzögerte Protokollnutzung durch den Protokolldienst
RBIO_RG_STORAGE_CHECKPOINT Verzögerte Protokollnutzung durch einen Seitenserver aufgrund eines langsamen Datenbankprüfpunkts
RBIO_RG_MIGRATION_TARGET Verzögerte Protokollnutzung durch die Nicht-Hyperscale-Datenbank während der Reversemigration

Die dynamische Verwaltungsfunktion (DMF) sys.dm_hs_database_log_rate() enthält zusätzliche Details, die Ihnen helfen, die Reduzierung der Protokollrate, wenn vorhanden, zu verstehen. So können Sie beispielsweise feststellen, welches sekundäre Replikat hinter dem Anwenden von Protokolldatensätzen liegt und welche Gesamtgröße das noch nicht angewendete Transaktionsprotokoll aufweist.

Seitenserver-Lesevorgänge

Die Computereplikate können eine vollständige Kopie der Datenbank nicht lokal zwischenspeichern. Die lokalen Daten für das Computereplikat werden im Pufferpool (im Arbeitsspeicher) und im lokalen RBPEX-Cache (Resilient Buffer Pool Extension) gespeichert, der eine Teilmenge der am häufigsten verwendeten Datenseiten enthält. Dieser lokale SSD-Cache ist proportional zur Größe der Rechnerressourcen dimensioniert. Jeder Seitenserver verfügt dagegen über einen vollständigen SSD-Cache für den Teil der Datenbank, den er verwaltet.

Wenn ein Lese-E/A für ein Computereplikat ausgegeben wird, wenn die Daten nicht im Pufferpool oder im lokalen SSD-Cache vorhanden sind, wird die Seite mit der angeforderten Protokollfolgenummer (LSN) vom entsprechenden Seitenserver abgerufen. Lesevorgänge von Seitenservern sind entfernt und langsamer als Lesevorgänge aus dem lokalen SSD-Cache. Bei der Behandlung von E/A-bezogenen Leistungsproblemen müssen wir ermitteln können, wie viele E/A-Vorgänge über relativ langsamere Seitenserverlesevorgänge erfolgten.

Einige dynamische Verwaltungssichten (DMVs) und erweiterte Ereignisse enthalten Spalten und Felder, die die Anzahl von Remotelesevorgängen von einem Seitenserver angeben, die mit der Gesamtanzahl von Lesevorgängen verglichen werden kann. Der Abfragespeicher erfasst auch Seitenserverlesevorgänge in Abfragelaufzeitstatistiken.

  • Spalten zum Berichten über Seitenserver-Lesevorgänge stehen in Ausführungs-DMVs und Katalogsichten zur Verfügung:
  • Der Seitenserver liest Felder, die in den folgenden erweiterten Ereignissen vorhanden sind:
    • sql_statement_completed
    • sp_statement_completed
    • sql_batch_completed
    • rpc_completed
    • scan_stopped
    • query_store_begin_persist_runtime_stat
    • query_store_execution_runtime_info
  • ActualPageServerReads/ActualPageServerReadAheads Attribute sind im Abfrageplan-XML für Pläne vorhanden, die Laufzeitstatistiken enthalten. Beispiel:
    <RunTimeCountersPerThread Thread="8" ActualRows="90466461" [...] ActualPageServerReads="0" ActualPageServerReadAheads="5687297" ActualLobPageServerReads="0" ActualLobPageServerReadAheads="0" />

    Tipp

    Wenn Sie diese Attribute im Fenster mit den Abfrageplaneigenschaften anzeigen möchten, ist SSMS 18.3 oder höher erforderlich.

Virtuelle Dateistatistiken und E/A-Kontoführung

In der Azure SQL-Datenbank ist die DMF sys.dm_io_virtual_file_stats() eine Möglichkeit, Datenbank-E/A-Statistiken wie IOPS, Durchsatz und Latenz zu überwachen. Die E/A-Merkmale in Hyperscale unterscheiden sich aufgrund der verteilten Architektur. In diesem Abschnitt konzentrieren wir uns auf E/A-Lese- und -Schreibvorgänge, wie in dieser DMF zu sehen ist. In Hyperscale entspricht jede Datendatei, die in diesem DMF sichtbar ist, einem Seitenserver. Die DMF stellt außerdem E/A-Statistiken für den lokalen SSD-Cache im Computereplikat und für das Transaktionsprotokoll bereit.

Lokale SSD-Cacheverwendung

Da sich der lokale SSD-Cache im selben Computereplikat befindet, in dem die Datenbank-Engine Abfragen verarbeitet, ist der Zugriff auf diesen Cache schneller als auf Seitenserver. In einer Hyperscale-Datenbank oder einem elastischen Pool verfügt sys.dm_io_virtual_file_stats() über eine spezielle Zeile, die die E/A-Statistik für den lokalen SSD-Cache angibt. Bei dieser Zeile lautet der Wert für die Spalten database_id und file_id gleich 0. Die folgende Abfrage gibt beispielsweise die lokale E/A-Statistik des SSD-Caches seit dem Datenbankstart zurück.

SELECT *
FROM sys.dm_io_virtual_file_stats(0, NULL);

Ein Verhältnis von Lesevorgängen aus dem lokalen SSD-Cache zu den aggregierten Lesevorgängen aus allen anderen Datendateien ist das lokale SSD-Cachetrefferverhältnis. Diese Metrik wird durch die RBPEX cache hit ratio- und RBPEX cache hit ratio base-Leistungsindikatoren bereitgestellt, die in der DMV sys.dm_os_performance_counters verfügbar sind.

Datenlesevorgänge

  • Wenn Lesevorgänge von der Datenbank-Engine in ein Computereplikat ausgegeben werden, werden sie möglicherweise entweder durch den lokalen SSD-Cache, durch Seitenserver oder eine Kombination der beiden Optionen verarbeitet (wenn mehrere Seiten gelesen werden).
  • Wenn das Computereplikat einige Seiten aus einer bestimmten Datendatei liest, z. B. die Datei mit file_id 1, wenn sich diese Daten ausschließlich im lokalen SSD-Cache befinden, wird der gesamte E/A-Durchsatz für diesen Lesevorgang für file_id 0 berücksichtigt. Wenn sich ein Teil dieser Daten im lokalen SSD-Cache befindet und sich ein Teil auf Seitenservern befindet, wird E/A zu file_id 0 für den Teil, der vom lokalen SSD-Cache bereitgestellt wird, berücksichtigt, und der Teil, der von Seitenservern bereitgestellt wird, wird den entsprechenden Dateien zugeordnet.
  • Wenn ein Computereplikat eine Seite mit einer bestimmten Protokollfolgenummer von einem Seitenserver anfordert und der Seitenserver noch nicht bei der angeforderten LSN angekommen ist, wartet der Lesevorgang im Computereplikat, bis der Seitenserver aufgeholt hat. Erst dann wird die Seite zurückgegeben. Bei jedem Lesevorgang von einem Seitenserver in das Computereplikat wird der Wartetyp PAGEIOLATCH_* angezeigt, wenn es auf diesen E/A-Vorgang wartet. Diese Wartezeit umfasst in Hyperscale sowohl die Zeit zum Aktualisieren der angeforderten Seite auf dem Seitenserver auf die erforderliche LSN als auch die Zeit, die zum Übertragen der Seite vom Seitenserver in das Computereplikat benötigt wird.
  • Umfangreiche Lesevorgänge wie „Read-Ahead“ erfolgen oft mithilfe von Scatter-Gather-Lesevorgängen. Dies ermöglicht das Lesen von bis zu 4 MB in einem einzigen E/A-Lesevorgang. Wenn sich die zu lesenden Daten jedoch im lokalen SSD-Cache befinden, werden diese Lesevorgänge als mehrere einzelne 8-KB-Lesevorgänge berücksichtigt, da der Pufferpool und der lokale SSD-Cache immer 8-KB-Seiten verwenden. Infolgedessen ist die Anzahl der für den lokalen SSD-Cache angezeigten E/A-Lesevorgänge möglicherweise größer als die tatsächliche Anzahl der von der Engine ausgeführten E/A-Vorgänge.

Datenschreibvorgänge

  • Das primäre Computereplikat schreibt nicht direkt auf Seitenserver. Stattdessen werden Protokolldatensätze des Protokolldiensts auf entsprechenden Seitenservern erneut wiedergegeben.
  • Schreibvorgänge für das Computereplikat werden überwiegend in den lokalen SSD-Cache geschrieben (file_id 0). Bei Schreibvorgängen, die größer als 8 KB sind, anders gesagt, die mit Gather-Writeausgeführt werden, wird jeder Schreibvorgang in mehrere separate 8-KB-Schreibvorgänge in den lokalen SSD-Cache übersetzt, da der Pufferpool und der lokale SSD-Cache immer 8-KB-Seiten verwenden. Infolgedessen ist die Anzahl der für den lokalen SSD-Cache angezeigten E/A-Schreibvorgänge möglicherweise größer als die tatsächliche Anzahl der von der Engine ausgeführten E/A-Vorgänge.
  • Andere Datendateien als file_id 0, die Seitenservern entsprechen, weisen möglicherweise auch Schreibvorgänge auf. In Hyperscale werden diese Schreibvorgänge simuliert, weil Computereplikate niemals direkt auf Seitenserver schreiben. E/A-Statistiken werden in Echtzeit im Computereplikat berücksichtigt. IOPS, Durchsatz und Latenz, die in einem Computereplikat für andere Datendateien als file_id 0 angezeigt werden, spiegeln nicht die tatsächliche E/A-Statistik von Schreibvorgängen wider, die auf Seitenservern auftreten.

Protokollschreibvorgänge

  • Im primären Computereplikat wird ein Protokollschreibvorgang in sys.dm_io_virtual_file_stats() unter file_id 2 berücksichtigt.
  • Im Gegensatz zu AlwaysOn-Verfügbarkeitsgruppen werden beim Abschluss einer Transaktion auf dem primären Replikat die Protokolldatensätze nicht auf dem sekundären Replikat gehärtet. In Hyperscale wird das Protokoll im Protokolldienst gespeichert und asynchron auf die sekundären Replikate angewendet. Da Protokollschreibvorgänge nicht tatsächlich auf sekundären Replikaten stattfinden, sollten Protokoll-E/A-Vorgänge in sys.dm_io_virtual_file_stats() für die sekundären Replikate nicht als Transaktionsprotokoll-E/A-Statistiken verwendet werden.

Daten-E/A in Statistiken zur Ressourcenauslastung

In einer Nicht-Hyperscale-Datenbank werden kombinierte Lese- und Schreib-IOPS für Datendateien relativ zum Daten-IOPS-Limit der Ressourcenkontrolle in den Sichten sys.dm_db_resource_stats und sys.resource_stats in der Spalte avg_data_io_percent ausgegeben. Die entsprechenden DMVs für Pools für elastische Datenbanken sind sys.dm_elastic_pool_resource_stats und sys.elastic_pool_resource_stats. Die gleichen Werte werden wie für die Azure Monitor-Metriken Daten-E/A-Prozentsatz für Datenbanken und Pools für elastische Datenbanken gemeldet.

In einer Hyperscale-Datenbank melden diese Spalten und Metriken die Daten-IOPS-Auslastung relativ zum Grenzwert für den lokalen SSD-Speicher ausschließlich für das Computereplikat. Dies umfasst E/A-Vorgänge für den lokalen SSD-Cache und die tempdb-Komponente der Datenbank. Ein Wert von 100 % in dieser Spalte gibt an, dass die Ressourcenkontrolle lokale Speicher-IOPS einschränkt. Wenn dies mit einem Leistungsproblem korreliert, sollten Sie die Arbeitsauslastung so optimieren, dass weniger E/A generiert wird, oder die Computegröße erhöhen, um das Max. Daten-IOPS-Limit der Ressourcengovernance zu erhöhen. Für die Ressourcengovernance von Lese- und -Schreibvorgängen für den lokalen SSD-Cache zählt das System einzelne 8-KB-E/A-Werte und keine größeren E/A-Werte, die von der Datenbank-Engine ausgegeben werden können.

Daten-E/A für Seitenserver werden nicht in Sichten zur Ressourcennutzung oder über Azure Monitor-Metriken gemeldet, sondern, wie zuvor beschrieben, in sys.dm_io_virtual_file_stats().

Verwandte Inhalte