SQL Server Health Check: Neleri Kapsamalı? 12 Başlıklık Kontrol Listesi

Bir SQL Server ortamı yıllarca sorunsuz çalışıyor gibi görünebilir; ta ki yedekten dönülmesi gereken gün yedeğin bozuk çıktığı, bir disk dolduğu ya da kimsenin fark etmediği bir bozulmanın ortaya çıktığı ana kadar. SQL Server health check, bu tür riskleri sorun yaşanmadan önce görünür kılan, yapılandırılmış bir incelemedir.

Bu rehberde iyi bir health check’in hangi alanları kapsaması gerektiğini, her alanda neye bakıldığını ve bazı kontrolleri kendiniz nasıl yapabileceğinizi anlatıyoruz. Bir hizmet sağlayıcıdan health check alacaksanız da, beklemeniz gereken kapsamı ve çıktıyı bu listeyle karşılaştırabilirsiniz.

Health Check Ne Zaman Yapılmalı?

• Ortamı yöneten DBA ayrıldığında ya da yeni bir ekip devraldığında.
• Bir upgrade, migration ya da donanım yenilemesinden önce.
• Kronik performans şikâyetleri olduğunda, ama nedeni bilinmediğinde.
• Bir denetim, siber güvenlik değerlendirmesi ya da regülasyon kontrolü öncesinde.
• Hiçbir şikâyet olmasa bile, yılda en az bir kez.

İyi Bir Health Check’in Kapsadığı 12 Alan

1. Yedekler ve geri dönüş

Her veritabanı için son full, differential ve log yedeğinin zamanı, recovery model’in yedek stratejisiyle uyumu, yedeklerin aynı sunucuda mı yoksa ayrı bir yerde mi durduğu ve en önemlisi düzenli restore testinin yapılıp yapılmadığı incelenir.

SELECT d.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.database_id <> 2
GROUP BY d.name, d.recovery_model_desc
ORDER BY last_full;

FULL recovery model’de olup log yedeği alınmayan veritabanları, sahada en sık bulduğumuz sorunlardan biridir: log dosyası durmadan büyür ve bir noktada diski doldurur.

2. Veri bütünlüğü (DBCC CHECKDB)

Her veritabanında son başarılı CHECKDB’nin ne zaman çalıştığı ve error log’da 823, 824 ve 825 hatalarının olup olmadığı kontrol edilir. Bozulma ne kadar geç fark edilirse, temiz bir yedeğe dönme şansı o kadar azalır.

SELECT name, DATABASEPROPERTYEX(name, 'LastGoodCheckDbTime') AS last_good_checkdb
FROM sys.databases
WHERE state_desc = N'ONLINE' AND database_id <> 2
ORDER BY last_good_checkdb;

3. Sürüm, build ve destek durumu

SQL Server ve Windows sürümünün destek kapsamında olup olmadığı, kurulu cumulative update ve bilinen hatalı build’ler kontrol edilir. Desteği bitmiş bir sürüm güvenlik yaması almaz.

SELECT SERVERPROPERTY('ProductVersion') AS version,
       SERVERPROPERTY('ProductLevel')   AS level,
       SERVERPROPERTY('ProductUpdateLevel') AS cu,
       SERVERPROPERTY('Edition')        AS edition;

4. Instance yapılandırması

Max server memory, MAXDOP, cost threshold for parallelism, Instant File Initialization, Lock Pages in Memory, priority boost gibi eski ayarlar ve varsayılandan farklı tüm sp_configure değerleri iş yüküyle birlikte değerlendirilir.

5. Güvenlik

sysadmin üyeleri, sa hesabının durumu, parola politikası uygulanmayan SQL login’leri, açık bırakılmış xp_cmdshell ve benzeri özellikler, servis hesaplarının yetkileri ve audit yapılandırması incelenir.

6. TempDB

Veri dosyası sayısı, eşit boyut ve büyüme ayarları, ayrı disk yerleşimi ve contention belirtileri kontrol edilir.

7. Depolama ve dosyalar

Disk gecikmeleri, boş alan, autogrowth ayarları (yüzde ile büyüme ya da çok küçük adımlar), log dosyalarındaki VLF sayısı ve dosyaların disklere yerleşimi incelenir. Disk gecikmesi için:

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_read_ms DESC;

