Son zamanlarda bir çok alanda yapay zeka akımının hızla yayıldığını görüyoruz. Anlaşılan o ki bu akım yakın gelecekte belli kurallara bağlı işlerin insan faktörü olmadan yapılabilmesine, bazı işlerin yapılma şeklinin değişmesine, bazı işlerin de çok farklı bir boyuta taşınmasına sebep olacak.
Veritabanı Yönetimi (Database Administrative) işi de artık bundan nasibini almaya başladı diyebiliriz. Zaten Query Optimizer bir tür yapay zeka olup sorgu performansını her geçen gün daha yetenekli şekilde yükseltmekteydi. Bununla birlikte artık son zamanlarda bakım işlerini otomatikleştirmeyi hedefleyen yeni mekanizmaları da (Automatic Database Tuning, Smart Backup seçenekleri gibi) kullanmaya başladık. İlerleyen günlerde çok daha fazlasını göreceğimizden eminim.
Bu gibi yenilikler belki Veritabanı Yöneticisi (Database Administrator) ihtiyacını tamamen ortadan kaldırmayacak ancak çalışma şeklini kesinlikle değiştirecektir. Bunu yakın gelecekte göreceğiz. Gelecek yaklaşa dursun, biz de bu arada DBA'in günlük rutininde neler olabilir bir bakalım.
Öncelikle DBA'in yönettiği sistemi ve ihtiyaçları iyi analiz etmesi gerekir. Bu analizleri de belli aralıklarla tekrarlamalıdır. Yol haritasına tatbikatları, acil durumda yapılacakları, kontrol listelerini, sağlık raporlarını eklemelidir. 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, haftalık, aylık olarak yapması gereken bazı görevleri olmalıdır. Bu görevlerin sırası, sayısı veya türü sistemin büyüklüğüne ve yoğunluğuna göre değişebilir. Biz bu yazımızda ortalama bir sistemde yapılabilecekleri özetleyelim, bazı ipuçları verelim. Bu özeti zenginleştirmesi size kalsın.
Günlük Görevler:
Öncelikle SQL Server Servislerinin çalışıp çalışmadığına bakılır. Servisler çalışıyorsa bağlantı kurulabiliyor mu diye bakılır. Servisler çalışmıyorsa veya bağlantı kurulamıyorsa sebebi araştırılmalıdır. Büyük ihtimalle bu konudaki detaylı ve yeterli bilgiye hata loglarından ulaşırsınız. Hata loglarının neler olduğunu aşağıda ikince maddede belirttim.
Eğer SQL Servisleri çalışıyorsa ve bağlantı kurulabiliyorsa gün içinde şunlar yapılır:
- Sistem yoğunluğu hakkında önceden fikir edinmek gerekir. Yönetilen sistemin genel yoğunluğunun ve ihtiyaçlarının neler olduğunu bilmek gerekir. Ortalama olarak CPU, Memory, Disk kaynak tüketimi ne seviyede? Disk büyüme hızı nedir? Disklerde yeterince boşluk var mı? Herhangi bir uzun süreli blocking söz konusu mu? Belki, belli bir sorgunun cevaplanma süresi bile referans alınabilir. Belirlenen bu bilgilere hızla bakılarak serverın içinde bulunduğu durum hakkında fikir edinmek mümkün olur. Bu durumu genel durumla kıyaslayıp server üzerindeki iş yükü görece olarak ölçülebilir. Bunun için SQL Server Management Studiodaki Activity Monitor veya Windows Task Manager'ı kullanmak yeterli olur. Bakıldığı anın özel bir an olup olmadığı da göz önünde bulundurulmalıdır. Yılın, haftanın, ayın veya günün iş yükünün anormal olduğu bir anında bakılıyor olabilir. Bunun için serverda yürüyen işler hakkında önceden fikir edinmek gerekir.
- Logların kontrolü yapılır. İşleyişi bozabilecek herhangi bir hata gerçekleştiyse bu kayıtlarda detaylara ulaşma ihtimali yüksek. Bunun için SQL Server'ın loglarına (SQL Server Logs, SQL Server Agent Error Logs) ve İşletim sistemi loglarına (Event Logs) bakılmalır. İşletim sistemi loglarında daha çok donanım bazlı hatalara odaklanmak zaman kazandırır. Zaten oradaki bazı kayıtlar SQL Server logları ile aynıdır. Bir de herhangi bir kayıp var mı diye @@PACKET_ERRORS global değişkeni ile ağdaki paket gönderim hatalarına bakmak gerekir. Bu kısım için sp_monitor'den de faydalı bilgiler elde edilebilirsiniz.
- Yedekler ve Joblar kontrol edilir. O ana kadar planlanmış yedekler sağlıklı şekilde alınmış mı? Ne kadar sürmüş? Yedek alınan yerler güvenli mi? Bu bilgiye SSMS / İlgili Database / Sağ Tık - Report / Backup and Restore Events raporundan erişebilirsiniz. Eğer açılması uzun sürerse msdb.dbo.backupset üzerinden de bu bilgilere ulaşabilirsiniz. Bu arada sahip olduğunuz SQL Server version/edition destekliyorsa Backup Compression özelliğini kullanmanızda fayda var. CPU'ya bir miktar yük bindirse de hem backup/restore hızınızı etkili şekilde arttırır. hem de disk alanında tasarruf ettirir. Ayrıca alınan yedeklerin sağlığını da belli aralıklarla kontrol etmekte fayda var. Yedeğin veya backup zincirinin bozulması backupların kullanılamayacağı anlamına gelir. Job aktivitelerini ise Job Activity Monitor'den izleyebilirsiniz.
- Veritabanlarının genel durumuna bakılır. Veritabının durumu hangi seviyede görünüyor? online, offline, restoring, recovering, recovery pending, suspect, emergency, single user. Sağlıklı durum olan online hariç diğer ifadeleri veritabanı adının yanında parantez içerisinde görebilirsiniz. Dilerseniz sys.databases üzerinden de bu bilgilere erişebilirsiniz. Bu arada belirttiğim bu metadata nesnesinde log_reuse_wait_desc alanı size logun neyi beklediğini anlatır. Önemli bir diğer şey ise tutarlılık kontrolleridir. Veritabanları tutarlılıklarına DBCC CHECKDB/CHECKTABLE/CHECKALLOC komutları yardımıyla kontrol edebilirsiniz. Tutarlılıkla ilgili bozukluklar yine bu komutların parametreleri ile giderilebilir.
- Sistemin performans değerleri hakkında periyodik bilgi toplanır. Activity Monitor, Performans Monitor, Profiler - Extented Events, Data Collection gibi araçlarla ve istatistik sunan metadata nesneleri ile periyodik olarak takipler yapılır ve sistemin performans değerleri takip edilir. Özellikle en maliyetli sorgular ve maliyetleri, servera sürekli erişen kişiler, bu kişilere ait program, yetki, oturum ve istekleri hakkında bilgiler, lock-deadlock sayısı ve sebepleri, uzun süre açık kalan transactionlar, beklenen görevler (waiting tasks) vs. dikkatlice takip edilmelidir. Tabi bu takibin sisteme ek yük bindireceğini unutmamak gerekir. Gün içinde sistemi yormayacak şekilde takipler yapılmalıdır. Serverın son başlatıldığı ana kadar olan bilgilere kolayca SSMS arayüzlerinden veya sp_who, sp_who2, sys.dm_exec_connections, sys.dm_exec_sessions, sys.dm_exec_requests, sys.dm_os_waiting_tasks, sys.dm_os_wait_stats, DBCC OPENTRAN nesnelerinden ulaşabilirsiniz.
- Indexlerin durumu kontrol edilir. Indexlerin bozulma ve kullanım durumları belli aralıklarla kontrol edilmelidir. Buna göre bakım türü, bakım sıklığı veya pageler içerisindeki dizilimi etkileyecek index tanımları belirlenir. Indexler hakkında bilgileri veritabanı raporlarından elde edebilirsiniz. Dilerseniz sys.dm_db_index_usage_stats, sys.dm_db_index_physical_stats, sys.indexes nesneleri üzerinden de bu bilgilere erişebilirsiniz. Belli aralıklarla oluşturulduğunda değer katacak indexleri keşfetmeniz faydalı olacaktır. Bu konuda ihtiyacınız olan bilgiye sys.dm_db_missing_index_groups ve sys.dm_db_missing_index_group_stats nesneleri üzerinden ulaşabilirsiniz. Bunlarla birlikte istatistiklerin güncelliğini de kontrol etmekte fayda var. STATS_DATE nesnesi table veya indexed view istatistiklerinin son güncelleme tarihini verecektir.
- High Availability sağlığını kontrol etmek. Replication (HA çözümü sayılmasa da), Log Shipping, Mirroring, AlwaysOn Availability Group, AlwaysOn Failover Cluster çözümlerinin kendi yönetim ve takip biçimleri vardır. Kullandığınız çözüme göre işleyiş sağlığı, gecikmeler, gecikmelerden doğan tepkiler hakkında oluşan bilgileri gözden geçirmek ve felaket olduğunda devreye alabilme pratikliğini kontrol etmek gerekir.
- Veritabanı güvenliği ne durumda. Kimler, nereden, hangi programlarla, hangi yetkilerle, kaç defa bağlanıyor? Kaç oturum açıyor ve ne talep ediyor? Yetkisiz erişim var mı? Özellikle takip etmek istediğimiz işlemlerle ilgili bir hareketlilik var mı? gibi soruların cevapları aranmalıdır. sys.dm_exec_connections, sys.dm_exec_sessions, sys.dm_exec_requests, sp_who ve sp_who2 gibi nesneler bir çok bilgi sağlayacaktır. Bununla birlikte Audit mekanizması da erişim aktiviteleri hakkında detaylı bilgi toplamayı kolaylaştıracaktır.
Yukarıda da bahsettiğim gibi sisteme ve iş yüküne bağlı olarak rutin işlerde farklılıklar olabilir. Çalışma esnasında bazı ipuçlarının peşine düşüp çok farklı konuları incelemek gerekebilir. Ancak günlük rutinde yapılan işler aşağı yukarı bunlardır. Zenginleştirmek ise size kalmış.
Yazının çok daha fazla uzamaması için scriptleri burada paylaşmak yerine ipuçları vermeyi tercih ettim.
Özetle sistem hakkında bilgi toplamak için SQL Server Logs, SQL Server Agent Logs, Windows Event Logs, Activity Monitor, Extended Events, Profiler, Data Collector, Performans Monitor, sistemde hazır gelen server ve database raporları, DMV ve Metadata nesnelerinden faydalanabilirsiniz.
Hazır gelen raporlara SSMS üzerinden server ve databaseleri sağ tıklayıp açılan Reports menüsünden ulaşabilirsiniz.
Metadata nesneleri gizli Resource veritabanında yer alır. SSMS / herhangi bir DB / Views / System Views altından ulaşılabilir.
DMV listesine de şu linkten ulaşabilirsiniz:
faydalı olması dileğiyle,
Hiç yorum yok:
Yorum Gönder