Uzun zamandır sahada, şirketlerin en kritik Microsoft SQL Server sunucularında sağlık-kontrolü çalışmaları yapıyorum. Şirketler bu çalışmayı başlıca şu nedenlerle talep ediyor:
- Kurulum en iyi pratiklere göre yapılmamış, vakti zamanında bir yazılımcı veya sistem yöneticisi "ileri" düğmesine tıklayarak yapmış kurulumu,
- Nedeni net olarak anlaşılamayan ve veritabanından kaynaklandığı tahmin edilen performans sorunları var,
- Veritabanı sunucusu uzun zamandır kendi kendine, bir şekilde çalışıyor, ama acaba her şey gerçekten de yolunda mı diye merak ediliyor ve bir bilenin kontrol etmesi isteniyor.
Şunu belirtmekte fayda var, veritabanı yöneticisi pozisyonu illa her şirkette olmak zorunda olan bir pozisyon değil. Çünkü birçok şirketin tam zamanlı olarak bir veritabanı yöneticisi çalıştırması gerekmiyor, bu nedenle bir süre varolan personel kaynağıyla durum idare ediliyor; özellikle KOBİ'ler için bu hem maliyet, hem de fayda açısından makul olmayabiliyor. Bununla birlikte veritabanı sunucularınız olduğunda, ki aşağı yukarı her şirketin vardır diyebiliriz, barındırılan veriler illa ki kritik oluyor ve IT yöneticileri bu verilerin sağlığından endişe ediyor.
Şimdiye kadar yaptığım sağlık-kontrolü çalışmalarını 3GB'lık veritabanı sunucularından tutun, 20TB'lık veritabanı sunucularına kadar uyguladım. Bu çalışmalar sayesinde birçok sürpriz ve olası felaket durumlarını ortaya çıkarttım. Bu yazıda bu sürprizlerden bazılarını, özetle de olsa vurgulamak istedim. Böylece belki hiç beklemediğiniz olası sürprizler hakkında sizin de haberiniz olur veya önlem almak için bir algı oluşur.
Senaryo 1:
Şirket yetkilisi veritabanlarının çok önemli olduğunu, finansal veri içerdiğini, güvenlik açısından asla taviz veremeyeceklerini iletti.
Sunucuyu kontrol ederken karşılaştığım en çarpıcı noktalar:
- Veritabanı sunucusunun internete açık olması,
- SQL Server TCP port numarasının varsayılan port numarası olan 1433 olması,
- "sa" kullanıcısının etkin olması ve şifresinin basit olması,
- Error Log dosyasında birçok farklı sunucudan, "admin", "sa" gibi birçok farklı kullanıcı adıyla bu "kritik" olan sunucuya bağlanılmaya çalışılmasıydı.
Bu konuda bilgili ve tecrübeli olanlarınız bunların çok bariz ve temel şeyler olduğunu düşünebilir, ama unutmayın, bunlar bilene kolay...
Senaryo 2:
Çok kritik verileri olan bir başka şirket veritabanı sunucularının sağlık kontrolünü yapmamı istedi, veritabanlarındaki veriler yine finansal açıdan çok kritik.
Sunucuyu kontrol ederken en kritik olan veritabanının yedeğinin en son 2 ay önce alındığını gördüm. Bunu kendilerine ifade ettiğimde, elbette oldukça soğuk bir duş etkisi yarattı.
Senaryo 3:
Uluslararası ortakları olan bir firma ile sağlık kontrolü çalışması yaparken, veritabanı yedeklerinin disk doluluğu nedeniyle uzun zamandır alınamadığını gördük. Maalesef ortamda disk kapasite takibi veya Job'lar hata aldığında bunları izleyecek bir mekanizma yoktu. Bu nedenle kimsenin bu hatalardan haberi olmamıştı.
Senaryo 4:
Bir firmanın kritik bir sunucusunda sağlık kontrol çalışması yaparken sunucuda ortalama olarak eşit şekilde yük yaratması beklenen en kritik iki veritabanından birinin aslında CPU, IO ve RAM kaynaklarının %80'ini kullandığını gördük. Tabii bir sorun olduğu net olarak ortaya çıkmış oldu ve iyileştirme çalışmaları için sistem kaynaklarını beklenenden daha fazla tüketen veritabanına odaklanıldı.
Senaryo 5:
Firmanın en kritik veritabanı sunucusunda performans sorunları olduğu iletildi. Sağlık kontrolü çalışması yaparken, 45 dakika ve daha fazla süren sorgular olduğunu tespit ettim. Kimsenin bu kadar uzun süren sorgular olduğundan haberi bile yoktu. Bu ve benzeri sorguları tespit edip, iyileştirme çalışmaları yaptıktan sonra sorunun büyük bir bölümü çözülmüştü.
Senaryo 6:
Canlı ortam olarak kullanılmak üzere düşünülen bir ortama Always On Availability Groups (AG) kurulumu yapılmıştı. Kurulumun yapılandırılmasını kontrol ettiğimde, kurulumu yapanların bir Listener oluşturmadıklarını gördüm. Kurulumu yapanlar, firmaya Connection String'te Cluster adını kullanabileceklerini iletmişti. Firmaya bunun -malumunuz- böyle çalışmayacağını, dilerse test edebileceğini ve testin hata ile sonuçlanacağını ilettim. Tabii ki test hata ile sonuçlandı. Firma tekrar kurulum yaptırmak istemediğini, bütçe ayıramayacağını söyledi ve firmanın "stand-alone" olan sistemlerini Always On AG ortamına taşıma projesi rafa kaldırıldı.
İlginizi çektiyse sağlık-kontrolü çalışmam hakkında daha fazla bilgi için lütfen buraya tıklayın.
Ekrem Önsoy
Microsoft SQL Server Danışmanı
www.ekremonsoy.com
