연습 - 성능 모니터링 및 문제 해결

  • 10분

이 연습에서는 친숙하거나 새로운 도구 및 기능을 사용하여 Azure SQL의 성능 문제를 모니터링하고 해결하는 방법을 알아봅니다.

설정: 스크립트를 사용하여 Azure SQL Database 배포

오른쪽의 터미널 세션인 Azure Cloud Shell에서 브라우저를 사용하여 Azure와 상호 작용할 수 있습니다. 이 연습에서는 AdventureWorks 데이터베이스를 사용하여 Azure SQL Database의 인스턴스인 환경을 만드는 스크립트를 실행합니다. (더 작고 간단한 샘플 AdventureWorksLT 데이터베이스가 사용되지만 혼동을 방지하기 위해 이를 AdventureWorks라고 하겠습니다.) 스크립트에서 디바이스를 데이터베이스에 연결할 수 있도록 암호화 로컬 IP 주소를 입력하라는 메시지가 표시됩니다.

이 스크립트는 완료하는 데 3~5분 정도가 걸립니다. 암호, 고유 ID 및 지역을 기록해 두세요. 이는 다시 표시되지 않습니다.

  1. 로컬 IP 주소를 가져와서 시작합니다. 연결되어 있다면 VPN 서비스 연결을 해제하고 디바이스에서 로컬 PowerShell 터미널을 열어야 합니다. 다음 명령을 실행하고 결과 IP 주소를 기록합니다.

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

  2. 오른쪽의 Azure Cloud Shell에서 다음 코드를 입력하고 메시지가 표시되면 이전 단계에서 검색한 복잡한 암호와 로컬 공용 IP 주소를 제공합니다. Enter 키를 눌러 스크립트의 마지막 줄을 실행합니다.

    $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에서 다음 스크립트를 실행합니다. 출력을 저장합니다. 이 정보는 모듈 전체에서 필요합니다. 코드에 붙여넣은 후 Enter 키를 누르면 코드의 마지막 줄에 필요한 출력이 인쇄됩니다.

    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

    팁

    출력을 저장하고 암호, 고유 ID, 서버를 적어 둡니다. 모듈 전체에서 이러한 항목이 필요합니다.

  4. 다음 스크립트를 실행하여 AdventureWorks 샘플이 포함된 Azure SQL Database 및 논리 서버 인스턴스를 배포합니다. 이 스크립트는 IP 주소를 방화벽 규칙으로 추가하고, Advanced Data Security를 사용하도록 설정하고, 이 모듈의 나머지 연습에서 사용할 스토리지 계정을 만듭니다. 스크립트를 완료하는 데 몇 분 정도 걸릴 수 있으며, 여러 번 일시 중지됩니다. 명령 프롬프트를 기다립니다.

    # 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. 로컬 디바이스에서 SSMS(SQL Server Management Studio)를 열어서 논리 서버에 대한 새 연결을 만듭니다.

  6. 서버에 연결 로그인 대화 상자에서 다음 정보를 제공합니다.

    필드 값
    서버 유형 ‘데이터베이스 엔진’(기본값).
    서버 이름 Cloud Shell에서 반환된 $serverName 및 나머지 URI. 예를 들어 aw-server<unique ID>.database.windows.net입니다.
    인증 ‘SQL Server 인증’(기본값).
    로그인 cloudadmin 이 연습의 1단계에서 할당된 adminSqlLogin입니다.
    암호 이 연습의 1단계에서 제공한 암호.
    암호 기억 checked

  7. 연결을 선택합니다.

    Screenshot of connection dialog for SQL Database in SSMS.

    참고 항목

    로컬 구성(예: VPN)에 따라 클라이언트 IP 주소는 배포 중에 사용되는 Azure Portal IP 주소와 다를 수도 있습니다. 다음과 같은 메시지가 표시됩니다. “클라이언트 IP 주소에 서버에 대한 액세스 권한이 없습니다. 액세스하려면 Azure 계정에 로그인하고 새 방화벽 규칙을 만드세요.” 이 메시지가 표시되면 샌드박스에 사용 중인 계정을 사용하여 로그인하고 클라이언트 IP 주소의 방화벽 규칙을 추가합니다. SSMS의 마법사를 사용하여 해당 단계를 모두 완료할 수 있습니다.

