SQL Server Alert’leri: Hangileri Açılmalı ve Doğru Nasıl Kurulur?

Bir SQL Server sorununu öğrenmenin en kötü yolu, bir kullanıcıdan duymaktır. Disk hataları, bozulma, dolan bir transaction log ya da arızalanan bir bellek modülü, genellikle kesintiye yol açmadan saatler hatta günler önce error log’da kendini belli eder. Ama gece 3’te kimse error log okumaz. SQL Server Agent alert’leri okur: bu mesajları oluştukları anda bir e-postaya ya da bildirime dönüştürür.

Bu rehberde alert’lerin nasıl çalıştığını, her production sunucuda hangilerinin olması gerektiğini, bunları oluşturan çalıştırmaya hazır bir script’i, sık atlanan ön koşulları ve alert sisteminin gerçekten çalıştığını nasıl test edeceğinizi anlatıyoruz.

SQL Server Alert’leri Nasıl Çalışır?

SQL Server birçok hatayı Windows uygulama günlüğüne (application log) yazar. SQL Server Agent bu günlüğü okur, her olayı tanımladığınız alert’lerle karşılaştırır ve biri eşleştiğinde alert’i tetikler: bir operator’e e-posta gönderir ve isteğe bağlı olarak bir job çalıştırır. Bir alert şunlara göre tanımlanabilir:

• Severity seviyesi: örneğin severity 23 olan her hata.
• Belirli bir hata numarası: örneğin 824 hatası.
• Bir performans koşulu: örneğin bir veritabanının log kullanımının %80’i aşması.
• Bir WMI olayı: daha özel senaryolar için.

Her Production Sunucuda Olması Gereken Alert’ler

Severity tabanlı alert’ler

Hata numarası tabanlı alert’ler

En önemli uyarıların bazılarının severity’si 19’un altındadır, bu yüzden severity alert’i onları yakalamaz. Bunları ayrıca ekleyin:

• 823: bir sayfa okunurken ya da yazılırken işletim sistemi bir I/O hatası bildirdi.
• 824: sayfa okundu ama içeriği yanlış (hatalı checksum, torn page). En sık görülen bozulma hatası.
• 825: bir okuma ancak tekrar denendikten sonra başarılı oldu; depolamanın arızalanmaya başladığının erken uyarısı.
• 832: değişmemesi gereken bir sayfa bellekte değiştirildi; genellikle bellek sorunlarına işaret eder.
• 855 / 856: donanım bellek bozulması tespit edildi (düzeltilemeyen / kurtarılan). Destekleyen donanım ve sürümlerde üretilir.

823, 824 ya da 825 tetiklendiğinde ne yapılması gerektiğini SQL Server Veritabanı Bozulması yazımızda anlattık.

İsteğe bağlı: Always On alert’leri

Availability group kullanıyorsanız 1480 (bir availability veritabanı rol değiştiriyor, yani failover oldu) ve 35264 / 35265 (bir replica’ya veri aktarımı durdu / devam etti) için de alert ekleyin. Bunların sizin sürümünüzde günlüğe yazıldığını aşağıdaki sorguyla kontrol edin.

Sık Atlanan Ön Koşullar

1. Database Mail yapılandırılmış ve çalışıyor olmalı. Önce Database Mail’den bir test e-postası gönderin.
2. SQL Server Agent’ta bir mail profili etkin olmalı. SSMS’te: SQL Server Agent → Properties → Alert System → Enable mail profile, ardından profili seçin. Sonrasında SQL Server Agent’ı yeniden başlatın. Bu adımın atlanması, alert’lerin “tetiklenip” e-postanın gelmemesinin en yaygın sebebidir.
3. Bir operator tanımlı olmalı; tercihen tek bir kişinin adresi yerine bir ekip posta kutusu ya da dağıtım listesi.
4. Fail-safe operator tanımlayın; böylece normal operator’e ulaşılamazsa bildirim yine bir yere gider. SQL Server Agent İçin Fail-Safe Operatör yazımıza bakabilirsiniz.

Script: Operator ve Alert’leri Oluşturun

Aşağıdaki script, eksikse operator’ü oluşturur; ardından yukarıda listelenen bütün alert’leri oluşturur ve her birine e-posta bildirimi ekler. Birden fazla kez çalıştırmak güvenlidir: mevcut alert’ler ve bildirimler atlanır. Önce operator adını ve e-posta adresini değiştirin.

USE [msdb];
GO
DECLARE @Operator sysname = N'DBA Team',
        @Email nvarchar(100) = N'[email protected]';

IF NOT EXISTS (SELECT 1 FROM dbo.sysoperators WHERE name = @Operator)
    EXEC dbo.sp_add_operator @name = @Operator, @enabled = 1, @email_address = @Email;

DECLARE @Alerts TABLE (alert_name sysname, severity int, message_id int);
INSERT @Alerts (alert_name, severity, message_id) VALUES
 (N'Severity 017 - Insufficient Resources',          17, 0),
 (N'Severity 018 - Nonfatal Internal Error',         18, 0),
 (N'Severity 019 - Fatal Error in Resource',         19, 0),
 (N'Severity 020 - Fatal Error in Current Process',  20, 0),
 (N'Severity 021 - Fatal Error in Database Process', 21, 0),
 (N'Severity 022 - Table Integrity Suspect',         22, 0),
 (N'Severity 023 - Database Integrity Suspect',      23, 0),
 (N'Severity 024 - Hardware Error',                  24, 0),
 (N'Severity 025 - Fatal Error',                     25, 0),
 (N'Error 823 - OS I/O Error',                        0, 823),
 (N'Error 824 - Logical Consistency I/O Error',       0, 824),
 (N'Error 825 - Read-Retry Required',                 0, 825),
 (N'Error 832 - Constant Page Has Changed',           0, 832),
 (N'Error 855 - Uncorrectable Memory Corruption',     0, 855),
 (N'Error 856 - Memory Corruption Recovered',         0, 856);

