SQL Server Error Log: Nerede Bulunur, Nasıl Okunur, Nelere Dikkat Edilmeli?

Bir şeyler ters gittiğinde deneyimli bir DBA’in ilk baktığı yer SQL Server error log’dur. Her şey yolunda görünürken ise en az kullanılan araçlardan biridir. Her başlangıcı, her başarısız login denemesini, motorun tespit ettiği her I/O sorununu ve her ciddi hatayı kaydeder. Çoğu zaman bunu kullanıcılar bir belirti fark etmeden saatler, hatta günler önce yapar.

Bu rehberde SQL Server error log’un nerede bulunduğunu, SSMS ve T-SQL ile nasıl okunup aranacağını, hangi mesajların hemen ilgilenilmesi gerektiğini, dosya boyutunun nasıl kontrol altında tutulacağını ve error log’u kesintiden sonra okunan bir dosya olmaktan çıkarıp bir erken uyarı sistemine nasıl dönüştüreceğinizi anlatıyoruz.

SQL Server Error Log Nedir?

SQL Server error log, Database Engine’in instance çalıştığı sürece yazdığı düz metin bir dosyadır. Adına rağmen yalnızca hataları içermez. Tipik bir error log’da şunlar yer alır:

• Başlangıç bilgileri: SQL Server sürümü ve edition’ı, build numarası, sunucu collation’ı, algılanan bellek ve CPU, aktif trace flag’ler ve kullanılan startup parametreleri.
• Veritabanı başlatma ve recovery: her veritabanının açılışı, crash recovery’nin ne kadar sürdüğü, kaç transaction’ın roll forward veya rollback edildiği.
• Kimlik doğrulama hataları: istemci IP adresi ve gerçek nedeni gösteren state koduyla birlikte başarısız login denemeleri (error 18456).
• Backup ve restore olayları: varsayılan olarak her başarılı backup ve restore ile her başarısız deneme.
• Microsoft’un her zaman error log’a yazıldığını belirttiği severity 19–24 arasındaki hatalar ve WITH LOG ile üretilen tüm mesajlar.
• Yavaş I/O, okuma tekrarları, bellek baskısı ve non-yielding scheduler gibi sağlık uyarıları.
• Always On availability group rol değişiklikleri ve mirroring durum değişiklikleri gibi yüksek erişilebilirlik olayları.

SQL Server Error Log Nerede Bulunur?

Varsayılan konum platforma ve instance’a göre değişir:

• Windows: <sürücü>:\Program Files\Microsoft SQL Server\MSSQL<sürüm>.<InstanceAdı>\MSSQL\Log\ERRORLOG (örneğin varsayılan bir SQL Server 2022 instance’ı için MSSQL16.MSSQLSERVER).
• Linux: /var/opt/mssql/log/ altındaki errorlog dosyası.

Güncel log dosyasının uzantısı yoktur. Eski loglar ERRORLOG.1 (en yeni arşiv), ERRORLOG.2 şeklinde devam eder. Kurulum sırasında yol değiştirilebildiği için çalışan bir instance’ta dosyayı bulmanın en güvenilir yolu SQL Server’a doğrudan sormaktır:

-- Güncel error log dosyasının tam yolu
SELECT SERVERPROPERTY('ErrorLogFileName') AS current_error_log;

-- Güncel log ve tüm arşivler, tarih ve boyutlarıyla
EXEC sys.sp_enumerrorlogs;

SQL Server açılmıyorsa

Servis başlamıyorsa sorgu çalıştıramazsınız. Ancak error log hata anına kadar yazılmaya devam eder ve nedeni bulmanın genellikle en hızlı yoludur. SQL Server Configuration Manager’da SQL Server servisinin özelliklerini açın ve Startup Parameters sekmesindeki -e parametresine bakın: bu, error log’un tam yoludur. Dosyayı herhangi bir metin editöründe açıp sondan başa doğru okuyun. Başlangıcı engelleyen tipik nedenler şunlardır: eksik veya kilitli bir master ya da tempdb dosyası, devreye girmeyen bir disk veya bir veri klasörüne yetkisi olmayan servis hesabı. Windows Application event log da aynı SQL Server mesajlarını içerir ve ikinci bir kaynak olarak işe yarar.

SQL Server Error Log Nasıl Okunur?

Yöntem 1: SSMS Log File Viewer

