Ćwiczenie — monitorowanie wydajności i rozwiązywanie problemów z nią

10 min

W tym ćwiczeniu dowiesz się, jak monitorować i rozwiązywać problemy z wydajnością usługi Azure SQL przy użyciu znanych i nowych narzędzi i możliwości.

Konfigurowanie: wdrażanie usługi Azure SQL Database przy użyciu skryptów

Sesja terminalu po prawej stronie usługi Azure Cloud Shell umożliwia interakcję z platformą Azure przy użyciu przeglądarki. W tym ćwiczeniu uruchomisz skrypt, aby utworzyć środowisko , wystąpienie usługi Azure SQL Database z bazą AdventureWorks danych. (Mniejsza, prostsza przykładowa AdventureWorksLT baza danych jest używana, ale wywołamy ją AdventureWorks , aby zapobiec nieporozumieniu). W skrypcie zostanie wyświetlony monit o podanie hasła i lokalnego adresu IP, aby umożliwić urządzeniu nawiązywanie połączenia z bazą danych.

Wykonanie tego skryptu trwa około 3–5 min. Pamiętaj o zanotowaniu hasła, unikatowego identyfikatora i regionu. Te informacje nie będą ponownie wyświetlane.

Zacznij od uzyskania lokalnego adresu IP. Upewnij się, że odłączono się od wszelkich usług sieci VPN i otwarto lokalny terminal programu PowerShell na urządzeniu. Uruchom następujące polecenie i zanotuj wynikowy adres IP:
```
(Invoke-WebRequest -Uri "https://ipinfo.io/ip").Content
```

W usłudze Azure Cloud Shell po prawej stronie wprowadź następujący kod, a po wyświetleniu monitu podaj złożone hasło i lokalny publiczny adres IP pobrany w poprzednim kroku. Naciśnij Enter, aby uruchomić ostatni wiersz skryptu.

$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)"

Uruchom następujący skrypt w usłudze Azure Cloud Shell. Zapisz dane wyjściowe; Te informacje będą potrzebne w całym module. Naciśnij Enter po wklejeniu kodu, aby ostatni wiersz kodu wydrukował potrzebne dane wyjściowe.
```
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
```
Napiwek

Zapisz dane wyjściowe i zanotuj hasło, unikatowy identyfikator i serwer. Te elementy będą potrzebne w całym module.

Uruchom następujący skrypt, aby wdrożyć wystąpienie usługi Azure SQL Database i serwer logiczny z przykładem AdventureWorks. Ten skrypt dodaje adres IP jako regułę zapory, włącza usługę Advanced Data Security i tworzy konto magazynu do użycia w pozostałych ćwiczeniach w tym module. Wykonanie skryptu może potrwać kilka minut i zostanie wstrzymane kilka razy. Poczekaj na wiersz polecenia.

# 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"

Na urządzeniu lokalnym otwórz program SQL Server Management Studio (SSMS), aby utworzyć nowe połączenie z serwerem logicznym.

W oknie dialogowym Łączenie z serwerem logowania podaj następujące informacje:

Pole	Wartość
Typ serwera	Aparat bazy danych (ustawienie domyślne).
Nazwa serwera	$serverName zwrócony w usłudze Cloud Shell oraz pozostałą część identyfikatora URI. Na przykład: aw-server`<unique ID>`.database.windows.net.
Uwierzytelnianie	Uwierzytelnianie programu SQL Server (ustawienie domyślne).
Zaloguj się	cloudadmin AdminSqlLogin przypisany w kroku 1 tego ćwiczenia.
Hasło	Hasło podane w kroku 1 tego ćwiczenia.
Remember password (Zapamiętaj hasło)	checked

Wybierz pozycję Połącz.

Uwaga

