SQL Server Corruption - Error 823/824/825: DBCC CHECKDB ve Page Restore
Msg 823, 824 veya 825 I/O hataları ve suspect_pages bozulmalarında veritabanını kapatmadan hasar tespiti yapma, Enterprise Edition tekil Page Restore, index rebuild ve son çare REPAIR_ALLOW_DATA_LOSS prosedürü.
Operasyonel Güvenlik ve Risk Uyarısı
Bu runbook müdahale adımları içerir; birçok adım yazma etkilidir (KILL, terminate, DROP, RESIZE). Önce test ortamında deneyin, üretimde adımları sırayla ve doğrulayarak uygulayın.
1. Belirti / Symptom
- `Msg 823, Level 24, State 2: I/O error (cyclic redundancy check CRC) detected during read`.
- `Msg 824, Level 24, State 2: SQL Server detected a logical consistency-based I/O error: torn page`.
- `Msg 825, Level 10, State 2: A read of the file succeeded after retrying n times` (ölmekte olan disk uyarısı).
- `msdb..suspect_pages` tablosunda yeni bozuk sayfa kayıtları oluştu; sorgular Severity 24 ile düşüyor.
2. Etki / Impact
P1 Kritik Kesinti. Bozuk sayfalara denk gelen tablolar okunamaz veya güncellenemez; disk sürücüsündeki fiziksel hasar genişleyebilir; yanlış müdahale (örneğin kontrolsüz restart veya tam yedeğin üzerine yazma) veritabanını tamamen kurtarılamaz hale getirebilir.
3. Teşhis / Diagnosis
- Veritabanı offline olursa suspect moda geçebilir ve tekrar online olmayabilir.
- Mevcut sağlam full/diff/log yedeklerini koruyun; asla bozuk DB'nin yedeğini sağlam yedeklerin üzerine yazdırmayın.
-- 1. Error log'dan 823/824 kayıtlarını çekin
EXEC sp_readerrorlog 0, 1, '824';
EXEC sp_readerrorlog 0, 1, '823';
-- 2. suspect_pages tablosunu sorgulayın
SELECT database_id, file_id, page_id, event_type, error_count, last_update_date
FROM msdb.dbo.suspect_pages
WHERE database_id = DB_ID('MyDB');
-- 3. Detaylı tutarlılık taraması (Trace 3604 ile SSMS ekranına bas)
DBCC TRACEON(3604);
DBCC CHECKDB('MyDB') WITH NO_INFOMSGS, ALL_ERRORMSGS;| Hata Kodu | Hata Anlamı | Kök Neden & Müdahale |
|---|---|---|
| **823** | İşletim sistemi / Donanım I/O hatası | Fiziksel disk, SAN veya RAID controller arızası; storage ekibini hemen çağırın. |
| **824** | Mantıksal I/O tutarsızlığı (Bad Checksum / Torn Page) | 8 KB sayfa diske eksik yazılmış; Page Restore ile kurtarılabilir. |
| **825** | Okuma tekrar deneme sonrası başarılı (Read-retry) | Disk sürücüsü sessizce ölmek üzere; proaktif disk değişimi planlayın. |
4. Müdahale / Response
### Seçenek A: Tek / Birkaç Sayfa Bozuk — PAGE RESTORE (En Güvenli, Enterprise Edition)
Ön koşul: Sağlam Full Backup ve kesintisiz Transaction Log zinciri. Veritabanı online kalır!
-- 1. Bozuk sayfayı Full yedekten geri yükleyin (Örnek: File 1, Page 234)
RESTORE DATABASE MyDB PAGE='1:234'
FROM DISK = 'D:\Backups\MyDB_FULL.bak' WITH NORECOVERY;
-- 2. Ardışık differential ve log yedeklerini uygulayın
RESTORE LOG MyDB FROM DISK = 'D:\Backups\MyDB_LOG1.trn' WITH NORECOVERY;
RESTORE LOG MyDB FROM DISK = 'D:\Backups\MyDB_LOG2.trn' WITH NORECOVERY;
-- 3. Sayfayı online kurtarmaya alın
RESTORE DATABASE MyDB WITH RECOVERY;
-- 4. Tablo seviyesinde bütünlük denetimi yapın
DBCC CHECKTABLE('dbo.Orders') WITH NO_INFOMSGS;### Seçenek B: Bozulma Sadece Nonclustered Index'te İse
Eğer CHECKDB hatası sadece kümelenmemiş bir indekste ise (heap veya clustered index sağlamsa):
-- İndeksi sıfır veri kaybı ile online yeniden oluşturun
ALTER INDEX [IX_Orders_OrderDate] ON dbo.Orders REBUILD WITH (ONLINE = ON);
DBCC CHECKTABLE('dbo.Orders');### Seçenek C: Son Çare — REPAIR_ALLOW_DATA_LOSS (Veri Kaybı Riski!)
⚠️ **SADECE YEDEK YOKSA VE YÖNETİM VERİ KAYBI ONAYI VERDİYSE!**
-- Veritabanını tek kullanıcı moduna alın
ALTER DATABASE MyDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DBCC CHECKDB('MyDB', REPAIR_ALLOW_DATA_LOSS);
ALTER DATABASE MyDB SET MULTI_USER;
-- İşlem biter bitmez tüm veriyi temiz yeni bir veritabanına aktarın!5. Doğrulama / Verification
- `DBCC CHECKDB('MyDB') WITH NO_INFOMSGS;` komutunun 0 hata döndürdüğünü teyit edin.
- `msdb.dbo.suspect_pages` tablosundaki ilgili satırların temizlendiğini veya çözüldüğünü doğrulayın.
- En kritik 10 iş tablosunda satır sayısı ve sağlama toplamlarını (`CHECKSUM_AGG`) kontrol edin.
6. Geri Alma / Rollback
- `REPAIR_ALLOW_DATA_LOSS` geri alınamaz; komut çalıştırılmadan önce DB'nin MDF/LDF dosyalarının salt okunur kopyası alınmalıdır.
- **Kök Neden ve Önleme Standartları:**
- [ ] Storage ekibi SAN switch, disk bad sector ve RAID kontrolcü pilini inceledi mi?
- [ ] Tüm veritabanlarında `PAGE_VERIFY CHECKSUM` zorunlu kılındı mı?
SELECT name, page_verify_option_desc FROM sys.databases;
-- CHECKSUM değilse derhal güncelleyin:
ALTER DATABASE MyDB SET PAGE_VERIFY CHECKSUM;- [ ] Antivirüs yazılımının SQL veri ve log dizinlerini (`.mdf`, `.ldf`, `.ndf`) taraması engellendi mi (Exclusion List)?
- [ ] Haftalık SQL Agent `DBCC CHECKDB` bakım işi aktif ve alarmlı mı?
- **İletişim:** 823/824 görüldüğü anda `#dba-p1` kanalını ve Altyapı/Storage ekibini ayağa kaldırın.
Mühendislik Triadı: Doğrudan Teşhis Scriptleri
Bu runbook kriz müdahalesinde darboğazı tespit etmek için önerilen hazır SQL / Shell scriptleri:
SQL Server Son Yedek Durumu ve RPO Kontrolü
Her veritabanı için son full, diferansiyel ve log yedek zamanlarını gösterir. Yedeksiz kalmış veya log yedeği alınmayan veritabanlarını hızla bulur.
SQL Server Dosya Bazında Disk I/O Gecikmesi
Her veri ve log dosyası için okuma/yazma gecikmesini ms cinsinden hesaplar. Disk kaynaklı yavaşlamayı kanıtlamak için kullanılır.