Übung: Überwachen der Leistung und Behandeln von Leistungsproblemen

  • 10 Minuten

In dieser Übung erfahren Sie, wie Sie mithilfe von neuen und altbekannten Tools und Funktionen ein Leistungsproblem in Azure SQL überwachen und beheben.

Setup: Verwenden von Skripts zum Bereitstellen von Azure SQL-Datenbank

Die Terminalsitzung rechts (Azure Cloud Shell) ermöglicht Ihnen die Interaktion mit Azure über einen Browser. Für diese Übung führen Sie ein Skript aus, um Ihre Umgebung zu erstellen: eine Instanz von Azure SQL-Datenbank mit der Datenbank AdventureWorks. (Die kleinere, einfachere Beispieldatenbank AdventureWorksLT wird verwendet, aber wir nennen sie AdventureWorks, um Verwirrung zu vermeiden.) Im Skript werden Sie aufgefordert, ein Kennwort und Ihre lokale IP-Adresse anzugeben, damit das Gerät eine Verbindung zur Datenbank herstellen kann.

Die Ausführung des Skripts dauert 3–5 Minuten. Vergessen Sie nicht, Ihr Kennwort, die eindeutige ID und die Region zu notieren. Diese Daten werden nicht noch einmal angezeigt.

  1. Rufen Sie zunächst Ihre lokale IP-Adresse ab. Vergewissern Sie sich, dass Ihre Verbindung zu anderen VPN-Diensten getrennt ist, und öffnen Sie ein lokales PowerShell-Terminal auf Ihrem Gerät. Führen Sie den folgenden Befehl aus, und notieren Sie die zurückgegebene IP-Adresse:

    (Invoke-WebRequest -Uri "https://ipinfo.io/ip").Content

  2. Geben Sie rechts in Azure Cloud Shell den folgenden Code ein, und geben Sie bei Aufforderung ein komplexes Kennwort und Ihre lokale öffentliche IP-Adresse ein, die Sie im vorherigen Schritt abgerufen haben. Drücken Sie die EINGABETASTE, um die letzte Zeile des Skripts auszuführen.

    $adminSqlLogin = "cloudadmin"
$password = Read-Host "Your username is 'cloudadmin'. Please enter a password for your Azure SQL Database server that meets the password requirements"
# Prompt for local ip address
$ipAddress = Read-Host "Disconnect your VPN, open PowerShell on your machine and run '(Invoke-WebRequest -Uri "https://ipinfo.io/ip").Content'. Please enter the value (include periods) next to 'Address':"
# Get resource group and location and random string
$resourceGroup = Get-AzResourceGroup | Where ResourceGroupName -like "<rgn>Sandbox resource group name</rgn>"
$resourceGroupName = "<rgn>Sandbox resource group name</rgn>"
$uniqueID = Get-Random -Minimum 100000 -Maximum 1000000
$storageAccountName = "mslearnsa"+$uniqueID
$location = $resourceGroup.Location
$serverName = "aw-server$($uniqueID)"

  3. Führen Sie das folgende Skript in Azure Cloud Shell aus. Speichern Sie die Ausgabe. Sie benötigen diese Informationen während des gesamten Moduls. Drücken Sie die EINGABETASTE, nachdem Sie den Code eingefügt haben, sodass in der letzten Codezeile die Ausgabe ausgibt, die Sie benötigen.

    Write-Host "Please note your unique ID for future exercises in this module:"  
Write-Host $uniqueID
Write-Host "Your resource group name is:"
Write-Host $resourceGroupName
Write-Host "Your resources were deployed in the following region:"
Write-Host $location
Write-Host "Your server name is:"
Write-Host $serverName

    Tipp

    Speichern Sie die Ausgabe, und notieren Sie sich Ihr Kennwort, Ihre eindeutige ID und Ihren Server. Diese Informationen benötigen Sie während des gesamten Moduls immer wieder.

  4. Führen Sie das folgende Skript aus, um eine Instanz von Azure SQL-Datenbank und einen logischen Server mit dem AdventureWorks-Beispiel bereitzustellen. Dieses Skript fügt Ihre IP-Adresse als Firewallregel hinzu, aktiviert Advanced Data Security und erstellt ein Speicherkonto für die verbleibenden Übungen in diesem Modul. Die Ausführung des Skripts kann einige Minuten dauern und wird mehrmals angehalten. Warten Sie auf eine Eingabeaufforderung.

    # The logical server name has to be unique in the system