SQL Server Management Studio’da Object Explorer’dan instance’ı genişletin ve Management → SQL Server Logs yolunu izleyin. Log File Viewer’ı açmak için Current‘a veya herhangi bir arşive çift tıklayın. Buradan birden fazla logu (SQL Server Agent ve Windows logları dahil) aynı anda seçip tek bir zaman çizelgesinde görebilir, Filter ile tarih aralığına, kaynağa veya mesaj metnine göre daraltabilirsiniz. Hızlı bir bakış için pratiktir; ancak çok büyük log dosyalarında yavaşlar. Bu da log boyutunu kontrol altında tutmak için bir neden daha (aşağıya bakın).

Yöntem 2: T-SQL ile sp_readerrorlog

Tekrarlanabilir aramalar ve scriptler için dokümante edilmiş sistem prosedürü sp_readerrorlog‘u kullanın. En fazla dört parametre alır:

• @p1: okunacak log. 0 güncel log, 1 ERRORLOG.1 ve bu şekilde devam eder.
• @p2: ürün. SQL Server error log için 1 (veya NULL), SQL Server Agent logu için 2.
• @p3: aranacak metin.
• @p4: ilk aramanın sonuçlarını daha da daraltan ikinci bir metin.

-- Güncel SQL Server error log'u oku
EXEC sys.sp_readerrorlog 0, 1;

-- Güncel logdaki başarısız login denemeleri
EXEC sys.sp_readerrorlog 0, 1, N'Login failed';

-- Bir önceki logda hem "Error" hem "Severity" içeren satırlar
EXEC sys.sp_readerrorlog 1, 1, N'Error', N'Severity';

-- Bir önceki SQL Server Agent logu
EXEC sys.sp_readerrorlog 1, 2;

Birçok scriptte xp_readerrorlog da görürsünüz. sp_readerrorlog‘un arkasındaki extended procedure’dür ve ek olarak başlangıç zamanı, bitiş zamanı ve sıralama yönü parametreleri alır. Microsoft tarafından resmi olarak dokümante edilmemiştir. Anlık sorun giderme için uygundur, ancak gelecek sürümlerde de çalışmasını beklediğiniz production araçlarında kullanmamak daha doğrudur.

Tüm arşiv loglarında tek seferde arama

sp_readerrorlog her seferinde tek bir dosya okur. Son restarttan önce başlamış olabilecek bir olayı incelerken aşağıdaki script mevcut tüm SQL Server error loglarını bir tablo değişkenine okur ve son yedi günün sorun gibi görünen kayıtlarını döndürür:

DECLARE @logs TABLE (ArchiveNo int, LogDate datetime, LogSizeBytes bigint);
DECLARE @entries TABLE (LogDate datetime, ProcessInfo nvarchar(100), LogText nvarchar(max));
DECLARE @i int = 0, @max int;

INSERT INTO @logs EXEC sys.sp_enumerrorlogs;
SELECT @max = MAX(ArchiveNo) FROM @logs;

WHILE @i <= @max
BEGIN
    INSERT INTO @entries EXEC sys.sp_readerrorlog @i, 1;
    SET @i += 1;
END;

SELECT LogDate, ProcessInfo, LogText
FROM @entries
WHERE LogDate >= DATEADD(DAY, -7, SYSDATETIME())
  AND (   LogText LIKE N'%Error:%'
       OR LogText LIKE N'%failed%'
       OR LogText LIKE N'%longer than 15 seconds%'
       OR LogText LIKE N'%paged out%'
       OR LogText LIKE N'%Non-yielding%')
ORDER BY LogDate DESC;

SQL Server bir hatayı genellikle art arda iki satır olarak yazar: biri Error: <numara>, Severity: <n>, State: <n> bilgisini, diğeri asıl mesajı içerir. Bir satır eşleştiğinde, tam resmi görmek için aynı zaman damgasına ve SPID’e sahip kayıtlara da bakın.

Bir Error Log Kaydı Nasıl Yorumlanır?

Her satırın üç bölümü vardır: zaman damgası, kaynak (Server, Logon, Backup veya mesajı üreten oturum için spidNN) ve mesaj. Hata mesajlarında dikkatle okunması gereken üç sayı bulunur:

