Überwachen der Leistung und Behandeln von Leistungsproblemen

Abgeschlossen

Die Überwachung und die Problembehandlung sind zwei Kernaspekte der Bereitstellung einer konsistenten Leistung. Neben den Tools und Features für die Leistungsüberwachung und Problembehandlung, die auch in SQL Server verfügbar sind, bietet Azure SQL auch zusätzliche Funktionen. Dazu zählen Features wie dynamische Verwaltungssichten (Dynamic Management Views, DMVs), erweiterte Ereignisse und Azure Monitor. Es ist wichtig, diese Tools und Funktionen zu kennen, um sie in verschiedenen Leistungsszenarios für Azure SQL einsetzen zu können, Diese Szenarien umfassen eine hohe CPU-Auslastung oder das Warten auf eine Ressource.

Tools und Funktionen zur Überwachung der Leistung

Azure SQL bietet Funktionen für die Überwachung und Problembehandlung aus dem Azure-Ökosystem sowie vertraute Tools aus SQL Server. Diese werden in den folgenden Abschnitten kurz beschrieben.

Azure Monitor

Azure Monitor ist Teil des Azure-Ökosystems und mit Azure SQL integriert, sodass Azure-Metriken, -Warnungen und -Protokolle unterstützt werden. Sie können Azure Monitor-Daten im Azure-Portal visualisieren, und Anwendungen können über Azure Event Hubs oder APIs auf diese Daten zugreifen. Ähnlich wie der Windows-Leistungsmonitor unterstützt auch Azure Monitor den Zugriff auf Ressourcennutzungsmetriken in Azure SQL, ohne dass Sie SQL Server-Tools verwenden müssen.

Dynamische Verwaltungssichten (DMV)

Azure SQL bietet nahezu die gleiche DMV-Infrastruktur wie SQL Server mit nur wenigen Unterschieden. DMVs sind für die Leistungsüberwachung entscheidend, da sie es Ihnen ermöglichen, wichtige SQL Server-Leistungsdaten mit T-SQL-Standardabfragen anzuzeigen. Dazu gehören z. B. Informationen wie aktive Abfragen, die Ressourcennutzung, Abfragepläne und Ressourcenwartetypen. Weitere Informationen zu DMVs mit Azure SQL finden Sie später in dieser Lerneinheit.

Erweiterte Ereignisse

Azure SQL bietet nahezu die gleiche Infrastruktur für erweiterte Ereignisse wie SQL Server mit nur wenigen Unterschieden. Erweiterte Ereignisse ermöglichen es Ihnen, wichtige Ausführungsereignisse in SQL Server-Plattform zu verfolgen, die wiederum Azure SQL unterstützt. Für eine bessere Leistung können Sie mit den erweiterten Ereignissen die Ausführung einzelner Abfragen verfolgen. Weitere Informationen zu erweiterten Ereignissen in Azure SQL finden Sie später in dieser Lerneinheit.

Einfache Abfrageprofilerstellung

Die einfache Profilerstellung ist eine erweiterte Methode zur Problembehandlung von Szenarien, die das Abrufen des tatsächlichen Ausführungsplans für In-Flight-Anforderungen und hochwertige Abfragen erfordern. Aufgrund ihres geringen Mehraufwands kann jeder Server, der nicht bereits CPU-gebunden ist, die einfache Profilerstellung kontinuierlich ausführen und es Datenbankexpert*innen ermöglichen, jederzeit auf jede aktuell ausgeführte Ausführung zuzugreifen; z. B. mit dem Aktivitätsmonitor in SQL Server Management Studio oder durch direktes Abfragen von sys.dm_exec_query_profiles oder sys.dm_exec_query_statistics_xml.