W zależności od konfiguracji lokalnej (np. sieci VPN) adres IP klienta może się różnić od adresu IP, który był używany przez witrynę Azure Portal podczas wdrażania. Jeśli tak się stanie, zostanie wyświetlony następujący komunikat: "Twój adres IP klienta nie ma dostępu do serwera. Zaloguj się do konta platformy Azure i utwórz nową regułę zapory, aby włączyć dostęp". Jeśli zostanie wyświetlony ten komunikat, zaloguj się przy użyciu konta używanego dla piaskownicy i dodaj regułę zapory dla adresu IP klienta. Wszystkie te kroki można wykonać przy użyciu kreatora w programie SSMS.

Przygotowywanie ćwiczenia przez ładowanie i edytowanie skryptów

Wszystkie skrypty dla tego ćwiczenia można znaleźć w folderze 04-Performance\monitor_and_scale w sklonowanym repozytorium GitHub lub pobranym pliku zip. Przygotujmy ćwiczenie, ładując i edytując skrypty.

W programie SSMS w Eksplorator obiektów rozwiń folder Databases i wybierz bazę danych AdventureWorks.

Wybierz pozycję Plik Otwórz>plik> i otwórz skrypt dmexecrequests.sql. Tekst w oknie edytora zapytań powinien wyglądać następująco:

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;

Użyj tej samej metody w programie SSMS do załadowania skryptu dmdbresourcestats.sql. Tekst w nowym oknie edytora zapytań powinien wyglądać następująco:
```
SELECT * FROM sys.dm_db_resource_stats;
```
Ten dynamiczny widok zarządzania będzie śledzić ogólne użycie zasobów w obciążeniu względem usługi Azure SQL Database. Śledzeniem będą na przykład objęte procesor CPU, operacje We/Wy i pamięć.
Otwórz i zmodyfikuj skrypt sqlworkload.cmd (który będzie używać programu ostress.exe).
- Zastąp wartość unique_id zapisaną ze skryptu wdrażania w nazwie serwera.
- Zastąp hasło użyte do logowania serwera usługi Azure SQL Database dla elementu -P parameter.
- Zapisz zmiany skryptu.

Uruchamianie obciążenia

W tym zadaniu uruchomisz obciążenie w zapytaniu T-SQL, aby obserwować wydajność symulowania współbieżnych użytkowników.

Użyj programu SSMS, aby otworzyć plik skryptu topcustomersales.sql w celu obserwowania zapytania. Nie będziesz uruchamiać zapytania z programu SSMS. Tekst w oknie edytora zapytań powinien wyglądać następująco:
```
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
```
Ta baza danych jest mała. Zapytanie w celu pobrania listy klientów i skojarzonych z nimi informacji o sprzedaży uporządkowanej przez klientów z największą sprzedażą nie powinno generować dużego zestawu wyników. To zapytanie można dostroić, zmniejszając liczbę kolumn w zestawie wyników, ale są one potrzebne do celów demonstracyjnych tego ćwiczenia.
W wierszu polecenia programu PowerShell wprowadź następujące polecenie, aby przejść do odpowiedniego katalogu na potrzeby tego ćwiczenia. Zastąp <base directory> ciąg identyfikatorem użytkownika i ścieżką dla tego modułu :
```
cd <base directory>\04-Performance\monitor_and_scale
```

Uruchom obciążenie przy użyciu następującego polecenia:

.\sqlworkload.cmd

W tym skrypcie będzie występować 10 współbieżnych użytkowników, którzy dwukrotnie uruchamiają zapytanie dotyczące obciążenia. Zwróć uwagę, że skrypt uruchamia pojedynczą partię, ale wykonuje pętle 10 000 razy. Przypisuje również wynik do zmiennej, eliminując przez to niemal cały ruch związany z zestawem wyników do klienta. Nie jest to konieczne, ale pomaga pokazać "czyste" obciążenie procesora CPU uruchomione całkowicie na serwerze.

Napiwek

Jeśli nie widzisz zachowania użycia procesora CPU w tym obciążeniu dla danego środowiska, możesz dostosować parametr -n parameter dla liczby użytkowników i parametr -r parameter dla iteracji.

Dane wyjściowe w wierszu polecenia powinny wyglądać podobnie do następujących danych wyjściowych:

[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...

Obserwowanie wydajności obciążenia

Użyjmy załadowanych wcześniej zapytań DMV, aby zaobserwować wydajność.

Uruchom w programie SSMS zapytanie, które wcześniej załadowano w celu monitorowania polecenia dm_exec_requests (dmexecrequests.sql), aby obserwować aktywne żądania. Uruchom to zapytanie pięć lub sześć razy i zwróć uwagę na niektóre wyniki:
```
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;
```
Powinno zostać wyświetlonych wiele żądań o stanie RUNNABLE, a last_wait_type wartość to SOS_SCHEDULER_YIELD. Jednym ze wskaźników wielu RUNNABLE żądań i wielu SOS_SCHEDULER_YIELD oczekiwań jest możliwy brak zasobów procesora CPU dla aktywnych zapytań.

Uwaga

Może zostać wyświetlone co najmniej jedno aktywne żądanie z poleceniem SELECT i wartością wait_type XE_LIVE_TARGET_TVF. Są to zapytania, które uruchamiają usługi zarządzane przez firmę Microsoft. Ułatwiają one korzystanie z funkcji, takich jak szczegółowe informacje o wydajności, przy użyciu zdarzeń rozszerzonych. Firma Microsoft nie publikuje szczegółowych informacji o tych sesjach.

Pozostaw to okno edytora zapytań otwarte. To zapytanie zostanie uruchomione ponownie w następnym ćwiczeniu.
Uruchom zapytanie w załadowanym wcześniej programie SSMS w celu monitorowania widoku sys.dm_db_resource_stats (dmdbresourcestats.sql). Uruchom zapytanie trzy- lub czterokrotnie, aby wyświetlić wyniki tego dynamicznego widoku zarządzania (DMV).
```
SELECT * FROM sys.dm_db_resource_stats;
```
W tym dynamicznym widoku zarządzania co 15 sekund jest rejestrowana migawka użycia zasobów bazy danych (przechowywana przez 1 godzinę). W przypadku kilku migawek powinna być wyświetlana kolumna avg_cpu_percent zawierająca wartości zbliżone do 100 procent. Jest to objaw obciążenia przekraczającego limity zasobów procesora dla bazy danych.

W przypadku środowiska lokalnego programu SQL Server zwykle używa się narzędzia specyficznego dla systemu operacyjnego do śledzenia ogólnego użycia zasobów, takiego jak procesor CPU. W tym celu można na przykład skorzystać z Monitora wydajności systemu Windows. Jeśli uruchomisz ten przykład na lokalnym serwerze SQL Server lub programie SQL Server na maszynie wirtualnej z dwoma procesorami CPU, na serwerze zobaczysz prawie 100 procent użycia procesora CPU.

Uwaga

Możesz uruchomić inny dynamiczny widok zarządzania, sys.resource_stats, w kontekście bazy danych serwera master usługi Azure SQL Database, aby wyświetlić użycie zasobów dla wszystkich baz danych usługi Azure SQL Database skojarzonych z serwerem. Ten widok jest mniej szczegółowy i pokazuje użycie zasobów co pięć minut (przechowywane przez 14 dni).

Pozostaw to okno edytora zapytań otwarte. To zapytanie zostanie uruchomione ponownie w następnym ćwiczeniu.
Pozwól na ukończenie obciążenia i zanotuj całkowity czas jego trwania. Po ukończeniu obciążenia powinny zostać wyświetlone wyniki podobne do poniższych danych wyjściowych, a następnie powinien nastąpić powrót do wiersza polecenia:
```
[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
```
Czas trwania może się różnić, ale zazwyczaj wynosi co najmniej 1–3 min. Pozwól na zakończenie działania. Po zakończeniu obciążenia nastąpi powrót do wiersza polecenia.

Korzystanie z magazynu zapytań w celu dalszej analizy

Magazyn zapytań jest funkcją usługi SQL Server umożliwiającą śledzenie wykonywania wydajności zapytań. Dane dotyczące wydajności są przechowywane w bazie danych użytkownika. Magazyn zapytań domyślnie nie jest włączony dla baz danych utworzonych w usłudze SQL Server, natomiast jest włączony dla usługi Azure SQL Database (i usługi Azure SQL Managed Instance).

Magazyn zapytań zawiera szereg systemowych widoków wykazu umożliwiających wyświetlanie danych dotyczących wydajności. Program SSMS udostępnia raporty przy użyciu tych widoków.

Używając Eksploratora obiektów w programie SSMS, otwórz folder Magazyn zapytań i znajdź raport Najważniejsze zapytania korzystające z zasobów.
Wybierz raport, aby dowiedzieć się, jakie zapytania zużyły średnio najwięcej zasobów, oraz poznać szczegóły dotyczące wykonywania tych zapytań. W oparciu o dotychczasowy przebieg obciążenia raport powinien wyglądać podobnie jak na poniższej ilustracji:

Pokazane zapytanie to zapytanie SQL z obciążenia dotyczącego sprzedaży dla klienta. Ten raport zawiera trzy składniki: zapytania o wysokim łącznym czasie trwania (można zmienić metrykę), skojarzony plan zapytania i statystyki środowiska uruchomieniowego oraz skojarzony plan zapytania w postaci mapy wizualizacji.
Wybierz wykres słupkowy dla zapytania (identyfikator query_id może być inny w Twoim systemie). Wyniki powinny wyglądać tak jak na poniższej ilustracji:

Zostanie wyświetlony łączny czas trwania zapytania i tekst zapytania.
Po prawej stronie tego wykresu słupkowego znajduje się wykres statystyk planu zapytania skojarzonego z zapytaniem. Umieść kursor nad kropką skojarzoną z planem. Wyniki powinny wyglądać tak jak na poniższej ilustracji:

Zwróć uwagę na średni czas trwania zapytania. W Twoim przypadku czasy mogą być inne, ale najważniejsze będzie porównanie tego średniego czasu trwania ze średnim czasem oczekiwania dla tego zapytania. Później wprowadzimy ulepszenia wydajności i ponownie przeprowadzimy porównanie, aby zobaczyć różnicę.
Składnik końcowy jest wizualnym planem zapytania. Plan zapytania dla tego zapytania wygląda tak jak na poniższej ilustracji:

Ta tabela bazy danych zawiera tak mało wierszy, że nie potrzebuje planu; może to być nieefektywne. Dostrajanie zapytania nie poprawi wydajności przez wymierną ilość. W planie może zostać wyświetlone ostrzeżenie dotyczące braku statystyk dla jednej z kolumn wyszukiwania indeksu klastrowanego. Nie ma to jednak wpływu na ogólną wydajność.
Po raporcie Najwięcej zapytań zużywających zasoby w programie SSMS jest raport o nazwie Statystyki oczekiwania zapytań. Z wcześniejszej diagnostyki wiemy, że duża liczba żądań stale miała stan RUNNABLE (możliwe do uruchomienia) oraz zużywała prawie 100 procent zasobów procesora. Magazyn zapytań jest dostarczany z raportami umożliwiającymi przyjrzenie się potencjalnym wąskim gardłom wydajności związanym z oczekiwaniem na zasoby. Wybierz ten raport i umieść kursor nad wykresem słupkowym. Wyniki powinny wyglądać tak jak na poniższej ilustracji:

Można zauważyć, że najważniejszymi kategoriami oczekiwania są procesor (jest to odpowiednik kategorii wait_type SOS_SCHEDULER_YIELD znajdującej się w widoku sys.dm_os_wait_stats) i średni czas oczekiwania.
Wybierz wykres słupkowy dotyczący procesora w raporcie. Najważniejsze zapytanie, oczekujące na procesor CPU, to zapytanie z obciążenia, którego używasz.

Zwróć uwagę, że średni czas oczekiwania procesora CPU w tym zapytaniu to wysoki procent ogólnego średniego czasu trwania zapytania.

Biorąc pod uwagę dowody bez dostrajania zapytań, obciążenie wymaga większej pojemności procesora CPU niż wdrożono dla naszego wystąpienia usługi Azure SQL Database.
Zamknij oba raporty magazynu zapytań. Tych samych raportów użyjesz w następnym ćwiczeniu.

Obserwowanie wydajności za pomocą usługi Azure Monitor

Użyjmy innej metody, aby wyświetlić użycie zasobów naszego obciążenia. Usługa Azure Monitor udostępnia metryki wydajności, które można wyświetlać na różne sposoby, w tym za pośrednictwem witryny Azure Portal.

Otwórz witrynę Azure Portal, a następnie znajdź swoje wystąpienie bazy danych AdventureWorks SQL Database. W okienku Przegląd bazy danych wybierz kartę Monitorowanie . Domyślnym widokiem w okienku Monitorowanie jest użycie zasobów obliczeniowych:

W tym przykładzie procent procesora CPU wynosi prawie 100 procent dla ostatniego zakresu czasu. Na tym wykresie przedstawiono użycie zasobów (procesor CPU i operacje we/wy są domyślne) w ciągu ostatniej godziny i jest stale odświeżane. Wybierz wykres, aby dostosować go, aby przyjrzeć się innej użyciu zasobów.
W menu bazy danych SQL wybierz pozycję Dodaj metryki. Innym sposobem wyświetlenia metryk wykorzystania zasobów obliczeniowych i innych metryk, które są automatycznie zbierane przez usługę Azure Monitor dla usługi Azure SQL Database, jest użycie Eksploratora metryk.

Uwaga

Wykorzystanie zasobów obliczeniowych to wstępnie zdefiniowany widok Eksploratora metryk. Jeśli wybierzesz listę rozwijaną Metryka w oknie Dodawanie metryk , zobaczysz następujące wyniki:

Jak pokazano na zrzucie ekranu, istnieje kilka metryk, których można użyć do wyświetlania w Eksploratorze metryk. Domyślny widok Eksploratora metryk dotyczy 24-godzinnego okresu z pięciominutowym stopniem szczegółowości. Widok Wykorzystanie zasobów obliczeniowych jest ostatnią godziną z jednominutowym szczegółowością (którą można zmienić). Aby wyświetlić ten sam widok, wybierz pozycję Procent użycia procesora CPU i zmień przechwytywanie na jedną godzinę. Stopień szczegółowości zmieni się na jedną minutę i powinien wyglądać tak jak na poniższej ilustracji:

Ustawieniem domyślnym jest wykres liniowy, ale widok Eksploratora umożliwia zmianę typu wykresu. Eksplorator metryk ma wiele opcji, w tym możliwość wyświetlania wielu metryk na tym samym wykresie.

Dzienniki usługi Azure Monitor

W tym ćwiczeniu dziennik usługi Azure Monitor nie został skonfigurowany, ale warto przyjrzeć się, jak może wyglądać dziennik w przypadku scenariusza użycia zasobów procesora. Dzienniki usługi Azure Monitor zapewniają znacznie dłuższy rejestr danych historycznych niż usługa Azure Metrics.

Jeśli skonfigurowano dzienniki usługi Azure Monitor z obszarem roboczym usługi Log Analytics, możesz użyć następującego zapytania Kusto, aby wyświetlić te same wyniki użycia procesora CPU dla bazy danych:

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

Wyniki będą wyglądać tak jak na poniższej ilustracji:

Zrzut ekranu przedstawiający zapytanie do pomiaru procesora.

Dzienniki usługi Azure Monitor mają opóźnienie podczas pierwszego konfigurowania diagnostyki dzienników dla bazy danych, dlatego wyświetlenie tych wyników może zająć trochę czasu.

W tym ćwiczeniu nauczyliśmy się, jak obserwować typowy scenariusz wydajności programu SQL Server i szczegółowo poznaliśmy sposób wybierania potencjalnych rozwiązań zwiększających wydajność. W następnej lekcji dowiesz się, jak przyspieszyć i dostosować wydajność.