Freigeben über

Diagnose zur Problembehandlung bei SQL-Hyperscale

  • Artikel

Gilt für: Azure SQL-Datenbank

Zur Behandlung von Leistungsproblemen in einer Hyperscale-Datenbank sind Methodiken der allgemeinen Leistungsoptimierung auf dem Azure SQL-Datenbank-Computeknoten der Ausgangspunkt für eine 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.

Wartezeiten für Protokollratendrosselung

Bei jedem Azure SQL-Datenbank-Dienstziel gibt es Limits für die Protokollgenerierungsrate, die über die Governance für die Protokollrate erzwungen werden. In Hyperscale ist das Limit für Protokollgovernance – unabhängig vom Servicelevel – auf 105 MB/Sek. festgelegt. Dieser Wert wird in sys.dm_user_db_resource_governance in der Spalte primary_max_log_rate verfügbar gemacht.

Es gibt jedoch Zeiten, in denen die Protokollgenerierungsrate für das primäre Computereplikat gedrosselt werden muss, um die SLAs (Vereinbarungen zum Servicelevel) für Wiederherstellbarkeit einzuhalten. Diese Drosselung erfolgt, wenn ein Seitenserver oder ein anderes Computereplikat mit der Anwendung neuer Protokolldatensätze vom Protokolldienst erheblich im Rückstand ist. Wenn sich keine Seitenserver oder Replikate im Rückstand befinden, ermöglicht der Drosselungsmechanismus eine Protokollgenerierungsrate von 100 MB/Sek. Dies ist die effektive maximale Protokollgenerierungsrate in allen Hyperscale-Dienstzielen. Protokollgenerierungsrate von 150 MB/s ist als Opt-In-Previewfunktion verfügbar. Weitere Informationen und die Möglichkeit, sich für 150 MB/s zu entscheiden, finden Sie im Blog: Hyperscale-Erweiterungen im November 2024.

Die folgenden Wartetypen (in sys.dm_os_wait_stats) beschreiben die Gründe, aus denen die Protokollrate beim primären Computereplikat nicht gedrosselt werden kann:

Wartetyp BESCHREIBUNG
RBIO_RG_STORAGE Tritt auf, wenn eine Protokollgenerierungsrate für den primären Serverknoten der Hyperscale-Datenbank infolge einer verzögerten Protokollnutzung durch mindestens einen Seitenserver gedrosselt wird.
RBIO_RG_DESTAGE Tritt auf, wenn eine Protokollgenerierungsrate für einen Hyperscale-Datenbank-Computeknoten infolge einer verzögerten Protokollnutzung durch den langfristigen Protokollspeicher gedrosselt wird.
RBIO_RG_REPLICA Tritt auf, wenn eine Protokollgenerierungsrate für einen Serverknoten der Hyperscale-Datenbank infolge einer verzögerten Protokollnutzung durch mindestens ein lesbares sekundäres Replikat gedrosselt wird.
.RBIO_RG_GEOREPLICA Tritt auf, wenn die Protokollerstellungsrate eines Hyperscale-Datenbank-Rechenknotens aufgrund eines verzögerten Protokollverbrauchs durch das Geo-Sekundärreplikat gedrosselt wird.
RBIO_RG_LOCALDESTAGE Tritt auf, wenn eine Protokollgenerierungsrate für einen Hyperscale-Datenbank-Computeknoten infolge einer verzögerten Protokollnutzung durch den Protokolldienst gedrosselt wird.

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, resiliente Pufferpoolerweiterung) gespeichert, bei dem es sich um einen partiellen (nicht abdeckenden) Cache von Datenseiten handelt. Dieser lokale RBPEX-Cache wird proportional zur Computegröße dimensioniert. Der RBPEX-Cache ähnelt dem Pufferpool insofern, als er die Daten enthält, auf die am häufigsten zugegriffen wird. Andererseits verfügt jeder Seitenserver über einen abdeckenden RBPEX-Cache für den von ihm verwalteten Teil der Datenbank.

