Azure SQL DMV’leri: PostgreSQL’den Gelenler İçin Tanı

PostgreSQL’den Azure SQL’e geçerken en çok hissedilen farklardan biri, veritabanının ne yaptığını anlamak için kullanılan araç setidir. Jerry Nixon’ın Azure SQL Devblogs’ta yayımlanan “PostgreSQL to SQL Field Notes” serisindeki bu bölüm, operasyonel istatistikleri iki motor açısından karşılaştırıyor. Karşılaştırmanın ekseni şu üç soru: PostgreSQL’de alışılmış istatistik görünümlerinin Azure SQL’deki karşılığı ne, hangi bilgi motora gömülü geliyor, hangi noktada ek yapılandırma gerekiyor.

Not: Microsoft dokümantasyonunda “SQL” ifadesi T-SQL (Transact-SQL) anlamına gelir. Kaynak makale Azure SQL Database ve Azure SQL Managed Instance’ı, karşılaştırma tabanı olarak da PostgreSQL 18’i esas alıyor.

PostgreSQL tarafında elinizde ne var?

Milisaniyelerle ölçülen bir sorgu aniden saniyelere çıktığında ilk bakılan yer genellikle pg_stat_activity oluyor:

SELECT *
FROM pg_stat_activity;

Görünüm aktif bağlantıları, oturum durumlarını, çalışan sorguları ve bekleme olaylarını verir. PostgreSQL’in kümülatif istatistik sistemi olgun ve geniştir, veritabanı, tablo, indeks ve G/Ç istatistiklerini yerel olarak toplar.

Yürütme planı tarafında da EXPLAIN güçlü bir araç:

EXPLAIN (ANALYZE, BUFFERS, WAL)
SELECT *
FROM orders
WHERE customer_id = 42;

Komut sorguyu çalıştırır, sonra operatör zamanlamasını, satır sayılarını, buffer etkinliğini ve WAL bilgisini içeren gerçek yürütme istatistiklerini raporlar.

PostgreSQL’de sınırların başladığı yer

Makale üç temel kısıtı öne çıkarıyor.

1) Çalışmakta olan sorguyu incelemek zordur. Beş dakikadır süren bir sorguyu pg_stat_activity içinde görürsünüz, ama zamanı hangi plan operatörünün tükettiğini, bir join’in beklenmedik şekilde milyonlarca satır işleyip işlemediğini ya da bir sıralamanın diske taşıp taşmadığını oradan göremezsiniz. EXPLAIN ANALYZE bu soruları yanıtlar, fakat normalde sorguyu enstrümantasyon altında yeniden çalıştırmayı gerektirir; başka bir oturumun süren yürütmesini incelemez. PostgreSQL’de vacuum, indeks oluşturma ve veri kopyalama gibi işlemler için ilerleme görünümleri ve pg_log_backend_memory_contexts(pid) fonksiyonu var, ancak bunlar rastgele çalışan bir SELECT için canlı operatör düzeyinde ilerleme sunmaz. Makaleye göre PostgreSQL 18 çekirdeğinde Azure SQL’in canlı yürütme tanılamasına genel bir karşılık bulunmuyor.

2) Tamamlanmış sorgu planları önceden hazırlık ister. pg_stat_statements uzantısı toplu yürütme sayıları, zamanlama ve buffer etkinliği verir, tamamlanmış sorguların gerçek yürütme planlarını ise saklamaz. auto_explain planları JSON dahil çeşitli biçimlerde günlüğe yazabilir, auto_explain.log_analyze ile gerçek çalışma zamanı istatistikleri de bu kayda girebilir; fakat bu da önceden yapılandırma gerektirir ve özellikle operatör bazlı zamanlamada ölçülebilir ek yük getirebilir. pg_stat_statements‘tan farklı olarak auto_explain tek tek oturumlara da yüklenebilir. Azure SQL’in “son gerçek plan” özelliği de önceden etkinleştirme ister; fark, planın önbellekte kaldığı sürece yerel bir fonksiyonla geri çağrılabilmesidir.

