Netsis’in altında çalışan SQL Server, bakım yapılmadan da uzun süre “çalışıyor” görünür; sorun tam da budur. Bakımsızlık kendini birden değil, sinsice gösterir: raporlar ay ay yavaşlar, log dosyası diski doldurur, en sonunda bir sabah sistem açılmaz. Bu rehber, Netsis veritabanı için asgari SQL Server bakım planını adım adım kurmanızı sağlar.
Adım 1: Kurtarma Modeli ve Log Büyümesi
En sık karşılaştığımız tablo şudur: veritabanı tam (full) kurtarma modelinde çalışıyor ama işlem günlüğü (transaction log) yedeği hiç alınmıyor. Bu kombinasyonda log dosyası hiç boşalmaz ve diski dolduana kadar büyür.
- Veritabanının kurtarma modelini öğrenin (tam mı, basit mi)
- Tam modeldeyseniz: düzenli log yedeği planlayın; log yedeği hem dakikalar mertebesinde geri dönüş noktası sağlar hem log dosyasının kontrolsüz büyümesini durdurur
- Gün içi geri dönüş noktasına ihtiyacınız yoksa: basit (simple) model + sık tam/fark yedeği de savunulabilir bir tercihtir; karar veri kaybı toleransınıza göre verilmelidir
- Log dosyasını rutin olarak küçültmeyi (shrink) çözüm sanmayın; büyümenin nedeni giderilmeden yapılan shrink, dosyanın tekrar büyüyüp diski yormasıyla sonuçlanır
Yedek zincirinin bütünü (tam + fark + log, saklama süreleri, dış kopya) için yedekleme stratejisi rehberimizi uygulayın.
Adım 2: İndeks ve İstatistik Bakımı
Hareket tabloları büyüdükçe indeksler parçalanır, istatistikler eskir; sorgu planları kötüleşir ve aynı rapor her ay biraz daha yavaş gelir.
- Haftalık bir bakım işi planlayın: parçalanma oranı düşük indekslerde yeniden düzenleme (reorganize), yüksek olanlarda yeniden oluşturma (rebuild) genel kabul görmüş yaklaşımdır
- İstatistik güncellemeyi aynı rutine ekleyin
- Bakım işini mesai dışı bir pencereye alın; rebuild sırasında tablolar yoğun kaynak tüketir
- İşin sonucunu e-posta veya log ile izleyin; “planlandı ama aylardır hata veriyor” durumu, hiç plan olmamasından daha tehlikelidir çünkü yapıldığı sanılır
Bakımın etkisini en net, bakım öncesi/sonrası aynı ağır raporun süresini karşılaştırarak görürsünüz. Genel yavaşlık teşhisi için performans iyileştirme rehberine bakın.
Adım 3: tempdb Kontrolü
SQL Server, sıralama ve geçici tablolar için tempdb veritabanını kullanır; ağır raporlarda tempdb darboğaza dönüşebilir:
- tempdb dosyalarını sistem diskinden ayrı, hızlı bir diskte tutun
- Çok çekirdekli sunucularda tempdb’yi birden fazla veri dosyasıyla yapılandırmak yaygın en iyi uygulamadır; dosya sayısı kararını ortamınıza göre veritabanı yöneticinizle verin
- tempdb’nin de disk doldurabileceğini unutmayın; disk doluluk uyarılarınıza tempdb diskini dahil edin
Adım 4: Bütünlük Kontrolü (DBCC CHECKDB)
Disk veya donanım kaynaklı sessiz bozulmalar, ancak bütünlük kontrolüyle erken yakalanır:
- Haftalık DBCC CHECKDB çalıştırın (büyük veritabanlarında mesai dışı pencerede)
- Çıktıyı mutlaka okuyun veya hata durumunda uyarı üretecek şekilde kurgulayın
- Hata raporlanırsa kendi başınıza onarım komutu denemeyin; yanlış onarım seçeneği veri kaybettirir. Sağlam yedeğe dönüş çoğu zaman daha güvenlidir — bu noktada bayinizden veya veritabanı uzmanından destek alın
Bütünlük hatalarının ihmal edildiği kurulumlar, bir gün veritabanının açılmadığı suspect senaryosuyla sonuçlanabilir; o durumun müdahale adımları suspect mode çözümü yazısındadır.
Adım 5: Uyarı Mekanizması Kurun
Bakım planının görünmez kahramanı uyarılardır; izlenmeyen bakım işi, olmayan bakım işiyle aynı kapıya çıkar:
- Disk doluluk eşiği için uyarı tanımlayın (veri, log ve tempdb disklerinin tamamına)
- Yedek ve bakım işlerinin başarısızlık durumunda e-posta üretmesini sağlayın; günlük başarı mesajları kısa sürede okunmaz olur, başarısızlık uyarısı ise mutlaka bir kişinin sorumluluğunda olmalıdır
- Uyarı e-postalarının gerçekten ulaştığını üç ayda bir test edin; değişen posta sunucusu ayarı yüzünden aylardır sessiz kalan uyarı sistemi, sahada gördüğümüz gerçek bir senaryodur
Adım 6: Bakım Takvimini Yazılı Hale Getirin
| Sıklık | İş |
|---|---|
| Sürekli | Disk doluluk ve yedek başarı uyarıları |
| Günlük | Tam/fark yedek kontrolü; tam modelde gün içi log yedekleri |
| Haftalık | İndeks + istatistik bakımı, DBCC CHECKDB, iş sonuçlarının okunması |
| Aylık | Log ve veri dosyası büyüme eğilimi, restore testi |
| Yıllık | Arşivleme kararı, kapasite planı, bakım planının gözden geçirilmesi |
Veritabanı boyutu bakım pencerelerine sığmamaya başladıysa kök çözüm arşivlemedir; yöntem için arşivleme yazımıza bakın.
Sıkça Sorulan Sorular
Bakım planını Netsis mi yapar, SQL Server mı?
Bu rehberdeki işler SQL Server tarafında planlanır ve Netsis’ten bağımsız çalışır. Netsis tarafındaki arşivleme ve dönem işlemleri ise uygulama içindedir; ikisi birbirinin yerine geçmez, birlikte yürür.
Log dosyası diski doldurdu, acil ne yapmalıyım?
Kalıcı çözüm kurtarma modeli kararı + düzenli log yedeğidir; acil durumda log yedeği almak dosyanın içinin boşalmasını sağlar. Paniğe kapılıp log dosyasını silmeyi asla denemeyin; veritabanını açılmaz hale getirir.
Deadlock uyarıları bakım planıyla çözülür mü?
Kısmen. Güncel istatistik ve sağlıklı indeksler kilitlenme süresini kısaltır; ancak deadlock çoğu zaman eşzamanlı iş akışlarıyla ilgilidir. Belirti sürüyorsa deadlock victim çözümü yazısındaki adımları izleyin.
Bu işler için ayrı bir veritabanı yöneticisine ihtiyacım var mı?
Küçük ve orta ölçekte, bir kez doğru kurulan plan uzun süre kendi kendine yürür; kritik olan sonuçların izlenmesidir. Kurulumu uzmana yaptırıp izlemeyi içeride üstlenmek en pratik modeldir.
SQL Server güncellemeleri bakım planına dahil mi?
Güvenlik yamalarını düzenli uygulamak bakımın parçasıdır; ancak ana sürüm yükseltmeleri farklı bir iştir ve kullandığınız Netsis sürümünün desteklediği SQL Server sürümleriyle uyumluluk kontrolü gerektirir. Sürüm atlamadan önce mutlaka bayinizle planlayın.
Bakım planınızın kurulumunu ve yıllık sağlık kontrolünü Giza Teknoloji Netsis destek ekibi yerinde yapabilir; sorularınız için iletişim sayfamıza yazın.