• Error numarası: sorunu tanımlar. Her numaranın Microsoft Learn’de kendi sayfası vardır (MSSQLSERVER_<numara> şeklinde aratabilirsiniz).
• Severity: sorunun ne kadar ciddi olduğu (aşağıdaki tabloya bakın).
• State: hatanın kodun neresinde üretildiği. Çoğu hata için bu bilgi yalnızca Microsoft Support’u ilgilendirir. Ancak login hatası 18456 gibi bazılarında mesajın en faydalı kısmı state’tir.

Hemen İlgilenilmesi Gereken Error Log Mesajları

Yoğun bir instance günde binlerce satır yazar ve bunların çoğu zararsızdır. Bir SQL Server error log’u incelerken ilk aradığımız mesajlar aşağıdakilerdir, çünkü her biri ya bir kesintinin kendisidir ya da genellikle bir kesintiden önce görülür:

Login hatalarını çözümlemek (error 18456)

SQL Server, saldırganlara ipucu vermemek için istemciye yalnızca login’in başarısız olduğunu söyler. Asıl neden error log’da state olarak yer alır, örneğin Error: 18456, Severity: 14, State: 8. En sık karşılaşacağınız state’ler şunlardır:

• State 2 veya 5: login mevcut değil. Çoğunlukla migration sonrası yanlış sunucuya bağlanan bir uygulama.
• State 7: login devre dışı ve parola yanlış.
• State 8: parola yanlış.
• State 11 veya 12: login geçerli ama sunucu erişimi başarısız. Genellikle yalnızca bir grup veya UAC üzerinden erişimi olan bir Windows kullanıcısı.
• State 18: parolanın değiştirilmesi gerekiyor.
• State 38 veya 46: bağlantı cümlesinde istenen veritabanı açılamıyor; adı yanlış yazılmış, offline veya recovery sürecinde.
• State 58: yalnızca Windows authentication’a ayarlı bir sunucuda SQL authentication denendi.

SQL Server varsayılan olarak yalnızca başarısız login denemelerini loglar. Bunu Server Properties → Security → Login auditing altından değiştirebilirsiniz (değişiklik servis yeniden başlatıldıktan sonra geçerli olur). Yoğun bir sunucuda başarılı login’leri de loglamak nadiren iyi bir fikirdir, çünkü error log’u doldurur. Kimin bağlandığının denetim kaydına ihtiyacınız varsa SQL Server Audit daha uygun bir araçtır.

Error Log Neleri Kaydetmez?

Eski makalelerin birçoğu error log’un yavaş sorguları, deadlock’ları veya şema değişikliklerini kaydettiğini söyler. Varsayılan ayarlarda bunları kaydetmez ve bir olay sırasında onları orada aramak değerli zaman kaybettirir:

• Yavaş sorgular loglanmaz. Query Store veya Extended Events kullanın.
• Deadlock’lar varsayılan olarak loglanmaz. Trace flag 1222 deadlock ayrıntılarını error log’a yazar, ancak Microsoft yoğun iş yükü olan sistemlerde kullanılmamasını önerir. Yerleşik system_health Extended Events oturumu deadlock grafiklerini zaten yakalar ve hiçbir şeyi değiştirmeden okunabilir.
• Nesne oluşturma, değiştirme ve silme işlemleri loglanmaz. Bunları default trace veya SQL Server Audit kaydeder.
• Başarılı login’ler, yukarıda anlatılan login auditing ayarını değiştirmediğiniz sürece loglanmaz.

Error Log Boyutunu ve Saklama Süresini Yönetmek

SQL Server, servis her başladığında yeni bir error log açar. Güncel dosya ERRORLOG.1 olur, önceki .1 .2 olur ve bu şekilde devam eder. Varsayılan olarak SQL Server güncel logla birlikte altı arşiv saklar; yeni bir log oluştuğunda en eskisi silinir.

Bu varsayılan ayar pratikte birbirinin tersi iki soruna yol açar:

• Aşırı büyüyen loglar: aylarca restart edilmeyen bir sunucuda güncel log yüzlerce megabayta, hatta birkaç gigabayta ulaşabilir. SSMS’in onu açması dakikalar sürer, hem de tam acelesi olduğunuz anda.
• Kaybolan geçmiş: bir olay veya patch sırasında sunucu art arda birkaç kez yeniden başlatılırsa, altı restart asıl nedeni içeren logu silmeye yeter.