3) Kaynak tanılaması bileşenlere dağılmıştır. PostgreSQL anlık beklemeleri, bellek bağlamlarını, geçici dosya etkinliğini ve ayrıntılı G/Ç istatistiklerini açar. Geçmişe dönük bekleme örneklemesi için pg_wait_sampling, ek işletim sistemi kaynak istatistikleri için pg_stat_kcache, otomatik plan yakalama için auto_explain eklenebilir. CPU zamanlaması işletim sistemine bırakılır; kendi yönettiğiniz sunucuda bu bir avantaj, çünkü Azure SQL Database’de bulunmayan OS profilleyicileri ve izleme araçları kullanılabilir. Yönetilen PostgreSQL servisleri ise bazı host erişimlerini ve uzantıları kısıtlar.

Bir olay anında yönetici istatistik görünümlerini, uzantı verilerini, sunucu günlüklerini ve harici izleme çıktılarını elde ilişkilendirmek zorunda kalır. Gerekli enstrümantasyon önceden açılmamışsa kanıt hiç bulunmayabilir. Makale bunun PostgreSQL’e özgü olmadığını da vurguluyor: Azure SQL’in önbellekteki planları ve geçici istatistikleri de tahliye, önbellek sıfırlama veya servis işlemlerinden sonra kaybolabilir. Hiçbir motor, hiç toplamadığı bilgiyi yeniden üretemez. Ayrımı yaratan şey, hangi yeteneğin motorun içine gömülü geldiğidir.

Azure SQL’de DMV ve DMF yaklaşımı

Microsoft SQL, iç tanılamayı Dynamic Management Views ve Functions (kısaca DMV ve DMF) üzerinden açar. Yürütme, bellek yönetimi, beklemeler, kilitlenme, G/Ç ve diğer motor kaynakları bu yolla görünür hale gelir. PostgreSQL’in istatistik görünümleri de ilişkisel ve sorgulanabilir olduğundan ayrım burada değil. Ayrımı yaratan, motorun yerel olarak sunduğu yürütme ve kaynak yönetimi bilgisinin kapsamı: bellek izinleri (memory grants), birikmiş beklemeler, süren yürütme planları ve yapılandırılmış motor olayları.

Süren sorguyu canlı incelemek

SELECT
r.session_id,
r.status,
r.wait_type,
r.cpu_time,
r.total_elapsed_time,
q.query_plan
FROM sys.dm_exec_requests AS r
CROSS APPLY
sys.dm_exec_query_statistics_xml(r.session_id) AS q
WHERE r.session_id <> @@SPID;

sys.dm_exec_query_statistics_xml, operatör düzeyinde çalışma zamanı istatistikleri içeren uçuş halindeki bir plan döndürür. Operatörlerin kaç satır işlediğine ve zamanın nerede biriktiğine, sorguyu iptal etmeden veya iş yükünü yeniden üretmeden bakabilirsiniz. Bu, sorgu profillemenin etkin olmasına bağlı; Azure SQL dağıtımlarında varsayılan olarak açık ve yalnızca hala yürütülen istekler için geçerli. Bazı Azure SQL Database katmanlarında bu bilgiye erişmek yükseltilmiş izin gerektirebilir.

Tamamlanmış sorgunun gerçek planı

ALTER DATABASE SCOPED CONFIGURATION
SET LAST_QUERY_PLAN_STATS = ON;

SELECT TOP (10)
qs.execution_count,
qs.total_worker_time,
qs.total_elapsed_time,
p.query_plan
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY
sys.dm_exec_query_plan_stats(qs.plan_handle) AS p
ORDER BY qs.total_elapsed_time DESC;

Tahmini planlar optimize edicinin beklentisini, gerçek planlar gerçekte ne olduğunu gösterir. Gerçek planlar operatör satır sayılarını, yürütme zamanlamasını, bellek izni bilgisini ve taşma (spill) uyarılarını içerebilir. Sınırlar da net. Basit sorgularda yalnızca sadeleştirilmiş bir kök SELECT planı dönebilir, önbellekteki planlar eninde sonunda kaybolur, özelliği sonradan açmak da geçmiş yürütmeleri geri getirmez.

Birikmiş bekleme istatistikleri

