Veritabanı Sağlık Kontrolü Nedir? SQL Server, Oracle ve PostgreSQL İçin Health Check Rehberi

Veritabanı sağlık kontrolü (database health check), bir veritabanı ortamının yapılandırmasını, yedekleme ve kurtarma hazırlığını, güvenliğini, performansını ve yüksek erişilebilirlik durumunu sistematik olarak inceleyen ve bulguları risk sırasına koyan bir değerlendirmedir. Amaç, sorunları bir kesinti veya veri kaybına dönüşmeden önce görmek ve hangi iyileştirmenin önce yapılacağını netleştirmektir.

Bu rehber; SQL Server, Oracle veya PostgreSQL kullanan kurumların BT yöneticileri ve veritabanı ekipleri için hazırlandı. Sağlık kontrolünün neleri kapsaması gerektiğini, platformlara göre nelerin değiştiğini, ne sıklıkla yapılması gerektiğini ve iyi bir raporun nasıl görünmesi gerektiğini özetliyoruz.

Kısaca: Veritabanı Sağlık Kontrolü

Sağlık Kontrolü Neden Gereklidir?

Veritabanı sorunlarının büyük kısmı bir anda ortaya çıkmaz; aylarca sessizce birikir. Dolmaya yaklaşan bir disk, hiç test edilmemiş bir yedek, artık izlenmeyen bir replikasyon ya da ay sonu yükünde kilitlenen bir rapor, ancak bir kesinti yaşandığında fark edilir.

Sahada en sık karşılaştığımız kök nedenler şunlardır:

• Üçüncü taraf uygulamaların verimsiz sorguları
• Bağlantı havuzu yönetiminin olmaması: açılan bağlantıların kapatılmaması ve boşta beklemesi
• Hatalı işlem (transaction) yönetiminin yol açtığı deadlock’lar
• Yedekleme politikasının olmaması; buna bağlı olarak log dosyalarının dolması veya replikasyonun durması
• Replikasyon ve Always On performansının izlenmemesi
• En iyi uygulamalara uymayan disk yapılandırmaları; yoğun saatlerde dolan diskler ve hatalı otomatik büyüme ayarları
• Eksik indeks bakımı ve tutarlılık kontrolü; bu yüzden veri bozulmasının çok geç fark edilmesi

Bu sorunların hiçbiri tek başına karmaşık değildir. Tehlikeli olan, kimsenin bakmadığı yerde birikmeleridir. Sağlık kontrolü, bu birikimi düzenli aralıklarla görünür kılar.

Sağlık Kontrolü Neleri Kapsamalı?

Platform ne olursa olsun, kapsamlı bir sağlık kontrolü aşağıdaki sekiz alanı incelemelidir:

Platforma Göre Öne Çıkan Kontroller

Sekiz alan her platformda aynıdır; ancak her veritabanının kendine özgü riskleri vardır.

SQL Server için 12 başlıklık ayrıntılı kontrol listesini SQL Server Health Check rehberimizde, PostgreSQL için on temel kuralı PostgreSQL Best Practices yazımızda bulabilirsiniz.

Hızlı Bir Başlangıç: Yedekler Gerçekten Alınıyor mu?

Sağlık kontrolünün ilk sorusu her zaman yedeklemedir. Aşağıdaki sorgu, SQL Server’da her veritabanı için son tam, fark (differential) ve log yedeğinin ne zaman alındığını gösterir. Recovery model’i FULL olduğu halde log yedeği hiç alınmayan veya son yedeği günler önce kalmış veritabanları, raporun ilk satırlarına yazılmalıdır.

SELECT d.name AS database_name,
       d.recovery_model_desc,
       MAX(CASE WHEN b.type = 'D' THEN b.backup_finish_date END) AS last_full,
       MAX(CASE WHEN b.type = 'I' THEN b.backup_finish_date END) AS last_diff,
       MAX(CASE WHEN b.type = 'L' THEN b.backup_finish_date END) AS last_log