Çözüm, logu düzenli aralıklarla döndürmek (cycle) ve daha fazla arşiv saklamaktır.

Restart etmeden yeni error log başlatmak

sp_cycle_errorlog, güncel logu kapatıp yenisini başlatır. Etkisi bir restart ile aynıdır, ancak hiçbir kesinti yaratmaz. Haftalık (çok yoğun sunucularda günlük) bir SQL Server Agent job’ı olarak zamanlayın. Agent logunun da kendi karşılığı vardır:

-- Yeni bir SQL Server error log başlat
EXEC sys.sp_cycle_errorlog;

-- Yeni bir SQL Server Agent logu başlat (SQLAGENT.OUT)
EXEC msdb.dbo.sp_cycle_agent_errorlog;

Haftalık döngüyü kurmak için iki prosedürü her pazar gece yarısı çalıştıran küçük bir SQL Server Agent job’ı oluşturun. Zamanlamayı bakım pencerenize göre değiştirin:

USE msdb;
GO
-- Weekly job: cycle the SQL Server and SQL Server Agent logs every Sunday at 00:00
EXEC dbo.sp_add_job        @job_name = N'DBA - Cycle error logs';
EXEC dbo.sp_add_jobstep    @job_name = N'DBA - Cycle error logs',
                           @step_name = N'Cycle logs',
                           @subsystem = N'TSQL',
                           @database_name = N'master',
                           @command = N'EXEC sys.sp_cycle_errorlog; EXEC msdb.dbo.sp_cycle_agent_errorlog;';
EXEC dbo.sp_add_schedule   @schedule_name = N'Weekly - Sunday 00:00',
                           @freq_type = 8,              -- weekly
                           @freq_interval = 1,          -- Sunday
                           @freq_recurrence_factor = 1, -- every week
                           @active_start_time = 0;      -- 00:00:00
EXEC dbo.sp_attach_schedule @job_name = N'DBA - Cycle error logs',
                            @schedule_name = N'Weekly - Sunday 00:00';
EXEC dbo.sp_add_jobserver  @job_name = N'DBA - Cycle error logs',
                           @server_name = N'(local)';

Daha fazla arşiv saklamak ve dosya boyutunu sınırlamak

SSMS’te Management → SQL Server Logs üzerine sağ tıklayıp Configure‘ı seçin. Limit the number of the error log files before they are recycled seçeneğini işaretleyin ve daha yüksek bir maksimum değer girin (en fazla 99). Güncel SSMS sürümleri dosya başına KB cinsinden maksimum boyut belirlemeye de izin verir; 0 sınırsız demektir. Haftalık döndürme ile 30 arşiv, altı aydan fazla geçmiş sağlar. Aynı ayarlar script ile de yapılabilir, bu da çok sayıda instance’ı standartlaştırırken işe yarar:

-- 30 arşiv error log sakla
EXEC master.dbo.xp_instance_regwrite
     N'HKEY_LOCAL_MACHINE',
     N'Software\Microsoft\MSSQLServer\MSSQLServer',
     N'NumErrorLogs', REG_DWORD, 30;

-- İsteğe bağlı: güncel log ~50 MB'a ulaştığında yeni log başlat
EXEC master.dbo.xp_instance_regwrite
     N'HKEY_LOCAL_MACHINE',
     N'Software\Microsoft\MSSQLServer\MSSQLServer',
     N'ErrorLogSizeInKb', REG_DWORD, 51200;

Gürültüyü azaltmak

Varsayılan olarak her başarılı backup error log’a bir satır yazar. Onlarca veritabanında 5–15 dakikada bir alınan log backup’larıyla bu satırlar logun büyük kısmını oluşturabilir ve önemli mesajları gömebilir. Trace flag 3226 bu başarı mesajlarını bastırır; başarısız backup’lar yine loglanır. Restartlardan sonra da geçerli olması için SQL Server Configuration Manager’da startup parametresi olarak (-T3226) ekleyin. Önce hiçbir script’in veya izleme aracının bu başarı satırlarına dayanmadığından emin olun. Backup geçmişinin msdb‘de kaydedilmeye devam ettiğini de unutmayın.

Log Okumaktan Uyarı Almaya

