Dinamik yönetim görünümlerini kullanarak Microsoft Azure SQL Veritabanı'nın ve Azure SQL Yönetilen Örneği'nin performansını izlemeMonitoring Microsoft Azure SQL Database and Azure SQL Managed Instance performance using dynamic management views

Uygulama hedefi: Azure SQL veritabanı Azure SQL yönetilen örneği

Microsoft Azure SQL Veritabanı ve Azure SQL yönetilen örneği, dinamik yönetim görünümlerinin bir alt kümesini, Engellenen veya uzun süreli sorgular, kaynak darboğazları, kötü sorgu planları vb. nedeniyle oluşan performans sorunlarını tanılamak için etkinleştirir.Microsoft Azure SQL Database and Azure SQL Managed Instance enable a subset of dynamic management views to diagnose performance problems, which might be caused by blocked or long-running queries, resource bottlenecks, poor query plans, and so on. Bu makalede, dinamik yönetim görünümlerini kullanarak yaygın performans sorunlarının algılanması hakkında bilgi verilmektedir.This article provides information on how to detect common performance problems by using dynamic management views.

Microsoft Azure SQL Veritabanı ve Azure SQL yönetilen örneği, dinamik yönetim görünümlerinin üç kategorisini kısmen destekler:Microsoft Azure SQL Database and Azure SQL Managed Instance partially support three categories of dynamic management views:

  • Veritabanıyla ilgili dinamik yönetim görünümleri.Database-related dynamic management views.
  • Yürütmeye ilişkin dinamik yönetim görünümleri.Execution-related dynamic management views.
  • İşlemle ilgili dinamik yönetim görünümleri.Transaction-related dynamic management views.

Dinamik yönetim görünümleri hakkında ayrıntılı bilgi için bkz. dinamik yönetim görünümleri ve işlevleri (Transact-SQL).For detailed information on dynamic management views, see Dynamic Management Views and Functions (Transact-SQL).

SQL Insights ile izlemeMonitor with SQL insights

Azure IZLEYICI SQL öngörüleri , Azure SQL VM 'lerinde Azure SQL yönetilen örnekleri, Azure SQL veritabanları ve SQL Server örneklerini izlemeye yönelik bir araçtır.Azure Monitor SQL insights is a tool for monitoring Azure SQL managed instances, Azure SQL databases, and SQL Server instances in Azure SQL VMs. Bu hizmet, dinamik yönetim görünümlerindeki (DMVs) verileri yakalamak ve verileri Azure Log Analytics yönlendirdiğinde, burada izlenebileceğiniz ve çözümlenebileceği bir uzak Aracı kullanır.This service uses a remote agent to capture data from dynamic management views (DMVs) and routes the data to Azure Log Analytics, where it can be monitored and analyzed. Bu verileri, Azure izleyici 'den belirtilen görünümlerde görüntüleyebilir veya sorguları çalıştırmak ve eğilimleri çözümlemek için günlük verilerine doğrudan erişebilirsiniz.You can view this data from Azure Monitor in provided views, or access the Log data directly to run queries and analyze trends. Azure Izleyici SQL öngörülerini kullanmaya başlamak için bkz. SQL Insights 'ı etkinleştirme.To start using Azure Monitor SQL insights, see Enable SQL insights.

İzinlerPermissions

Azure SQL veritabanı 'nda, dinamik bir yönetim görünümünü sorgulamak için VERITABANı durumunu görüntüle izinleri gerekir.In Azure SQL Database, querying a dynamic management view requires VIEW DATABASE STATE permissions. VERITABANı durumunu görüntüle izni, geçerli veritabanı içindeki tüm nesneler hakkında bilgi döndürür.The VIEW DATABASE STATE permission returns information about all objects within the current database. Belirli bir veritabanı kullanıcısına VERITABANı durumunu görüntüle iznini vermek için aşağıdaki sorguyu çalıştırın:To grant the VIEW DATABASE STATE permission to a specific database user, run the following query:

GRANT VIEW DATABASE STATE TO database_user;

Azure SQL yönetilen örneği 'nde, dinamik bir yönetim görünümünü sorgulamak için sunucu durumu Izinlerinin görünüm olması gerekir.In Azure SQL Managed Instance, querying a dynamic management view requires VIEW SERVER STATE permissions. Daha fazla bilgi için bkz. sistem dinamik yönetim görünümleri.For more information, see System Dynamic Management Views.

SQL Server örneğinde ve Azure SQL yönetilen örneği 'nde, dinamik yönetim görünümleri sunucu durum bilgilerini döndürür.In an instance of SQL Server and in Azure SQL Managed Instance, dynamic management views return server state information. Azure SQL veritabanı 'nda yalnızca geçerli mantıksal veritabanınızla ilgili bilgileri döndürür.In Azure SQL Database, they return information regarding your current logical database only.

Bu makale, aşağıdaki sorgu performans sorunlarının türlerini algılamak için SQL Server Management Studio veya Azure Data Studio kullanarak yürütebilmeniz gereken DMV sorgularının bir koleksiyonunu içerir:This article contains a collection of DMV queries that you can execute using SQL Server Management Studio or Azure Data Studio to detect the following types of query performance issues:

CPU performansı sorunlarını belirlemeIdentify CPU performance issues

CPU tüketimi, uzun süre boyunca %80 üzerinde ise, aşağıdaki sorun giderme adımlarını göz önünde bulundurun:If CPU consumption is above 80% for extended periods of time, consider the following troubleshooting steps:

CPU sorunu şimdi gerçekleşiyorThe CPU issue is occurring now

Sorun şu anda gerçekleşirse, iki olası senaryo vardır:If issue is occurring right now, there are two possible scenarios:

Yüksek CPU kullanan çok sayıda tekil sorguMany individual queries that cumulatively consume high CPU

En üstteki sorgu karmalarını belirlemek için aşağıdaki sorguyu kullanın:Use the following query to identify top query hashes:

PRINT '-- top 10 Active CPU Consuming Queries (aggregated)--';
SELECT TOP 10 GETDATE() runtime, *
FROM (SELECT query_stats.query_hash, SUM(query_stats.cpu_time) 'Total_Request_Cpu_Time_Ms', SUM(logical_reads) 'Total_Request_Logical_Reads', MIN(start_time) 'Earliest_Request_start_Time', COUNT(*) 'Number_Of_Requests', SUBSTRING(REPLACE(REPLACE(MIN(query_stats.statement_text), CHAR(10), ' '), CHAR(13), ' '), 1, 256) AS "Statement_Text"
    FROM (SELECT req.*, SUBSTRING(ST.text, (req.statement_start_offset / 2)+1, ((CASE statement_end_offset WHEN -1 THEN DATALENGTH(ST.text)ELSE req.statement_end_offset END-req.statement_start_offset)/ 2)+1) AS statement_text
          FROM sys.dm_exec_requests AS req
                CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) AS ST ) AS query_stats
    GROUP BY query_hash) AS t
ORDER BY Total_Request_Cpu_Time_Ms DESC;

CPU kullanan uzun süre çalışan sorgular hala çalışıyorLong running queries that consume CPU are still running

Bu sorguları tanımlamak için aşağıdaki sorguyu kullanın:Use the following query to identify these queries:

PRINT '--top 10 Active CPU Consuming Queries by sessions--';
SELECT TOP 10 req.session_id, req.start_time, cpu_time 'cpu_time_ms', OBJECT_NAME(ST.objectid, ST.dbid) 'ObjectName', SUBSTRING(REPLACE(REPLACE(SUBSTRING(ST.text, (req.statement_start_offset / 2)+1, ((CASE statement_end_offset WHEN -1 THEN DATALENGTH(ST.text)ELSE req.statement_end_offset END-req.statement_start_offset)/ 2)+1), CHAR(10), ' '), CHAR(13), ' '), 1, 512) AS statement_text
FROM sys.dm_exec_requests AS req
    CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) AS ST
