Alıştırma - Performansı izleme ve sorunlarını giderme

  • 10 dakika

Bu alıştırmada, tanıdık ve yeni araçları ve özellikleri kullanarak Azure SQL ile ilgili bir performans sorununu izlemeyi ve gidermeyi öğreneceksiniz.

Kurulum: Azure SQL Veritabanı dağıtmak için betikleri kullanma

Sağdaki Azure Cloud Shell terminal oturumu, tarayıcı kullanarak Azure ile etkileşim kurmanızı sağlar. Bu alıştırmada, veritabanıyla AdventureWorks Azure SQL Veritabanı örneği olan ortamınızı oluşturmak için bir betik çalıştıracaksınız. (Daha küçük, daha basit örnek AdventureWorksLT veritabanı kullanılır, ancak karışıklığı önlemek için bu AdventureWorks veritabanını çağıracağız.) Betikte, cihazınızın veritabanına bağlanmasını sağlamak için bir parola ve yerel IP adresiniz istenir.

Bu betiğin tamamlanması 3-5 dakika sürer. Parolanızı, benzersiz kimliğinizi ve bölgenizi not aldığınızdan emin olun. Bunlar tekrar gösterilmeyecektir.

  1. Başlangıç olarak yerel IP adresinizi alın. Hiçbir VPN hizmetine bağlı olmadığınızdan ve cihazınızda yerel bir PowerShell terminali açtığınızdan emin olun. Aşağıdaki komutu çalıştırın ve sonuçta elde edilen IP adresini not edin:

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

  2. Sağdaki Azure Cloud Shell'de aşağıdaki kodu girin ve istendiğinde karmaşık bir parola ve önceki adımda aldığınız yerel genel IP adresinizi girin. Betiğin son satırını çalıştırmak için Enter tuşuna basın.

    $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. Azure Cloud Shell'de aşağıdaki betiği çalıştırın. Çıkışı kaydedin; modül boyunca bu bilgilere ihtiyacınız olacaktır. Kodu yapıştırdıktan sonra Enter tuşuna basın; böylece son kod satırı ihtiyacınız olan çıkışı yazdırır.

    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

    Bahşiş

    Çıkışı kaydedin ve parolanızı, benzersiz kimliğinizi ve sunucunuzu not edin. Modül boyunca bu öğelere ihtiyacınız olacak.

  4. Aşağıdaki betiği çalıştırarak AdventureWorks örneğiyle bir Azure SQL Veritabanı ve mantıksal sunucu örneğini dağıtın. Bu betik IP adresinizi güvenlik duvarı kuralı olarak ekler, Gelişmiş Veri Güvenliği'ni etkinleştirir ve bu modüldeki kalan alıştırmalarda kullanmak üzere bir depolama hesabı oluşturur. Betiğin tamamlanması birkaç dakika sürebilir ve birkaç kez duraklatılır. Komut istemini bekleyin.

    # 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. Mantıksal sunucunuza yeni bir bağlantı oluşturmak için yerel cihazınızda SQL Server Management Studio'yu (SSMS) açın.

  6. Sunucuya Bağlan oturum açma iletişim kutusunda aşağıdaki bilgileri sağlayın:

    Alan Değer
    Sunucu türü Veritabanı Altyapısı (varsayılan).
    Sunucu adı Cloud Shell'de döndürülen $serverName ve URI'nin geri kalanı. Örneğin: aw-server<unique ID>.database.windows.net.
    Kimlik Doğrulaması SQL Server Kimlik Doğrulaması (varsayılan).
    Oturum aç cloudadmin Bu alıştırmanın 1. adımında atanan adminSqlLogin.
    Password Bu alıştırmanın 1. adımında sağladığınız parola.
    Parolayı unutmayın checked

  7. Bağlan'ı seçin.

    Screenshot of connection dialog for SQL Database in SSMS.

    Dekont

    Yerel yapılandırmanıza (örneğin VPN) bağlı olarak istemci IP adresiniz dağıtım sırasında Azure portalın kullandığı IP adresinden farklı olabilir. Varsa şu iletiyi alırsınız: "İstemci IP adresinizin sunucuya erişimi yok. Bir Azure hesabında oturum açın ve erişimi etkinleştirmek için yeni bir güvenlik duvarı kuralı oluşturun." Bu iletiyi alırsanız, korumalı alan için kullandığınız hesabı kullanarak oturum açın ve istemci IP adresiniz için bir güvenlik duvarı kuralı ekleyin. Bu adımların tümünü, SQL Server Management Studio’daki sihirbazı kullanarak tamamlayabilirsiniz.

