SQL Server Production Kesintisi: İlk 30 Dakika İçin Sakin Bir Runbook

Telefon çalar: “Sistem çöktü.” Siparişler kaydedilmiyor, ERP ekranı donmuş ve veritabanı sunucusuna şimdiden beş kişi bağlanmış. Sonraki 30 dakikada olanlar, genellikle bunun 15 dakikalık bir olay mı yoksa dört saatlik bir kesinti mi olacağını belirler.

Yıllardır bu çağrılara yanıt veren bir ekip olarak şunu öğrendik: uzun kesintilerin çoğuna asıl sorun sebep olmaz. Sebep, ilk dakikalarda yapılanlardır: yanlış anda bir restart, yanlış session’a bir KILL ya da aynı anda beş farklı şeyi değiştiren beş kişi. Bu runbook, DBA ekibimizin izlediği ve SQL Server’ı production’da çalıştıran her ekibe önerdiğimiz sakin ve sıralı yaklaşımdır.

Yapılmaması Gerekenler: Dakikaları Saatlere Çeviren Panik Hamleleri

Sahada en sık gördüğümüz ve her biri bir kesintiyi gereğinden uzun hale getirmiş hatalar şunlar:

• Sunucuyu ya da SQL Server servisini hemen restart etmek. Uzun transaction’lar çalışıyorsa, restart sonrasında her veritabanı recovery’den geçmek ve onları geri almak (rollback) zorundadır; bitene kadar açılmaz. Accelerated Database Recovery yoksa recovery süresi kabaca en uzun aktif transaction’ın büyüklüğüyle orantılıdır. Yavaş olan sistem, tamamen kapalı bir sisteme dönüşür.
• İlgili ilgisiz SQL Server Agent job’larını durdurmak. Büyük bir veri yüklemesinin ya da indeks rebuild’in ortasındaki bir job’ı durdurmak onu yok etmez; yapılan iş kadar sürebilecek bir rollback başlatır ve bir veritabanını recovery’ye sokabilir.
• Activity Monitor’deki uzun süren transaction’ları kill etmek. Session ortadan kalkmaz; KILLED/ROLLBACK olarak görünür ve rollback bitene kadar lock’larını tutmaya devam eder. Yanlış session’ı kill etmek blocking’i azaltmak yerine artırabilir.
• Herkesin aynı anda müdahale etmesi. Biri sanallaştırma tarafında sanal makinenin kaynaklarını değiştirir, biri process kill eder, bir üçüncüsü DBCC FREEPROCCACHE çalıştırıp bütün sorguları yeniden derlenmeye zorlar, bir dördüncüsü MAXDOP’u değiştirir. Sonunda hangi değişikliğin ne yaptığını kimse bilmez ve bazıları durumu kötüleştirmiştir.
• Bütün bunlardan sonra bir de restart etmek. En kötü kombinasyon budur: kill’lerin ve durdurulan job’ların başlattığı rollback’ler artık crash recovery içinde tamamlanmak zorundadır ve herkes beklerken veritabanı uzun süre açılmaz.

0–5. Dakika: Durun, Organize Olun, Not Alın

1. Tek bir olay sorumlusu belirleyin. Sunucuda neyin değişeceğine tek kişi karar verir. Diğerleri inceleme yapabilir, ama sorumlunun haberi olmadan kimse bir şey değiştirmez.
2. Değişiklikleri dondurun. İlk teşhis yapılana kadar restart yok, kill yok, konfigürasyon değişikliği yok, sanal makine değişikliği yok.
3. Bir olay günlüğü başlatın. Zaman damgalı ortak bir doküman ya da sohbet kanalı: ne gözlemlendi, ne değiştirildi, kim yaptı. Yavaşlatıyor gibi görünür; saatler kazandırır.
4. “Ne değişti?” diye sorun. Son saatlerde ya da günlerde yapılan bir deployment, yeni bir rapor, bir patch, bir konfigürasyon değişikliği, bir depolama ya da ağ değişikliği çoğu zaman sebebe giden en kısa yoldur.
5. Belirtiyi net tanımlayın. Her şey mi kapalı, yoksa tek bir uygulama mı? Bağlanılabiliyor mu? Yavaşlık mı, blocking mi, hata mı? Her biri farklı bir sebebe işaret eder.

5–15. Dakika: Müdahale Etmeden Önce Teşhis Koyun

Ekibimiz bir olayı devraldığında ilk baktığı yerler kabaca bu sıradadır.

1. İzleme uyarıları ve error log

İzleme sisteminiz varsa, neyi ne zaman bildirdiğiyle başlayın. Ardından SQL Server error log’unu okuyun: 823, 824 ya da 825 hataları depolamaya işaret eder; 9002 bir transaction log’un dolduğunu gösterir; 17883 ve benzeri scheduler uyarıları CPU ya da worker sorunlarına işaret eder; recovery’deki bir veritabanı ilerlemesini de burada gösterir. SQL Server Error Log rehberimize ve SQL Server Alert’leri yazımıza bakabilirsiniz.