Sie können die einfache Abfrageprofilerstellung verwenden, um den Abfrageplan und den Ausführungsstatus einer aktiven Abfrage zu untersuchen. Dies ist ein wichtiges Feature zum Debuggen der Abfrageleistung für Anweisungen, während diese ausgeführt werden. Diese Funktion verkürzt die Lösungsdauer von Leistungsproblemen im Vergleich zu Tools wie erweiterten Ereignissen für die Verfolgung der Abfrageleistung. Sie können über DMVs auf die einfache Abfrageprofilerstellung zugreifen, und diese Funktion ist für Azure SQL ebenso wie für SQL Server 2019 und höhere Versionen standardmäßig aktiviert.

Debugfunktionen für den Abfrageplan

In einigen Situationen benötigen Sie möglicherweise weitere Details zur Abfrageleistung einer einzelnen T-SQL-Anweisung. T-SQL-SET-Anweisungen wie SHOWPLAN und STATISTICS können diese Details bereitstellen und werden für Azure SQL ebenso wie für SQL Server vollständig unterstützt.

Abfragespeicher

Abfragespeicher ist ein Verlaufsdatendatz der Leistungsausführung für Abfragen, die in der Benutzerdatenbank gespeichert sind. Der Abfragespeicher ist für Azure SQL standardmäßig aktiviert und dient zum Bereitstellen von Funktionen wie der automatischen Plankorrektur und der automatischen Optimierung. SQL Server Management Studio-Berichte (SSMS) sind in Azure SQL für den Speicher verfügbar. Mithilfe dieser Berichte können Sie die Abfragen mit dem höchsten Ressourcenverbrauch, einschließlich Abfrageplanunterschieden, sowie die häufigsten Wartekategorien für Ressourcenwarteszenarios feststellen.

Leistungsvisualisierungen

Für Azure SQL-Datenbank sind im Azure-Portal integrierte Informationen zur Leistung des Abfragespeichers in Form von Visualisierungen verfügbar. So können Sie für den Abfragespeicher einen Teil der gleichen Informationen anzeigen, die auch mit einem Clienttool wie SSMS verfügbar sind. Verwenden Sie die Optionen „Leistungsübersicht“ und „Query Performance Insight“ im Azure-Portal.

Informationen zu DMVs

DMVs spielen seit vielen Jahren eine maßgebliche Rolle bei der Leistungsüberwachung und Problembehandlung in SQL Server. Die gängigen DMVs für SQL Server sind auch in Azure SQL verfügbar. Es gibt jedoch auch einige zusätzliche, Azure-spezifische DMVs.

Azure SQL Managed Instance

Alle SQL Server-DMVs sind auch für SQL Managed Instance verfügbar. Wichtige DMVs wie sys.dm_exec_requests und sys.dm_os_wait_stats werden häufig verwendet, um die Abfrageleistung zu untersuchen.

Die Systemansicht „sys.server_resource_stats“ ist spezifisch für SQL Managed Instance und zeigt den Verlauf der Ressourcennutzung an. Dies ist ein wichtiges Tool zum Anzeigen der Ressourcennutzung, da Sie keinen direkten Zugriff auf Betriebssystemtools wie den Leistungsmonitor haben.

Azure SQL-Datenbank

Die meisten gängigen DMVs, die Sie für die Leistung benötigen, einschließlich sys.dm_exec_requests und sys.dm_os_wait_stats, sind verfügbar. Beachten Sie, dass die von diesen DMVs bereitgestellten Informationen datenbankspezifisch sind und nicht datenbankübergreifend für einen logischen Server gelten.

Die DMV „sys.dm_db_resource_stats“ ist spezifisch für Azure SQL-Datenbank, und Sie können sie verwenden, um einen Verlauf der Ressourcennutzung für die Datenbank anzuzeigen. Die Verwendung dieser DMV erfolgt ähnlich wie die von sys.server_resource_stats für eine verwaltete Instanz.

Die DMV „sys.elastic_pool_resource_stats“ ist vergleichbar mit der DMV „sys.dm_db_resource_stats“, aber Sie können sie verwenden, um die Ressourcennutzung von Pools für elastische Datenbanken anzuzeigen.

Erforderliche DMVs

Sie benötigen die folgenden DMVs, um bestimmte Leistungsszenarios für Azure SQL zu lösen:

• sys.dm_io_virtual_file_stats ist wichtig, weil Sie keinen Direktzugriff auf die Betriebssystemmetriken für die E/A-Leistung pro Datei haben.
• sys.dm_os_performance_counters ist sowohl für Azure SQL-Datenbank als auch für SQL Managed Instance verfügbar, um allgemeine SQL Server-Leistungsmetriken anzuzeigen. Mit dieser DMV lassen sich Informationen des SQL Server-Leistungsindikators anzeigen, die normalerweise im Leistungsmonitor verfügbar sind.
• Mit sys.dm_instance_resource_governance können Sie Ressourcenlimits für eine verwaltete Instanz anzeigen. Anhand dieser Informationen können Sie sehen, wie Ihre erwarteten Ressourcenlimits aussehen sollten, ohne das Azure-Portal zu verwenden.
• sys.dm_user_db_resource_governance ermöglicht es Ihnen, allgemeine Ressourcenlimits nach Bereitstellungsoption, Dienstebene und Umfang Ihrer Azure SQL-Datenbank-Bereitstellung anzuzeigen. Anhand dieser Informationen können Sie sehen, wie Ihre erwarteten Ressourcenlimits aussehen sollten, ohne das Azure-Portal zu verwenden.

DMVs für einen tieferen Einblick

Diese DMVs bieten einen tieferen Einblick in Ressourcenlimits und Ressourcenkontrolle für Azure SQL. Sie sind nicht für übliche Szenarios gedacht, können aber bei einer genaueren Analyse von komplexen Leistungsproblemen hilfreich sein. In der Dokumentation finden Sie alle Details dieser DMVs:

• sys.dm_user_db_resource_governance_internal (nur SQL Managed Instance)
• sys.dm_resource_governor_resource_pools_history_ex
• sys.dm_resource_governor_workload_groups_history_ex

Details zu erweiterten Ereignissen

Das Feature „Erweiterte Ereignisse“ ist der Mechanismus von SQL Server für die Ablaufverfolgung. Erweiterte Ereignisse in Azure SQL basieren auf der SQL Server-Engine und sind daher nahezu identisch für Azure SQL. Es bestehen jedoch einige bedeutende Unterschiede. Diese werden in den folgenden Abschnitten behandelt.

Erweiterte Ereignisse für Azure SQL-Datenbank

Sie können erweiterte Ereignisse für Azure SQL-Datenbank auf die gleiche Weise wie bei SQL Server verwenden, indem Sie Sitzungen erstellen und Ereignisse, Aktionen und Ziele verwenden. Behalten Sie diese wichtigen Punkte im Hinterkopf, wenn Sie Sitzungen für erweiterte Ereignisse erstellen:

• Die meisten gängigen Ereignisse und Aktionen werden unterstützt.
• Dateien, ring_buffer und Zähler werden als Ziele unterstützt.
• Dateiziele werden mit Azure Blob Storage unterstützt, da Sie keinen Zugriff auf die zugrunde liegenden Datenträger des Betriebssystems haben.

Sie können SSMS oder T-SQL verwenden, um Sitzungen zu erstellen und zu starten. Sie können SSMS verwenden, um Zieldaten von Sitzungen mit erweiterten Ereignissen oder die Systemfunktion sys.fn_xe_file_target_read_file anzuzeigen.

Hinweis

Es ist nicht möglich, SSMS zum Anzeigen aktiver Daten für Azure SQL-Datenbank zu verwenden.

Berücksichtigen Sie zudem, dass alle erweiterten Ereignisse, die für Ihre Sitzungen ausgelöst werden, für Ihre Datenbank spezifisch sind und nicht für den logischen Server gelten.

Erweiterte Ereignisse für Azure SQL Managed Instance

Die Verwendung von erweiterten Ereignissen erfolgt in SQL Managed Instance und SQL Server auf die gleiche Weise: durch Erstellung von Sitzungen und mithilfe von Ereignissen, Aktionen und Zielen. Behalten Sie diese wichtigen Punkte im Hinterkopf, wenn Sie Sitzungen für erweiterte Ereignisse erstellen:

• Alle Ereignisse, Ziele und Aktionen werden unterstützt.
• Dateiziele werden mit Azure Blob Storage unterstützt, da Sie keinen Zugriff auf die zugrunde liegenden Datenträger des Betriebssystems haben.
• In SQL Managed Instance sind einige spezifische Ereignisse verfügbar, mit denen verwaltungs- und ausführungsbezogene Ereignisse der Instanz verfolgt werden können.

Sie können SSMS oder T-SQL verwenden, um Sitzungen zu erstellen und zu starten. Sie können SSMS verwenden, um Zieldaten von Sitzungen mit erweiterten Ereignissen oder die Systemfunktion sys.fn_xe_file_target_read_file anzuzeigen. Die Anzeige von Livedaten in SSMS wird für SQL Server und Azure SQL Managed Instance unterstützt.

Leistungsszenarios für Azure SQL

Damit Sie entscheiden können, wie Leistungstools und -funktionen zur Überwachung und Problembehebung eingesetzt werden sollen, sollten Sie die Leistung für Azure SQL anhand von Szenarios analysieren.

Allgemeine Leistungsszenarios

Eine gängige Methode zur Behandlung von Leistungsproblemen bei SQL Server besteht darin, zu untersuchen, ob ein Leistungsproblem bei der Ausführung (hohe CPU) oder beim Warten (wartet auf eine Ressource) auftritt. Das folgende Diagramm zeigt eine Entscheidungsstruktur, anhand derer festgestellt werden kann, ob ein SQL Server-Leistungsproblem bei der Ausführung oder beim Warten auftritt und wie Leistungstools zur Ursachenermittlung und Lösung eingesetzt werden können.

Sehen wir uns die Details der einzelnen Aspekte des Diagramms genauer an.

Ausgeführte Ressourcen im Vergleich zu wartenden Ressourcen

Sehen Sie sich zunächst die allgemeine Ressourcennutzung an. Für eine SQL Server-Standardbereitstellung können Sie Tools wie den Leistungsmonitor unter Windows oder Top unter Linux verwenden. Für Azure SQL können Sie die folgenden Methoden verwenden:

• Azure-Portal/PowerShell/Warnungen

  Azure Monitor verfügt über integrierte Metriken, um die Ressourcennutzung für Azure SQL anzuzeigen. Zudem können Sie Warnungen einrichten, um nach Bedingungen für die Ressourcennutzung zu suchen.

• sys.dm_db_resource_stats

  Für Azure SQL-Datenbank können Sie sich diese DMV ansehen, um die CPU-, Arbeitsspeicher- und E/A-Ressourcennutzung für die Datenbankbereitstellung zu sehen. Diese DMV nimmt alle 15 Sekunden eine Momentaufnahme dieser Daten auf.

• sys.server_resource_stats

  Diese DMV verhält sich zwar genau wie sys.dm_db_resource_stats, dient jedoch dazu, die Ressourcennutzung der verwalteten Instanz für die CPU, den Arbeitsspeicher und die E/A anzuzeigen. Diese DMV erstellt ebenfalls alle 15 Sekunden eine Momentaufnahme.

• sys.dm_user_db_resource_governance

  Für Azure SQL-Datenbank gibt diese DMV die tatsächlichen Konfigurations- und Kapazitätseinstellungen zurück, die von Ressourcengovernancemechanismen in der aktuellen Datenbank oder dem Pool für elastische Datenbanken verwendet werden.

• sys.dm_instance_resource_governance

  Für Azure SQL Managed Instance gibt diese DMV ähnliche Informationen wie sys.dm_user_db_resource_governance zurück, aber für die aktuelle SQL Managed Instance.

Wird ausgeführt

Wenn Sie festgestellt haben, dass das Problem eine hohe CPU-Auslastung ist, wird dies als „Wird ausgeführt“-Szenario bezeichnet. Dies kann Abfragen beinhalten, die durch Kompilierung oder Ausführung Ressourcen verbrauchen. Führen Sie mithilfe der folgenden Tools eine genauere Analyse durch:

• Abfragespeicher

  Verwenden Sie die Berichte über die Ressourcen mit dem höchsten Verbrauch in SSMS, Katalogsichten im Abfragespeicher oder Query Performance Insight im Azure-Portal (nur Azure SQL-Datenbank), um herauszufinden, welche Abfragen die meisten CPU-Ressourcen verbrauchen.

• sys.dm_exec_requests

  Verwenden Sie diese DMV in Azure SQL, um eine Momentaufnahme des Zustands der aktiven Abfragen zu erhalten. Suchen Sie nach Abfragen mit dem Status RUNNABLE und dem Wartetyp SOS_SCHEDULER_YIELD, um herauszufinden, ob genügend CPU-Kapazität vorhanden ist.

• sys.dm_exec_query_stats

  Mit dieser DMV können Sie, ähnlich wie mit dem Abfragespeicher, die Abfragen finden, die den höchsten Ressourcenverbrauch aufweisen. Beachten Sie, dass diese DMV nur für zwischengespeicherte Abfragepläne verfügbar ist, während der Abfragespeicher einen dauerhaften Leistungsverlauf bereitstellt. Mit dieser DMV können Sie auch nach dem Abfrageplan für eine zwischengespeicherte Abfrage suchen.

• sys.dm_exec_procedure_stats

  Diese DMV stellt Informationen auf ähnliche Weise wie sys.dm_exec_query_stats zur Verfügung. Der Unterschied besteht darin, dass die Leistungsdaten auf der Ebene der gespeicherten Prozedur angezeigt werden können.

  Nachdem Sie ermittelt haben, welche Abfragen die meisten Ressourcen beanspruchen, müssen Sie möglicherweise überprüfen, ob genügend CPU-Ressourcen für Ihre Arbeitsauslastung vorhanden sind. Abfragepläne können mit Tools wie der einfachen Abfrageprofilerstellung, SET-Anweisungen, dem Abfragespeicher oder der Ablaufverfolgung für erweiterte Ereignisse gedebuggt werden.

Wartend

Wenn das Problem offenbar nicht in einer zu hohen CPU-Auslastung besteht, könnte es mit dem Warten auf eine Ressource zusammenhängen. Zu den Szenarios, die das Warten auf Ressourcen beinhalten, gehören:

• E/A-Wartevorgänge
• Sperrenwartevorgänge
• Latchwartevorgänge
• Pufferpoollimits
• Speicherzuweisungen
• Plancacheentfernung

Um Analysen zu Warteszenarien durchzuführen, werden in der Regel die folgenden Tools verwendet:

• sys.dm_os_wait_stats

  Verwenden Sie diese DMV, um zu ermitteln, welche die häufigsten Wartetypen für die Datenbank bzw. Instanz sind. Anhand der am häufigsten auftretenden Wartetypen können Sie ermitteln, welche Maßnahmen als Nächstes zu ergreifen sind.

• sys.dm_exec_requests

  Mit dieser DMV können Sie bestimmte Wartetypen für aktive Abfragen finden, um festzustellen, auf welche Ressource sie warten. Hierbei kann es sich um ein Standardsperrszenario handeln, in dem auf Sperrungen von anderen Benutzern gewartet wird.

• sys.dm_os_waiting_tasks

  Sie können diese DMV verwenden, um Wartetypen für eine bestimmte Aufgabe einer bestimmten Abfrage zu finden, die derzeit ausgeführt wird, vielleicht um herauszufinden, warum es länger dauert als normal. sys.dm_os_waiting_tasks enthält die Live-Wartezeitstatistiken, die sys.dm_os_wait_stats im Laufe der Zeit aggregiert.

• Abfragespeicher

  Abfragespeicher bietet Berichte und Katalogsichten, die eine Aggregation der häufigsten Wartevorgänge für die Ausführung von Abfrageplänen zeigen. Beachten Sie, dass das Warten der CPU einem Problem bei der Ausführung gleichkommt.

Tipp