Bir sorgu her zaman çok iş yaptığı için yavaş değildir; kilit, G/Ç, bellek veya başka bir kaynak beklediği için de yavaşlar. sys.dm_exec_requests aktif bir isteğin güncel beklemesini, sys.dm_os_waiting_tasks bekleyen görevleri gösterir.

SELECT
wait_type,
waiting_tasks_count,
wait_time_ms,
signal_wait_time_ms
FROM sys.dm_db_wait_stats
ORDER BY wait_time_ms DESC;

sys.dm_db_wait_stats hem Azure SQL Database hem Azure SQL Managed Instance’ta kullanılabilir; Managed Instance ayrıca örnek düzeyinde inceleme için sys.dm_os_wait_stats sunar. PostgreSQL’in wait_event alanı, inceleme anında bir backend’in neyi beklediğini bildirir, Azure SQL ise bunun üzerine bekleme türüne göre kümülatif sayı ve süreleri kaydeder. Sayaçlar kümülatif olduğundan anlamlı yorum genellikle zaman içindeki ölçümleri karşılaştırmayı gerektirir. Toplamlar genel örüntüleri ortaya çıkarır, belirli bir sorgunun şu anda neyi beklediğini söylemez; onun için aktif istek ve bekleyen görevlerden başlamak gerekir.

Sorgu belleğinin nereye gittiği

SELECT
session_id,
requested_memory_kb,
granted_memory_kb,
required_memory_kb,
used_memory_kb,
max_used_memory_kb,
wait_time_ms
FROM sys.dm_exec_query_memory_grants;

SQL motoru sıralama ve hash gibi işlemler için bellek izni kullanır. Bu DMV bir sorgunun ne kadar bellek istediğini, ne kadar aldığını, ne kadarını kullandığını ve ek izin bekleyip beklemediğini doğrudan gösterir; belirtileri yorumlayıp tahmin yürütmeniz gerekmez.

PostgreSQL tarafında work_mem sorgu başına bir bütçe değildir. Birden fazla sıralama ve hash ayrı ayrı bellek tüketebilir, hash işlemleri hash_mem_multiplier ile ek bellek kullanabilir, paralel yürütme talebi katlayabilir. Eşzamanlı üç sıralama, yapılandırılmış work_mem değerine ayrı ayrı yaklaşabilir. Taşma tanılaması da PostgreSQL’de eksik değil: EXPLAIN ANALYZE geçici disk kullanımını raporlar, pg_stat_statements geçici blok etkinliğini izler, log_temp_files geçici dosya tahsislerini kaydedebilir. Makaleye göre bellek izinleri mimari bir tercih, PostgreSQL’in unuttuğu bir özellik değil. Azure SQL’de sorgular izin için sıraya girebilir veya aşırı tahsis alabilir; avantaj, motorun bu kararlarının yerleşik DMV üzerinden görünür olması. Görünüm her taşmayı veya her tür bellek tüketimini tanılamaz, Azure SQL Database de kiracı izolasyonu için bazı bilgileri kısıtlar.

Extended Events ile olayları yakalamak

Bazen anlık görüntü yetmez, zaman içinde olup biteni kaydetmek gerekir. Azure SQL’in Extended Events altyapısı; sorgu yürütme, beklemeler, çekişme ve deadlock dahil motor içi olayları sonradan analiz edilebilecek ayrıntıda toplayan yerel ve hafif bir çerçeve. Azure SQL Database veritabanı kapsamlı oturumları kutudan çıktığı gibi destekler.

PostgreSQL deadlock’ları zaten tespit eder, günlükleri katılan süreçleri, çakışan kilitleri ve ifadeleri gösterebilir, JSON dahil yapılandırılmış günlüklemeyi de destekler. Ayrım deadlock tespitinde değil, Azure SQL’in genel amaçlı olay izleme çerçevesinde ve Azure izleme hizmetleriyle entegrasyonunda. Örneğin Azure SQL Database sqlserver.database_xml_deadlock_report olayını destekler; Deadlocks tanılama günlüğü kategorisi, XML deadlock grafiğini içeren deadlock_xml_s alanını barındırabilir. Yöneticiler tanılama ayarlarıyla bu veriyi Log Analytics, Azure Storage veya Event Hubs’a gönderebilir ya da hedefli bir Extended Events oturumu oluşturabilir.