-- "error" içeren ya da recovery ilerlemesini gösteren son error log kayıtları
EXEC sys.sp_readerrorlog 0, 1, N'error';
EXEC sys.sp_readerrorlog 0, 1, N'Recovery of database';

2. Ne çalışıyor, kim kimi blokluyor?

Aktif istekleri, wait’leri ve blocking zincirini inceleyin. Birçok ekip bunun için ücretsiz topluluk prosedürü sp_WhoIsActive’i kullanır; ekibimiz ayrıca kendi geliştirdiği script’leri kullanır. Yerleşik DMV’ler her yerde çalışır:

SELECT r.session_id, r.blocking_session_id, r.status, r.command,
       r.wait_type, r.wait_time / 1000 AS wait_sec,
       r.total_elapsed_time / 1000 AS elapsed_sec,
       DB_NAME(r.database_id) AS database_name,
       s.login_name, s.host_name, s.program_name,
       t.text AS sql_text
FROM sys.dm_exec_requests AS r
JOIN sys.dm_exec_sessions AS s ON s.session_id = r.session_id
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) AS t
WHERE s.is_user_process = 1 AND r.session_id <> @@SPID
ORDER BY r.total_elapsed_time DESC;

Head blocker‘ı, yani diğerlerini bloklayan ama kendisi bloklanmayan session’ı bulun. Bu her zaman aktif bir sorgu değildir. Sık görülen bir durum, bir transaction açıp hiç kapatmayan bir uygulamadır; session açık bir transaction’la sleeping durumda bekler ve lock’ları tutar:

-- Hâlâ açık transaction'ı olan sleeping session'lar
SELECT s.session_id, s.login_name, s.host_name, s.program_name,
       s.open_transaction_count, s.last_request_end_time
FROM sys.dm_exec_sessions AS s
WHERE s.status = N'sleeping' AND s.open_transaction_count > 0
ORDER BY s.last_request_end_time;

3. Agent job’ları ve kaynak tüketimi

Şu anda hangi SQL Server Agent job’larının ne zamandan beri çalıştığını kontrol edin: bir bakım job’ı, büyük bir import ya da yanlış saate zamanlanmış bir rapor sık görülen sebeplerdendir. Ardından logical processor’lar genelinde CPU kullanımını, bellek baskısını ve tek bir sorgunun ya da session’ın her şeyi domine edip etmediğini kontrol edin.

4. Disk gecikmesi ve boş alan

Yavaş depolama her şeyi yavaşlatır, dolu bir disk ise her şeyi durdurur. İkisini de kontrol edin:

-- Veritabanı dosyalarının bulunduğu her volume'daki boş alan
SELECT DISTINCT vs.volume_mount_point,
       vs.total_bytes / 1073741824 AS total_gb,
       vs.available_bytes / 1073741824 AS free_gb
FROM sys.master_files AS f
CROSS APPLY sys.dm_os_volume_stats(f.database_id, f.file_id) AS vs;

-- Log neden yeniden kullanılamıyor? (LOG_BACKUP, ACTIVE_TRANSACTION, REPLICATION, AVAILABILITY_REPLICA ...)
SELECT name, log_reuse_wait_desc FROM sys.databases WHERE log_reuse_wait_desc <> N'NOTHING';

-- Başlangıçtan bu yana dosya başına ortalama I/O gecikmesi (diğerlerinden çok yüksek olanlara bakın)
SELECT DB_NAME(vfs.database_id) AS database_name, mf.physical_name,
       vfs.io_stall_read_ms / NULLIF(vfs.num_of_reads, 0) AS avg_read_ms,
       vfs.io_stall_write_ms / NULLIF(vfs.num_of_writes, 0) AS avg_write_ms
FROM sys.dm_io_virtual_file_stats(NULL, NULL) AS vfs
JOIN sys.master_files AS mf ON mf.database_id = vfs.database_id AND mf.file_id = vfs.file_id
ORDER BY avg_write_ms DESC;

15–30. Dakika: En Küçük Güvenli Müdahale, Sonra İletişim

Sebebi bulduğunuzda, en az riskli ve geri alınması en az iş çıkaracak müdahaleyi seçin:

