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,
Hiç yorum yok:
Yorum Gönder