Betikleri yükleyip düzenleyerek alıştırmaya hazırlanma

Bu alıştırmanın tüm betiklerini kopyaladığınız GitHub deposundaki 04-Performance\monitor_and_scale klasöründe veya indirdiğiniz zip dosyasında bulabilirsiniz. Şimdi betikleri yükleyip düzenleyerek alıştırmaya hazırlanın.

  1. SSMS'de, Nesne Gezgini Veritabanları klasörünü genişletin ve AdventureWorks veritabanını seçin.

  2. Dosya>Dosya Aç'ı> seçin ve dmexecrequests.sql betiğini açın. Sorgu düzenleyicisi pencereniz aşağıdaki metin gibi görünmelidir:

    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. SSMS'de aynı yöntemi kullanarak dmdbresourcestats.sql betiğini yükleyin. Yeni bir sorgu düzenleyicisi penceresi aşağıdaki metin gibi görünmelidir:

    SELECT * FROM sys.dm_db_resource_stats;

    Bu dinamik yönetim görünümü (DMV), Azure SQL Veritabanı’nda iş yükünüzün genel kaynak kullanımını izler. Örneğin, CPU, G/Ç ve belleği izler.

  4. sqlworkload.cmd betiğini açın ve düzenleyin (ostress.exe programını kullanır).

    • unique_id Dağıtım betiğinden kaydettiğinizi sunucu adına yazın.
    • için Azure SQL Veritabanı sunucusu için oturum açma için kullandığınız parolayı değiştirin-P parameter.
    • Değişiklikleri betikte kaydedin.

İş yükünü çalıştırma

Bu görevde T-SQL sorgusunda bir iş yükü çalıştırarak eşzamanlı kullanıcıların performansının benzetimini yapacaksınız.

  1. Sorguyu gözlemlemek için topcustomersales.sql betik dosyasını açmak için SSMS'yi kullanın. Sorguyu SQL Server Management Studio’dan çalıştırmayacaksınız. Sorgu düzenleyicisi pencereniz aşağıdaki metin gibi görünmelidir:

    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

    Bu veritabanı küçük. En çok satışa sahip müşteriler tarafından sipariş edilen müşterilerin listesini ve ilişkili satış bilgilerini alma sorgusu büyük bir sonuç kümesi oluşturmamalıdır. Sonuç kümesindeki sütun sayısını azaltarak bu sorguyu ayarlayabilirsiniz, ancak bunlar bu alıştırmanın tanıtım amacıyla gereklidir.

  2. PowerShell komut isteminden aşağıdaki komutu girerek bu alıştırma için doğru dizine gidin. değerini bu modül için kullanıcı kimliğiniz ve yolunuzla değiştirin <base directory> :

    cd <base directory>\04-Performance\monitor_and_scale

  3. Aşağıdaki komutla iş yükünü çalıştırın:

    .\sqlworkload.cmd

    Bu betik, iş yükü sorgusunu iki kez çalıştıran 10 eşzamanlı kullanıcı kullanır. Betiğin tek bir toplu iş çalıştırdığına ama 10.000 kez döngü yaptığına dikkat edin. Ayrıca sonucu bir değişkene atadığından istemciye yönelik neredeyse tüm sonuç kümesi trafiğini ortadan kaldırır. Bu gerekli değildir, ancak tamamen sunucuda "saf" bir CPU iş yükü çalıştırmasının gösterilmesine yardımcı olur.

    Bahşiş

    Ortamınız için bu iş yüküyle CPU kullanım davranışını görmüyorsanız, kullanıcı sayısı için -n parameter parametresini ve yinelemeler için de -r parameter parametresini ayarlayabilirsiniz.

    Komut istemindeki çıkış aşağıdaki çıkışa benzer olmalıdır:

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