DECLARE @name sysname, @sev int, @msg int;
DECLARE c CURSOR LOCAL FAST_FORWARD FOR SELECT alert_name, severity, message_id FROM @Alerts;
OPEN c;
FETCH NEXT FROM c INTO @name, @sev, @msg;
WHILE @@FETCH_STATUS = 0
BEGIN
    IF NOT EXISTS (SELECT 1 FROM dbo.sysalerts WHERE name = @name)
        EXEC dbo.sp_add_alert @name = @name, @severity = @sev, @message_id = @msg,
             @enabled = 1, @delay_between_responses = 900,
             @include_event_description_in = 1;

    IF NOT EXISTS (SELECT 1 FROM dbo.sysalerts AS a
                   JOIN dbo.sysnotifications AS n ON n.alert_id = a.id
                   WHERE a.name = @name)
        EXEC dbo.sp_add_notification @alert_name = @name,
             @operator_name = @Operator, @notification_method = 1;  -- 1 = e-posta

    FETCH NEXT FROM c INTO @name, @sev, @msg;
END
CLOSE c; DEALLOCATE c;

@delay_between_responses = 900, aynı alert’in en fazla 15 dakikada bir e-posta göndermesini sağlar; böylece bir hata dalgası posta kutusunu doldurmaz. @include_event_description_in = 1 gerçek hata metnini e-postaya ekler; ne olduğunu öğrenmek için sunucuya bağlanma ihtiyacını azaltır.

Performans Koşulu Alert’leri: Sorunu Hatadan Önce Yakalayın

Hata alert’leri bir şeyin zaten ters gittiğini söyler. Performans koşulu alert’leri ise bundan önce uyarabilir. Faydalı bir örnek: bir veritabanının transaction log’u %80’den fazla dolduğunda, yani 9002 hatası bütün yazma işlemlerini durdurmadan çok önce alert verin:

-- Default instance: nesne adı SQLServer:Databases
-- Named instance:   MSSQL$InstanceAdi:Databases
EXEC msdb.dbo.sp_add_alert
     @name = N'SalesDB - Log Used Above 80 Percent',
     @performance_condition = N'SQLServer:Databases|Percent Log Used|SalesDB|>|80',
     @enabled = 1, @delay_between_responses = 1800;

EXEC msdb.dbo.sp_add_notification
     @alert_name = N'SalesDB - Log Used Above 80 Percent',
     @operator_name = N'DBA Team', @notification_method = 1;

Bu alert tetiklenirse log’un neden truncate edilemediğini bulun; SQL Server Transaction Log’unuz Çok mu Büyük? yazımıza bakabilirsiniz.

Alert Sisteminin Gerçekten Çalıştığını Test Edin

Hiç test edilmemiş bir alert kurulumu bir güvenlik ağı değil, bir varsayımdır. En basit test, günlüğe yazılan bir severity 19 hatası üretmektir; bunun için sysadmin yetkisi ve WITH LOG gerekir:

RAISERROR (N'Alert test - please ignore', 19, 1) WITH LOG;

Bir dakika içinde operator’ün “Severity 019” alert’i için bir e-posta alması gerekir. Gelmezse şu sırayla kontrol edin: Agent mail profili ayarı, Database Mail günlüğü (msdb.dbo.sysmail_event_log) ve SQL Server Agent error log’u. Ardından hangi alert’lerin ne sıklıkla tetiklendiğini inceleyin:

SELECT name, severity, message_id, enabled, occurrence_count,
       last_occurrence_date, last_occurrence_time, has_notification
FROM msdb.dbo.sysalerts
ORDER BY occurrence_count DESC;

-- Bir hata günlüğe yazılıyor mu (yani alert'e uygun mu)?
SELECT message_id, severity, is_event_logged
FROM sys.messages
WHERE language_id = 1033 AND message_id IN (823, 824, 825, 832, 855, 856, 1480, 9002, 35264, 35265);

Alert’ler İzlemenin Tamamı Değildir

Alert’ler olaylara tepki verir. Bazı sorunlar iş işten geçene kadar hiç hata üretmez; bunları ayrıca kapsayın:

• Başarısız job’lar: backup, CHECKDB ve bakım job’ları hata durumunda bir operator’e bildirim göndermeli. SQL Agent Bildirimlerini Kullanarak Job’larınızı Güvende Tutun yazımıza bakabilirsiniz.
• Eksik backup’lar ve bütünlük kontrolleri: son backup zamanlarını ve son başarılı CHECKDB’yi her gün kontrol edin. SQL Server Backup Planı Nasıl Kurulur? ve SQL Server’da DBCC CHECKDB yazılarımıza bakabilirsiniz.
• Disk alanı, blocking ve performans: bunlar yalnızca hata alert’leriyle değil, eşikler ve trendlerle izlenmelidir.
• Error log’un kendisi: düzenli olarak inceleyin; SQL Server Error Log rehberimize bakabilirsiniz.

Sık Sorulan Sorular