Dinamik yönetim görünümleri ((Dynamic management views)(DMV’ler)) Nedir?

SQL Server 2005’te tanıtılan Dinamik yönetim görünümleri (DMV’ler), SQL Server’ın önemli özellikleridir. Yürütme planları, sorgu istatistikleri, son sorgular vb. hakkında veri sağlayan birkaç DMV vardır. Bunlar, bir SQL Server örneğinde neler olup bittiğini belirlemek için birlikte kullanılabilir. Bu gönderide, kaynaklarınızın nereye harcandığını ve çok daha fazlasını belirlemenize yardımcı olabilecek bazı yararlı sorguları listeleyeceğim. NOT: Sorgular şunlar için geçerlidir: SQL Server 2014 (12.x) ve sonrası.

Top TSQL by reads

Storage okumaları SQL’in yapabileceği en yavaş işlemdir. Bu nedenle, ayarlama yaparken, en fazla mantıksal okumaya neden olan TSQL çağrılarına odaklanmak genellikle mantıklıdır. Depolama erişimi azaltılırsa SQL daha az CPU’ya ihtiyaç duyar ve sorgunun süresi artar. Mantıksal (depolama) okumalara göre en pahalı 10 TSQL çağrısını elde etmek için aşağıdaki sorguyu çalıştırın:
SELECT TOP(10) DB_NAME(t.[dbid]) AS [Database], REPLACE(REPLACE(LEFT(t.[text], 255), CHAR(10),”), CHAR(13),”) AS [ShortQueryTXT], qs.total_logical_reads AS [TotalLogicalReads], qs.min_logical_reads AS [MinLogicalReads], qs.total_logical_reads/qs.execution_count AS [AvgLogicalReads], qs.max_logical_reads AS [MaxLogicalReads], qs.min_worker_time AS [MinWorkerTime], qs.total_worker_time/qs.execution_count AS [AvgWorkerTime], qs.max_worker_time AS [MaxWorkerTime], qs.min_elapsed_time AS [MinElapsedTime], qs.total_elapsed_time/qs.execution_count AS [AvgElapsedTime], qs.max_elapsed_time AS [MaxElapsedTime], qs.execution_count AS [ExecutionCount], CASE WHEN CONVERT(nvarchar(max), qp.query_plan) LIKE N’%%’ THEN 1 ELSE 0 END AS [HasMissingIX], qs.creation_time AS [CreationTime] ,t.[text] AS [Complete Query Text], qp.query_plan AS [QueryPlan] FROM sys.dm_exec_query_stats AS qs WITH (NOLOCK) CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS t CROSS APPLY sys.dm_exec_query_plan(plan_handle) AS qp ORDER BY qs.total_logical_reads DESC OPTION (RECOMPILE)

Top TSQL by CPU

Toplam Çalışan Süresi en yüksek toplam CPU döngüsü anlamına gelir. En pahalı ilk 10 TSQL CPU tüketicisini bulmak için aşağıdaki sorguyu çalıştırın.
SELECT TOP(10) DB_NAME(t.[dbid]) AS [Database], REPLACE(REPLACE(LEFT(t.[text], 255), CHAR(10),”), CHAR(13),”) AS [ShortQueryText], qs.total_worker_time AS [Total Worker Time], qs.min_worker_time AS [MinWorkerTime], qs.total_worker_time/qs.execution_count AS [AvgWorkerTime], qs.max_worker_time AS [MaxWorkerTime], qs.min_elapsed_time AS [MinElapsedTime], qs.total_elapsed_time/qs.execution_count AS [AvgElapsedTime], qs.max_elapsed_time AS [MaxElapsedTime], qs.min_logical_reads AS [MinLogicalReads], qs.total_logical_reads/qs.execution_count AS [AvgLogicalReads], qs.max_logical_reads AS [MaxLogicalReads], qs.execution_count AS [ExecutionCount], CASE WHEN CONVERT(nvarchar(max), qp.query_plan) LIKE N’%%’ THEN 1 ELSE 0 END AS [HasMissingIX], qs.creation_time AS [CreationTime] ,t.[text] AS [Query Text], qp.query_plan AS [QueryPlan] FROM sys.dm_exec_query_stats AS qs WITH (NOLOCK) CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS t CROSS APPLY sys.dm_exec_query_plan(plan_handle) AS qp ORDER BY qs.total_worker_time DESC OPTION (RECOMPILE)