Eksik indeks önerileri

SELECT TOP (10)
d.statement AS TableName,
d.equality_columns,
d.inequality_columns,
d.included_columns,
s.user_seeks,
s.user_scans,
s.avg_user_impact,
s.avg_total_user_cost
FROM sys.dm_db_missing_index_details AS d
INNER JOIN sys.dm_db_missing_index_groups AS g
ON d.index_handle = g.index_handle
INNER JOIN sys.dm_db_missing_index_group_stats AS s
ON g.index_group_handle = s.group_handle
WHERE d.database_id = DB_ID()
ORDER BY
s.avg_total_user_cost
* s.avg_user_impact
* (s.user_seeks + s.user_scans) DESC;

Azure SQL yürütme planları örtük dönüşümler, verimsiz bellek izinleri ve taşmalar hakkında uyarı verir. Optimize edici bunun ötesine de geçer, gerçek sorgu etkinliğine dayanarak hangi sütunların indeksleneceğini ve olası faydayı tahmin eden öneriler üretir. Yukarıdaki sorgu önerilen indeks sütunlarını, tahmini sorgu maliyeti iyileşmesini ve optimize edicinin bu fırsatı ne sıklıkla tespit ettiğini listeler.

PostgreSQL tarafında yerel görünümler tablo ve indeks etkinliğini raporlar, pg_qualstats predicate bilgisi toplar, HypoPG varsayımsal indeksleri değerlendirmeye yardımcı olur. Fark, Azure SQL’in önerilen indeks tanımlarını ve tahmini faydayı doğrudan yerel tanılama görünümlerinde üretmesi. Önemli uyarı: bunlar optimize edici tahminleridir, ölçülmüş performans kazanımları değil.

Geçiş yaparken ne akılda kalmalı?

Makale PostgreSQL’i tanılama konusunda zayıf bulmuyor, ayrımı dağılım ile gömülülük arasında kuruyor: geniş kapsamlı tanılama PostgreSQL’de bağımsız biçimde yapılandırılan birkaç bileşene dağılır, Azure SQL’de ise büyük ölçüde motorun içinde yer alır. Pratikte bu, Azure SQL’e geçtiğinizde canlı yürütme planı, bellek izni, bekleme birikimi ve indeks önerileri için yeni uzantı kurmak yerine DMV ve DMF’leri sorgulamayı öğrenmeniz demek. Buna karşılık LAST_QUERY_PLAN_STATS gibi bazı özelliklerin önceden açılması ve plan önbelleğinin kalıcı olmadığının bilinmesi gerekir.

Kaynaklar ve İleri Okuma

• devblogs.microsoft.com

• PostgreSQL to SQL Field Notes: Operational Statistics (Jerry Nixon, Azure SQL Devblogs)
• Azure SQL Devblogs ana sayfası
• System Dynamic Management Objects (DMV ve DMF genel bakış)
• sys.dm_exec_query_statistics_xml
• sys.dm_exec_query_plan_stats
• sys.dm_exec_query_memory_grants
• sys.dm_db_wait_stats (Azure SQL Database)
• sys.dm_db_missing_index_group_stats
• Azure SQL Database’de deadlock analizi ve önleme
• Azure SQL tanılama telemetrisi ve dışa aktarma yapılandırması
• Azure SQL Database ile ücretsiz başlangıç
• .NET ve PostgreSQL ile Azure’da Cache’i Ciddiye Almak

Aşkın KILIÇYazar

20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

İlgili Yazılar

GitHub Copilot CLI: Kurulum, Komutlar ve Güvenlik12 Nis 2026

GitHub Enterprise Server 3.22 Sürüm Adayı Yayınlandı12 Ağu 2026

Copilot Memory’de Yeni Kontrol Dalgası: Silme, Kapsam ve CLI28 May 2026

GPT-5.6 Sol, Terra, Luna Copilot'ta: Hangisi Sizin İçin?9 Tem 2026