27 Ocak 2019 Pazar

Veritabanı Yöneticisinin Rutini - Aylık (DBA's Routine - Monthly)

Bir önceki yazımızda DBA'in haftalık görevlerinin neler olabileceğine odaklandık. Daha önceki yazımızda ise günlük görevlerinin neler olabileceğine odaklanmıştık.

Önceki yazılarımıza şu linklerden ulaşabilirsiniz:

Veritabanı Yöneticisinin Rutini - Haftalık (DBA's Routine - Weekly)

Veritabanı Yöneticisinin Rutini - Günlük (DBA's Routine - Daily)

Daha önce belirttiğimiz şu ibare bu yazının odağını oluşturmaktadır: 

"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."

Bir DBA'in aylık sorumlukları daha çok uzun süreli toplanan istatistiklere ya da değişikliklere bakılarak yapılan aksiyonları içerir. Bunların neler olduğuna bir göz atalım:

Aylık Görevler

  • Haftalık görevlerde yer verdiğimiz konularda daha detaylı ve kapsamlı çalışmalar yapmak gerekir. Örneğin sadece index bozulmalarını inceleyip bakım yapmak yerine kullanılmayan indexleri de tespit edip kaldırmak gerekir. Bu çalışma sistemdeki kaynak tüketimini azaltacaktır. Üstelik bu sayede daha seyrek bakım ihtiyacı doğar. Kullanılmayan indexleri SSMS'te veritabanı üzerindeki raporlardan veya sys.dm_db_index_usage_stats nesnesinden tespit edebilirsiniz. Seek, Scan, Lookup işlemleri Update işleminden bariz şekilde daha az görünüyorsa bu index pek kullanılmıyor demektir. Sisteme yüktür. Bazen yeni indexler dikkatsizce tanımlandığında önceki indexlere gelen sorguları da cevaplar. Böylece eski indexler okumada kullanılamaz. Ancak her yapılan değişiklik indexlere yansıdığı için sürekli güncellenip bozulur. Bu da hiç ihtiyacınız olmayan bu indexlere gereksiz yere bakım yapmanıza sebep olur. Başka bir örnek de backup stratejiniz hakkında olabilir. FULL, DIFF ve LOG backupları doğru anlamak ve onları tam da gerekli olduğu zamanlarda kullanmak gerekir. Mesela LOG backupa ihtiyacınız yokken veritabanın FULL Recovery modda olmasının hiç bir faydası olmaz. Özellikle veriambarı tasarlarken çok fazla veri akış testleri yapılır. Bu esnada log sürekli büyür. Gereksiz yere kaynak tüketir. Recovery modu Simple moda çekip çalışmak bu gibi durumlarda daha avantajlı olur. Bu arada çok çeşitli yedekleme stratejileri geliştirilebilir. Veritabanın bir kısmını daha sık bir kısmını daha seyrek yedekleyebilirsiniz. Aynı anda birden fazla yere yedek alabilir. Yedeklerinizi sıkıştırabilir, şifreleyebilir, son kullanım tarihi verebilirsiniz. Doğru yedekleme stratejisi geliştirebilmek için temelde iki şeye bakılır. Ne kadar büyüklükte verinin kurtarılamamasına göz yumarım? Ne kadar zamanda sistemin ayağa kalkmasına tahammül edebilirim? Bu örneklerde olduğu gibi aylık görevlerde, haftalık görevleri daha detaylı ve kapsamlı şekilde ele almak gerekir.
  • Gereksiz yetki ve login/user ları temizlemek gerekir. Belli aralıklarla toplanan istatistiklere bakarak kullanıcıların ne sıklıkla, hangi roller ne şekilde giriş yaptığı bilinir. Bu bilgiler ışığı altında gereksiz yetki ve kullanıcıları kaldırmak en iyi seçenek olur. Özellikle sa loginin bir, iki kişide olmasına özen göstermek gerekir. sysadmin rolüne kimlerin sahip olduğunu, Yetki devretme yetkisinin kimlerde olduğunu tespit etmek ve bu yetkileri kısıtlamak gerekir. sysadmin yetkilerine sahip bir kullanıcı dilerse SQL Server içinden disklere format bile atabilir.
  • Server seviyesi konfigurasyonları ihtiyaca uygun hale getirmek gerekir. CPU, Memory kullanımı, parallelism vs. ihtiyaca uygun olarak ayarlanmalıdır. Buradaki ayarlar oldukça güçlüdür. Mesela ClrIntegrationEnabled özelliği ile .net kodlarını kullanarak kullanıcı tanımlı veritabanı nesneleri oluşturabilir, SQL Server'da yapılamayan programatik işleri yapabilirsiniz. xp_cmdshell nesnesi ile shell komutlarının SQL Server üzerinden çalıştırılmasını sağlayabilirsiniz. Buradaki konfigurasyonlar bilinçli kullanılmazsa ciddi güvenlik açığına sebep olabilir. Varsayılan olarak kapalı gelen DAC özelliğini RemoteDacEnabled seçeneğinden aktif edebilir, kimsenin giriş yapamadığı yoğunluktaki bir sisteme admin olarak her zaman giriş yapma imtiyazına sahip olabilirsiniz.
  • Veritabanı seviyesi konfigurasyonları ihtiyaca uygun hale getirmek gerekir. Veritabanlarının uyumluluk modu, recovery modu, verileri dikey veya yatay mantıkta farklı disklere ayırmak için file grouplar oluşturma seçeneği, sadece veri tabanı seviyesinde giriş yapabilen kullanıcı girişinin aktif edilmesi gibi seçenekleri ihtiyaca göre değiştirebilirsiniz.
  • Sistemin zinde kalmasını sağlamak gerekir. Disklerde yeterince boşluk oluşturulması, disklerdeki fragmantasonun azaltılması, bozulmaların giderilmesi, Windows, SQL Server, Management Studio güncellemelerinin takip edilip planlı şekilde uygulanması gerekir. I/O ve network performansı, buffer cache hit ratio, page life expectancy gibi değerler takip edilerek iyileştirmeler yapılmalıdır. Veritabanı tutarlılıkları DBCC CHECKDB gibi komutları ile kontrol edilmeli ve bozukluklar giderilmelidir. Alınan yedekleri sağlığı ve bu yedeklerden geri dönülüp dönülemeyeceği test edilmeli. Test ortamlarında felaket senaryoları, yedekten dönüş senaryoları uygulanmalıdır. Zaman zaman kullanılan nesnelerde performans iyileştirmeleri yapılabilmesi için ilgililere önerilerde bulunmak da isabetli olur. Sistemin zinde kalması için donanımın yükseltilmesi en son çare olmalıdır.
  • Tüm topolojinin ihtiyaca uygun olup olmadığını kontrol etmek gerekir. Zaman içerisinde bazı server ve veritabanları hiç kullanılmamaktadır. Bu da gereksiz lisans maliyeti demektir. Belli aralıklarla farklı serverdaki veritabanlarını aynı server altında birleştirmek mümkün olur mu diye kontrol etmek gerekir. Bazen de iş yükü çok büyüdüğü için okuma ve yazma iş yükleri farklı serverlar üzerine dağıtılır. Bu sefer de birden fazla serverı High Availbility kapsamında aynı amaç için bir araya getirme planları yapılır. SQL Server'ın yüklü olduğu serverlarda yoğun kaynak tüketen diğer programları da bulundurmaktan kaçınmak gerekir. Mesela mümkünse virüs programı kullanmamak, kullanılsa bile veritabanı dosyaları için exceptionlar oluşturmak gerekir.
  • Belli aralıklarla önceden hazırlanmış kontrol listeleri üzerinden sağlık kontrolleri yapmak gerekir. Sağlık kontrollerini belli kapsamda ve belli aralıklarla yapmak sistemin mevcut durumu ve serüveni hakkında bilgi toplamada önemli bir yere sahiptir. Özellikle test sonuçlarını raporlar haline getirmek, görsel olarak karşılaştırmak sistemi zinde tutmak için ciddi bir motivasyon oluşturur.
Son üç yazıda DBA'in günlük, haftalık ve aylık görevlerinin neler olabileceğinden bahsettik. Bu yazılarda bahsi geçen başlıklar birer öneri niteliğindedir. Bu başlıkların altında veya bu başlıklar haricinde bir çok konuda çalışma yapılabilir. Yaygın olarak yapılması gerekenler aşağı yukarı bunlardır. Konunun zenginleştirilmesi veya ihtiyacınız kadarını kullanmak size kalmış. 

DBA'in görevlerini özetlemek gerekirse; 

Bir DBA'in günlük olarak sistem hakkında üretilen bilgileri takip etmesi ve ani gelişen olaylara müdahale etmesi beklenir. Haftalık olarak takip işini bazı konular için biraz daha detaylandırır ve çalışmalarının kapsamını genişletir. Bir takım konularda da bakım yapar, iyileştirme fırsatlarını değerlendirmek üzere aksiyon planları hazırlar. Aylık olarak da daha çok sistemin uzun vadede güncel ve zinde kalması için gerekli güçlü dokunuşları yapar. Sistemi gereksiz yüklerden arındırır, daha fazla iş yükünü göğüsleyebilmek için geniş ölçekli planlar hazırlar, uygular.

Önceki yazılarımıza şu linklerden ulaşabilirsiniz:

Veritabanı Yöneticisinin Rutini - Haftalık (DBA's Routine - Weekly)



Veritabanı Yöneticisinin Rutini - Günlük (DBA's Routine - Daily)


Faydalı olması dileğiyle,

Veritabanı Yöneticisinin Rutini - Haftalık (DBA's Routine - Weekly)

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,

26 Ocak 2019 Cumartesi

Veritabanı Yöneticisinin Rutini - Günlük (DBA's Routine - Daily)

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_whosp_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,