• Blocking: yalnızca head blocker’ı kill edin; o da ancak ne yaptığını ve ne kadar iş yaptığını kontrol ettikten sonra. İki saattir satır güncelleyen bir session’ın rollback’i uzun sürer. Kill’den sonra tahmin etmek yerine rollback’i izleyin: KILL 87 WITH STATUSONLY; tamamlanma yüzdesini ve tahmini kalan süreyi gösterir.
• Dolu transaction log: sebebi log_reuse_wait_desc‘te bulun ve o sebebi giderin: log backup alın, açık transaction’ı çözün ya da takılan replikasyonu veya availability replica’yı düzeltin. Gerekirse başka bir volume’a log alanı ekleyin. Panikle log dosyalarını silmeyin ya da shrink etmeyin. SQL Server Transaction Log’unuz Çok mu Büyük? yazımıza bakabilirsiniz.
• Dolu veri diski: alan açın ya da ekleyin veya başka bir volume’a dosya ekleyin. Ardından autogrowth ayarını düzeltin ki dosyalar günün en yoğun anında küçük adımlarla büyümeye çalışmasın.
• Depolama ya da bozulma hataları: durun ve doğaçlama yerine bir kurtarma planı izleyin. SQL Server Veritabanı Bozulması yazımıza ve veritabanı açılmıyorsa RECOVERY PENDING veya SUSPECT yazımıza bakın.
• Recovery’deki bir veritabanı: bekleyin ve error log’daki ilerleme mesajlarını izleyin. Restart etmek onu hızlandırmaz.

Ardından iletişim kurun: ne oldu, ne yaptınız, kullanıcılar ne beklemeli ve bir sonraki güncellemeyi ne zaman vereceksiniz. Her 15–30 dakikada bir kısa ve dürüst bir mesaj, işi yapan kişileri yavaşlatan telefon yağmurunu önler.

Sahadan Bir Örnek: Ay Sonu Raporu

Büyük bir üretici firmada ay sonu raporu bütün sistemi kilitledi. Ekibimiz blocking zincirini buldu, raporun session’ını head blocker olarak tespit etti ve yalnızca o operasyonu durdurdu. Başka hiçbir şeye dokunulmadı. Sistem 12 dakikada normale döndü. Ardından raporun kendisini tune ettik: dört saat süren çalıştırma artık 19 dakikada bitiyor; böylece aynı kesinti bir sonraki ay geri gelmiyor.

En Sık Gördüğümüz Kök Nedenler

Çağrıldığımız kesintilerin çoğu kısa bir sebepler listesine dayanır. Neredeyse hepsi önlenebilir:

• Kalitesiz yazılmış üçüncü taraf uygulama sorguları ve bağlantıları ya da transaction’ları iyi yönetemeyen uygulamalar: açılıp hiç kapatılmayan connection’lar (connection pooling yönetilemiyor), açık transaction’la sleeping durumda bekleyen session’lar, deadlock’lara yol açan transaction yönetimi. SQL Deadlock yazımıza bakabilirsiniz.
• Gerçek bir backup politikasının olmaması; bunun sonucunda dolan transaction log’lar ya da devam edemeyen replikasyon. SQL Server Backup Planı Nasıl Kurulur? yazımıza bakabilirsiniz.
• Replikasyon ve Always On performansının izlenmemesi; bir replica ya da log reader geride kalırken log truncate edilemez.
• Depolamanın best practice’lere uygun kurulmamış olması ve yalnızca yük altında ortaya çıkan disk gecikmesi.
• Yoğun saatlerde diskte yer kalmaması; çoğu zaman yanlış autogrowth ayarlarıyla birlikte: veritabanı en yoğun anda büyümeye çalışır ve bütün session’lar bu işlemi bekler. Otomatik Büyüme Ayarları İçin En İyi Uygulamalar yazımıza bakabilirsiniz.
• Doğru indeks bakımının ve tutarlılık kontrollerinin yapılmaması; böylece bozulma gibi sorunlar kesintiden önce değil, kesinti sırasında fark edilir. SQL Server Bakım Planları yazımıza bakabilirsiniz.

Olaydan Sonra

1. Kök nedeni hafızanız tazeyken olay günlüğünü kullanarak yazıya dökün.
2. Belirtiyi değil sebebi düzeltin: sorguyu tune edin, uygulamanın bağlantı yönetimini düzeltin, sizi önceden uyaracak alert’i ekleyin, autogrowth ayarını düzeltin.
3. Veritabanlarını kontrol edin: herhangi bir depolama hatası ya da beklenmedik kapanma olduysa DBCC CHECKDB çalıştırın ve backup’ların yeniden çalıştığını doğrulayın.
4. Öğrendiklerinizle bu runbook’u güncelleyin.

Her Kesintide Bize Sorulan Sorular

Aryasoft’un yönetilen DBA müşterileri tam da bu anlar için taahhüt edilmiş müdahale sürelerine sahiptir: SLA müşterilerine mesai saatlerinde 30 dakika, mesai dışında 2 saat içinde; bakım-destek müşterilerine ise 2 saat ve 4 saat içinde yanıt verilir.