Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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. Das Protokollratenlimit wird in der primary_max_log_rate Spalte in sys.dm_user_db_resource_governance verfügbar gemacht.
Manchmal muss die Protokollgenerierungsrate für das primäre Computereplikat reduziert werden, um Vereinbarungen auf Serviceebene (Recoverability Service Level Agreements, 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 keine Hyperscale-Komponenten vorhanden sind, ermöglicht der Protokollratenverwaltungsmechanismus, die Protokollgenerierungsrate auf 150 MiB/s pro Datenbank für Premium-Serie und speicheroptimierte Premium-Serie Hardware zu erhöhen. Für Hardware der Standardreihe beträgt die maximale Protokollrate 100 MiB/s pro Datenbank. Bei elastischen Pools beträgt die maximale Protokollrate 150 MiB/s pro Pool für optimierte Hardware der Premium-Serie und 125 MiB/s pro Pool für andere Hardware.
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 sys.dm_hs_database_log_rate() dynamische Verwaltungsfunktion (DYNAMIC Management Function, DMF) enthält weitere Details, die Ihnen helfen, die Protokollratenreduzierung zu verstehen, falls vorhanden. 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 speichern keine vollständige Kopie der Datenbank lokal zwischen. 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 Melden von Seitenserverlesungen stehen in Ausführungs-DMVs und Katalogansichten zur Verfügung:
Die Felder werden vom Seitenserver in den folgenden erweiterten Ereignissen gelesen:
sql_statement_completedsp_statement_completedsql_batch_completedrpc_completedscan_stoppedquery_store_begin_persist_runtime_statquery_store_execution_runtime_info
ActualPageServerReads/ActualPageServerReadAheadsAttribute 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.
Für Hyperscale sind die relevanten Daten sys.dm_io_virtual_file_stats() wie folgt:
Die Zeilen, in denen der
database_idWert mit dem von der funktion DB_ID zurückgegebenen Wert übereinstimmt und derfile_idWert nicht 2 ist, entspricht seitenservern. In der Regel entspricht jede Zeile einem Seitenserver. Bei größeren Dateien werden jedoch mehrere Seitenserver verwendet.- Die Zeile mit
file_id2 entspricht dem Transaktionsprotokoll.
- Die Zeile mit
Die Zeilen, in denen der Wert in der
database_idSpalte 0 ist, entsprechen dem lokalen SSD-Cache im Computereplikat.
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 gibt es sys.dm_io_virtual_file_stats() spezielle Zeilen, die E/A-Statistiken für den lokalen SSD-Cache melden. Diese Zeilen weisen den Wert 0 für die database_id Spalte auf. Die folgende Abfrage gibt z. B. 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 der aggregierten Lesevorgänge aus den lokalen SSD-Cachedateien 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_id1), wenn sich diese Daten ausschließlich im lokalen SSD-Cache befinden, wird alle E/A für diesen Lesevorgang für die lokalen SSD-Cachedateien berücksichtigt, wobeidatabase_id0 ist. Wenn sich ein Teil dieser Daten im lokalen SSD-Cache befindet und ein Teil auf Seitenservern ist, wird E/A teilweise für die lokalen SSD-Cachedateien und teilweise für die Datendateien berücksichtigt, die den Seitenservern entsprechen.Wenn ein Computereplikat eine Seite an einem bestimmten LSN von einem Seitenserver anfordert, wenn der Seitenserver noch nicht den angeforderten LSN erfasst hat, wartet das Lesen im Computereplikat, bis der Seitenserver nachholt, bevor die Seite zurückgegeben wird. Für jeden Lesevorgang von einem Seitenserver im Berechnungsreplikat wird ein
PAGEIOLATCH_*-Wartetyp angezeigt, wenn auf diese E/A gewartet wird. 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 (
database_id0). 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
database_id0, 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 bei einem Computereplikat für Datendateien, die nichtdatabase_id0 sind, reflektieren nicht die tatsächlichen E/A-Statistiken der Schreibvorgänge, die auf Seitenservern stattfinden.
Protokollschreibvorgänge
Im primären Computereplikat werden Protokollschreibvorgänge unter
sys.dm_io_virtual_file_stats()file_id2 erfasst.Im Gegensatz zu Verfügbarkeitsgruppen werden Protokolldatensätze, wenn eine Transaktion auf dem primären Rechenreplikat festgeschrieben wird, nicht auf dem sekundären Replikat gesichert. 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 E/A-Grenzwert der Ressourcengovernancedaten in sys.dm_db_resource_stats und sys.resource_stats Ansichten in der avg_data_io_percent Spalte gemeldet. 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 berichten diese Spalten und Metriken über die Daten-Ein-/Ausgabe-Nutzung im Verhältnis zum Grenzwert für den lokalen SSD-Speicher, der ausschließlich für Computereplikate vorgesehen ist. Dies umfasst die Ein-/Ausgabe für den lokalen SSD-Cache und die tempdb 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 lokalen SSD-Cache-Lese- und Schreibvorgängen zählt das System einzelne 8-KB-IOs und nicht größere IOs, die vom Datenbankmodul ausgegeben werden können.
Daten-E/A für Seitenserver werden nicht in Ansichten zur Ressourcennutzung oder über Azure Monitor-Metriken gemeldet, sondern wie zuvor beschrieben in sys.dm_io_virtual_file_stats() gemeldet.