Wenn bei einem Lesevorgang in einem Computereplikat die Daten nicht im Pufferpool oder im lokalen RBPEX-Cache vorhanden sind, wird die Funktion getPage(pageId, LSN) aufgerufen und die Seite vom entsprechenden Seitenserver abgerufen. Lesevorgänge von Seitenservern aus sind Remotelesevorgänge und folglich langsamer als Lesevorgänge aus dem lokalen RBPEX-Cache. Bei der Behandlung von E/A-bezogenen Leistungsproblemen müssen wir ermitteln können, wie viele E/A-Vorgänge über relativ langsamere Remoteseitenserver-Lesevorgä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 Remotelesevorgänge als Teil der Abfragelaufzeitstatistiken.

  • Spalten zum Berichten über Seitenserver-Lesevorgänge stehen in Ausführungs-DMVs und Katalogsichten zur Verfügung, z. B.:

  • Seitenserver-Lesevorgänge werden den folgenden erweiterten Ereignissen hinzugefügt:

    • 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“ werden dem Abfrageplan-XML-Code für tatsächliche Pläne hinzugefügt. Beispiel:

<RunTimeCountersPerThread Thread="8" ActualRows="90466461" ActualRowsRead="90466461" Batches="0" ActualEndOfScans="1" ActualExecutions="1" ActualExecutionMode="Row" ActualElapsedms="133645" ActualCPUms="85105" ActualScans="1" ActualLogicalReads="6032256" ActualPhysicalReads="0" ActualPageServerReads="0" ActualReadAheads="6027814" ActualPageServerReadAheads="5687297" ActualLobLogicalReads="0" ActualLobPhysicalReads="0" ActualLobPageServerReads="0" ActualLobReadAheads="0" ActualLobPageServerReadAheads="0" />

Hinweis

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 Azure SQL-Datenbank ist die dynamische Verwaltungsfunktion sys.dm_io_virtual_file_stats() die primäre Methode zum Überwachen der E/A-Vorgänge von SQL-Datenbank. Die E/A-Merkmale in Hyperscale unterscheiden sich aufgrund der verteilten Architektur. In diesem Abschnitt konzentrieren wir uns bei E/A-Vorgängen (Lese- und Schreibvorgänge) auf Datendateien, die in dieser DMF angezeigt werden. In Hyperscale entspricht jede in dieser DMF sichtbare Datendatei einem Remoteseitenserver. Der hier erwähnte RBPEX-Cache ist ein lokaler SSD-basierter Cache, bei dem es sich um einen nicht abdeckenden Cache auf dem Computereplikat handelt.

Lokale RBPEX-Cachenutzung

Der lokale RBPEX-Cache befindet sich auf dem Computereplikat im lokalen SSD-Speicher. Folglich ist die E/A für diesen Cache schneller als die E/A auf Remoteseitenservern. Derzeit enthält sys.dm_io_virtual_file_stats() in einer Hyperscale-Datenbank eine spezielle Zeile mit einem Bericht über den E/A-Vorgang, der im lokalen RBEX-Cache für das Computereplikat erfolgt ist. Bei dieser Zeile lautet der Wert für die Spalten database_id und file_id gleich „0“. In der Abfrage unten beispielsweise wird die RBPEX-Nutzungsstatistik seit dem Datenbankstart zurückgegeben.

select * from sys.dm_io_virtual_file_stats(0,NULL);

Das Verhältnis von Lesevorgängen im RBPEX-Cache zu aggregierten Lesevorgängen in allen anderen Datendateien liefert die RBPEX-Cachetrefferquote. Der Zähler RBPEX cache hit ratio wird auch in der DMV der Leistungsindikatoren sys.dm_os_performance_counters angezeigt.