Top TSQL by execution count

En iyi 10 TSQL çağrısını almak için aşağıdaki sorguyu çalıştırın.
SELECT TOP(10) LEFT(t.[text], 50) AS [ShortQueryText], qs.execution_count AS [ExecutionCount], qs.total_logical_reads AS [TotalLogicalReads], qs.total_logical_reads/qs.execution_count AS [AvgLogicalReads], qs.total_worker_time AS [TotalWorkerTime], qs.total_worker_time/qs.execution_count AS [AvgWorkerTime], qs.total_elapsed_time AS [TotalElapsedTime], qs.total_elapsed_time/qs.execution_count AS [AvgElapsedTime], CASE WHEN CONVERT(nvarchar(max), qp.query_plan) LIKE N’%%’ THEN 1 ELSE 0 END AS [HasMissingIX], qs.creation_time AS [CreationTime] ,t.[text] AS [CompleteQueryText], qp.query_plan AS [Query Plan] FROM sys.dm_exec_query_stats AS qs WITH (NOLOCK) CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS t CROSS APPLY sys.dm_exec_query_plan(plan_handle) AS qp WHERE t.dbid = DB_ID() ORDER BY [ExecutionCount] DESC OPTION (RECOMPILE)

Ortalama Değişken Zamana Göre Top SPs

Bu, sorgunun bazen hızlı bazen yavaş olduğunu gösterir. Genellikle bu, kötü sorgu planının önbelleğe alındığı ve SP yeniden çalıştırıldığında kötü plan kullandığı anlamına gelir. Bunu ayarlamak kolay olabilir. Ortalama değişken zamana göre ilk 10 Stored procedure almak için aşağıdaki sorguyu çalıştırınız:
SELECT TOP(10) p.name AS [SPName], qs.min_elapsed_time, qs.total_elapsed_time/qs.execution_count AS [AvgElapsedTime], qs.max_elapsed_time, qs.last_elapsed_time, qs.total_elapsed_time, qs.execution_count, ISNULL(qs.execution_count/DATEDIFF(Minute, qs.cached_time, GETDATE()), 0) AS [Calls/Minute], qs.total_worker_time/qs.execution_count AS [AvgWorkerTime], qs.total_worker_time AS [TotalWorkerTime], CASE WHEN CONVERT(nvarchar(max), qp.query_plan) LIKE N’%%’ THEN 1 ELSE 0 END AS [HasMissingIX], FORMAT(qs.last_execution_time, ‘yyyy-MM-dd HH:mm:ss’, ‘en-US’) AS [LastExecutionTime], FORMAT(qs.cached_time, ‘yyyy-MM-dd HH:mm:ss’, ‘en-US’) AS [PlanCachedTime] ,qp.query_plan AS [QueryPlan] FROM sys.procedures AS p WITH (NOLOCK) INNER JOIN sys.dm_exec_procedure_stats AS qs WITH (NOLOCK) ON p.[object_id] = qs.[object_id] CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) AS qp WHERE qs.database_id = DB_ID() AND DATEDIFF(Minute, qs.cached_time, GETDATE()) > 0 ORDER BY [AvgElapsedTime] DESC OPTION (RECOMPILE)

Top SPs by CPU usage

