Bir önceki yazımızda Veri Tabanı Yönetim Sistemlerinde yapay zeka akımının etkilerini görebiliyoruz demiştik. Bu akım yakın gelecekte DBA'lerin iş yapma şeklinde ciddi değişikliklere sebep olacağa benziyor. Şimdiden bu değişiklikler olmaya başladı bile.
Bu akımın etkileri gele dursun biz bir DBA'in rutininde neler olabileceğini incelemeye devam edelim. Önceki yazımızda günlük rutine odaklanmıştık. Bu yazımızda haftalık rutinde neler olabileceğini ele alalım.
Önceki yazıya ulaşmak için:
Veritabanı Yöneticisinin Rutini - Günlük (DBA's Routine - Daily)
Önceki yazımızda bahsettiğimiz şu beklenti bu yazının konusunu oluşturmakta ;
"Bir DBA'in riskleri belirleyerek önlemleri zamanında alması, iyileştirme fırsatlarını görerek uzun ve kısa vadede çeşitli aksiyon planları oluşturması beklenir."
DBA'in günlük görevleri daha çok üretilen istatistikleri incelemekten, ani ve kısa süreli müdahalelerde bulunmaktan ibarettir. Haftalık ve aylık görevleri ise bu bilgiler ışığı altında bakım ve iyileştirmeler yapmaktır.
Haftalık Görevler
- Metadata üzerinde daha kapsamlı ve detaylı inceleme yapılır. Günlük görevlerde bahsettiğimiz tüm takipler gün içinde yetişmeyebilir. Bunları biraz daha detaylı olacak şekilde haftalık görevler arasına almak gerekebilir.
- Sistem veritabanlarının yedeklerini almak. Tüm yedekler hakkında bilgiyi detaylı bir şekilde incelemek, yedeklerin sağlığından emin olmak gerekir. Bununla birlikte sistem veritabanlarının yedekleri sistem yoğunluğuna göre belli aralıklarla alınmalıdır. tempdb zaten her yeniden başlatmada sıfırdan oluşur. model veritabanı yeni oluşacak veritabanları için bir tür template görevi görür. Genelde tempdb ve model (bazı senaryolar için anlamlı olabilir) veritabanlarının yedeğine ihtiyaç duyulmaz. Ancak master ve msdb veritabanları bir hayli önemlidir. Özellikle master veritabanında server ayarları, kullanıcı, veritabanı, şifrelemeye dair bilgiler gibi hassas veriler yer alır. master kullanılamaz olduğunda sistemi işler hale getirmek ya çok sancılı olur ya da veriler artık kullanılamaz hale gelir.
- Veritabanı yedeklerin kullanılabildiğinden emin olmak gerekir. Genel en fazla yedek almaya odaklanılır. Ancak yedeklerin kullanılabileceğini kontrol etmek en az yedek almak kadar önemli bir konudur. Yanlış stratejiler veya kullanılan ek ürünlerden dolayı LSN zinciri bozulmuş olabilir. Ya da backup alınan yerde çıkan bir hata yüzünden dosya kullanılamaz hale gelmiş olabilir. Yedekten dönmeyi denemeden yedeklerin işe yarayıp yaramayacağını anlayamayız. Bu yüzden test sunucularda restore senaryolarını belli aralıklarla uygulamak çok önemlidir.
- Takipler ve incelemeler sonucunda elde edilen bulgulara göre Maintenance Plans (Bakım Planları) hazırlanmalıdır. Bakım planları SSMS / Management / Maintenance Plans altında oluşturabilirsiniz. Daha sonra bu planları SQL Server Agent üzerinde oluşturacağınız job'larda kullanabilir çeşitli periyotlarda bakımların yapılmasını sağlayabilirsiniz. Bu planlar içerisinde yedek alma, index rebuild-reorganize, istatistikleri güncelleme, veritabanı tutarlılık kontrolleri gibi işleri yapabilirsiniz. Daha kompleks işleri yürütmek için SSIS projesi açıp burada oluşturduğunuz paketlerden joblar tanımlamayı da tercih edebilirsiniz.
- İstatistikleri güncellemek ve indexlere bakım yapmak gerekir. İstatistiklerin güncel, indexlerin bakımlı olması sorgu performansını doğrudan etkiler. önceki yazıda bahsettiğimiz şekilde bu bilgilere erişip bakım planımızı oluşturabiliriz. İstatistikler varsayılan olarak otomatik güncellenir. Eğer güncel değilse Maintenance Planlarla veya Update Statistics 'tabloveyaindexedview' komutu ile güncelleyebilirsiniz. Indexlerin bozulmalarına bakarak eğer bozulma %5 ile %30 arasında ise Reorganize, %30'dan fazla ise Rebuild yapmanız gerekir. Bozulma bilgisine SSMS üzerindeki raporlardan veya ilgili tablonun altında indexleri sağ tıklayıp açılan menüdeki özelliklerden veya sorgu ile sys.dm_db_index_physical_stats nesnesinin avg_fragmentation_in_percent kolonundan öğrenebilirsiniz. Bakımı da yine SSMS üzerinden indexe erişerek veya Maintenance Planlar üzerinden yapabilirsiniz. Dilerseniz Alter Index IndexAdı on TabloAdı REORGANIZE/REBUILD komutlarını ve ihtiyacınız olan parametreleri de kullanabilirsiniz. Index bakım sıklığını ve bozulmayı etkileyebilecek şeyler yoğun veri girişi, fillfactor ve padindex ayarlarıdır. Bu iki ayar sayesinde çok sık bakım gerekmesin diye index sayfalarında boşluk bırakırız. Mesala fillfactor %80 ise %80 sayfalar dolu olsun %20 boşluk kalsın demiş oluruz. Buradaki değeri düşürmek bakımı geciktirir. Ancak çok düşürürsek bu sefer de bilgi çok fazla index pagee dağılacağı için blocking de artış olur. Optimum değer sistemimize bağlıdır. Dilerseniz padindex özelliğini kullanarak doluluk oranının indexin ara seviyelerine de uygulanmasını sağlayabilirsiniz.
- En maliyetli sorgular ve en çok beklenen görevler için iyileştirmeler yapmak gerekir. Sorgularla ilgili en azından üç noktayı takip etmek lazım. Bunların ilki en maliyetli sorguların neden o kadar maliyetli olduğunu öğrenmektir. Sorgu yazımında, sorgunun kullandığı nesnelerin performansında, sorgunun cachedeki durumunda, index ve istatistiklerin bakımında bir problem var mı diye kontrol edip iyileştirmeleri ekip çalışmalarıyla yapmak gerekir. İkinci nokta ise maliyeti düşük fakat gün için defalarca çalışan sorguları nasıl iyileştirebileceğini araştırmak. Üçüncü nokta ise birer defa çalıştırılan sorgu sayına ulaşmak ve eğer çok fazla tek seferlik sorgu varsa server ayarlarından Optimze for Ad hoc Workloads özelliğini aktif etmek gerekir. Diğer bir konu ise en çok beklenen görevlerin neler olduğunu tespit etmektir. Önceki yazımızda da belirttiğimiz gibi sys.databases, sys.dm_os_wait_stats, sys.dm_os_waiting_tasks nesneleri ile hangi görevlerin beklendiği belirlenebilir. En çok beklenen görevlere bakılarak iyileştirmeler yapılabilir.
- Latch, lock, block ve deadlock aktivitelerini takip edip çözüm üretmek gerekir. Latch diskten memorye geçişte yaşanan çok küçük kilitlenmelerdir. Normalde gözardı edilir. Ancak sistem çok yoğunsa baş belası olmaya başlar. Latch problem olmaya başladığında donanım bazlı iyileştirmelere veya inmemory özelliklerine göz atılabilir. Lock nesneler üzerinde bir işlem yapıldığında devreye girer. İhtyaca göre küçük veya büyük bir alana kilit konabilir. Lock arttıkça diğer işlemler blocklanır. Blocklamalarda bir işlem yapılırken diğerleri bekler. Blocking takip edilerek sebebi araştırılmalı biran önce çözüm üretilmelidir. Çok fazla işlem yapılması yüzünden daha büyük bir alana kilit uygulanması veya uzun süre açık kalan transactionlar yüzünden kilidin uzun süre kalması en sık görülen bloklama sebepleridir. Kodlar yapılacak düzenlemelerle veya uygun Isolation seviyeleri ile blocking problemi çözülebilir. Deadlock ise neredeyse hiç fark edilmez. İstekler askıda beklemez tamamen reddolur. Çapraz bir şekilde aynı kaynaklara erişmeye çalışan isteklerden varsayılan olarak geri çevrilmesi en maliyetli olanı işleme alınır, diğerleri iptal edilir. Deadlock aktivitelerini profiler, extended event gibi araçlar takip edebilirsiniz. Elde edilen bilgilere göre deadlocklar azaltılabilir.
- HA, Audit, Job, Maintenance Plans, Database Mail gibi özelliklerden kaynaklı aktiviteler sağlıklı şekilde devam ediyor mu diye bakılır. Bu aktivitelerin loglarına ve ayarlarına bakılarak sağlıkları kontrol edilmelidir. Beklenenin dışında bir işlem olmuş mu diye kontrol edilmelidir. Gerekli düzeltmeler tespit edilip uygulanmalıdır.
DBA'gün günlük işleri daha çok takip üzerine ve ani ihtiyaçlara cevap verme üzerine kuruludur. Gün ortasında yavaş çalıştığı ifade edilen bir sisteme bakım yapmak çok pratik olmaz. Günlük takipte edilen bilgiler ışığı altında yukarıda bahsettiğimiz şekilde haftalık bakımlar yapmak gerekir. Kendi sisteminizin ihtiyaçlarını göre burada yazanları zenginleştirebilirsiniz.
Burada bahsettiğimiz konuların sayısı, sırası ve içerikleri sistemin büyüklüğüne göre değişebilir. Bu yazıyı tamamlayıcı nitelikte olan önceki yazımıza da göz atmanızı tavsiye ederim.
Önceki yazıya ulaşmak için:
Veritabanı Yöneticisinin Rutini - Günlük (DBA's Routine - Daily)
Faydalı olması dileğiyle,
