Netsis Veritabanı Suspect ve Bozulma Hatası Çözümü

Kısa cevap: Netsis veritabanı “suspect” veya “recovery pending” durumuna düştüğünde ilk kural panikle onarım komutu çalıştırmamaktır. Önce veritabanı dosyalarının (MDF/LDF) kopyasını alın, DBCC CHECKDB ile hasarın kapsamını raporlayın ve sağlam bir yedek varsa en güvenli yol olan yedekten dönüşü değerlendirin. repair_allow_data_loss adı üstünde veri kaybettirebilir; son çare olarak ve mutlaka uzman eşliğinde kullanılmalıdır.

Sabah Netsis açılmıyor, SQL Server’da veritabanının yanında “Suspect” yazıyor ya da log’larda 823/824 I/O hataları mı görüyorsunuz? Bu, veritabanı bozulmasının (corruption) belirtisidir ve yanlış ilk müdahale veri kaybını büyütür. Bu rehber doğru sırayla ne yapılacağını anlatıyor.

Not: Deadlock, tempdb dolması ve transaction log şişmesi ayrı konulardır ve sitemizde kendi rehberleri vardır; bu yazı fiziksel bozulma ve suspect senaryosuna odaklanır.

Belirtiler

Veritabanı SQL Server’da Suspect veya Recovery Pending görünüyor
Windows/SQL loglarında error 823, 824 veya 825 (disk I/O tutarlılık hataları)
Belirli bir ekran veya rapor açılırken “logical consistency error” benzeri mesajlar
DBCC CHECKDB çıktısında allocation/consistency hataları

Bozulmanın Tipik Sebepleri

Disk arızası: En yaygın kök neden. 823/824/825 hataları çoğunlukla diskin veya disk denetleyicisinin sorunudur.
Elektrik kesintisi / donma anında kapatma: Yazma ortasında kesilen güç, dosya tutarlılığını bozabilir. UPS’siz sunucu ciddi risktir.
Diskin tamamen dolması: Log dosyası kontrolsüz büyüyüp diski doldurursa veritabanı yazamaz hale gelir; bu senaryonun önlenmesi için transaction log şişmesi rehberimize bakın.
Antivirüsün MDF/LDF dosyalarına müdahalesi: Veritabanı dosyaları antivirüs istisnasında değilse tarama sırasında kilitlenme/bozulma yaşanabilir.
Dosyaların dosya sisteminde kopyalanarak taşınması: SQL Server çalışırken MDF/LDF dosyasını kopyalayıp taşımak dosyayı tutarsız bırakabilir.

Adım Adım Doğru Müdahale

1. Durun ve Kopya Alın

Hiçbir onarım komutu çalıştırmadan önce SQL Server servisini kontrollü durdurup MDF ve LDF dosyalarının birebir kopyasını ayrı bir diske alın. Bu, her denemenin geri alınabilir olmasını sağlar.

2. Hasar Kapsamını Raporlayın

DBCC CHECKDB('NETSIS_DB') WITH NO_INFOMSGS, ALL_ERRORMSGS;

Çıktı, hangi tablolarda ne tür hata olduğunu ve önerilen en düşük onarım seviyesini gösterir. Bu rapor, “yedekten mi dönülür, onarılır mı” kararının temelidir.

3. Yedek Durumunu Netleştirin

En güvenli kurtarma yolu sağlam ve güncel bir yedekten dönüştür. Kontrol edin:

En son FULL yedek ne zaman alındı ve geri yüklenebilirliği test edildi mi?
Log yedekleri varsa bozulma anına yakın bir noktaya dönüş mümkün mü?

Geri yükleme adımları için yedek geri yükleme rehberimize, yedek stratejinizdeki boşluklar için yedekleme hataları ve çözümleri yazımıza bakın.

4. Onarım Yalnızca Son Çare

Yedek yoksa veya çok eskiyse onarım denemesi gündeme gelir:

Hasar yalnızca indekslerdeyse (repair_rebuild yeterliyse) veri kaybı olmadan onarım mümkündür.
repair_allow_data_loss ise bozuk sayfaları silerek tutarlılığı sağlar; hangi kayıtların gideceğini önceden bilemezsiniz. Muhasebe verisinde bu, fark edilmesi haftalar sürebilecek eksikler demektir.
EMERGENCY moda alma, tek kullanıcı moduna geçiş ve onarım sırası deneyim gerektirir; bu aşamada uzman desteği almak toplam kaybı küçültür.

5. Kök Nedeni Kapatmadan Sisteme Dönmeyin

Kurtarma sonrası aynı disk üzerinde çalışmaya devam etmek, aynı sorunu kısa sürede tekrar yaşamak demektir. Disk sağlığını (SMART/olay günlükleri) doğrulayın, gerekiyorsa diski değiştirin, UPS’i devreye alın.

İpucu: SQL Server Bozulmayı Sizden Önce Görür

SQL Server, okuma sırasında yakaladığı şüpheli sayfaları msdb veritabanındaki suspect_pages tablosuna kaydeder:

SELECT * FROM msdb.dbo.suspect_pages;

Bu tabloda kayıt görünmesi, tam çökmeden önce gelen erken uyarıdır. Haftalık kontrol listesine bu sorguyu ekleyin; tek bir sayfa hatası aşamasında yakalanan bozulma, veritabanı yedeği güncelken sayfa düzeyinde geri yükleme gibi çok daha az acılı seçeneklerle çözülebilir.

Bozulmayı Erken Yakalamak İçin

✅ Haftalık zamanlanmış DBCC CHECKDB çalıştırın ve çıktısını kontrol edin
✅ Yedeklerde CHECKSUM kullanın ve düzenli geri yükleme testi yapın
✅ MDF/LDF dosyalarını antivirüs istisnasına ekleyin
✅ Sunucuyu UPS’e bağlayın
✅ Disk doluluk ve SMART uyarıları için alarm kurun

Sıkça Sorulan Sorular

Veritabanı suspect görünüyor; yeniden başlatınca düzelir mi?

Bazen recovery pending durumu geçici bir kaynak sorunundan (dosya kilidi, disk erişimi) kaynaklanır ve servis yeniden başlatılınca düzelir. Ancak tekrar suspect’e düşüyorsa gerçek bozulma vardır; art arda yeniden başlatma denemek yerine dosya kopyası alıp CHECKDB raporuna geçin.

CHECKDB hata verdi ama Netsis çalışıyor; bekleyebilir miyiz?

Beklemek riski büyütür. Bozulma genellikle ilerleyicidir ve bir sonraki yazma işlemleri hasarı derinleştirebilir. Netsis’in çalışıyor olması hasarın henüz aktif kullanılan sayfalara ulaşmadığını gösterir; en kısa sürede yedek alıp kurtarma planı yapılmalıdır.

repair_allow_data_loss ne kadar veri kaybettirir?

Önceden bilinemez; bozuk sayfa sayısına ve hangi tablolarda olduğuna bağlıdır. Kayıp tek bir hareket kaydı da olabilir, bir aylık fatura bloğu da. Bu belirsizlik yüzünden sağlam yedek varken bu komuta hiç başvurulmaz.

Elimizde güncel yedek yok; veri kurtarma şansı var mı?

Çoğu durumda kısmi kurtarma mümkündür: hasarsız tablolar dışarı aktarılır, bozuk bölgeler için onarım seçenekleri hasar raporuna göre değerlendirilir. Bu, deneme sırası kritik bir süreçtir; Netsis destek hattımızdan acil müdahale alabilirsiniz. 2018’den beri yetkili bayi olarak bu vakalarda önce dosya kopyası, sonra kontrollü kurtarma prensibiyle çalışıyoruz.

Haftalık CHECKDB sistemi yavaşlatır mı; ne zaman çalıştırmalıyız?

CHECKDB yoğun disk ve CPU kullanan bir işlemdir; mesai saatinde çalıştırılırsa kullanıcılar yavaşlık hisseder. Doğru pratik, gece veya hafta sonu boş saatlere planlamak ve çıktının gerçekten kontrol edilmesini sağlamaktır: hatasız tamamlandığını kimsenin doğrulamadığı bir bakım işi, koruma sağlamaz.