Toplam Çalışma Süresi–, SQL Engine yeniden başlatıldıktan sonra bu store procedure tarafından tüketilen toplam CPU maliyetidir. CPU’ya göre en pahalı 10 stored procedures almak için aşağıdaki sorguyu çalıştırın.
SELECT TOP(10) p.name AS [SPName], qs.total_worker_time AS [TotalWorkerTime], qs.total_worker_time/qs.execution_count AS [AvgWorkerTime], qs.execution_count AS [ExecutionCount], ISNULL(qs.execution_count/DATEDIFF(Minute, qs.cached_time, GETDATE()), 0) AS [Calls/Minute], qs.total_elapsed_time, qs.total_elapsed_time/qs.execution_count AS [AvgElapsedTime], CASE WHEN CONVERT(nvarchar(max), qp.query_plan) LIKE N’%%’ THEN 1 ELSE 0 END AS [HasMissingIX], FORMAT(qs.last_execution_time, ‘yyyy-MM-dd HH:mm:ss’, ‘en-US’) AS [LastExecutionTime], FORMAT(qs.cached_time, ‘yyyy-MM-dd HH:mm:ss’, ‘en-US’) AS [PlanCachedTime] ,qp.query_plan AS [Query Plan] FROM sys.procedures AS p WITH (NOLOCK) INNER JOIN sys.dm_exec_procedure_stats AS qs WITH (NOLOCK) ON p.[object_id] = qs.[object_id] CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) AS qp WHERE qs.database_id = DB_ID() AND DATEDIFF(Minute, qs.cached_time, GETDATE()) > 0 ORDER BY qs.total_worker_time DESC OPTION (RECOMPILE)  

Top SPs By Execution Count

En çok yürütülen ilk 10 stored procedure ‘leri almak için aşağıdaki sorguyu çalıştırın.
SELECT TOP(10) p.name AS [SPName], qs.execution_count AS [ExecutionCount], ISNULL(qs.execution_count/DATEDIFF(Minute, qs.cached_time, GETDATE()), 0) AS [Calls/Minute], qs.total_elapsed_time/qs.execution_count AS [AvgElapsedTime], qs.total_worker_time/qs.execution_count AS [AvgWorkerTime], qs.total_logical_reads/qs.execution_count AS [AvgLogicalReads], CASE WHEN CONVERT(nvarchar(max), qp.query_plan) LIKE N’%%’ THEN 1 ELSE 0 END AS [HasMissingIX], FORMAT(qs.last_execution_time, ‘yyyy-MM-dd HH:mm:ss’, ‘en-US’) AS [LastExecutionTime], FORMAT(qs.cached_time, ‘yyyy-MM-dd HH:mm:ss’, ‘en-US’) AS [PlanCachedTime] ,qp.query_plan AS [QueryPlan] FROM sys.procedures AS p WITH (NOLOCK) INNER JOIN sys.dm_exec_procedure_stats AS qs WITH (NOLOCK) ON p.[object_id] = qs.[object_id] CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) AS qp WHERE qs.database_id = DB_ID() AND DATEDIFF(Minute, qs.cached_time, GETDATE()) > 0 ORDER BY [ExecutionCount] DESC OPTION (RECOMPILE)

Top SPs by I/O

Bu, en çok I/O’ya neden olan stored procedure’lerin hangileri olduğunu gösterir. Ortalama I/O’ya göre en pahalı 10 store procudere çağrısını almak için aşağıdaki sorguyu çalıştırın.
SELECT TOP(10) OBJECT_NAME(qt.objectid, dbid) AS [SPName], (qs.total_logical_reads + qs.total_logical_writes) /qs.execution_count AS [AvgIO], qs.execution_count AS [ExecutionCount], SUBSTRING(qt.[text],qs.statement_start_offset/2, (CASE WHEN qs.statement_end_offset = -1 THEN LEN(CONVERT(nvarchar(max), qt.[text])) * 2 ELSE qs.statement_end_offset END – qs.statement_start_offset)/2) AS [QueryText] FROM sys.dm_exec_query_stats AS qs WITH (NOLOCK) CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS qt WHERE qt.[dbid] = DB_ID() ORDER BY [AvgIO] DESC OPTION (RECOMPILE)  
 

Size ve Veritabanlarınıza Yardımcı Olmak İçin Bekliyoruz!

İletişime geçerek hemen destek alabilirsiniz.