ORDER BY cpu_time DESC;
GO

Geçmişte CPU sorunu oluştuThe CPU issue occurred in the past

Sorun geçmişte oluştuysa ve kök neden çözümlemesi yapmak istiyorsanız sorgu deposu' nu kullanın.If the issue occurred in the past and you want to do root cause analysis, use Query Store. Veritabanı erişimi olan kullanıcılar, sorgu deposu verilerini sorgulamak için T-SQL kullanabilir.Users with database access can use T-SQL to query Query Store data. Sorgu deposu varsayılan yapılandırması 1 saat ayrıntı düzeyi kullanır.Query Store default configurations use a granularity of 1 hour. Yüksek CPU kullanan sorgulara yönelik etkinliklere bakmak için aşağıdaki sorguyu kullanın.Use the following query to look at activity for high CPU consuming queries. Bu sorgu, en üstteki 15 CPU kullanan sorguları döndürür.This query returns the top 15 CPU consuming queries. Değiştirmeyi unutmayın rsi.start_time >= DATEADD(hour, -2, GETUTCDATE() :Remember to change rsi.start_time >= DATEADD(hour, -2, GETUTCDATE():

-- Top 15 CPU consuming queries by query hash
-- note that a query  hash can have many query id if not parameterized or not parameterized properly
-- it grabs a sample query text by min
WITH AggregatedCPU AS (SELECT q.query_hash, SUM(count_executions * avg_cpu_time / 1000.0) AS total_cpu_millisec, SUM(count_executions * avg_cpu_time / 1000.0)/ SUM(count_executions) AS avg_cpu_millisec, MAX(rs.max_cpu_time / 1000.00) AS max_cpu_millisec, MAX(max_logical_io_reads) max_logical_reads, COUNT(DISTINCT p.plan_id) AS number_of_distinct_plans, COUNT(DISTINCT p.query_id) AS number_of_distinct_query_ids, SUM(CASE WHEN rs.execution_type_desc='Aborted' THEN count_executions ELSE 0 END) AS Aborted_Execution_Count, SUM(CASE WHEN rs.execution_type_desc='Regular' THEN count_executions ELSE 0 END) AS Regular_Execution_Count, SUM(CASE WHEN rs.execution_type_desc='Exception' THEN count_executions ELSE 0 END) AS Exception_Execution_Count, SUM(count_executions) AS total_executions, MIN(qt.query_sql_text) AS sampled_query_text
                       FROM sys.query_store_query_text AS qt
                            JOIN sys.query_store_query AS q ON qt.query_text_id=q.query_text_id
                            JOIN sys.query_store_plan AS p ON q.query_id=p.query_id
                            JOIN sys.query_store_runtime_stats AS rs ON rs.plan_id=p.plan_id
                            JOIN sys.query_store_runtime_stats_interval AS rsi ON rsi.runtime_stats_interval_id=rs.runtime_stats_interval_id
                       WHERE rs.execution_type_desc IN ('Regular', 'Aborted', 'Exception')AND rsi.start_time>=DATEADD(HOUR, -2, GETUTCDATE())
                       GROUP BY q.query_hash), OrderedCPU AS (SELECT query_hash, total_cpu_millisec, avg_cpu_millisec, max_cpu_millisec, max_logical_reads, number_of_distinct_plans, number_of_distinct_query_ids, total_executions, Aborted_Execution_Count, Regular_Execution_Count, Exception_Execution_Count, sampled_query_text, ROW_NUMBER() OVER (ORDER BY total_cpu_millisec DESC, query_hash ASC) AS RN
                                                              FROM AggregatedCPU)
SELECT OD.query_hash, OD.total_cpu_millisec, OD.avg_cpu_millisec, OD.max_cpu_millisec, OD.max_logical_reads, OD.number_of_distinct_plans, OD.number_of_distinct_query_ids, OD.total_executions, OD.Aborted_Execution_Count, OD.Regular_Execution_Count, OD.Exception_Execution_Count, OD.sampled_query_text, OD.RN
FROM OrderedCPU AS OD
WHERE OD.RN<=15
ORDER BY total_cpu_millisec DESC;

Sorunlu sorguları tanımladıktan sonra, CPU kullanımını azaltmak için bu sorguları ayarlamaya zaman atalım.Once you identify the problematic queries, it's time to tune those queries to reduce CPU utilization. Sorguları ayarlamaya yönelik bir zaman yoksa, bu sorunu geçici olarak çözmek için veritabanının SLO 'yu yükseltmeyi de tercih edebilirsiniz.If you don't have time to tune the queries, you may also choose to upgrade the SLO of the database to work around the issue.

GÇ performans sorunlarını tanımlaIdentify IO performance issues

GÇ performans sorunlarını belirlerken, GÇ sorunlarıyla ilişkilendirilmiş en önemli bekleme türleri şunlardır:When identifying IO performance issues, the top wait types associated with IO issues are:

  • PAGEIOLATCH_*

    Veri dosyası GÇ sorunları (, PAGEIOLATCH_SH PAGEIOLATCH_EX ,, dahil PAGEIOLATCH_UP ) için.For data file IO issues (including PAGEIOLATCH_SH, PAGEIOLATCH_EX, PAGEIOLATCH_UP). Bekleme türü adında varsa, bir GÇ sorununa işaret eder.If the wait type name has IO in it, it points to an IO issue. Sayfa mandal bekleme adında yoksa, farklı bir sorun türüne (örneğin, tempdb çekişmesi) işaret eder.If there is no IO in the page latch wait name, it points to a different type of problem (for example, tempdb contention).

  • WRITE_LOG

    İşlem günlüğü GÇ sorunları için.For transaction log IO issues.

GÇ sorunu şu anda gerçekleşirseIf the IO issue is occurring right now

Ve ' i görmek için sys.dm_exec_requests veya sys.dm_os_waiting_tasks kullanın wait_type wait_time .Use the sys.dm_exec_requests or sys.dm_os_waiting_tasks to see the wait_type and wait_time.

Veri ve günlük GÇ kullanımını tanımlaIdentify data and log IO usage

Veri ve günlük GÇ kullanımını belirlemek için aşağıdaki sorguyu kullanın.Use the following query to identify data and log IO usage. Veri veya günlük GÇ %80 ' den fazla ise, kullanıcılar SQL veritabanı hizmet katmanı için kullanılabilir GÇ 'yi kullandık.If the data or log IO is above 80%, it means users have used the available IO for the SQL Database service tier.

SELECT end_time, avg_data_io_percent, avg_log_write_percent
FROM sys.dm_db_resource_stats
ORDER BY end_time DESC;

GÇ sınırına ulaşıldığında, iki seçeneğiniz vardır:If the IO limit has been reached, you have two options:

  • 1. Seçenek: İşlem boyutunu veya hizmet katmanını yükseltinOption 1: Upgrade the compute size or service tier
  • 2. seçenek: en fazla GÇ kullanan sorguları belirleyip ayarlayın.Option 2: Identify and tune the queries consuming the most IO.

2. seçenek için, izlenen etkinliğin son iki saatini görüntülemek üzere arabelleğin ilgili GÇ için sorgu deposunda aşağıdaki sorguyu kullanabilirsiniz:For option 2, you can use the following query against Query Store for buffer-related IO to view the last two hours of tracked activity:

-- top queries that waited on buffer
-- note these are finished queries
WITH Aggregated AS (SELECT q.query_hash, SUM(total_query_wait_time_ms) total_wait_time_ms, SUM(total_query_wait_time_ms / avg_query_wait_time_ms) AS total_executions, MIN(qt.query_sql_text) AS sampled_query_text, MIN(wait_category_desc) AS wait_category_desc
                    FROM sys.query_store_query_text AS qt
                         JOIN sys.query_store_query AS q ON qt.query_text_id=q.query_text_id
                         JOIN sys.query_store_plan AS p ON q.query_id=p.query_id
                         JOIN sys.query_store_wait_stats AS waits ON waits.plan_id=p.plan_id
                         JOIN sys.query_store_runtime_stats_interval AS rsi ON rsi.runtime_stats_interval_id=waits.runtime_stats_interval_id
                    WHERE wait_category_desc='Buffer IO' AND rsi.start_time>=DATEADD(HOUR, -2, GETUTCDATE())
                    GROUP BY q.query_hash), Ordered AS (SELECT query_hash, total_executions, total_wait_time_ms, sampled_query_text, wait_category_desc, ROW_NUMBER() OVER (ORDER BY total_wait_time_ms DESC, query_hash ASC) AS RN
                                                        FROM Aggregated)
SELECT OD.query_hash, OD.total_executions, OD.total_wait_time_ms, OD.sampled_query_text, OD.wait_category_desc, OD.RN
FROM Ordered AS OD
WHERE OD.RN<=15
ORDER BY total_wait_time_ms DESC;
GO

WRITELOG Wait için toplam günlük GÇ görüntülemeView total log IO for WRITELOG waits

Bekleme türü ise WRITELOG , toplam log IO for bildirisini görüntülemek için aşağıdaki sorguyu kullanın:If the wait type is WRITELOG, use the following query to view total log IO by statement:

-- Top transaction log consumers
-- Adjust the time window by changing
-- rsi.start_time >= DATEADD(hour, -2, GETUTCDATE())
WITH AggregatedLogUsed
AS (SELECT q.query_hash,
           SUM(count_executions * avg_cpu_time / 1000.0) AS total_cpu_millisec,
           SUM(count_executions * avg_cpu_time / 1000.0) / SUM(count_executions) AS avg_cpu_millisec,
           SUM(count_executions * avg_log_bytes_used) AS total_log_bytes_used,
           MAX(rs.max_cpu_time / 1000.00) AS max_cpu_millisec,
           MAX(max_logical_io_reads) max_logical_reads,
           COUNT(DISTINCT p.plan_id) AS number_of_distinct_plans,
           COUNT(DISTINCT p.query_id) AS number_of_distinct_query_ids,
           SUM(   CASE
                      WHEN rs.execution_type_desc = 'Aborted' THEN
                          count_executions
                      ELSE
                          0
                  END
              ) AS Aborted_Execution_Count,
           SUM(   CASE
                      WHEN rs.execution_type_desc = 'Regular' THEN
                          count_executions
                      ELSE
                          0
                  END
              ) AS Regular_Execution_Count,
           SUM(   CASE
                      WHEN rs.execution_type_desc = 'Exception' THEN
                          count_executions
                      ELSE
                          0
                  END
              ) AS Exception_Execution_Count,
           SUM(count_executions) AS total_executions,
           MIN(qt.query_sql_text) AS sampled_query_text
    FROM sys.query_store_query_text AS qt
        JOIN sys.query_store_query AS q
            ON qt.query_text_id = q.query_text_id
        JOIN sys.query_store_plan AS p
            ON q.query_id = p.query_id
        JOIN sys.query_store_runtime_stats AS rs
            ON rs.plan_id = p.plan_id
        JOIN sys.query_store_runtime_stats_interval AS rsi
            ON rsi.runtime_stats_interval_id = rs.runtime_stats_interval_id
    WHERE rs.execution_type_desc IN ( 'Regular', 'Aborted', 'Exception' )
          AND rsi.start_time >= DATEADD(HOUR, -2, GETUTCDATE())
    GROUP BY q.query_hash),
     OrderedLogUsed
AS (SELECT query_hash,
           total_log_bytes_used,
           number_of_distinct_plans,
           number_of_distinct_query_ids,
           total_executions,
           Aborted_Execution_Count,
           Regular_Execution_Count,
           Exception_Execution_Count,
           sampled_query_text,
           ROW_NUMBER() OVER (ORDER BY total_log_bytes_used DESC, query_hash ASC) AS RN
    FROM AggregatedLogUsed)
SELECT OD.total_log_bytes_used,
       OD.number_of_distinct_plans,
       OD.number_of_distinct_query_ids,
       OD.total_executions,
       OD.Aborted_Execution_Count,
       OD.Regular_Execution_Count,
       OD.Exception_Execution_Count,
       OD.sampled_query_text,
       OD.RN
FROM OrderedLogUsed AS OD
WHERE OD.RN <= 15
ORDER BY total_log_bytes_used DESC;
GO

tempdbPerformans sorunlarını tanımlaIdentify tempdb performance issues

GÇ performans sorunlarını tanımlarken, sorunlarla ilişkili en üstteki bekleme türleri tempdb PAGELATCH_* (değil PAGEIOLATCH_* ) olur.When identifying IO performance issues, the top wait types associated with tempdb issues is PAGELATCH_* (not PAGEIOLATCH_*). Ancak, PAGELATCH_* beklemeleri her zaman çekişmeye sahip olduğunuz anlamına gelmez tempdb .However, PAGELATCH_* waits do not always mean you have tempdb contention. Bu bekleme aynı veri sayfasını hedefleyen eşzamanlı isteklerden dolayı kullanıcı-nesne veri sayfası çekişmesiyle karşılaştığınızı gösteriyor da olabilir.This wait may also mean that you have user-object data page contention due to concurrent requests targeting the same data page. Çekişmeyi daha fazla onaylamak için tempdb sys.dm_exec_requests kullanarak wait_resource değerin, 2:x:y 2 tempdb ' nin VERITABANı kimliği olduğu, x dosya kimliği ve y sayfa kimliği olduğunu doğrulamak için kullanın.To further confirm tempdb contention, use sys.dm_exec_requests to confirm that the wait_resource value begins with 2:x:y where 2 is tempdb is the database ID, x is the file ID, and y is the page ID.

Tempdb çekişmesi için ortak bir yöntem, ' i temel alan uygulama kodunu azaltmaktır veya yeniden yazmaktır tempdb .For tempdb contention, a common method is to reduce or rewrite application code that relies on tempdb. Ortak tempdb kullanım alanlarında şunlar bulunur:Common tempdb usage areas include:

  • Geçici tablolarTemp tables
  • Tablo değişkenleriTable variables
  • Tablo değerli parametrelerTable-valued parameters
  • Sürüm deposu kullanımı (uzun süren işlemlerle ilişkili)Version store usage (associated with long running transactions)
  • Sıralama, karma ile birleştirme ve biriktirici kullanan sorgu planlarına sahip sorgularQueries that have query plans that use sorts, hash joins, and spools

Tablo değişkenlerini ve geçici tabloları kullanan popüler sorgularTop queries that use table variables and temporary tables

Tablo değişkenlerini ve geçici tabloları kullanan en iyi sorguları belirlemek için aşağıdaki sorguyu kullanın:Use the following query to identify top queries that use table variables and temporary tables:

SELECT plan_handle, execution_count, query_plan
INTO #tmpPlan
FROM sys.dm_exec_query_stats
     CROSS APPLY sys.dm_exec_query_plan(plan_handle);
GO