8. Bekleme istatistikleri

Sunucunun zamanını neye harcadığı (CPU, disk, kilit, bellek, ağ) wait istatistiklerinden okunur. Bu, performans sorunlarının hangi yönde aranacağını belirler.

9. Index’ler ve istatistikler

Eksik, kullanılmayan ve tekrarlanan index’ler, heap tablolar, bakım planının durumu ve eskimiş istatistikler incelenir.

10. SQL Server Agent ve job’lar

Başarısız job’lar, sahibi ayrılmış personel olan job’lar, aynı anda başlayıp çakışan bakım işleri ve bildirim (operator) ayarları kontrol edilir.

11. Yüksek erişilebilirlik ve felaket kurtarma

Always On Availability Group’ların senkronizasyon durumu, failover hazırlığı, replikalar arasındaki login ve job farkları, RPO ve RTO hedeflerinin gerçekte karşılanıp karşılanmadığı değerlendirilir.

12. İzleme ve uyarılar

Önem derecesi 17-25 hataları ve 823/824/825 için uyarıların kurulu olup olmadığı, Database Mail’in çalışıp çalışmadığı ve uyarıların doğru kişilere gidip gitmediği kontrol edilir.

Sahada En Sık Bulduğumuz Sorunlar

Deneyimimize göre health check’lerde aynı başlıklar tekrar tekrar karşımıza çıkar:

• Yedek politikası olmaması; dolan log dosyaları ve durmuş replikasyon.
• Hiç çalışmamış ya da yıllardır çalışmayan CHECKDB; bozulmanın geç fark edilmesi.
• Best practice’lere uymayan disk yerleşimi ve yoğun saatlerde dolan diskler, kötü autogrowth ayarlarıyla birlikte.
• Index bakımının hiç yapılmaması ya da gereksiz yere her gece tüm index’lerin rebuild edilmesi.
• Bağlantıları kapatmayan, sleeping oturum biriktiren uygulamalar ve deadlock’a yol açan transaction yönetimi.
• Always On ve replikasyon performansının hiç izlenmemesi.

Bir Hizmet Sağlayıcıdan Ne Beklemelisiniz?

• Salt okunur çalışma: Health check sırasında ortamda hiçbir değişiklik yapılmamalı ve üretim iş yüküne yük bindirilmemelidir.
• Şeffaflık: Çalıştırılan script’ler görülebilir olmalı; hangi verinin toplandığı açıkça belirtilmelidir.
• Veriye değil, yapılandırmaya bakılması: Müşteri verisi okunmamalı, dışarı taşınmamalıdır.
• Önceliklendirilmiş rapor: Her bulgu için risk, etki, çözüm önerisi ve tahmini efor.
• Tekrarlanabilirlik: Düzeltmelerden sonra aynı kontroller yeniden çalıştırılıp ilerleme ölçülebilmelidir.

Aryasoft Bunu Nasıl Yapıyor?

Aryasoft, health check’lerde GarajX TEKMER bünyesinde Ar-Ge projesi olarak geliştirdiği otomatik sağlık kontrolü aracı HELT360‘ı kullanır:

• HELT360 salt okunur çalışır, yalnızca yapılandırma kontrolleri yapar ve sunucuya yük bindirmez.
• Çalıştırdığı tüm script’ler panelde görülebilir; talep edilirse tüm trafiği metin dosyalarına kaydedilir.
• Bulgular zaman damgalı olarak raporlanır ve önceliklendirilir; düzeltmelerden sonra aynı tarama tekrarlanarak ilerleme ölçülür.
• Otomatik taramanın üzerine kıdemli DBA’larımız iş yükünü, bekleme istatistiklerini ve mimariyi yorumlar; rapor teknik ekibe olduğu kadar yöneticilere de anlaşılır bir özet sunar.

İsteyen müşterilerimizde health check, yönetilen veritabanı hizmetinin ilk adımıdır: bulgular önceliklendirilmiş bir iş planına dönüşür ve düzeltmeler kesinti yaratmadan uygulanır.