Datenlesevorgänge

  • Lesevorgänge von der SQL Server-Datenbank-Engine für ein Computereplikat werden möglicherweise entweder durch den lokalen RBPEX-Cache, durch Remoteseitenserver oder eine Kombination aus beidem verarbeitet, wenn mehrere Seiten gelesen werden.
  • Wenn das Computereplikat einige Seiten aus einer bestimmten Datei liest, z.B. „file_id 1“, (falls sich diese Daten ausschließlich im lokalen RBPEX-Cache befinden) werden alle E/A-Vorgänge für diesen Lesevorgang auf „file_id 0 (RBPEX)“ angerechnet. Wenn sich ein Teil dieser Daten im lokalen RBPEX-Cache befindet und ein Teil auf einem Remoteseitenserver, wird der E/A-Vorgang für den vom RBPEX-Cache verarbeiteten Teil in „file_id 0“ berücksichtigt und der vom Remoteseitenserver verarbeitete Teil in „file_id 1“.
  • Wenn ein Computereplikat eine Seite mit einer bestimmten LSN (Log Sequence Number, Protokollfolgenummer) von einem Seitenserver anfordert und der Seitenserver die angeforderte LSN noch nicht erreicht hat, wartet der Lesevorgang im Computereplikat, bis der Seitenserver entsprechend aufgeholt hat. Erst dann wird die Seite an das Computereplikat zurückgegeben. Bei jedem Lesevorgang von einem Seitenserver im Computereplikat wird der Wartetyp „PAGEIOLATCH_*“ angezeigt, wenn er 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 Lesevorgänge für Seiten mit einer Gesamtgröße von bis zu 4 MB gleichzeitig, was in der SQL Server-Datenbank-Engine als ein einzelner Lesevorgang gilt. Wenn sich die gelesenen Daten jedoch im RBPEX -Cache befinden, werden diese Lesevorgänge als mehrere einzelne 8-KB-Lesevorgänge angesehen, da der Pufferpool und der RBPEX-Cache immer 8-KB-Seiten verwenden. Infolgedessen ist die Anzahl der für RBPEX 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 im Computereplikat werden vorwiegend in den lokalen RBPEX-Cache „(file_id 0)“ geschrieben. Bei Schreibvorgängen in logischen Dateien, die größer als 8 KB sind (d. h. dazu wurde Gather-Write verwendet), wird jeder Vorgang in mehrere einzelne 8-KB-Schreibvorgänge in RBPEX übersetzt, da der Pufferpool und der RBPEX-Cache immer 8-KB-Seiten verwenden. Infolgedessen ist die Anzahl der für RBPEX angezeigten E/A-Schreibvorgänge möglicherweise größer als die tatsächliche Anzahl der von der Engine ausgeführten E/A-Vorgänge.
  • Nicht-RBPEX-Dateien oder andere Datendateien als „file_id 0“, die Seitenservern entsprechen, zeigen ebenfalls Schreibvorgänge an. In der Dienstebene „Hyperscale“ werden diese Schreibvorgänge simuliert, weil die Computereplikate niemals direkt auf Seitenserver schreiben. Schreib-IOPS und Durchsatz werden für das Computereplikat berücksichtigt, aber die Latenz bei anderen Datendateien als „file_id 0“ spiegelt nicht die tatsächliche Latenz von Seitenserver-Schreibvorgängen wider.

Protokollschreibvorgänge

  • Bei der primären Compute-Instanz wird in „file_id 2“ von „sys.dm_io_virtual_file_stats“ ein Protokollschreibvorgang berücksichtigt. Ein Protokollschreibvorgang in der primären Computeressource ist ein Schreibvorgang in die Protokollzielzone.
  • Protokolldatensätze werden auf dem sekundären Replikat bei einem Commit nicht festgeschrieben. Bei Hyperscale wird das Protokoll vom Protokolldienst asynchron auf die sekundären Replikate angewendet. Da auf sekundären Replikaten eigentlich keine Protokollschreibvorgänge erfolgen, dient die Erfassung der Protokoll-E/A-Vorgänge auf den sekundären Replikaten lediglich der Nachverfolgung.

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. Der gleiche Wert wird im Azure-Portal als Daten-E/A in Prozent angezeigt.

In einer Hyperscale-Datenbank zeigt diese Spalte die Daten-IOPS-Auslastung in Bezug auf den Grenzwert für den lokalen Speicher nur für das Computereplikat an, insbesondere E/A für RBPEX und tempdb. 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 Workload so optimieren, dass weniger E/A generiert wird, oder Sie erhöhen das Ziel des Datenbankdiensts, um das Limit Max. Data-IOPS der Ressourcenkontrolle zu erhöhen. Für die Ressourcenkontrolle für RBPEX-Lese- und -Schreibvorgänge zählt das System einzelne E/A-Vorgänge mit einer Größe von 8 KB statt größere E/A-Vorgänge, die möglicherweise von der SQL Server-Datenbank-Engine ausgegeben werden.

Daten-E/A für Remoteseitenserver wird nicht in Ressourcenverwendungssichten oder im Portal gemeldet, sondern in der sys.dm_io_virtual_file_stats ()-DMF, wie bereits erwähnt.

Zusätzliche Ressourcen