WITH XMLNAMESPACES('http://schemas.microsoft.com/sqlserver/2004/07/showplan' AS sp)
SELECT plan_handle, stmt.stmt_details.value('@Database', 'varchar(max)') 'Database', stmt.stmt_details.value('@Schema', 'varchar(max)') 'Schema', stmt.stmt_details.value('@Table', 'varchar(max)') 'table'
INTO #tmp2
FROM(SELECT CAST(query_plan AS XML) sqlplan, plan_handle FROM #tmpPlan) AS p
    CROSS APPLY sqlplan.nodes('//sp:Object') AS stmt(stmt_details);
GO

SELECT t.plan_handle, [Database], [Schema], [table], execution_count
FROM(SELECT DISTINCT plan_handle, [Database], [Schema], [table]
     FROM #tmp2
     WHERE [table] LIKE '%@%' OR [table] LIKE '%#%') AS t
    JOIN #tmpPlan AS t2 ON t.plan_handle=t2.plan_handle;

Uzun süre çalışan işlemleri tanımlaIdentify long running transactions

Uzun süre çalışan işlemleri tanımlamak için aşağıdaki sorguyu kullanın.Use the following query to identify long running transactions. Uzun süre çalışan işlemler, sürüm deposunu temizlemeyi önler.Long running transactions prevent version store cleanup.

SELECT DB_NAME(dtr.database_id) 'database_name',
       sess.session_id,
       atr.name AS 'tran_name',
       atr.transaction_id,
       transaction_type,
       transaction_begin_time,
       database_transaction_begin_time transaction_state,
       is_user_transaction,
       sess.open_transaction_count,
       LTRIM(RTRIM(REPLACE(
                              REPLACE(
                                         SUBSTRING(
                                                      SUBSTRING(
                                                                   txt.text,
                                                                   (req.statement_start_offset / 2) + 1,
                                                                   ((CASE req.statement_end_offset
                                                                         WHEN -1 THEN
                                                                             DATALENGTH(txt.text)
                                                                         ELSE
                                                                             req.statement_end_offset
                                                                     END - req.statement_start_offset
                                                                    ) / 2
                                                                   ) + 1
                                                               ),
                                                      1,
                                                      1000
                                                  ),
                                         CHAR(10),
                                         ' '
                                     ),
                              CHAR(13),
                              ' '
                          )
                  )
            ) Running_stmt_text,
       recenttxt.text 'MostRecentSQLText'
FROM sys.dm_tran_active_transactions AS atr
    INNER JOIN sys.dm_tran_database_transactions AS dtr
        ON dtr.transaction_id = atr.transaction_id
    LEFT JOIN sys.dm_tran_session_transactions AS sess
        ON sess.transaction_id = atr.transaction_id
    LEFT JOIN sys.dm_exec_requests AS req
        ON req.session_id = sess.session_id
           AND req.transaction_id = sess.transaction_id
    LEFT JOIN sys.dm_exec_connections AS conn
        ON sess.session_id = conn.session_id
    OUTER APPLY sys.dm_exec_sql_text(req.sql_handle) AS txt
    OUTER APPLY sys.dm_exec_sql_text(conn.most_recent_sql_handle) AS recenttxt
WHERE atr.transaction_type != 2
      AND sess.session_id != @@spid
ORDER BY start_time ASC;

Bellek verme bekleme performans sorunlarını tanımlaIdentify memory grant wait performance issues

En iyi bekleme türü ise RESOURCE_SEMAHPORE ve yüksek CPU kullanım sorununuz yoksa, bekleyen bir bellek verme sorunu olabilir.If your top wait type is RESOURCE_SEMAHPORE and you don't have a high CPU usage issue, you may have a memory grant waiting issue.

RESOURCE_SEMAHPOREBekleme en çok bekleme olup olmadığını belirlemeDetermine if a RESOURCE_SEMAHPORE wait is a top wait

Bekleme en çok bekleme olup olmadığını anlamak için aşağıdaki sorguyu kullanın RESOURCE_SEMAHPOREUse the following query to determine if a RESOURCE_SEMAHPORE wait is a top wait

SELECT wait_type,
       SUM(wait_time) AS total_wait_time_ms
FROM sys.dm_exec_requests AS req
    JOIN sys.dm_exec_sessions AS sess
        ON req.session_id = sess.session_id
WHERE is_user_process = 1
GROUP BY wait_type
ORDER BY SUM(wait_time) DESC;

Yüksek bellek kullanan deyimleri tanımlaIdentify high memory-consuming statements

Yüksek bellek kullanan deyimleri belirlemek için aşağıdaki sorguyu kullanın:Use the following query to identify high memory-consuming statements:

SELECT IDENTITY(INT, 1, 1) rowId,
    CAST(query_plan AS XML) query_plan,
    p.query_id
INTO #tmp
FROM sys.query_store_plan AS p
    JOIN sys.query_store_runtime_stats AS r
        ON p.plan_id = r.plan_id
    JOIN sys.query_store_runtime_stats_interval AS i
        ON r.runtime_stats_interval_id = i.runtime_stats_interval_id
WHERE start_time > '2018-10-11 14:00:00.0000000'
      AND end_time < '2018-10-17 20:00:00.0000000';
GO
;WITH cte
AS (SELECT query_id,
        query_plan,
        m.c.value('@SerialDesiredMemory', 'INT') AS SerialDesiredMemory
    FROM #tmp AS t
        CROSS APPLY t.query_plan.nodes('//*:MemoryGrantInfo[@SerialDesiredMemory[. > 0]]') AS m(c) )
SELECT TOP 50
    cte.query_id,
    t.query_sql_text,
    cte.query_plan,
    CAST(SerialDesiredMemory / 1024. AS DECIMAL(10, 2)) SerialDesiredMemory_MB
FROM cte
    JOIN sys.query_store_query AS q
        ON cte.query_id = q.query_id
    JOIN sys.query_store_query_text AS t
        ON q.query_text_id = t.query_text_id
ORDER BY SerialDesiredMemory DESC;

İlk 10 etkin bellek verdiğini tanımlaIdentify the top 10 active memory grants

En iyi 10 etkin belleği veren izinleri tanımlamak için aşağıdaki sorguyu kullanın:Use the following query to identify the top 10 active memory grants:

SELECT TOP 10
    CONVERT(VARCHAR(30), GETDATE(), 121) AS runtime,
       r.session_id,
       r.blocking_session_id,
       r.cpu_time,
       r.total_elapsed_time,
       r.reads,
       r.writes,
       r.logical_reads,
       r.row_count,
       wait_time,
       wait_type,
       r.command,
       OBJECT_NAME(txt.objectid, txt.dbid) 'Object_Name',
       LTRIM(RTRIM(REPLACE(
                              REPLACE(
                                         SUBSTRING(
                                                      SUBSTRING(
                                                                   text,
                                                                   (r.statement_start_offset / 2) + 1,
                                                                   ((CASE r.statement_end_offset
                                                                         WHEN -1 THEN
                                                                             DATALENGTH(text)
                                                                         ELSE
                                                                             r.statement_end_offset
                                                                     END - r.statement_start_offset
                                                                    ) / 2
                                                                   ) + 1
                                                               ),
                                                      1,
                                                      1000
                                                  ),
                                         CHAR(10),
                                         ' '
                                     ),
                              CHAR(13),
                              ' '
                          )
                  )
            ) stmt_text,
       mg.dop,                                               --Degree of parallelism
       mg.request_time,                                      --Date and time when this query requested the memory grant.
       mg.grant_time,                                        --NULL means memory has not been granted
       mg.requested_memory_kb / 1024.0 requested_memory_mb,  --Total requested amount of memory in megabytes
       mg.granted_memory_kb / 1024.0 AS granted_memory_mb,   --Total amount of memory actually granted in megabytes. NULL if not granted
       mg.required_memory_kb / 1024.0 AS required_memory_mb, --Minimum memory required to run this query in megabytes.
       max_used_memory_kb / 1024.0 AS max_used_memory_mb,
       mg.query_cost,                                        --Estimated query cost.
       mg.timeout_sec,                                       --Time-out in seconds before this query gives up the memory grant request.
       mg.resource_semaphore_id,                             --Non-unique ID of the resource semaphore on which this query is waiting.
       mg.wait_time_ms,                                      --Wait time in milliseconds. NULL if the memory is already granted.
       CASE mg.is_next_candidate --Is this process the next candidate for a memory grant
           WHEN 1 THEN
               'Yes'
           WHEN 0 THEN
               'No'
           ELSE
               'Memory has been granted'
       END AS 'Next Candidate for Memory Grant',
       qp.query_plan
FROM sys.dm_exec_requests AS r
    JOIN sys.dm_exec_query_memory_grants AS mg
        ON r.session_id = mg.session_id
           AND r.request_id = mg.request_id
    CROSS APPLY sys.dm_exec_sql_text(mg.sql_handle) AS txt
    CROSS APPLY sys.dm_exec_query_plan(r.plan_handle) AS qp
ORDER BY mg.granted_memory_kb DESC;

Veritabanı ve nesne boyutlarını hesaplamaCalculating database and objects sizes

Aşağıdaki sorgu veritabanınızın boyutunu döndürür (megabayt cinsinden):The following query returns the size of your database (in megabytes):

-- Calculates the size of the database.
SELECT SUM(CAST(FILEPROPERTY(name, 'SpaceUsed') AS bigint) * 8192.) / 1024 / 1024 AS DatabaseSizeInMB
FROM sys.database_files
WHERE type_desc = 'ROWS';
GO

Aşağıdaki sorgu veritabanınızdaki tek tek nesnelerin boyutunu döndürür (megabayt cinsinden):The following query returns the size of individual objects (in megabytes) in your database:

-- Calculates the size of individual database objects.
SELECT sys.objects.name, SUM(reserved_page_count) * 8.0 / 1024
FROM sys.dm_db_partition_stats, sys.objects
WHERE sys.dm_db_partition_stats.object_id = sys.objects.object_id
GROUP BY sys.objects.name;
GO

İzleme bağlantılarıMonitoring connections

Belirli bir sunucuya ve yönetilen örneğe ve her bir bağlantının ayrıntılarına kurulan bağlantılar hakkında bilgi almak için sys.dm_exec_connections görünümünü kullanabilirsiniz.You can use the sys.dm_exec_connections view to retrieve information about the connections established to a specific server and managed instance and the details of each connection. Ayrıca, sys.dm_exec_sessions görünümü tüm etkin kullanıcı bağlantıları ve iç görevler hakkında bilgi alırken yararlı olur.In addition, the sys.dm_exec_sessions view is helpful when retrieving information about all active user connections and internal tasks.

Aşağıdaki sorgu geçerli bağlantı hakkındaki bilgileri alır:The following query retrieves information on the current connection:

SELECT
    c.session_id, c.net_transport, c.encrypt_option,
    c.auth_scheme, s.host_name, s.program_name,
    s.client_interface_name, s.login_name, s.nt_domain,
    s.nt_user_name, s.original_login_name, c.connect_time,
    s.login_time
FROM sys.dm_exec_connections AS c
JOIN sys.dm_exec_sessions AS s
    ON c.session_id = s.session_id
WHERE c.session_id = @@SPID;

Not

Sys.dm_exec_requests ve sys.dm_exec_sessions görünümleri YÜRÜTÜRKEN, veritabanında veritabanı durumunu görüntüle izniniz varsa, veritabanında yürütülen tüm oturumları görürsünüz; Aksi takdirde, yalnızca geçerli oturumu görürsünüz.When executing the sys.dm_exec_requests and sys.dm_exec_sessions views, if you have VIEW DATABASE STATE permission on the database, you see all executing sessions on the database; otherwise, you see only the current session.

Kaynak kullanımını izlemeMonitor resource use

SQL veritabanı sorgu performansı içgörülerikullanarak Azure SQL veritabanı kaynak kullanımı 'nı izleyebilirsiniz.You can monitor Azure SQL Database resource usage using SQL Database Query Performance Insight. Azure SQL veritabanı ve Azure SQL yönetilen örneği için Query Store'u kullanarak izleyebilirsiniz.For Azure SQL Database and Azure SQL Managed Instance, you can monitor using Query Store.

Ayrıca, bu görünümleri kullanarak kullanımı izleyebilirsiniz:You can also monitor usage using these views:

sys.dm_db_resource_statssys.dm_db_resource_stats

Her veritabanında sys.dm_db_resource_stats görünümünü kullanabilirsiniz.You can use the sys.dm_db_resource_stats view in every database. Sys.dm_db_resource_stats görünümü, hizmet katmanına göre son kaynak kullanım verilerini gösterir.The sys.dm_db_resource_stats view shows recent resource use data relative to the service tier. CPU, veri GÇ, günlük yazma ve bellek için Ortalama yüzdeler, 15 saniyede bir kaydedilir ve 1 saat boyunca sürdürülür.Average percentages for CPU, data IO, log writes, and memory are recorded every 15 seconds and are maintained for 1 hour.

Bu görünüm, kaynak kullanımına daha ayrıntılı bir bakış sağladığından, geçerli durum analizi veya sorun giderme için önce sys.dm_db_resource_stats kullanın.Because this view provides a more granular look at resource use, use sys.dm_db_resource_stats first for any current-state analysis or troubleshooting. Örneğin, bu sorgu, son saat içindeki geçerli veritabanı için Ortalama ve en yüksek kaynak kullanımını gösterir:For example, this query shows the average and maximum resource use for the current database over the past hour:

SELECT  
    AVG(avg_cpu_percent) AS 'Average CPU use in percent',
    MAX(avg_cpu_percent) AS 'Maximum CPU use in percent',
    AVG(avg_data_io_percent) AS 'Average data IO in percent',
    MAX(avg_data_io_percent) AS 'Maximum data IO in percent',
    AVG(avg_log_write_percent) AS 'Average log write use in percent',
    MAX(avg_log_write_percent) AS 'Maximum log write use in percent',
    AVG(avg_memory_usage_percent) AS 'Average memory use in percent',
    MAX(avg_memory_usage_percent) AS 'Maximum memory use in percent'
FROM sys.dm_db_resource_stats;  

Diğer sorgular için sys.dm_db_resource_statsörneklere bakın.For other queries, see the examples in sys.dm_db_resource_stats.

sys.server_resource_statssys.server_resource_stats

Azure SQL yönetilen örneği için CPU kullanımı, GÇ ve depolama verilerini döndürmek üzere sys.server_resource_stats kullanabilirsiniz.You can use sys.server_resource_stats to return CPU usage, IO, and storage data for an Azure SQL Managed Instance. Veriler, beş dakikalık aralıklar içinde toplanır ve toplanır.The data is collected and aggregated within five-minute intervals. 15 saniyelik her raporlama için bir satır vardır.There is one row for every 15 seconds reporting. Döndürülen veriler CPU kullanımı, depolama boyutu, GÇ kullanımı ve yönetilen örnek SKU 'SU içerir.The data returned includes CPU usage, storage size, IO utilization, and managed instance SKU. Geçmiş verileri yaklaşık 14 gün boyunca tutulur.Historical data is retained for approximately 14 days.

DECLARE @s datetime;  
DECLARE @e datetime;  
SET @s= DateAdd(d,-7,GetUTCDate());  
SET @e= GETUTCDATE();  
SELECT resource_name, AVG(avg_cpu_percent) AS Average_Compute_Utilization
FROM sys.server_resource_stats
WHERE start_time BETWEEN @s AND @e  
GROUP BY resource_name  
HAVING AVG(avg_cpu_percent) >= 80;

sys.resource_statssys.resource_stats

Ana veritabanındaki sys.resource_stats görünümünde, veritabanınızın performansını belirli hizmet katmanında ve işlem boyutuyla izlemenize yardımcı olabilecek ek bilgiler bulunur.The sys.resource_stats view in the master database has additional information that can help you monitor the performance of your database at its specific service tier and compute size. Veriler her 5 dakikada bir toplanır ve yaklaşık 14 gün boyunca korunur.The data is collected every 5 minutes and is maintained for approximately 14 days. Bu görünüm, veritabanınızın kaynakları nasıl kullandığına yönelik daha uzun vadeli geçmiş analizler için yararlıdır.This view is useful for a longer-term historical analysis of how your database uses resources.

Aşağıdaki grafikte, bir haftada her saat için P2 işlem boyutuyla bir Premium veritabanı için CPU kaynak kullanımı gösterilmektedir.The following graph shows the CPU resource use for a Premium database with the P2 compute size for each hour in a week. Bu grafik Pazartesi günü başlar, beş iş günü gösterir ve uygulamada çok daha az gerçekleştiğinde bir hafta sonu gösterir.This graph starts on a Monday, shows five work days, and then shows a weekend, when much less happens on the application.

Veritabanı kaynak kullanımı

Bu veritabanında Şu anda, P2 işlem boyutuna (Salı günü Orta gün) göre yüzde 50 ' luk CPU 'nun en yüksek CPU yükü vardır.From the data, this database currently has a peak CPU load of just over 50 percent CPU use relative to the P2 compute size (midday on Tuesday). CPU, uygulamanın kaynak profilinde baskın bir faktörse, iş yükünün her zaman uygun olmasını sağlamak için P2 doğru işlem boyutu olduğuna karar verebilirsiniz.If CPU is the dominant factor in the application's resource profile, then you might decide that P2 is the right compute size to guarantee that the workload always fits. Bir uygulamanın zaman içinde büyümesini bekleseniz, uygulamanın performans düzeyi sınırına ulaşmaması için ek bir kaynak arabelleğinin olması iyi bir fikirdir.If you expect an application to grow over time, it's a good idea to have an extra resource buffer so that the application doesn't ever reach the performance-level limit. İşlem boyutunu artırdıysanız, bir veritabanı istekleri etkili bir şekilde işlemek için yeterli güce sahip olmadığında, özellikle de gecikme süresine duyarlı ortamlarda oluşabilecek, müşteri tarafından görünen hatalardan kaçınmanıza yardımcı olabilirsiniz.If you increase the compute size, you can help avoid customer-visible errors that might occur when a database doesn't have enough power to process requests effectively, especially in latency-sensitive environments. Veritabanı çağrılarının sonuçlarına göre Web sayfalarını boyayan bir uygulamayı destekleyen bir veritabanıdır.An example is a database that supports an application that paints webpages based on the results of database calls.

Diğer uygulama türleri aynı grafiği farklı şekilde yorumlayabilir.Other application types might interpret the same graph differently. Örneğin, bir uygulama her gün Bordro verilerini işlemeye çalışırsa ve aynı grafiğe sahipse, bu tür "Batch işi" modeli P1 işlem boyutunda ince bir işlem gösterebilir.For example, if an application tries to process payroll data each day and has the same chart, this kind of "batch job" model might do fine at a P1 compute size. P1 işlem boyutunun, P2 işlem boyutundaki 200 DTU ile karşılaştırıldığında 100 DTU vardır.The P1 compute size has 100 DTUs compared to 200 DTUs at the P2 compute size. P1 işlem boyutu, P2 işlem boyutu performansının yarısını sağlar.The P1 compute size provides half the performance of the P2 compute size. Bu nedenle, P2 cinsinden CPU kullanımı yüzdesi ' nde 50, P1 ' de yüzde 100 CPU kullanımı.So, 50 percent of CPU use in P2 equals 100 percent CPU use in P1. Uygulamanın zaman aşımları yoksa, bugün yapılacağından, bir işin 2 saat veya 2,5 saat sürer.If the application does not have timeouts, it might not matter if a job takes 2 hours or 2.5 hours to finish, if it gets done today. Bu kategorideki bir uygulama büyük olasılıkla P1 işlem boyutunu kullanabilir.An application in this category probably can use a P1 compute size. Kaynak kullanımı düşük olduğunda gün içinde zaman dilimi olduğunu düşündüğünde, "büyük tepe" nın, gün içinde Troughs daha sonraki bir arasında taşma süresi vardır.You can take advantage of the fact that there are periods of time during the day when resource use is lower, so that any "big peak" might spill over into one of the troughs later in the day. P1 işlem boyutu, işlerin her gün bitebilmesi koşuluyla, bu tür bir uygulama (ve tasarruf) için uygun olabilir.The P1 compute size might be good for that kind of application (and save money), as long as the jobs can finish on time each day.

Veritabanı altyapısı her bir etkin veritabanı için tüketilen kaynak bilgilerini her bir sunucuda ana veritabanının sys.resource_stats görünümünde gösterir.The database engine exposes consumed resource information for each active database in the sys.resource_stats view of the master database in each server. Tablodaki veriler 5 dakikalık aralıklar için toplanır.The data in the table is aggregated for 5-minute intervals. Temel, standart ve Premium hizmet katmanlarıyla, verilerin tabloda görünmesi 5 dakikadan uzun sürebilir, bu nedenle bu veriler, neredeyse gerçek zamanlı analizler yerine geçmiş analize yönelik daha kullanışlı olabilir.With the Basic, Standard, and Premium service tiers, the data can take more than 5 minutes to appear in the table, so this data is more useful for historical analysis rather than near-real-time analysis. Bir veritabanının son geçmişini görmek ve seçtiğiniz rezervasyonun gerektiğinde istediğiniz performansı teslim edilip edilmeyeceğini doğrulamak için sys.resource_stats görünümünü sorgulayın.Query the sys.resource_stats view to see the recent history of a database and to validate whether the reservation you chose delivered the performance you want when needed.

Not

Azure SQL veritabanı 'nda aşağıdaki örneklerde sys.resource_stats sorgulamak için ana veritabanına bağlı olmanız gerekir.On Azure SQL Database, you must be connected to the master database to query sys.resource_stats in the following examples.

Bu örnek, bu görünümdeki verilerin nasıl sunulduğunu gösterir:This example shows you how the data in this view is exposed:

SELECT TOP 10 *
FROM sys.resource_stats
WHERE database_name = 'resource1'
ORDER BY start_time DESC;

Sys.resource_stats Catalog görünümü

Sonraki örnekte, veritabanınızın kaynakları nasıl kullandığı hakkında bilgi almak için sys.resource_stats katalog görünümünü kullanmanın farklı yolları gösterilmektedir:The next example shows you different ways that you can use the sys.resource_stats catalog view to get information about how your database uses resources:

  1. Veritabanı userdb1 için geçen haftaki kaynak kullanımına bakmak için bu sorguyu çalıştırabilirsiniz:To look at the past week's resource use for the database userdb1, you can run this query:

    SELECT *
    FROM sys.resource_stats
    WHERE database_name = 'userdb1' AND
        start_time > DATEADD(day, -7, GETDATE())
    ORDER BY start_time DESC;
    
  2. İş yükünüzün işlem boyutuna ne kadar iyi uyduğunu değerlendirmek için, kaynak ölçümlerinin her bir yönüyle ayrıntıya inmelisiniz: CPU, okuma, yazma, çalışan sayısı ve oturum sayısı.To evaluate how well your workload fits the compute size, you need to drill down into each aspect of the resource metrics: CPU, reads, writes, number of workers, and number of sessions. Bu kaynak ölçümlerinin ortalama ve en büyük değerlerini raporlamak için sys.resource_stats kullanan düzeltilmiş bir sorgu aşağıda verilmiştir:Here's a revised query using sys.resource_stats to report the average and maximum values of these resource metrics:

    SELECT
        avg(avg_cpu_percent) AS 'Average CPU use in percent',
        max(avg_cpu_percent) AS 'Maximum CPU use in percent',
        avg(avg_data_io_percent) AS 'Average physical data IO use in percent',
        max(avg_data_io_percent) AS 'Maximum physical data IO use in percent',
        avg(avg_log_write_percent) AS 'Average log write use in percent',
        max(avg_log_write_percent) AS 'Maximum log write use in percent',
        avg(max_session_percent) AS 'Average % of sessions',
        max(max_session_percent) AS 'Maximum % of sessions',
        avg(max_worker_percent) AS 'Average % of workers',
        max(max_worker_percent) AS 'Maximum % of workers'
    FROM sys.resource_stats
    WHERE database_name = 'userdb1' AND start_time > DATEADD(day, -7, GETDATE());
    
  3. Her kaynak ölçüsünün ortalama ve en yüksek değerleriyle ilgili bu bilgilerle, iş yükünüzün seçtiğiniz işlem boyutuna ne kadar iyi uyduğunu değerlendirebilirsiniz.With this information about the average and maximum values of each resource metric, you can assess how well your workload fits into the compute size you chose. Genellikle sys.resource_stats içindeki ortalama değerler, hedef boyutunda kullanmak için iyi bir taban çizgisi sağlar.Usually, average values from sys.resource_stats give you a good baseline to use against the target size. Bu, birincil ölçüm çubuğu olmalıdır.It should be your primary measurement stick. Bir örnek için, S2 işlem boyutuyla standart hizmet katmanını kullanıyor olabilirsiniz.For an example, you might be using the Standard service tier with S2 compute size. CPU ve GÇ okuma ve yazma işlemleri için Ortalama kullanım yüzdesi %40, ortalama çalışan sayısı 50 ' in altında ve ortalama oturum sayısı 200 ' in altında.The average use percentages for CPU and IO reads and writes are below 40 percent, the average number of workers is below 50, and the average number of sessions is below 200. İş yükünüz, S1 işlem boyutuna uygun hale gelebilir.Your workload might fit into the S1 compute size. Veritabanınızın çalışan ve oturum sınırlarına uygun olup olmadığını kolayca görebilirsiniz.It's easy to see whether your database fits in the worker and session limits. Bir veritabanının CPU, okuma ve yazma işlemlerinde daha düşük bir işlem boyutuna uygun olup olmadığını görmek için, düşük işlem boyutunun DTU numarasını geçerli işlem boyutunuzu DTU numarası ile bölün ve sonucu 100 ile çarpın:To see whether a database fits into a lower compute size with regard to CPU, reads, and writes, divide the DTU number of the lower compute size by the DTU number of your current compute size, and then multiply the result by 100:

    S1 DTU / S2 DTU * 100 = 20 / 50 * 100 = 40

    Sonuç, yüzde cinsinden iki işlem boyutu arasındaki göreli performans farklılığı.The result is the relative performance difference between the two compute sizes in percentage. Kaynak kullanımı bu miktarı aşmazsa, iş yükünüz daha düşük işlem boyutuna sığabilecek.If your resource use doesn't exceed this amount, your workload might fit into the lower compute size. Bununla birlikte, tüm kaynak kullanım değerleri aralıklarına bakmanız ve veritabanı iş yükünüzün daha düşük bilgi işlem boyutuna ne sıklıkta uyduğunu belirlemeniz gerekir.However, you need to look at all ranges of resource use values, and determine, by percentage, how often your database workload would fit into the lower compute size. Aşağıdaki sorgu, bu örnekte hesaplandığımız %40 eşiğine bağlı olarak kaynak boyutu başına sığdırma yüzdesini verir:The following query outputs the fit percentage per resource dimension, based on the threshold of 40 percent that we calculated in this example:

     SELECT
         (COUNT(database_name) - SUM(CASE WHEN avg_cpu_percent >= 40 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'CPU Fit Percent',
         (COUNT(database_name) - SUM(CASE WHEN avg_log_write_percent >= 40 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Log Write Fit Percent',
         (COUNT(database_name) - SUM(CASE WHEN avg_data_io_percent >= 40 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Physical Data IO Fit Percent'
     FROM sys.resource_stats
     WHERE database_name = 'userdb1' AND start_time > DATEADD(day, -7, GETDATE());
    

    Veritabanı hizmet katmanınıza göre, iş yükünüzün daha düşük işlem boyutuna uygun olup olmadığına karar verebilirsiniz.Based on your database service tier, you can decide whether your workload fits into the lower compute size. Veritabanı iş yükü hedefiniz yüzde 99,9 ise ve önceki sorgu üç kaynak boyutu için yüzde 99,9 ' den daha büyük değerler döndürürse, iş yükünüz büyük olasılıkla daha düşük bilgi işlem boyutuna uyum altına ar.If your database workload objective is 99.9 percent and the preceding query returns values greater than 99.9 percent for all three resource dimensions, your workload likely fits into the lower compute size.

    Aynı yüzdeyi göz altına almak, amacınızı karşılamak için bir sonraki daha yüksek işlem boyutuna geçmeniz gerekip gerekmediğini de size fikir verir.Looking at the fit percentage also gives you insight into whether you should move to the next higher compute size to meet your objective. Örneğin, userdb1, önceki hafta için aşağıdaki CPU kullanımını gösterir:For example, userdb1 shows the following CPU use for the past week:

    Ortalama CPU yüzdesiAverage CPU percent En yüksek CPU yüzdesiMaximum CPU percent
    24,524.5 100,00100.00

    Ortalama CPU, işlem boyutu sınırının bir çeyreği ile ilgilidir ve veritabanının işlem boyutuna da uyum sağlayacak.The average CPU is about a quarter of the limit of the compute size, which would fit well into the compute size of the database. Ancak en büyük değer, veritabanının işlem boyutu sınırına ulaştığını gösterir.But, the maximum value shows that the database reaches the limit of the compute size. Sonraki daha yüksek işlem boyutuna geçmeniz gerekiyor mu?Do you need to move to the next higher compute size? İş yükünüzün kaç kez yüzde 100 ' e ulaştığını inceleyin ve ardından veritabanı iş yükü hedefiniz ile karşılaştırın.Look at how many times your workload reaches 100 percent, and then compare it to your database workload objective.

    SELECT
        (COUNT(database_name) - SUM(CASE WHEN avg_cpu_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'CPU fit percent'
        ,(COUNT(database_name) - SUM(CASE WHEN avg_log_write_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Log write fit percent'
        ,(COUNT(database_name) - SUM(CASE WHEN avg_data_io_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Physical data IO fit percent'
        FROM sys.resource_stats
        WHERE database_name = 'userdb1' AND start_time > DATEADD(day, -7, GETDATE());
    

    Bu sorgu, üç kaynak boyutundan herhangi biri için yüzde 99,9 ' dan düşük bir değer döndürürse, sonraki daha yüksek işlem boyutuna geçmeyi ya da veritabanı üzerindeki yükü azaltmak için uygulama ayarlama tekniklerini kullanmayı düşünün.If this query returns a value less than 99.9 percent for any of the three resource dimensions, consider either moving to the next higher compute size or use application-tuning techniques to reduce the load on the database.

  4. Bu alıştırma, gelecekte öngörülen iş yükünüzün artışını de dikkate alır.This exercise also considers your projected workload increase in the future.

Elastik havuzlar için bu bölümde açıklanan olan tekniklerle havuzda bulunan tek veritabanlarını izleyebilirsiniz.For elastic pools, you can monitor individual databases in the pool with the techniques described in this section. Ancak havuzu bir bütün olarak da izleyebilirsiniz.But you can also monitor the pool as a whole. Bilgi için bkz. Elastik havuz izleme ve yönetme.For information, see Monitor and manage an elastic pool.

Maksimum eşzamanlı istek sayısıMaximum concurrent requests

Eşzamanlı isteklerin sayısını görmek için, bu Transact-SQL sorgusunu veritabanınızda çalıştırın:To see the number of concurrent requests, run this Transact-SQL query on your database:

SELECT COUNT(*) AS [Concurrent_Requests]
FROM sys.dm_exec_requests R;

Bir SQL Server veritabanının iş yükünü çözümlemek için, bu sorguyu çözümlemek istediğiniz belirli veritabanına göre filtrelemek üzere değiştirin.To analyze the workload of a SQL Server database, modify this query to filter on the specific database you want to analyze. Örneğin, MyDatabase adlı bir şirket içi veritabanınız varsa, bu Transact-SQL sorgusu söz konusu veritabanındaki eşzamanlı isteklerin sayısını döndürür:For example, if you have an on-premises database named MyDatabase, this Transact-SQL query returns the count of concurrent requests in that database:

SELECT COUNT(*) AS [Concurrent_Requests]
FROM sys.dm_exec_requests R
INNER JOIN sys.databases D ON D.database_id = R.database_id
AND D.name = 'MyDatabase';

Bu, tek bir noktadaki yalnızca bir anlık görüntüdür.This is just a snapshot at a single point in time. İş yükünüzü ve eşzamanlı istek gereksinimlerinizi daha iyi anlamak için zaman içinde birçok örnek toplamanız gerekir.To get a better understanding of your workload and concurrent request requirements, you'll need to collect many samples over time.

Maksimum eşzamanlı oturum açmaMaximum concurrent logins

Kullanıcı ve uygulama desenlerinizi çözümleyerek oturum açma sıklığının bir fikrini alabilirsiniz.You can analyze your user and application patterns to get an idea of the frequency of logins. Ayrıca, bu makalede tartıştığımız bu veya diğer sınırlara ulaştığınızdan emin olmak için bir test ortamında gerçek dünya yüklerini çalıştırabilirsiniz.You also can run real-world loads in a test environment to make sure that you're not hitting this or other limits we discuss in this article. Eşzamanlı oturum açma sayısını veya geçmişi gösterebilmeyen tek bir sorgu veya dinamik yönetim görünümü (DMV) yoktur.There isn't a single query or dynamic management view (DMV) that can show you concurrent login counts or history.

Birden çok istemci aynı bağlantı dizesini kullanıyorsa, hizmet her oturum açmanın kimliğini doğrular.If multiple clients use the same connection string, the service authenticates each login. 10 Kullanıcı aynı anda bir veritabanına aynı Kullanıcı adı ve parola kullanarak bağlanırsa, 10 eşzamanlı oturum açma işlemleri olur.If 10 users simultaneously connect to a database by using the same username and password, there would be 10 concurrent logins. Bu sınır yalnızca oturum açma ve kimlik doğrulama süresi boyunca geçerlidir.This limit applies only to the duration of the login and authentication. Aynı 10 kullanıcının veritabanına sırayla bağlanması halinde, eşzamanlı oturum açma sayısı 1 ' den büyük olmaz.If the same 10 users connect to the database sequentially, the number of concurrent logins would never be greater than 1.

Not

Şu anda, bu sınır elastik havuzlardaki veritabanları için geçerli değildir.Currently, this limit does not apply to databases in elastic pools.

En fazla oturum sayısıMaximum sessions

Geçerli etkin oturumların sayısını görmek için, bu Transact-SQL sorgusunu veritabanınızda çalıştırın:To see the number of current active sessions, run this Transact-SQL query on your database:

SELECT COUNT(*) AS [Sessions]
FROM sys.dm_exec_connections;

Bir SQL Server iş yükünü analiz ediyorsanız, sorguyu belirli bir veritabanına odaklanmak üzere değiştirin.If you're analyzing a SQL Server workload, modify the query to focus on a specific database. Bu sorgu, Azure 'a taşımayı düşünüyorsanız veritabanına yönelik olası oturum ihtiyaçlarını belirlemenize yardımcı olur.This query helps you determine possible session needs for the database if you are considering moving it to Azure.

SELECT COUNT(*) AS [Sessions]
FROM sys.dm_exec_connections C
INNER JOIN sys.dm_exec_sessions S ON (S.session_id = C.session_id)
INNER JOIN sys.databases D ON (D.database_id = S.database_id)
WHERE D.name = 'MyDatabase';

Yine, bu sorgular bir zaman noktası sayısı döndürür.Again, these queries return a point-in-time count. Zaman içinde birden çok örnek topluyorsanız, oturum kullanımı en iyi şekilde öğrenirsiniz.If you collect multiple samples over time, you'll have the best understanding of your session use.

Sys.resource_stats görünümünü sorgulayarak ve active_session_count sütununu inceleyerek oturumlardaki geçmiş istatistiklerini alabilirsiniz.You can get historical statistics on sessions by querying the sys.resource_stats view and reviewing the active_session_count column.

Sorgu performansını izlemeMonitoring query performance

Yavaş veya uzun süre çalışan sorgular önemli sistem kaynaklarını kullanabilir.Slow or long running queries can consume significant system resources. Bu bölümde, yaygın olarak karşılaşılan bazı sorgu performans sorunlarını algılamak için dinamik yönetim görünümlerinin nasıl kullanılacağı gösterilmektedir.This section demonstrates how to use dynamic management views to detect a few common query performance problems.

İlk N sorguyu bulmaFinding top N queries

Aşağıdaki örnek, ortalama CPU zamanına göre derecelendirilen ilk beş sorgu hakkında bilgi döndürür.The following example returns information about the top five queries ranked by average CPU time. Bu örnek, sorguları kendi sorgu karmalarına göre toplar, böylece mantıksal olarak eşdeğer sorguların birikimli kaynak tüketimine göre gruplanmasıdır.This example aggregates the queries according to their query hash, so that logically equivalent queries are grouped by their cumulative resource consumption.

SELECT TOP 5 query_stats.query_hash AS "Query Hash",
    SUM(query_stats.total_worker_time) / SUM(query_stats.execution_count) AS "Avg CPU Time",
     MIN(query_stats.statement_text) AS "Statement Text"
FROM
    (SELECT QS.*,
        SUBSTRING(ST.text, (QS.statement_start_offset/2) + 1,
            ((CASE statement_end_offset
                WHEN -1 THEN DATALENGTH(ST.text)
                ELSE QS.statement_end_offset END
            - QS.statement_start_offset)/2) + 1) AS statement_text
FROM sys.dm_exec_query_stats AS QS
CROSS APPLY sys.dm_exec_sql_text(QS.sql_handle) as ST) as query_stats
GROUP BY query_stats.query_hash
ORDER BY 2 DESC;

Engellenen sorguları izlemeMonitoring blocked queries

Yavaş veya uzun süre çalışan sorgular aşırı kaynak tüketimine katkıda bulunabilir ve engellenen sorguların sonucu olabilir.Slow or long-running queries can contribute to excessive resource consumption and be the consequence of blocked queries. Engellemenin nedeni kötü uygulama tasarımı, hatalı sorgu planları, faydalı dizinlerin bulunmaması vb. olabilir.The cause of the blocking can be poor application design, bad query plans, the lack of useful indexes, and so on. Veritabanındaki geçerli kilitleme etkinliği hakkında bilgi almak için sys.dm_tran_locks görünümünü kullanabilirsiniz.You can use the sys.dm_tran_locks view to get information about the current locking activity in database. Örnek kod için bkz. sys.dm_tran_locks (Transact-SQL).For example code, see sys.dm_tran_locks (Transact-SQL). Engelleme sorunlarını giderme hakkında daha fazla bilgi için bkz. Azure SQL engelleme sorunlarını anlama ve çözme.For more information on troubleshooting blocking, see Understand and resolve Azure SQL blocking problems.

Sorgu planlarını izlemeMonitoring query plans

Verimsiz bir sorgu planı, CPU tüketimini de artırabilir.An inefficient query plan also may increase CPU consumption. Aşağıdaki örnek, hangi sorgunun en birikimli CPU 'YU kullandığını belirleyen sys.dm_exec_query_stats görünümünü kullanır.The following example uses the sys.dm_exec_query_stats view to determine which query uses the most cumulative CPU.

SELECT
    highest_cpu_queries.plan_handle,
    highest_cpu_queries.total_worker_time,
    q.dbid,
    q.objectid,
    q.number,
    q.encrypted,
    q.[text]
FROM
    (SELECT TOP 50
        qs.plan_handle,
        qs.total_worker_time
    FROM
        sys.dm_exec_query_stats qs
ORDER BY qs.total_worker_time desc) AS highest_cpu_queries
CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS q
ORDER BY highest_cpu_queries.total_worker_time DESC;

Ayrıca bkz.See also

Azure SQL veritabanı ve Azure SQL yönetilen örneği 'ne girişIntroduction to Azure SQL Database and Azure SQL Managed Instance