스크립트를 로드하고 편집하여 연습 준비

이 연습에 대한 모든 스크립트는 복제한 GitHub 리포지토리의 04-Performance\monitor_and_scale 폴더 또는 다운로드한 Zip 파일에서 찾을 수 있습니다. 스크립트를 로드하고 편집하여 연습을 준비해 보겠습니다.

  1. SSMS의 개체 탐색기에서 Databases 폴더를 확장하고 AdventureWorks 데이터베이스를 선택합니다.

  2. 파일>열기>파일을 선택하고 dmexecrequests.sql 스크립트를 엽니다. 쿼리 편집기 창은 다음 텍스트와 같이 표시됩니다.

    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에서 동일한 방법을 사용하여 dmdbresourcestats.sql 스크립트를 로드합니다. 새 쿼리 편집기 창은 다음 텍스트와 같이 표시됩니다.

    SELECT * FROM sys.dm_db_resource_stats;

    이 DMV(동적 관리 뷰)는 Azure SQL Database에 대해 워크로드의 전체 리소스 사용량을 추적합니다. 예를 들어 CPU, I/O 및 메모리를 추적합니다.

  4. ostress.exe 프로그램을 사용하는 sqlworkload.cmd 스크립트를 열고 편집합니다.

    • 서버 이름의 배포 스크립트에서 저장한 unique_id를 대체합니다.
    • -P parameter에 대해 Azure SQL Database 서버의 로그인에 사용한 암호를 대체합니다.
    • 변경 내용을 스크립트에 저장합니다.

워크로드 실행

이 작업에서 T-SQL 쿼리의 워크로드를 실행하여 동시 사용자를 시뮬레이션하는 성능을 관찰합니다.

  1. SSMS를 사용하여 topcustomersales.sql 스크립트 파일을 열어 쿼리를 확인합니다. SSMS에서 해당 쿼리를 실행하지는 않습니다. 쿼리 편집기 창은 다음 텍스트와 같이 표시됩니다.

    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

    이 데이터베이스는 작습니다. 판매량이 가장 많은 고객별로 정렬하는 고객 목록과 관련 판매 정보를 검색하는 쿼리는 큰 결과 집합을 생성하지 않습니다. 결과 집합의 열 수를 줄여 이 쿼리를 조정할 수 있지만 이는 이 연습의 예시에 필요합니다.

  2. PowerShell 명령 프롬프트에서 다음 명령을 입력하여 이 연습의 올바른 디렉터리로 이동합니다. <base directory>를 이 모듈의 사용자 ID와 경로로 바꿉니다.

    cd <base directory>\04-Performance\monitor_and_scale

  3. 다음 명령을 사용하여 워크로드 실행:

    .\sqlworkload.cmd

    이 스크립트는 워크로드 쿼리를 2번 실행하는 10명의 동시 사용자를 사용합니다. 스크립트 자체는 단일 일괄 처리를 실행하지만 1만 번 반복합니다. 또한 결과를 변수에 할당했으므로 클라이언트에 대한 거의 모든 결과 세트 트래픽이 제거됩니다. 이 작업이 필수는 아니지만 서버에서 완전히 실행되는 "순수" CPU 워크로드를 표시하는 데 도움이 됩니다.

    팁

    사용자 환경에 대해 이 워크로드의 CPU 사용량 동작이 표시되지 않는 경우 사용자 수에 대한 -n parameter와 반복에 대한 -r parameter를 조정할 수 있습니다.

    명령 프롬프트의 출력은 다음 출력과 유사하게 표시됩니다.

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

워크로드 성능 확인