Error log’u her sabah incelemek iyi bir alışkanlıktır, ancak kritik hatalar birinin onları okumasını beklememelidir. SQL Server Agent alert’leri, ciddi bir hata loglandığı anda sizi bilgilendirebilir. Makul bir başlangıç, 17’den 25’e kadar her severity için bir alert ve ayrıca 823, 824 ve 825 hataları için özel alert’lerdir. 825 bilgilendirme mesajı olarak loglandığı için severity’ye dayalı bir alert onu hiçbir zaman yakalamaz. 823 ve 824 zaten severity 24 alert’ini tetikler, ancak ayrı bir alert bildirimin tam olarak ne olduğunu söylemesini sağlar.

-- Database Mail ve 'DBA Team' adlı bir operatörün tanımlı olduğu varsayılır
DECLARE @sev int = 17, @name sysname;
WHILE @sev <= 25
BEGIN
    SET @name = N'Severity ' + CAST(@sev AS nvarchar(2));
    EXEC msdb.dbo.sp_add_alert
         @name = @name, @severity = @sev,
         @delay_between_responses = 60, @include_event_description_in = 1;
    EXEC msdb.dbo.sp_add_notification
         @alert_name = @name, @operator_name = N'DBA Team', @notification_method = 1;
    SET @sev += 1;
END;

DECLARE @err int;
DECLARE err_cur CURSOR LOCAL FAST_FORWARD FOR SELECT v FROM (VALUES (823), (824), (825)) AS e(v);
OPEN err_cur;
FETCH NEXT FROM err_cur INTO @err;
WHILE @@FETCH_STATUS = 0
BEGIN
    SET @name = N'Error ' + CAST(@err AS nvarchar(5));
    EXEC msdb.dbo.sp_add_alert
         @name = @name, @message_id = @err, @severity = 0,
         @delay_between_responses = 60, @include_event_description_in = 1;
    EXEC msdb.dbo.sp_add_notification
         @alert_name = @name, @operator_name = N'DBA Team', @notification_method = 1;
    FETCH NEXT FROM err_cur INTO @err;
END;
CLOSE err_cur; DEALLOCATE err_cur;

@delay_between_responses = 60, aynı hatanın art arda tekrarlanmasının e-posta kutunuzu doldurmasını engeller. Alert’lerin hiçbir zaman sessizce kaybolmaması için bir fail-safe operatör de tanımlayın. Daha ayrıntılı bir anlatım için SQL Server uyarılarını kurmanın doğru yolu rehberimize göz atabilirsiniz.

Pratik Bir Error Log İnceleme Rutini

Alert’ler kritik olayları yakalar. Kısa ve düzenli bir inceleme ise alert’lerin kaçırdığı eğilimleri yakalar. Çoğu ortamda iyi çalışan bir rutin:

1. Günlük: son 24 saatte severity 17 ve üzeri hataları, I/O uyarılarını (825, 833), bellek uyarılarını (17890, 701) ve başarısız backup’ları (3041) tarayın.
2. Günlük: başarısız login’leri state’e ve istemci IP’sine göre sayın. Ani bir artış neredeyse her zaman ya yanlış connection string ile yapılmış bir deployment’a ya da parola deneyen birine işaret eder.
3. Her restart veya failover sonrasında: başlangıç bölümünü okuyun. Build numarasını, trace flag’leri, algılanan belleği ve tüm veritabanlarının recovery’yi tamamladığını doğrulayın.
4. Haftalık: error log’u ve Agent logunu döndürün; saklama süresinden eski arşivlerin silindiğini kontrol edin.
5. Aylık: tekrar eden desenlere bakın. Örneğin her gece aynı saatte görülen 833 uyarıları genellikle backup job’ları, antivirüs taramaları veya depolama snapshot’larıyla çakışır.

Bu rutin, daha kapsamlı bir SQL Server izleme düzeninin doğal bir parçasıdır ve bir SQL Server health check çalışmasında ilk kontrol ettiğimiz konulardan biridir.

Azure SQL Hakkında Bir Not

Azure SQL Managed Instance, error log’u SQL Server’a oldukça benzer şekilde sunar ve sp_readerrorlog orada da çalışır. Azure SQL Database (tekil veritabanları ve elastic pool’lar) ise bir instance error log’una erişim vermez. Orada aynı bilgiler Azure Monitor diagnostic ayarlarından, Extended Events’ten ve veritabanının kaynak ve audit loglarından elde edilir.

Sık Sorulan Sorular