SQL Server Extended Events: Temel Oturumlar, Hedefler ve Analiz Rehberi

Bir performans sorunu ya da beklenmeyen bir hata yaşandığında en değerli bilgi, sorunun yaşandığı anda sunucuda neler olduğudur. Hangi sorgu ne kadar sürdü, hangi uygulama hata aldı, kim kimi blokladı? Sorun geçtikten sonra DMV’ler bu soruların çoğuna cevap veremez. Extended Events (XE), bu bilgiyi olay anında, düşük maliyetle ve seçici olarak toplamanızı sağlayan, SQL Server’ın yerleşik izleme altyapısıdır.

Bu rehberde Extended Events’in nasıl çalıştığını, oturum ayarlarının performansa etkisini, hangi hedefin hangi durumda kullanılması gerektiğini ve üretim ortamlarında en çok işimize yarayan oturumları hazır betiklerle ele alıyoruz.

Extended Events Nedir ve Neden Profiler Değil?

Extended Events, SQL Server 2008 ile gelen ve sonraki her sürümde genişletilen olay tabanlı izleme sistemidir. Veritabanı motorunun içindeki yüzlerce noktada tanımlı olayları (event) yakalar, bunlara ek bilgi ekler, koşullara göre filtreler ve belirlediğiniz bir hedefe yazar.

Microsoft, SQL Trace’i ve SQL Server Profiler’ı veritabanı motoru için kullanımdan kaldırılacak (deprecated) özellikler olarak işaretlemiştir ve yerine Extended Events’i önermektedir. Bunun iki pratik nedeni vardır. Birincisi, Profiler’daki olaylar SQL Server 2008 R2 düzeyinde kalmıştır; Always On, columnstore, Query Store ya da yeni bekleme türleriyle ilgili olaylar yalnızca Extended Events’te bulunur. İkincisi, Extended Events oturumları genellikle SQL Trace’e kıyasla çok daha az kaynak tüketir. Profiler’ı üretim sunucusuna uzaktan bağlayıp filtresiz iz toplamak ise hâlâ yaygın olan ve kendisi bir performans sorunu yaratabilen bir alışkanlıktır.

Temel Kavramlar

Bir Extended Events oturumu (session) beş yapı taşından oluşur:

Performans açısından en önemli ayrıntı, işlem sırasıdır. Bir olay tetiklendiğinde önce predicate değerlendirilir; koşulu sağlamayan olay, action’lar toplanmadan ve hedefe yazılmadan atılır. Bu nedenle iyi tasarlanmış bir oturumda filtreler mümkün olduğunca seçici olmalı, sql_text gibi maliyetli action’lar ise yalnızca gerçekten gereken olaylara eklenmelidir.

Önce Elinizdekine Bakın: system_health Oturumu

Her SQL Server kurulumunda varsayılan olarak çalışan system_health oturumu, birçok sorunun cevabını siz hiçbir şey yapılandırmadan önce kaydetmiş olur. Microsoft’un dokümantasyonuna göre bu oturum şunları toplar:

• Tespit edilen tüm deadlock’lar ve deadlock grafikleri.
• Severity değeri 20 ve üzerinde olan hatalar ile 701, 802, 8645 gibi bellekle ilgili hatalar.
• 30 saniyeden uzun süren lock beklemeleri ve 15 saniyeden uzun süren latch beklemeleri.
• Non-yielding scheduler sorunları, sp_server_diagnostics bileşen sonuçları, bağlantı ve güvenlik hataları.

Oturum hem ring_buffer hem de event_file hedefine yazar. Dosya hedefi varsayılan olarak 5 MB’lık 4 dosya ile sınırlıdır; Standard ve Enterprise sürümlerinde bu sınır 100 MB’lık 10 dosyadır. Microsoft bu oturumun durdurulmamasını, değiştirilmemesini ve silinmemesini önerir; yapılan değişikliklerin bir sonraki güncellemede geri alınabileceğini de belirtir.

Örneğin son deadlock’ları, ayrı bir oturum kurmadan system_health dosyalarından okuyabilirsiniz:

SELECT
    xf.timestamp_utc,
    CAST(xf.event_data AS xml).query('(event/data[@name="xml_report"]/value/deadlock)[1]') AS deadlock_grafigi