$serverName = "aw-server$($uniqueID)"
# The sample database name
$databaseName = "AdventureWorks"
# The storage account name has to be unique in the system
$storageAccountName = $("sql$($uniqueID)")
# Create a new server with a system wide unique server name
$server = New-AzSqlServer -ResourceGroupName $resourceGroupName `
    -ServerName $serverName `
    -Location $location `
    -SqlAdministratorCredentials $(New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $adminSqlLogin, $(ConvertTo-SecureString -String $password -AsPlainText -Force))
# Create a server firewall rule that allows access from the specified IP range and all Azure services
$serverFirewallRule = New-AzSqlServerFirewallRule `
    -ResourceGroupName $resourceGroupName `
    -ServerName $serverName `
    -FirewallRuleName "AllowedIPs" `
    -StartIpAddress $ipAddress -EndIpAddress $ipAddress 
$allowAzureIpsRule = New-AzSqlServerFirewallRule `
    -ResourceGroupName $resourceGroupName `
    -ServerName $serverName `
    -AllowAllAzureIPs
# Create a database
$database = New-AzSqlDatabase  -ResourceGroupName $resourceGroupName `
    -ServerName $serverName `
    -DatabaseName $databaseName `
    -SampleName "AdventureWorksLT" `
    -Edition "GeneralPurpose" -Vcore 2 -ComputeGeneration "Gen5"
# Enable Advanced Data Security
$advancedDataSecurity = Enable-AzSqlServerAdvancedDataSecurity `
    -ResourceGroupName $resourceGroupName `
    -ServerName $serverName