İletişim
SQL DEADLOCK HER ZAMAN HER YERDE OLABİLİR. SİZİN ORTAMLARINIZDA OLMADIĞINA EMİN MİSİNİZ? SQL deadlock, bir veya daha fazla işlem arasında işlemi tamamlamak için birbirlerine bağımlı olan iki veya daha fazla kaynak arasında bir çekişme veya rekabet olduğunda ortaya çıkar. Bu tür bir çekişme, işlemler arasında yalnızca kilitlenme ve serbest bırakma işlemleri ile çözülebilir. Bu makalede, SQL deadlock’ların ne olduğunu, neden oluştuğunu ve nasıl önlenebileceğini tartışacağız. SQL Deadlock Nedir? SQL deadlock, iki veya daha fazla işlem arasında bir kaynak üzerinde rekabetin olduğu bir durumdur. Örneğin, bir işlem bir kaynağı kullanmakta ve diğer işlem de aynı kaynağı kullanmak için beklemekteyse, deadlock oluşabilir. Bu durumda, her iki işlem de birbirlerinin tamamlanmasını bekliyor olacaktır ve her ikisi de diğerini engellemekte olacaktır. Bu şekilde, her iki işlem de birbirlerinin tamamlanmasını beklemek zorunda kalacaktır ve bu da bir çıkmaza neden olur. SQL Deadlock Nedenleri SQL deadlock, bir dizi farklı nedenle ortaya çıkabilir. En yaygın nedenler şunlardır: İki veya daha fazla işlem, aynı kaynağı kullanmak için rekabet eder. İki veya daha fazla işlem, aynı kaynağa farklı sıra numaraları ile erişmek için bekler. İki veya daha fazla işlem, aynı kaynağa erişirken farklı kilitleme modları kullanır. İki veya daha fazla işlem, farklı sıra numaralarıyla birden fazla kaynağı kullanmak için rekabet eder. Bu nedenlerin herhangi biri, bir SQL deadlock’un oluşmasına neden olabilir. SQL Deadlock Nasıl Önlenir? SQL deadlock’ların önlenmesi için birkaç yol vardır. Bunlar şunları içerir:   SQL Deadlock Nasıl Çözülür? SQL deadlock’lar, işlem sürecinde birçok hata ve soruna neden olabilir. Bu nedenle, SQL deadlock’ların hızlı ve etkili bir şekilde çözülmesi önemlidir. SQL deadlock’ların çözümü için şu adımlar izlenebilir:
  1. Deadlock’ın tespit edilmesi: Deadlock’ın tespit edilmesi, çözüm sürecinin başlangıç ​​noktasıdır. Deadlock’ın tespiti için birçok yöntem kullanılabilir.
  2. Deadlock’ın nedeninin belirlenmesi: Deadlock’ın nedeninin belirlenmesi, doğru bir çözüm sürecinin başlatılması için önemlidir. Deadlock’ın nedeni belirlendikten sonra, çözüm süreci daha etkili bir şekilde planlanabilir.
  3. Deadlock’ın çözümü: Deadlock’ın çözümü, iki veya daha fazla işlem arasındaki çekişmenin sona erdirilmesini sağlar. Deadlock’ın çözümü için birkaç yöntem vardır, örneğin:
Sonuç SQL deadlock’lar, bir veya daha fazla işlem arasında kaynaklara eşzamanlı erişim çekişmesi nedeniyle oluşabilir. Bunlar, veritabanı sisteminin performansını azaltabilir ve ciddi sorunlara neden olabilir. SQL deadlock’ları önlemek için, kaynaklara erişimi düzenlemek, işlem sürelerini azaltmak ve işlem sırasını sınırlandırmak gibi yöntemler kullanılabilir. Deadlock’lar oluşursa, deadlock algılama ve çözümleme mekanizmaları kullanılabilir. Deadlock’ların çözümü, deadlock’un tespit edilmesi ve nedeninin belirlenmesiyle başlar. Daha sonra, işlemlerin yeniden başlatılması, işlemlerin önceliklerinin değiştirilmesi veya kaynakların serbest bırakılması gibi yöntemler kullanılarak deadlock çözülebilir. SQL deadlock’ları, veritabanı sistemleri üzerinde çalışan uygulama geliştiricileri ve yöneticileri tarafından dikkate alınmalıdır. Doğru önlemler alınarak SQL deadlock’larının önlenmesi, veritabanı sisteminin performansının artırılması ve hataların önlenmesi için önemlidir.

Size ve Veritabanlarınıza Yardımcı Olmak İçin Bekliyoruz!

İletişime geçerek hemen destek alabilirsiniz.

İletişim