FROM sys.databases AS d
LEFT JOIN msdb.dbo.backupset AS b
       ON b.database_name = d.name
WHERE d.name <> 'tempdb'
GROUP BY d.name, d.recovery_model_desc
ORDER BY last_full;

PostgreSQL’de aynı soru WAL arşivlemenin çalışıp çalışmadığıyla başlar. Başarısız arşivleme, belirli bir ana geri dönüş imkânını sessizce ortadan kaldırır:

SELECT archived_count, last_archived_time,
       failed_count, last_failed_time
FROM pg_stat_archiver;

İyi Bir Sağlık Kontrolü Raporu Nasıl Olmalı?

Sağlık kontrolünün değeri raporun kalitesiyle ölçülür. Yüzlerce sayfalık bir ham veri dökümü, kimsenin okumadığı bir dosya olarak kalır. İyi bir rapor şu özellikleri taşır:

Sağlık Kontrolü Ne Sıklıkla Yapılmalı?

Sağlık kontrolü, sürekli izlemenin yerini tutmaz. İzleme, bugün olan sorunu gösterir; sağlık kontrolü ise sistemin yapısal risklerini ortaya koyar. İkisi birbirini tamamlar. Hangi metriklerin sürekli izlenmesi gerektiğini SQL Server izleme kontrol listemizde anlattık.

Kendiniz mi Yapmalısınız, Uzmana mı Yaptırmalısınız?

Temel kontrolleri, örneğin yedeklerin alınıp alınmadığını, disk doluluğunu ve hata loglarını, kurum içi ekibiniz düzenli olarak yapabilir ve yapmalıdır. Bağımsız bir uzman değerlendirmesi ise şu durumlarda fark yaratır:

• Ekip, kendi kurduğu sistemdeki hataları görmekte zorlanıyorsa; dışarıdan bir göz, alışkanlıkla kabul edilmiş riskleri fark eder.
• Ortamda birden fazla veritabanı platformu varsa ve her biri için ayrı uzmanlık gerekiyorsa.
• Sonuçlar bir denetim, yatırım kararı veya hizmet sağlayıcı seçimi için kullanılacaksa.
• Veritabanı yöneticisi ayrılmış ve sistemin gerçek durumunu bilen kimse kalmamışsa.

Aryasoft Sağlık Kontrolünü Nasıl Yapıyor?

Aryasoft, SQL Server sağlık kontrollerinde kendi geliştirdiği HELT360 aracını kullanır. GarajX TEKMER bünyesinde Ar-Ge projesi olarak geliştirilen HELT360, salt okunur çalışır, yalnızca yapılandırma kontrolleri yapar ve sisteme yük bindirmez. Çalıştırdığı tüm script’ler panelinde görüntülenebilir; talep edilirse tüm trafiği metin dosyalarına kaydedilir. Bulgular zaman damgasıyla raporlanır.

Oracle ve PostgreSQL ortamlarında ise aynı sekiz alanı kıdemli uzmanlarımız platforma özgü kontrollerle inceler. Sonuçta, yönetici özeti ve öncelik sırasıyla birlikte, kesinti gerektirmeyen düzeltmelerden başlayan bir iyileştirme planı teslim edilir. Ortamınızın düzenli takibini istiyorsanız, sağlık kontrolü yönetilen veritabanı hizmetlerimizin de başlangıç adımıdır.

Sıkça Sorulan Sorular

Kaynaklar

Bu rehberdeki teknik bilgiler Kasım 2026’da aşağıdaki resmi dokümantasyonla karşılaştırıldı.

1. Microsoft Learn: backupset (Transact-SQL)
2. Microsoft Learn: DBCC CHECKDB
3. PostgreSQL dokümantasyonu: The Cumulative Statistics System (pg_stat_archiver)
4. PostgreSQL dokümantasyonu: Routine Vacuuming
5. Oracle Database Licensing Information (Diagnostics Pack)