Günümüzde kullanmış olduğumuz bilgi işlem kaynakları çok çeşitlidir.

Kaynaklarımızın bu kadar çeşitli olması biz bilgi işlem yöneticileri için birçok kez avantaja bazı durumlardaysa dezavantaja dönüşmektedir.

Uygulama ve servislerimiz üzerinde yaşamış olduğumuz bir dar boğaz çoğu durumda tahmin bile etmediğimiz noktada oluşmakta ve bazen bu performans kaybını bulmak uzun eforlar harcamaktayız.

Sağlıklı bir yedekleme sonrasında servis ve uygulama sunucularımız için performans kazanımı elde edebilir sunucularımızın daha verimli ve güvenli çalışmasını sağlayabiliriz.

Geleneksel yöntemlerde yedek kullanımı, bir veri kaybı ya da bir saldırı sonrasında kullanabilecek olduğumuz bir kaskodur.

Fakat, günümüz veri tabanına sahip sunucu sistemleri daha sağlıklı çalışabilmek için düzenli bakıma muhtaçtır.

Bu bakımlar ise günümüzde, yedekleme işlemleriyle mümkün olmaktadır.

Microsoft SQL Server ve Exchange Server sunucuları. Edb ve mdf ismine sahip iki türden veri tabanı dosyasına sahiptir.

Bu veri tabanları aynı zamanda log dosyaları da bulunmaktadır.

Bir kullanıcı ya da bir sistem veri tabanı üzerinde bir değişiklik yapmak istediği zaman yapılacak olan değişiklik işlemleri öncelikle bu log dosyaları üzerinde yapılmaktadır.

Öncelikle log dosyası üzerinde değişiklik yapılmasının temelde iki nedeni bulunmaktadır. Bu nedenler performans ve güvenlik önlemleri olarak inceleyebiliriz.

Log dosyalarının veri tabanımız üzerinde performans katkıları nelerdir?

Veri tabanı dosyamız ile log dosyalarımızı bilgi işlem kaynaklarımıza benzetirsek eğer veri tabanı dosyaları sabit depolama birimleri log dosyaları ise belleğe benzemektedir.

Çalışma mantıkları da bu bilgi işlem kaynaklarından esinlenmiştir.

Bildiğiniz gibi bellekler bilgi işlem kaynaklarımız arasında yer alan ve sahip olmadığımız geçici verileri saklayan hızlı bilgi işlem kaynaklarıdır.

Veri depolama havuzları ise verilerimizi kalıcı olarak saklayan daha yavaş bilgi işlem kaynaklarıdır.

Bir tanesi geçici bir diğeri ise kalıcı verileri saklamaktadır.

Bu mantık veri tabanı sunucuları içinde geçerlidir.

Exchange Server üzerinde bir mail alış-verişi olduğu zaman veriler öncelikli olarak olay günlüklerine yazılmaktadır.

Değişiklikler direk olarak Exchange veri tabanına yazılmaz. SQL Server gibi veri ambarı sunucularımız için de durum aynıdır.

Olay günlüklerinin hızlı ya da yavaş yazılması veri tabanına sahip sunucuların performansına etki etmektedir.

Kalıcı veriler veri tabanına yazılmadan önce olay günlüklerine yazılmaktadır.

Bu özellik aynı zamanda veri tabanı güvenliği için düşünülmüş ikinci nedendir.

Çalışma hayatım içinde birçok kez karşılaştım. Log dosyalarının aşırı derece büyümesi ve çok fazla olay günlüklerinin oluşması.

Bu durum büyük bir işlemin oluşması sonrasında olabileceği gibi bir saldırı bir zafiyet sonrası da mümkündür.

Olay günlük mimarisini performans ve güvenlik için kullansak bile saldırganlar içinde bir saldırı kapsısıdır.

Olay günlüklerinin devasa büyüklükte oluşması ve hızlı bir şekilde büyümeleri veri tabanlarının tutarlı bir şekilde çalışmasına da engel olacaktır.

Bu sebepten olay günlük tasarımlar da iyi planlanmalıdır.

Tutarlı, performanslı ve sağlıklı veri tabanları için olay günlüklerinin iki yedekleme zamanı içinde ne kadar büyüyeceğini planlamalıyız.

Bu plan çerçevesinde uygun hızda ve kapasitede veri depolama havuzlarını ayırmamız gerekmektedir.

Aynı zamanda bir yedekleme görevinin başarısız olması durumunda olay günlüklerinin de temizlenmeyeceğini bilmeli ve hata durumuna karşı hazır durumda bekleyen kapasiteleri de planlarımıza eklemeliyiz.

Tutarlı Veri Tabanı için Olay Günlükleri yüksek öneme sahiptir ve yedekleme yazılımları da bu olay günlüklerini düzenli olarak temizleyen ve veri tabanına yazmak ve bakımlarını gerçekleştirmek için tasarlanmış yazılımlardır.