Erweiterte Ereignisse können für alle Ausführungs- oder Warteszenarios verwendet werden. Zu diesem Zweck müssen Sie eine Sitzung für erweiterte Ereignisse einrichten, um Abfragen zu verfolgen. Diese Methode zum Debuggen eines Leistungsproblems ist fortgeschrittener und kann viele Informationen zurückgeben, aber auch mehr Leistungsaufwand als DMVs verursachen.

Spezifische Szenarios für Azure SQL

Es gibt einige Leistungsszenarios, sowohl für die Ausführung als auch das Warten, die nur in Azure SQL auftreten. Hierzu gehören die Protokollgovernance, Workerlimits, Wartevorgänge für Dienstebenen des Typs „Unternehmenskritisch“ und Wartevorgänge, die für Hyperscale-Bereitstellungen spezifisch sind.

Protokollgovernance

In Azure SQL können mithilfe der Protokollratengovernance Ressourcenlimits für die Verwendung von Transaktionsprotokollen durchgesetzt werden. Diese Maßnahme ist häufig erforderlich, um Ressourcenlimits und die zugesagte SLA einzuhalten. Die Protokollgovernance kann unter folgenden Gesichtspunkten betrachtet werden:

• LOG_RATE_GOVERNOR: wartet auf Azure SQL-Datenbank
• POOL_LOG_RATE_GOVERNOR: wartet auf Pools für elastische Datenbanken
• INSTANCE_LOG_GOVERNOR: wartet auf Azure SQL Managed Instance
• HADR_THROTTLE_LOG_RATE*: wartet auf Vorgänge des Typs „Unternehmenskritisch“ und Georeplikationslatenz

Workerlimits

SQL Server verwendet einen Workerpool von Threads, verfügt jedoch über Grenzwerte für die maximale Anzahl von Workern. Anwendungen mit einer großen Anzahl gleichzeitiger Benutzer*innen können sich den Workerlimits nähern, die für Azure SQL-Datenbank und SQL Managed Instance durchgesetzt werden:

• Azure SQL-Datenbank ist in Bezug auf die Dienstebene und den Umfang begrenzt. Wenn Sie diese Grenzwerte überschreiten, tritt bei einer neuen Abfrage ein Fehler auf.
• Derzeit verwendet SQL Managed Instance max worker threads, sodass für Worker, die dieses Limit überschreiten, THREADPOOL-Wartevorgänge auftreten.

Unternehmenskritische HADR-Wartevorgänge

Wenn Sie eine Dienstebene des Typs „Unternehmenskritisch“ nutzen, können unerwartet die folgenden Wartetypen auftreten:

• HADR_SYNC_COMMIT
• HADR_DATABASE_FLOW_CONTROL
• HADR_THROTTLE_LOG_RATE_SEND_RECV

Obwohl diese Wartevorgänge Ihre Anwendung unter Umständen nicht verlangsamen, können sie dennoch unerwartet auftreten. Normalerweise treten sie jedoch nur bei Verwendung einer Always On-Verfügbarkeitsgruppe auf. In Dienstebenen des Typs „Unternehmenskritisch“ wird die Technologie der Verfügbarkeitsgruppen eingesetzt, um SLA-Features und Verfügbarkeitsfeatures zu implementieren. Mit diesen Wartetypen ist also zu rechnen. Beachten Sie, dass lange Wartezeiten auf einen Engpass hinweisen können, z. B. auf E/A-Wartezeit oder ein verzögertes Replikat.

Hyperscale

Die Hyperscalearchitektur kann einige einzigartige Wartetypen ergeben, denen das Präfix RBIO vorangestellt ist (ein möglicher Hinweis auf die Protokollgovernance). Darüber hinaus wurden DMVs, Katalogsichten und erweiterte Ereignisse verbessert und zeigen nun Metriken für Seitenlesevorgänge des Servers an.

In der folgenden Übung erfahren Sie, wie Sie mit den Tools und dem Wissen, das Sie in dieser Lerneinheit erworben haben, ein Leistungsproblem für Azure SQL überwachen und lösen.