İş yükünün performansını gözlemleme

Şimdi performansı gözlemlemek için daha önce yüklediğiniz DMV sorgularını kullanalım.

  1. Daha önce dm_exec_requests izlemesi için yüklediğiniz sorguyu (dmexecrequests.sql) SQL Server Management Studio’da çalıştırarak etkin istekleri gözlemleyin. Bu sorguyu beş veya altı kez çalıştırıp sonuçlardan bazılarını gözlemleyin:

    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;

    İsteklerin çoğunun durumunun RUNNABLEolduğunu ve last_wait_type olduğunu SOS_SCHEDULER_YIELDgörmeniz gerekir. Birçok RUNNABLE isteğin ve birçok SOS_SCHEDULER_YIELD beklemenin bir göstergesi, etkin sorgular için cpu kaynaklarının eksik olmasıdır.

    Dekont

    ve komutuyla SELECTwait_typeXE_LIVE_TARGET_TVFbir veya daha fazla etkin istek görebilirsiniz. Bunlar, Microsoft tarafından yönetilen hizmetler tarafından çalıştırılan sorgulardır. Genişletilmiş olayları kullanarak performans içgörüleri gibi olanaklara yardımcı olur. Microsoft bu oturumların ayrıntılarını yayımlamaz.

    Bu sorgu düzenleyici penceresini açık bırakın. Sonraki alıştırmada bunu tekrar çalıştıracaksınız.

  2. SSMS'de daha önce sys.dm_db_resource_stats izlemesi için çalıştırdığınız sorguyu (dmdbresourcestats.sql) çalıştırın. Bu DMV'nin sonuçlarını görmek için sorguyu üç veya dört kez çalıştırın.

    SELECT * FROM sys.dm_db_resource_stats;

    Bu DMV, 15 saniyede bir veritabanı için kaynak kullanımının anlık görüntüsünü kaydeder (1 saat süreyle saklanır). Birkaç anlık görüntüde avg_cpu_percent sütununun %100’e yakın olduğunu göreceksiniz. Bu, veritabanının CPU kaynağı sınırlarını zorlayan bir iş yükünün belirtisidir.

    Bir SQL Server şirket içi ortamı için genellikle cpu gibi genel kaynak kullanımını izlemek için işletim sistemine özgü bir araç kullanırsınız. Örneğin, bu amaçla Windows Performans İzleyicisi’ni kullanabilirsiniz. Bu örneği iki CPU'su olan bir sanal makinede şirket içi SQL Server veya SQL Server üzerinde çalıştırdıysanız, sunucuda yüzde 100'e yakın CPU kullanımı görürsünüz.

    Dekont

    Sunucuyla ilişkili tüm Azure SQL Veritabanı veritabanlarının kaynak kullanımını görmek için Azure SQL Veritabanı sunucusunun master veritabanı bağlamında başka bir DMV sys.resource_statsçalıştırabilirsiniz. Bu görünüm daha az ayrıntılıdır ve kaynak kullanımını beş dakikada bir gösterir (14 gün boyunca saklanır).

    Bu sorgu düzenleyici penceresini açık bırakın. Sonraki alıştırmada bunu tekrar çalıştıracaksınız.

  3. İş yükünün tamamlanmasını bekleyin ve toplam süresini not alın. İş yükü tamamlandığında aşağıdaki çıkışa benzer sonuçlar görmeli ve komut istemine dönmelisiniz:

    [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

    Süreniz değişebilir, ancak bu genellikle en az 1-3 dakika kadar sürer. Bunu tamamlanana kadar çalıştırmaya dikkat edin. İş yükü tamamlandığında komut istemine geri dönersiniz.

Daha fazla analiz için Sorgu Deposu'nu kullanma

Sorgu Deposu SQL Server'ın sorguların performansını izlemeye yönelik özelliğidir. Performans verileri kullanıcı veritabanında depolanır. Sorgu Deposu, SQL Server’da oluşturulan veritabanları için varsayılan olarak etkinleştirilmez, ancak Azure SQL Veritabanı’nda (ve Azure SQL Yönetilen Örneği’nde) varsayılan olarak açıktır.

Sorgu Deposu performans verilerini görüntülemek için bir dizi sistem katalog görünümüyle gelir. SQL Server Management Studio, bu görünümleri kullanarak raporlar sağlar.

  1. SQL Server Management Studio’da Nesne Gezgini’ni kullanarak Sorgu Deposu klasörünü açıp En Çok Kaynak Tüketen Sorgular raporunu bulun.

    Screenshot of the Query Store.

  2. Ortalama olarak en fazla kaynak tüketen sorguları ve bu sorguların yürütme ayrıntılarını bulmak için raporu açın. Bu noktaya gelirken çalıştırılan iş yüküne bağlı olarak raporunuz aşağıdaki resme benzer görünmelidir:

    Screenshot of the top query report.

    Gösterilen sorgu müşteri satışları için iş yükünden gelen SQL sorgusudur. Bu rapor üç bileşen içerir: toplam süresi uzun olan sorgular (ölçümü değiştirebilirsiniz), ilişkili sorgu planı ve çalışma zamanı istatistikleri ve görsel haritada gösterilen ilişkili sorgu planı.

  3. Sorgu için çubuk grafiğini seçin (query_id, sisteminiz için farklı olabilir). Sonuçlarınız aşağıdaki resme benzer olmalıdır:

    Screenshot of the query ID.

    Sorgunun toplam süresini ve sorgu metnini görebilirsiniz.

  4. Çubuk grafiğin sağ tarafında sorguyla ilişkilendirilmiş sorgu planının istatistiklerini gösteren bir grafik yer alır. Planla ilişkilendirilmiş olan noktanın üzerine gelin. Sonuçlarınız aşağıdaki resme benzer olmalıdır:

    Screenshot of slow query statistics.

    Sorgunun ortalama süresini not alın. Zamanlar değişiklik gösterebilir, ancak bu ortalama süreyi, bu sorgunun ortalama bekleme süresiyle karşılaştırın. Daha sonra bir performans geliştirmesi sunacağız ve farklı görmek için tekrar bu karşılaştırmayı yapacaksınız.

  5. Son bileşen görsel sorgu planıdır. Bu sorgunun sorgu planı aşağıdaki resme benzer görünmelidir:

    Screenshot of the workload query plan.

    Bu veritabanı tablosunda o kadar az satır var ki plana ihtiyacı yok; verimsiz olabilir. Sorgunun ayarlanması performansı ölçülebilir bir miktar artırmaz. Planda kümelenmiş dizin aramasının sütunlarından biri için istatistik eksikliğiyle ilgili bir uyarı görebilirsiniz. Bu, genel performansa katılmaz.

  6. SSMS'de En Çok Kaynak Tüketen Sorgular raporunun ardından Sorgu Bekleme İstatistikleri adlı bir rapor bulunur. Önceki tanılama işlemlerinden, neredeyse yüzde 100 CPU düzeyiyle sürekli RUNNABLE durumda kalan çok fazla sorgu olduğunu biliyorsunuz. Sorgu Deposu, kaynaklardaki beklemelerden kaynaklanan olası performans sorunlarına bakmanızı sağlayan raporlarla gelir. Bu raporu seçin ve imleci çubuk grafiğin üzerine getirin. Sonuçlarınız aşağıdaki resme benzer olmalıdır:

    Screenshot of the top wait statistics.

    En uzun bekleme kategorisinin CPU olduğunu (bu, sys.dm_os_wait_stats içinde görülebilen wait_type SOS_SCHEDULER_YIELD ile eşdeğerdir) ve ortalama bekleme süresini görebilirsiniz.

  7. Rapordaki CPU çubuk grafiğini seçin. CPU'yu bekleyen en üstteki sorgu, kullandığınız iş yükünden gelen sorgudur.

    Screenshot of the top wait statistics query.

    Bu sorgudaki CPU için ortalama bekleme süresinin, sorgu için genel ortalama sürenin yüksek bir yüzdesi olduğuna dikkat edin.

    Kanıt göz önünde bulundurularak, sorgu ayarlaması yapılmadan iş yükümüz, Azure SQL Veritabanı örneğimiz için dağıtılandan daha fazla CPU kapasitesi gerektirir.

  8. Her iki Sorgu Deposu raporunu da kapatın. Sonraki alıştırmada aynı raporları kullanacaksınız.

Azure İzleyici ile performansı gözlemleme

İş yükümüzün kaynak kullanımını görüntülemek için başka bir yöntem kullanalım. Azure İzleyici, Azure portalı aracılığıyla da dahil olmak üzere çeşitli yollarla görüntüleyebileceğiniz performans ölçümleri sağlar.

  1. Azure portalını açın ve AdventureWorks SQL veritabanı örneğinizi bulun. Veritabanının Genel Bakış bölmesinde İzleme sekmesini seçin. İzleme bölmesindeki varsayılan görünüm İşlem Kullanımı'dır:

    Screenshot of the Azure portal with a slow query.

    Bu örnekte, son zaman aralığı için CPU yüzdesi yüzde 100'e yakındır. Bu grafik, son bir saat içindeki kaynak kullanımını gösterir (CPU ve G/Ç varsayılandır) ve sürekli yenilenir. Grafiği seçerek diğer kaynak kullanımına bakacak şekilde özelleştirebilirsiniz.

  2. SQL veritabanı menüsünde Ölçüm ekle'yi seçin. Azure SQL Veritabanı için Azure İzleyici tarafından otomatik olarak toplanan İşlem Kullanımı ölçümlerini ve diğer ölçümleri görüntülemenin bir diğer yolu da Ölçüm Gezgini'ni kullanmaktır.

    Dekont

    İşlem Kullanımı, Ölçüm Gezgini'nin önceden tanımlanmış bir görünümüdür. Ölçüm ekle penceresinde Ölçüm açılan listesini seçerseniz aşağıdaki sonuçları görürsünüz:

    Screenshot of Azure Monitor metrics.

    Ekran görüntüsünde gösterildiği gibi, Ölçüm Gezgini ile görüntülemek için kullanabileceğiniz çeşitli ölçümler vardır. Ölçüm Gezgini varsayılan görünümü, beş dakikalık ayrıntı düzeyine sahip 24 saatlik bir süre içindir. İşlem Kullanımı görünümü, bir dakikalık ayrıntı düzeyine sahip son saattir (bunu değiştirebilirsiniz). Aynı görünümü görmek için CPU yüzdesi'ni seçin ve yakalamayı bir saat boyunca değiştirin. Ayrıntı düzeyi bir dakika olarak değiştirilir ve aşağıdaki resme benzer olmalıdır:

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

    Varsayılan grafik türü çizgi grafiğidir ama Gezgin görünümünde grafik türünü değiştirmenize izin verilir. Ölçüm Gezgini'nde, aynı grafikte birden çok ölçümü gösterme özelliği de dahil olmak üzere birçok seçenek vardır.

Azure İzleyici günlükleri

Bu alıştırmada bir Azure İzleyici günlüğü ayarlamadınız, ancak bir CPU kaynak kullanımı senaryosu için bir günlüğün nasıl görünebileceğine göz atmak faydalı olacaktır. Azure İzleyici günlükleri, Azure Ölçümleri’nden çok daha uzun bir geçmiş kaydı sağlayabilir.

Azure İzleyici günlüklerini Log Analytics çalışma alanıyla yapılandırdıysanız, veritabanı için aynı CPU kullanım sonuçlarını görüntülemek için aşağıdaki Kusto sorgusunu kullanabilirsiniz:

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

Sonuçlarınız aşağıdaki resme benzer olur:

Screenshot of a query measuring CPU.

Veritabanı için günlük tanılaması ilk kez yapılandırıldığında Azure İzleyici günlüklerinde bir gecikme olur, dolayısıyla bu sonuçların görüntülenmesi biraz zaman alabilir.

Bu alıştırmada yaygın bir SQL Server performansı senaryosunu gözlemlemeyi ve performansı geliştirmeye yönelik olası bir çözüme karar verme sürecinin ayrıntılarına gitmeyi öğrendiniz. Sonraki ünitede performansı hızlandırma ve ayarlama yöntemlerini öğreneceksiniz.