이전에 로드한 DMV 쿼리를 사용하여 성능을 관찰해 보겠습니다.

  1. dm_exec_requests(dmexecrequests.sql)를 모니터링하기 위해 이전에 로드한 SSMS에서 쿼리를 실행하여 활성 요청을 살펴봅니다. 이 쿼리를 5~6번 실행하고 결과를 살펴봅니다.

    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;

    많은 요청의 상태가 RUNNABLE이고 last_wait_type이 SOS_SCHEDULER_YIELD인 것을 볼 수 있습니다. 많은 RUNNABLE 요청과 많은 SOS_SCHEDULER_YIELD 대기가 있음을 나타내는 한 가지 지표는 활성 쿼리를 위한 CPU 리소스 부족 현상일 수 있습니다.

    참고 항목

    SELECT 명령과 XE_LIVE_TARGET_TVF의 wait_type을 사용하여 하나 이상의 활성 요청이 표시될 수 있습니다. Microsoft에서 관리하는 서비스에서 실행하는 쿼리입니다. 확장 이벤트를 사용하여 성능 인사이트와 같은 기능을 지원합니다. Microsoft는 이러한 세션의 세부 정보를 게시하지 않습니다.

    이 쿼리 편집기 창을 열어둡니다. 다음 연습에서 다시 실행합니다.

  2. 이전에 로드한 SSMS에서 쿼리를 실행하여 sys.dm_db_resource_stats(dmdbresourcestats.sql)를 모니터링합니다. 이 쿼리를 실행하여 이 DMV의 결과를 3~4번 확인합니다.

    SELECT * FROM sys.dm_db_resource_stats;

    이 DMV는 15초마다 데이터베이스의 리소스 사용에 대한 스냅샷을 기록합니다(1시간 동안 보관). 일부 스냅샷에서 avg_cpu_percent 열이 100%에 가까운 것을 볼 수 있습니다. 이것은 데이터베이스의 CPU 리소스 한계를 촉진하는 워크로드의 증상입니다.

    SQL Server 온-프레미스 환경의 경우 일반적으로 운영 체제 관련 도구를 사용하여 CPU와 같은 전체 리소스 사용량을 추적합니다. 예를 들어 이러한 용도로 Windows 성능 모니터를 사용할 수 있습니다. 온-프레미스 SQL Server 또는 CPU가 2개인 가상 머신의 SQL Server에서 이 예제를 실행한 경우 서버에서 CPU 사용률이 100%에 가까운 것을 볼 수 있습니다.

    참고 항목

    Azure SQL Database 서버의 master 데이터베이스 컨텍스트에서 다른 DMV인 sys.resource_stats를 실행하여 서버와 연결된 모든 Azure SQL Database 데이터베이스의 리소스 사용량을 확인할 수 있습니다. 이 보기는 덜 세부적이며 5분마다 리소스 사용량을 표시합니다(14일 동안 유지).

    이 쿼리 편집기 창을 열어둡니다. 다음 연습에서 다시 실행합니다.

  3. 워크로드를 완료할 때까지 두고 전체 지속 시간을 기록해 둡니다. 작업이 완료되면 다음 출력과 같은 결과가 표시되고 명령 프롬프트로 돌아갑니다.

    [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

    지속 시간은 다를 수 있지만 일반적으로 1-3분 이상 소요됩니다. 이 실행이 완료되도록 합니다. 워크로드가 완료되면 명령 프롬프트로 돌아갑니다.

추가 분석을 위해 쿼리 저장소 사용

쿼리 저장소는 쿼리의 성능 실행을 추적하는 SQL Server의 기능입니다. 성능 데이터는 사용자 데이터베이스에 저장됩니다. 쿼리 저장소는 SQL Server에서 만든 데이터베이스에 대해 기본적으로 사용하도록 설정되어 있지 않지만 Azure SQL Database(및 Azure SQL Managed Instance)에서는 기본적으로 사용하도록 설정됩니다.

쿼리 저장소에는 성능 데이터를 볼 수 있는 일련의 시스템 카탈로그 뷰가 포함되어 있습니다. SSMS는 이러한 보기를 사용하여 보고서를 제공합니다.

  1. SSMS의 개체 탐색기를 사용하여 쿼리 저장소 폴더를 열고 리소스를 가장 많이 사용하는 쿼리 보고서를 찾습니다.

    Screenshot of the Query Store.

  2. 이 보고서를 선택하여 가장 많은 평균 리소스를 사용한 쿼리와 해당 쿼리의 실행 세부 정보를 확인합니다. 이 시점가지의 워크로드 실행에 따라, 보고서는 다음 이미지와 유사한 결과를 표시합니다.

    Screenshot of the top query report.

    표시되는 쿼리는 고객 판매 워크로드에 대한 SQL 쿼리입니다. 이 보고서에는 세 가지 구성 요소가 있습니다. 총 기간이 긴 쿼리(메트릭 변경 가능), 연결된 쿼리 계획 및 런타임 통계, 시각적 맵의 관련 쿼리 계획이 포함되어 있습니다.

  3. 쿼리에 대한 가로 막대형 차트를 선택합니다(query_id는 시스템에 대해 다를 수 있음). 결과는 다음 이미지와 같습니다.

    Screenshot of the query ID.

    쿼리의 총 기간과 쿼리 텍스트를 볼 수 있습니다.

  4. 이 가로 막대형 차트 오른쪽에는 쿼리와 연결된 쿼리 계획에 대한 통계 차트가 표시됩니다. 플랜과 연결된 점을 마우스로 가리킵니다. 결과는 다음 이미지와 같습니다.

    Screenshot of slow query statistics.

    쿼리의 평균 기간을 기록합니다. 시간은 다를 수 있지만 이 쿼리에 대한 평균 대기 시간과 이 평균 기간을 비교합니다. 나중에 성능 개선을 도입하고, 다시 비교하여 차이를 확인합니다.

  5. 최종 구성 요소는 시각적 쿼리 플랜입니다. 이 쿼리에 대한 쿼리 플랜은 다음 이미지와 같습니다.

    Screenshot of the workload query plan.

    이 데이터베이스 테이블에는 플랜이 필요하지 않은 행이 거의 없으므로 비효율적일 수 있습니다. 쿼리를 튜닝해도 측정 가능한 양만큼 성능이 향상되지는 않습니다. 클러스터형 인덱스 검색에 대한 열 중 하나의 통계 부족 관련 경고가 플랜에 표시될 수 있습니다. 이는 전반적인 성능에 영향을 주지 않습니다.

  6. SSMS의 리소스를 가장 많이 사용하는 쿼리 보고서 다음에 쿼리 대기 통계 보고서가 있습니다. 이전 진단을 통해 많은 수의 요청이 거의 100% CPU를 사용하는 RUNNABLE 상태였음을 알 수 있습니다. 쿼리 저장소에는 대기 리소스로 인한 가능한 성능 병목 상태를 확인할 수 있는 보고서가 함께 제공됩니다. 이 보고서를 선택하고 가로 막대형 차트를 마우스로 가리킵니다. 결과는 다음 이미지와 같습니다.

    Screenshot of the top wait statistics.

    상위 대기 범주는 CPU(sys.dm_os_wait_stats에서 볼 수 있는 wait_type SOS_SCHEDULER_YIELD와 같음) 및 평균 대기 시간입니다.

  7. 보고서에서 CPU 가로 막대형 차트를 선택합니다. CPU를 대기하는 상위 쿼리는 사용 중인 워크로드의 쿼리입니다.

    Screenshot of the top wait statistics query.

    이 쿼리에서 CPU의 평균 대기 시간은 쿼리의 전체 평균 기간 중에서 높은 백분율을 차지합니다.

    증거를 고려하면 쿼리 튜닝이 없을 경우 워크로드에 Azure SQL Database 인스턴스에 대해 배포한 것보다 더 많은 CPU 용량이 필요할 것입니다.

  8. 두 쿼리 저장소 보고서를 모두 닫습니다. 다음 연습에서 동일한 보고서를 사용하게 됩니다.

Azure Monitor를 사용하여 성능 관찰

또 다른 방법을 사용하여 워크로드의 리소스 사용량을 확인하겠습니다. Azure Monitor는 Azure Portal을 비롯한 다양한 방법으로 볼 수 있는 성능 메트릭을 제공합니다.

  1. Azure Portal을 열고 AdventureWorks SQL 데이터베이스의 인스턴스를 찾습니다. 데이터베이스의 개요 창에서 모니터링 탭을 선택합니다. 모니터링 창의 기본 보기는 컴퓨팅 사용률입니다.

    Screenshot of the Azure portal with a slow query.

    이 예에서 최근 시간 범위 동안 CPU 비율은 100%에 가깝습니다. 이 차트는 지난 1시간 동안 리소스 사용량(기본값은 CPU 및 I/O)을 표시하며 지속적으로 새로 고쳐집니다. 차트를 선택하면 차트를 사용자 지정하여 다른 리소스 사용량을 확인할 수 있습니다.

  2. SQL 데이터베이스 메뉴에서 통계 추가를 선택합니다. 컴퓨팅 사용률 메트릭과 Azure SQL Database용 Azure Monitor에서 자동으로 수집된 다른 메트릭을 보는 또 다른 방법은 메트릭 탐색기를 사용하는 것입니다.

    참고

    컴퓨팅 사용률은 메트릭 탐색기의 사전 정의된 보기입니다. 메트릭 추가 창에서 메트릭 드롭다운을 선택하면 다음과 같은 결과가 표시됩니다.

    Screenshot of Azure Monitor metrics.

    이 스크린샷에서 표시된 대로 메트릭 탐색기에서 보는 데 사용할 수 있는 여러 가지 메트릭이 있습니다. 메트릭 탐색기 기본 보기는 24시간 동안 5분 단위로 표시됩니다. 컴퓨팅 사용률 보기는 1분 간격으로 마지막 1시간을 표시합니다(변경할 수 있음). 동일한 보기를 보려면 CPU 비율을 선택하고 캡처를 1시간 동안 변경합니다. 간격이 1분으로 변경되고 다음 이미지와 같이 표시됩니다.

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

    기본 보기는 꺾은선형 차트이지만 탐색기 보기를 사용하여 차트 종류를 변경할 수 있습니다. 메트릭 탐색기에는 동일한 차트에 여러 메트릭을 표시하는 기능을 포함하여 많은 옵션이 있습니다.

Azure Monitor 로그

이 연습에서는 Azure Monitor 로그를 설정하지 않았지만 CPU 리소스 사용량 시나리오에 대한 로그의 형태를 살펴볼 가치가 있습니다. Azure Monitor 로그는 Azure 메트릭에 비해 훨씬 더 긴 기록 레코드를 제공할 수 있습니다.

Log Analytics 작업 영역을 사용하여 Azure Monitor 로그를 구성한 경우 다음 Kusto 쿼리를 사용하여 데이터베이스에 대해 동일한 CPU 사용률 결과를 볼 수 있습니다.

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

결과는 다음 이미지와 같습니다.

Screenshot of a query measuring CPU.

Azure Monitor 로그는 데이터베이스의 로그 진단을 처음 구성할 때 지연이 발생하므로 이러한 결과를 표시하는 데 다소 시간이 걸릴 수 있습니다.

이 연습에서는 일반적인 SQL Server 성능 시나리오를 확인하고 자세한 정보를 검토하여 성능을 향상시킬 수 있는 솔루션을 결정하는 방법을 배웠습니다. 다음 단원에서는 성능을 가속화하고 조정하는 방법을 알아봅니다.