# Create a Storage Account
$storageAccount = New-AzStorageAccount -ResourceGroupName $resourceGroupName `
    -AccountName $storageAccountName `
    -Location $location `
    -Type "Standard_LRS"

  5. Öffnen Sie SQL Server Management Studio (SSMS) auf Ihrem lokalen Gerät, um eine neue Verbindung zu Ihrem logischen Server herzustellen.

  6. Geben Sie in das Anmeldedialogfeld „Verbindung mit Server herstellen“ die folgenden Informationen ein:

    Feld Wert
    Servertyp Datenbank-Engine (Standard)
    Servername Der Wert von $serverName, der in Cloud Shell zurückgegeben wurde, sowie der Rest des URI. zum Beispiel aw-server<unique ID>.database.windows.net.
    Authentifizierung SQL-Serverauthentifizierung (Standard)
    Anmelden cloudadmin, der in Schritt 1 dieser Übung zugewiesene adminSqlLogin
    Kennwort Das Kennwort, das Sie in Schritt 1 dieser Übung angegeben haben
    Kennwort speichern checked

  7. Wählen Sie Verbinden.

    Screenshot of connection dialog for SQL Database in SSMS.

    Hinweis

    Je nach lokaler Konfiguration (z. B. VPN) unterscheidet sich Ihre Client-IP-Adresse möglicherweise von der IP-Adresse, die im Azure-Portal bei der Bereitstellung verwendet wurde. Wenn dies der Fall ist, wird Ihnen folgende Meldung angezeigt: „Ihre Client-IP-Adresse hat keinen Zugriff auf den Server. Melden Sie sich bei einem Azure-Konto an, und erstellen Sie eine neue Firewallregel für die Aktivierung des Zugriffs.“ Wenn diese Meldung angezeigt wird, müssen Sie sich mit dem Konto anmelden, das Sie für die Sandbox verwenden, und eine Firewallregel für Ihre Client-IP-Adresse hinzufügen. All diese Schritte können Sie mithilfe des Assistenten in SSMS durchführen.

Übungsvorbereitung: Laden und Bearbeiten von Skripts

Sie finden alle Skripts für diese Übung im Ordner 04-Performance\monitor_and_scale im GitHub-Repository, das Sie geklont haben, oder in der heruntergeladenen ZIP-Datei. Nachfolgend erfahren Sie, wie Sie zur Vorbereitung auf die Übung Skripts laden und bearbeiten.

  1. Erweitern Sie im SSMS im Objekt-Explorerden Ordner Datenbanken und wählen Sie die AdventureWorks-Datenbank aus.

  2. Wählen Sie Datei>Öffnen>Datei aus und öffnen Sie das Skript dmexecrequests.sql. Das Fenster des Abfrage-Editors sollte in etwa den folgenden Text beinhalten:

    SELECT er.session_id, er.status, er.command, er.wait_type, er.last_wait_type, er.wait_resource, er.wait_time
FROM sys.dm_exec_requests er
INNER JOIN sys.dm_exec_sessions es
ON er.session_id = es.session_id
AND es.is_user_process = 1;

  3. Gehen Sie in SSMS genauso vor, um das Skript dmdbresourcestats.sql zu laden. Ein neues Fenster des Abfrage-Editors sollte in etwa den folgenden Text beinhalten:

    SELECT * FROM sys.dm_db_resource_stats;

    Diese dynamische Verwaltungssicht (Dynamic Management View, DMV) verfolgt die allgemeine Ressourcennutzung Ihrer Arbeitsauslastung für Azure SQL-Datenbank nach, z. B. für die CPU, die E/A und den Arbeitsspeicher.

  4. Öffnen und bearbeiten Sie das Skript sqlworkload.cmd (welches das Programm „ostress.exe“ verwendet).

    • Ersetzen Sie im Servernamen Ihren unique_id-Wert, den Sie aus dem Bereitstellungsskript gespeichert haben.
    • Ersetzen Sie das Kennwort nach dem -P parameter, das Sie für die Anmeldung beim Azure SQL-Datenbank-Server verwendet haben.
    • Speichern Sie die vorgenommenen Skriptänderungen.

Ausführen der Arbeitsauslastung

In dieser Aufgabe führen Sie eine Arbeitsauslastung in einer T-SQL-Abfrage aus, um die Leistung zu beobachten, während gleichzeitige Benutzer simuliert werden.

  1. Verwenden Sie SSMS, um die Skriptdatei topcustomersales.sql zu öffnen und die Abfrage zu beobachten. Die Abfrage wird nicht über SSMS ausgeführt. Das Fenster des Abfrage-Editors sollte in etwa den folgenden Text beinhalten:

    DECLARE @x int
DECLARE @y float
SET @x = 0;
WHILE (@x < 10000)
BEGIN
SELECT @y = sum(cast((soh.SubTotal*soh.TaxAmt*soh.TotalDue) as float))
FROM SalesLT.Customer c
INNER JOIN SalesLT.SalesOrderHeader soh
ON c.CustomerID = soh.CustomerID
INNER JOIN SalesLT.SalesOrderDetail sod
ON soh.SalesOrderID = sod.SalesOrderID
INNER JOIN SalesLT.Product p
ON p.ProductID = sod.ProductID
GROUP BY c.CompanyName
ORDER BY c.CompanyName;
SET @x = @x + 1;
END
GO

    Diese Datenbank ist klein. Die Abfrage zum Abrufen einer Kundenliste und der zugehörigen Vertriebsinformationen, die nach Kunden mit den meisten Verkäufen sortiert ist, sollte kein großes Resultset generieren. Sie könnten diese Abfrage optimieren, indem Sie die Anzahl der Spalten im Resultset reduzieren. In dieser Übung sind sie jedoch zur Veranschaulichung notwendig.

  2. Geben Sie in einer PowerShell-Eingabeaufforderung den folgenden Befehl ein, um in das richtige Verzeichnis für diese Übung zu wechseln. Ersetzen Sie <base directory> durch Ihre Benutzer-ID und den Pfad für dieses Modul:

    cd <base directory>\04-Performance\monitor_and_scale

  3. Führen Sie die Arbeitsauslastung mit dem folgenden Befehl aus:

    .\sqlworkload.cmd

    Dieses Skript verwendet 10 gleichzeitige Benutzer, die die Arbeitsauslastungsabfrage zweimal ausführen. Das Skript selbst führt zwar nur einen einzelnen Batch, jedoch auch eine Schleife mit 10.000 Durchläufen aus. Außerdem hat es das Ergebnis einer Variablen zugewiesen, sodass fast der gesamte Resultsetdatenverkehr auf dem Client entfällt. Dieser Vorgang ist nicht erforderlich, hilft aber, eine reine CPU-Arbeitsauslastung zu veranschaulichen, die komplett auf dem Server ausgeführt wird.

    Tipp

    Wenn Ihnen für diese Arbeitsauslastung keine CPU-Nutzung für Ihre Umgebung angezeigt wird, können Sie den -n parameter für die Anzahl der Benutzer und den -r parameter für die Iterationen anpassen.

    Die Ausgabe in der Eingabeaufforderung sollte in etwa wie folgt aussehen:

    [datetime] [ostress PID] Max threads setting: 10000
[datetime] [ostress PID] Arguments:
[datetime] [ostress PID] -S[server].database.windows.net
[datetime] [ostress PID] -isqlquery.sql
[datetime] [ostress PID] -U[user]
[datetime] [ostress PID] -dAdventureWorks
[datetime] [ostress PID] -P********
[datetime] [ostress PID] -n10
[datetime] [ostress PID] -r2
[datetime] [ostress PID] -q
[datetime] [ostress PID] Using language id (LCID): 1024 [English_United States.1252] for character formatting with NLS: 0x0006020F and Defined: 0x0006020F
[datetime] [ostress PID] Default driver: SQL Server Native Client 11.0
[datetime] [ostress PID] Attempting DOD5015 removal of [directory]\sqlquery.out]
[datetime] [ostress PID] Attempting DOD5015 removal of [directory]\sqlquery_1.out]
[datetime] [ostress PID] Attempting DOD5015 removal of [directory]\sqlquery_2.out]
[datetime] [ostress PID] Attempting DOD5015 removal of [directory]\sqlquery_3.out]
[datetime] [ostress PID] Attempting DOD5015 removal of [directory]\sqlquery_4.out]
[datetime] [ostress PID] Attempting DOD5015 removal of [directory]\sqlquery_5.out]
[datetime] [ostress PID] Attempting DOD5015 removal of [directory]\sqlquery_6.out]
[datetime] [ostress PID] Attempting DOD5015 removal of [directory]\sqlquery_7.out]
[datetime] [ostress PID] Attempting DOD5015 removal of [directory]\sqlquery_8.out]
[datetime] [ostress PID] Attempting DOD5015 removal of [directory]\sqlquery_9.out]
[datetime] [ostress PID] Starting query execution...
[datetime] [ostress PID]  BETA: Custom CLR Expression support enabled.
[datetime] [ostress PID] Creating 10 thread(s) to process queries
[datetime] [ostress PID] Worker threads created, beginning execution...

Beobachten der Leistung der Arbeitsauslastung

Wir verwenden nun die DMV-Abfragen, die Sie zuvor geladen haben, um die Leistung zu beobachten.

  1. Führen Sie die Abfrage, die Sie zuvor geladen haben, in SSMS aus, um dm_exec_requests (dmexecrequests.sql) zu überwachen und aktive Anforderungen zu beobachten. Führen Sie diese Abfrage fünf- oder sechsmal aus, und sehen Sie sich einen Teil der Ergebnisse an:

    SELECT er.session_id, er.status, er.command, er.wait_type, er.last_wait_type, er.wait_resource, er.wait_time
FROM sys.dm_exec_requests er
INNER JOIN sys.dm_exec_sessions es
ON er.session_id = es.session_id
AND es.is_user_process = 1;

    Sie sollten sehen, dass viele der Anforderungen einen Status von RUNNABLE haben, und dass last_wait_type ist SOS_SCHEDULER_YIELD. Ein Indikator für viele RUNNABLE-Anforderungen und viele SOS_SCHEDULER_YIELD-Wartezeiten ist ein möglicher Mangel an CPU-Ressourcen für aktive Abfragen.

    Hinweis

    Möglicherweise werden eine oder mehrere aktive Anforderungen mit einem Befehl von SELECT und einer wait_type von XE_LIVE_TARGET_TVF angezeigt. Dies sind Abfragen, die von Diensten ausgeführt werden, die von Microsoft verwaltet werden. Sie helfen durch Funktionen wie Leistungseinblicke durch erweiterte Ereignisse. Die Details dieser Sitzungen werden von Microsoft nicht veröffentlicht.

    Lassen Sie dieses Fenster des Abfrage-Editors geöffnet. Sie werden es in der nächsten Übung noch einmal ausführen.

  2. Führen Sie die Abfrage in SSMS aus, das Sie zuvor zur Überwachung von sys.dm_db_resource_stats (dmdbresourcestats.sql) geladen haben. Führen Sie die Abfrage aus, um die Ergebnisse dieser DMV drei oder vier Mal anzuzeigen.

    SELECT * FROM sys.dm_db_resource_stats;

    Diese DMV zeichnet alle 15 Sekunden eine Momentaufnahme der Ressourcennutzung in der Datenbank auf (die eine Stunde lang gespeichert wird). Die Werte in der Spalte avg_cpu_percent sollten für mehrere Momentaufnahmen nahezu 100 % betragen. Dies ist ein Hinweis auf eine Arbeitsauslastung, die an die Limits der CPU-Ressourcen für die Datenbank stößt.

    In einer lokalen SQL Server-Umgebung wird die allgemeine Ressourcennutzung, z. B. die CPU-Auslastung, normalerweise mithilfe eines betriebssystemspezifischen Tools nachverfolgt. Der Windows-Systemmonitor bietet sich beispielsweise zu diesem Zweck an. Wenn Sie dieses Beispiel auf einer SQL Server-Instanz mit 100 CPUs ausführen, die lokal oder in einer VM ausgeführt wird, ergäbe sich eine nahezu 100%ige CPU-Auslastung auf dem Server.

    Hinweis

    Sie können eine weitere DMV, sys.resource_stats, im Kontext der master-Datenbank des Azure SQL-Datenbankservers ausführen, um die Ressourcennutzung für alle Azure SQL-Datenbankdatenbanken anzuzeigen, die dem Server zugeordnet sind. Diese Ansicht zeigt weniger detailliert die Ressourcennutzung alle fünf Minuten an (die für 14 Tage gespeichert wird).

    Lassen Sie dieses Fenster des Abfrage-Editors geöffnet. Sie werden es in der nächsten Übung noch einmal ausführen.

  3. Lassen Sie die Arbeitsauslastung abschließen, und vermerken Sie ihre Gesamtdauer. Nach Beendigung der Arbeitsauslastung sollten Ergebnisse wie die folgende Ausgabe angezeigt. Anschließend sollte eine Rückkehr zur Eingabeaufforderung erfolgen.

    [datetime] [ostress PID] Total IO waits: 0, Total IO wait time: 0 (ms)
[datetime] [ostress PID] OSTRESS exiting normally, elapsed time: 00:01:22.637

    Die Dauer kann variieren, in der Regel beträgt sie jedoch mindestens 1–3 Minuten. Lassen Sie den Vorgang unbedingt zu Ende ausführen. Anschließend gelangen Sie zurück zur Eingabeaufforderung.

Verwenden des Abfragespeichers zur weiteren Analyse

Der Abfragespeicher ist eine Funktion in SQL Server, um die Leistung bei der Ausführung von Abfragen zu verfolgen. Die Leistungsdaten werden in der Benutzerdatenbank gespeichert. Der Abfragespeicher ist für in SQL Server erstellte Datenbanken standardmäßig deaktiviert, in Azure SQL-Datenbank (und Azure SQL Managed Instance) jedoch standardmäßig aktiviert.

Der Abfragespeicher enthält verschiedene Systemkatalogsichten zur Anzeige von Leistungsdaten. SSMS stellt mithilfe dieser Ansichten Berichte bereit.

  1. Öffnen Sie mit dem Objekt-Explorer in SSMS den Ordner Abfragespeicher, um nach dem Bericht für Abfragen mit dem höchsten Ressourcenverbrauch zu suchen.

    Screenshot of the Query Store.

  2. Wählen Sie den Bericht aus, um herauszufinden, welche Abfragen im Durchschnitt die meisten Ressourcen verbraucht haben, und um Einzelheiten zur Ausführung dieser Abfragen zu erfahren. Basierend auf der bis zu diesem Punkt ausgeführten Arbeitsauslastung sollte der Bericht in etwa wie im folgenden Bild aussehen:

    Screenshot of the top query report.

    Die angezeigte Abfrage ist die SQL-Abfrage aus der Arbeitsauslastung für Kundenumsätze. Dieser Bericht verfügt über drei Komponenten: Abfragen mit hoher Gesamtdauer (diese Metrik können Sie ändern), den zugehörigen Abfrageplan und die zugehörige Laufzeitstatistik sowie den zugehörige Abfrageplan in einer visuellen Darstellung.

  3. Klicken Sie auf das Balkendiagramm der Abfrage (query_id fällt für Ihr System möglicherweise anders aus). Die Ergebnisse sollten wie im folgenden Bild aussehen:

    Screenshot of the query ID.

    Die Gesamtdauer der Abfrage und der Abfragetext werden angezeigt.

  4. Rechts von diesem Balkendiagramm befindet sich ein Diagramm für Statistiken zum Abfrageplan der Abfrage. Zeigen Sie auf den Punkt, der dem Plan zugeordnet ist. Die Ergebnisse sollten wie im folgenden Bild aussehen:

    Screenshot of slow query statistics.

    Beachten Sie die Durchschnittsdauer der Abfrage. Ihre Zeiten weichen unter Umständen ab. Vergleichen Sie jedoch diese Durchschnittsdauer mit der durchschnittlichen Wartezeit für diese Abfrage. Später führen Sie eine Leistungsverbesserung ein und führen diesen Vergleich noch einmal aus, um den Unterschied zu untersuchen.

  5. Der letzte Bestandteil ist der visuell dargestellte Abfrageplan. Der Abfrageplan für diese Abfrage sieht wie im folgenden Bild aus:

    Screenshot of the workload query plan.

    Diese Datenbanktabelle enthält so wenig Zeilen, dass sie keinen Plan benötigt – dies kann ineffizient sein. Die Abfrageoptimierung führt nicht zu einer messbaren Leistungsverbesserung. Möglicherweise wird im Plan eine Warnung zu fehlenden Statistiken für eine der Spalten der gruppierten Indexsuche angezeigt. Dies hat keine Auswirkungen auf die Gesamtleistung.

  6. Nach dem Bericht Abfragen mit dem höchsten Ressourcenverbrauch ist in SSMS auch der Bericht Statistik der Abfragewartezeit aufgeführt. Aus früheren Diagnosen wissen Sie, dass eine hohe Anzahl von Anforderungen konstant den Status RUNNABLE (AUSFÜHRBAR) und eine CPU-Auslastung von fast 100 % aufwies. Der Abfragespeicher enthält Berichte, um mögliche Leistungsengpässe aufzudecken, die durch das Warten auf Ressourcen entstehen. Klicken Sie auf den Bericht, und zeigen Sie auf das Balkendiagramm. Die Ergebnisse sollten wie im folgenden Bild aussehen:

    Screenshot of the top wait statistics.

    Die häufigste Wartekategorie „CPU“ (entspricht dem Wartetyp (wait_type) SOS_SCHEDULER_YIELD, der in sys.dm_os_wait_stats zu sehen ist) und die durchschnittliche Wartezeit werden angezeigt.

  7. Klicken Sie im Bericht auf das CPU-Balkendiagramm. Die Abfrage, die am längsten auf die CPU wartet, ist die Abfrage Ihrer Arbeitsauslastung.

    Screenshot of the top wait statistics query.

    Beachten Sie, dass die durchschnittliche Wartezeit für die CPU in dieser Abfrage einen hohen Prozentanteil der durchschnittlichen Gesamtdauer der Abfrage darstellt.

    Nach den bisherigen Erkenntnissen erfordert die Arbeitsauslastung ohne jegliche Abfrageoptimierung mehr CPU-Kapazität, als Sie für Ihre Instanz von Azure SQL-Datenbank bereitgestellt haben.

  8. Schließen Sie beide Berichte des Abfragespeichers. Sie werden in der nächsten Übung dieselben Berichte verwenden.

Beobachten der Leistung mit Azure Monitor

Nun wenden Sie eine andere Methode an, um die Ressourcennutzung der Arbeitsauslastung anzuzeigen. Azure Monitor bietet Leistungsmetriken, die Sie über verschiedene Wege anzeigen können, z. B. über das Azure-Portal.

  1. Öffnen Sie das Azure-Portal, und suchen Sie Ihre Instanz der SQL Datenbank „AdventureWorks“. Wählen Sie im Bereich Übersicht für die Datenbank die Registerkarte Überwachung aus. Die Standardansicht im Bereich Überwachung lautet Compute-Auslastung:

    Screenshot of the Azure portal with a slow query.

    In diesem Beispiel liegt die CPU-Auslastung für den aktuellen Zeitbereich bei nahezu 100 Prozent. Dieses Diagramm zeigt die Ressourcennutzung (standardmäßig anhand der CPU und der E/A) während der letzten Stunde und wird ständig aktualisiert. Klicken Sie auf das Diagramm, damit Sie es anpassen und die Nutzung anderer Ressourcen untersuchen können.

  2. Klicken Sie im SQL-Datenbank-Menü auf Metriken hinzufügen. Es gibt eine alternative Methode, die Metriken zur Computenutzung sowie weitere Metriken anzuzeigen, die Azure Monitor automatisch für Azure SQL-Datenbank im Metrik-Explorer erfasst.

    Hinweis

    Computenutzung eine vordefinierte Ansicht des Metrik-Explorers. Wenn Sie die Dropdownliste Metrik im Fenster Metriken hinzufügen auswählen, werden die folgenden Ergebnisse angezeigt:

    Screenshot of Azure Monitor metrics.

    Wie im Screenshot gezeigt, gibt es mehrere Metriken, die über den Metrik-Explorer angezeigt werden können. Die Standardansicht des Metrik-Explorers umfasst einen Zeitraum von 24 Stunden, für den sich Werte mit einer Genauigkeit von 5 Minuten anzeigen lassen. In der Ansicht für die Computenutzung wird die letzte Stunde mit einer minutengenauen Auflösung dargestellt (die Sie anpassen können). Wenn Sie dieselbe Ansicht erhalten möchten, klicken Sie auf CPU-Prozentsatz, und ändern Sie den Erfassungszeitraum in eine Stunde. Die Granularität wird in eine Minute geändert und sollte nun wie im folgenden Bild aussehen:

    Screenshot of Azure Monitor metrics, including CPU after 1 minute.

    Die Standardeinstellung ist ein Liniendiagramm, aber die Explorer-Ansicht ermöglicht es Ihnen, den Diagrammtyp zu ändern. Der Metrik-Explorer bietet viele verschiedene Optionen, z. B. die Anzeige mehrerer Metriken im selben Diagramm.

Azure Monitor-Protokolle

In dieser Übung haben Sie zwar kein Azure Monitor-Protokoll eingerichtet, es ist jedoch interessant herauszufinden, wie ein Protokoll für das Verwendungsszenario einer CPU-Ressource aussehen könnte. Azure Monitor-Protokolle können einen viel umfangreicheren Verlaufsdatensatz liefern als Azure-Metriken.

Wenn Sie Azure Monitor-Protokolle mit einem Log Analytics-Arbeitsbereich konfiguriert haben, können Sie mithilfe der folgenden Kusto-Abfrage dieselben Ergebnisse für die CPU-Auslastung der Datenbank anzeigen:

AzureMetrics
| where MetricName == 'cpu_percent'
| where Resource == "ADVENTUREWORKS"
| project TimeGenerated, Average
| render columnchart

Die Ergebnisse sollten wie im folgenden Bild aussehen:

Screenshot of a query measuring CPU.

Azure Monitor-Protokolle unterliegen einer Verzögerung, wenn die Protokolldiagnose zum ersten Mal für eine Datenbank konfiguriert wird. Es kann daher etwas dauern, bis diese Ergebnisse angezeigt werden.

In dieser Übung haben Sie erfahren, wie Sie ein gängiges SQL Server-Leistungsszenario beobachten und die Details analysieren, um über eine mögliche Lösung zur Leistungsverbesserung zu entscheiden. In der nächsten Lerneinheit machen Sie sich mit den Methoden zur Beschleunigung und Optimierung der Leistung vertraut.