FROM sys.fn_xe_file_target_read_file(N'system_health*.xel', NULL, NULL, NULL) AS xf
WHERE xf.object_name = N'xml_deadlock_report'
ORDER BY xf.timestamp_utc DESC;

Sonuçtaki XML’i .xdl uzantısıyla kaydedip SSMS’te açtığınızda deadlock grafiğini görsel olarak inceleyebilirsiniz. Deadlock analizinin ayrıntılarını SQL Server deadlock rehberimizde ele aldık. Always On kullanan ortamlarda benzer şekilde varsayılan olarak gelen AlwaysOn_health oturumu da replika durum değişikliklerini ve failover olaylarını kaydeder.

Oturum Ayarları ve Performansa Etkisi

Bir oturumun sunucu üzerindeki etkisini, seçilen olaylar kadar oturum düzeyindeki ayarlar da belirler:

• MAX_MEMORY: Olayların hedefe gönderilmeden önce bekletildiği tamponların toplam boyutudur. Varsayılan değer 4 MB’dır ve çoğu oturum için yeterlidir.
• EVENT_RETENTION_MODE: Tamponlar dolduğunda ne olacağını belirler. Varsayılan ALLOW_SINGLE_EVENT_LOSS, tamponlar dolduğunda tek tek olay kaybına izin vererek performans etkisini en aza indirir. ALLOW_MULTIPLE_EVENT_LOSS çok yoğun oturumlar için uygundur.
• MAX_DISPATCH_LATENCY: Olayların bellekte en fazla ne kadar bekleyeceğidir. Varsayılan 30 saniyedir; canlı izleme sırasında olayların geç görünmesinin nedeni çoğu zaman bu ayardır.
• STARTUP_STATE: ON olduğunda oturum SQL Server her başladığında otomatik olarak açılır. Sürekli çalışması gereken oturumlar için bu ayarı mutlaka kullanın.
• TRACK_CAUSALITY: Aynı işe ait olayları ilişkilendiren bir kimlik ekler; örneğin bir batch ile içindeki statement’ları birlikte izlemeyi kolaylaştırır.
• MAX_DURATION: SQL Server 2025 ile gelen bu ayar, oturumun belirtilen süre sonunda kendiliğinden durmasını sağlar. Geçici tanı oturumlarının unutulup haftalarca çalışmasını önlemenin en temiz yoludur.

Hangi Hedef Ne Zaman Kullanılmalı?

Üretim Ortamları İçin Dört Temel Oturum

Aşağıdaki oturumlar, bir ortamı tanımak ve sorunları erken yakalamak için en fazla fayda sağlayan ve doğru filtrelendiğinde kalıcı olarak açık bırakılabilen yapılardır. Dosya yollarını ve eşik değerlerini kendi ortamınıza göre uyarlayın.

1. Uzun süren sorgular

Uygulamalardan gelen stored procedure çağrılarını (rpc_completed) ve ad hoc batch’leri (sql_batch_completed) 5 saniye eşiğiyle yakalar. Sistem oturumları dışarıda bırakılır:

CREATE EVENT SESSION [UzunSorgular] ON SERVER
ADD EVENT sqlserver.rpc_completed (
    ACTION (sqlserver.client_app_name, sqlserver.client_hostname,
            sqlserver.database_name, sqlserver.username, sqlserver.query_hash)
    WHERE (sqlserver.is_system = 0 AND duration >= 5000000)
),
ADD EVENT sqlserver.sql_batch_completed (
    ACTION (sqlserver.client_app_name, sqlserver.client_hostname,
            sqlserver.database_name, sqlserver.username, sqlserver.query_hash)
    WHERE (sqlserver.is_system = 0 AND duration >= 5000000)
)
ADD TARGET package0.event_file (
    SET filename = N'E:\XE\UzunSorgular.xel', max_file_size = 100, max_rollover_files = 5
)
WITH (MAX_MEMORY = 4 MB, EVENT_RETENTION_MODE = ALLOW_SINGLE_EVENT_LOSS,
      MAX_DISPATCH_LATENCY = 30 SECONDS, STARTUP_STATE = ON);
GO
ALTER EVENT SESSION [UzunSorgular] ON SERVER STATE = START;

query_hash action’ı, parametreleri farklı olsa da aynı yapıdaki sorguları gruplamanızı sağlar. Böylece tek seferlik bir yavaşlık ile gün içinde yüzlerce kez tekrarlanan bir sorunu birbirinden ayırabilirsiniz.

2. Hatalar ve zaman aşımları

Kullanıcıların “ara sıra hata alıyoruz” şikâyetlerinin büyük kısmı, uygulama loglarında genel bir mesajla görünen ama veritabanında belirli bir hata numarasına karşılık gelen sorunlardır. attention olayı ise istemcinin bir sorguyu iptal ettiği ya da zaman aşımına uğradığı durumları yakalar:

CREATE EVENT SESSION [HatalarZamanAsimlari] ON SERVER
ADD EVENT sqlserver.error_reported (
    ACTION (sqlserver.client_app_name, sqlserver.client_hostname,
            sqlserver.database_name, sqlserver.username, sqlserver.sql_text)
    WHERE (severity >= 16 AND sqlserver.is_system = 0)
),
ADD EVENT sqlserver.attention (
    ACTION (sqlserver.client_app_name, sqlserver.client_hostname,
            sqlserver.database_name, sqlserver.username, sqlserver.sql_text)
)
ADD TARGET package0.event_file (
    SET filename = N'E:\XE\HatalarZamanAsimlari.xel', max_file_size = 50, max_rollover_files = 5
)
WITH (STARTUP_STATE = ON);
GO
ALTER EVENT SESSION [HatalarZamanAsimlari] ON SERVER STATE = START;

3. Blocking

Blocking, deadlock’tan farklı olarak kendiliğinden çözülmez ve system_health yalnızca 30 saniyeyi aşan lock beklemelerini kaydeder. Daha erken ve daha ayrıntılı bilgi için önce blocked process threshold ayarını saniye cinsinden tanımlamanız gerekir. Bu değer varsayılan olarak kapalıdır, en az 5 saniye olabilir ve lock monitor yalnızca 5 saniyede bir çalıştığı için rapor anlık değil, en iyi çabayla üretilir:

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'blocked process threshold', 20;
RECONFIGURE;
GO
CREATE EVENT SESSION [Blocking] ON SERVER
ADD EVENT sqlserver.blocked_process_report
ADD TARGET package0.event_file (
    SET filename = N'E:\XE\Blocking.xel', max_file_size = 50, max_rollover_files = 5
)
WITH (STARTUP_STATE = ON);
GO
ALTER EVENT SESSION [Blocking] ON SERVER STATE = START;

Her rapor, bekleyen ve bekleten oturumun sorgu metnini, giriş bilgilerini ve beklenen kaynağı içerir. Bir blocking zincirinin kökündeki oturumu bulmak için raporları zaman sırasına göre incelemek genellikle yeterlidir.

4. Dağılım için histogram

Bazen her olayın ayrıntısına değil, dağılımına ihtiyaç duyarsınız. Örneğin sunucuda en sık hangi hataların oluştuğunu görmek için tüm hata olaylarını dosyaya yazmak yerine, hata numarasına göre sayan bir histogram yeterlidir. Bu oturum diskte neredeyse hiç yer kaplamaz:

CREATE EVENT SESSION [HataDagilimi] ON SERVER
ADD EVENT sqlserver.error_reported (
    WHERE (severity >= 11 AND sqlserver.is_system = 0)
)
ADD TARGET package0.histogram (
    SET filtering_event_name = N'sqlserver.error_reported',
        source = N'error_number',
        source_type = 0,
        slots = 1024
);
GO
ALTER EVENT SESSION [HataDagilimi] ON SERVER STATE = START;

Toplanan Veriyi Okumak

Kısa incelemeler için SSMS’te oturuma sağ tıklayıp Watch Live Data ya da dosya hedefinde View Target Data seçeneklerini kullanabilirsiniz. Daha kapsamlı analizler ve raporlar için ise sys.fn_xe_file_target_read_file fonksiyonu ile dosyaları T-SQL’den okuyup XML’i kolonlara ayırmak gerekir. SQL Server 2017 ve sonrasında fonksiyon UTC cinsinden bir timestamp_utc kolonu da döndürür; bu kolonla filtrelemek, XML’i tüm olaylar için ayrıştırmaktan çok daha hızlıdır:

WITH olaylar AS (
    SELECT xf.timestamp_utc, CAST(xf.event_data AS xml) AS ed
    FROM sys.fn_xe_file_target_read_file(N'E:\XE\UzunSorgular*.xel', NULL, NULL, NULL) AS xf
    WHERE xf.timestamp_utc >= DATEADD(HOUR, -24, SYSUTCDATETIME())
)
SELECT
    timestamp_utc,
    ed.value('(event/@name)[1]', 'sysname') AS olay,
    ed.value('(event/data[@name="duration"]/value)[1]', 'bigint') / 1000 AS sure_ms,
    ed.value('(event/data[@name="cpu_time"]/value)[1]', 'bigint') / 1000 AS cpu_ms,
    ed.value('(event/data[@name="logical_reads"]/value)[1]', 'bigint') AS logical_reads,
    ed.value('(event/action[@name="database_name"]/value)[1]', 'sysname') AS veritabani,
    ed.value('(event/action[@name="client_app_name"]/value)[1]', 'nvarchar(256)') AS uygulama,
    ed.value('(event/action[@name="username"]/value)[1]', 'nvarchar(256)') AS kullanici,
    COALESCE(ed.value('(event/data[@name="statement"]/value)[1]', 'nvarchar(max)'),
             ed.value('(event/data[@name="batch_text"]/value)[1]', 'nvarchar(max)')) AS sorgu
FROM olaylar
ORDER BY sure_ms DESC;

Bu fonksiyonu kullanmak için SQL Server 2019 ve öncesinde VIEW SERVER STATE, SQL Server 2022 ve sonrasında ise VIEW SERVER PERFORMANCE STATE yetkisi gerekir. Büyük dosyalarda XML ayrıştırması CPU tüketen bir işlemdir; yoğun saatlerde üretim sunucusu üzerinde çalıştırmak yerine dosyaları başka bir sunucuya kopyalayıp orada analiz etmenizi öneririz.

Çalışan Oturumları İzlemek

Extended Events ile ilgili yaygın bir sorun, bir problemi incelemek için açılıp sonra unutulan oturumlardır. Her kilit alımını ya da her sorgu planını toplayan bir oturum, unutulduğunda haftalarca sessizce kaynak tüketmeye devam eder. Sunucuda hangi oturumların açık olduğunu, ne kadar bellek kullandığını ve olay kaybı yaşayıp yaşamadığını şu sorguyla düzenli olarak kontrol edebilirsiniz:

SELECT
    s.name AS oturum,
    s.create_time AS baslangic,
    s.total_buffer_size / 1024 AS tampon_kb,
    s.dropped_event_count AS kaybolan_olay,
    s.dropped_buffer_count AS kaybolan_tampon,
    t.target_name AS hedef
FROM sys.dm_xe_sessions AS s
JOIN sys.dm_xe_session_targets AS t ON t.event_session_address = s.address
ORDER BY s.create_time;

dropped_event_count değerinin sürekli artması, oturumun ürettiği olay hacminin tamponlara sığmadığını gösterir. Bu durumda tampon boyutunu artırmak yerine filtreyi daraltmak genellikle daha doğru çözümdür.

Extended Events ve SQL Server Audit Arasındaki Fark

Her iki özellik de aynı altyapıyı kullanır, ancak amaçları farklıdır. Extended Events tanı ve performans analizi içindir; oturumlar esnek, çoğu zaman geçicidir ve olay kaybına izin verecek şekilde tasarlanır. Güvenlik ve uyum amacıyla “kim, ne zaman, neyi yaptı” sorusunun eksiksiz ve kanıt değeri taşıyan kaydı gerektiğinde ise SQL Server Audit kullanılmalıdır. Audit, kayıt yazılamadığında ne olacağını belirleyen hata davranışları ve kendi değişikliklerini kaydedebilme gibi bu amaca yönelik özellikler sunar.

Kontrol Listesi

• system_health oturumu çalışıyor ve değiştirilmemiş.
• Uzun süren sorgular, hatalar ve blocking için kalıcı oturumlar STARTUP_STATE = ON ile tanımlı.
• Tüm event_file hedeflerinde dosya boyutu ve sayısı sınırlı; dosyalar veri disklerinden ayrı bir klasörde ve erişim yetkileri kısıtlı.
• Süre filtreleri mikrosaniye cinsinden doğru yazılmış.
• NO_EVENT_LOSS ve çalışma planı toplayan olaylar üretimde kalıcı olarak kullanılmıyor.
• Çalışan oturumlar ve olay kayıpları düzenli olarak gözden geçiriliyor.