Bu makalede SQL Server2014 ile gelen bir özellik olan ilişkisel veri tabanlarının ortak bir özelliği olan Delayed Durability den bahsedeceğim.
Bu özellik hakkında detaylı bir şekilde konuşmaya başlamadan önce tekrar etmemiz gereken bir özellik var o da bir verinin yazılmasının aşamaları. Veri öncelikle log file olan .ldf dosyasına yazılmadan (log flush), data file olan .mdf veya .ndf dosyalarına yazılma işlemi (page flushing) gerçekleşmez.
Veri tabanına verinin yazılması sürecinde işlem commit edilerek bunun bilgisi kullanıcıya dönüş sağlanır ancak aksi bir durumda crash veya buna benzer durumlarda sql server veriyi log dosyasından recover edebileceği için verinin kaybolmamasının garantisini sağlamış olur. Bu aşamada makalemizin konusu olan Delayed Durability bize esneklik sağlayabilir. Kısaca açıklayacak olursak bu özellik sayesinde veri tabanına verinin yazılması sürecinde işlem commit edilmeden kullanıcıya sürecin tamamlandığı bilgisi veriliyor bu güzellik bir özellik gibi görünse de aslında bir dezavantaj aslında işlem tamamlanmış olmuyor bu özelliği kullanırken crash veya buna benzer durumlarda sql server veriyi log dosyasından recover edemeyeceği için veri kaybı riskimiz ortaya çıkmış oluyor ancak bu özellik bize işlemleri beklemeksizin veriyi yazabilme yeteneği sunar buda özelliğimizin avantajı oluyor.
SQL Server 2016 ile birlikte Always On Availability Groups (AG) yapılandırmasında daha uyumlu çalışması sağlanmıştır. Bu geliştirmeler öncesinde primary ve secondary replika arasında log kayıtlarının doğru senkronizasyonunda sorunlar yaşanabiliyordu. SQL Server 2016 ve sonrasında Transaction log senkronizasyon mekanizmasında iyileştirmeler yapıldı log girişlerinin minimum kayıpla işlenmesi için yeni bir algoritma uygulanmıştır ancak veri kaybı riski tamamen ortadan kalkmaz. Asynchronous Commit modunda primary replikada bellek üzerinde bekleyen loglar, bir crash anında kaybolabilir.
SQL Server 2016 ve 2019 geliştirmeleri ile disk I/O operasyonları ve bellek kullanımındaki gecikmeler optimize edildi. Sistem görünümü ve izleme mekanizmaları geliştirilerek Query Store ve Extended Events kullanılarak Delayed Durability işlemleri daha iyi analiz edilebilir hale getirildi.
Şimdi veri tabanı seviyesinde Delayed Durability seçeneklerine göz atalım;
ALTER DATABASE DatabaseName SET DELAYED_DURABILITY = {DISABLED | ALLOWED | FORCED }
DISABLED, Default davranış şeklidir.
ALLOWED, Durability ‘nin kullanılabilir olarak belirlenmesidir.
FORCED, veri tabanına gelen tüm transactionların Delayed Durability zorlanması anlamına gelir.
Veri tabanınızda Durability ayarlarını değiştirdikten sonra tekrar kapatabilirsiniz, aşağıdaki script örneği ile,
ALTER DATABASE DatabaseName SET DELAYED_DURABILITY = DISABLED
Görsel – 1
Görsel – 2
Veri tabanınızda Durability ayarlarını script haricinde gösterdiğim adımları takip ederekte değiştirebilirsiniz.
Ayrıca yukarıda bahsetmiş olduğumuz log file (.ldf) dosyasına yazılmadan (log flush) işlemini kontrollerini Performance Monitor üzerinden kontrollerini sağlayabilirsiniz. MSSQL$Instance: Databases menüsü altından ilgili parametreleri ekleyerek ortamlarınızda değerlerinizin kontrollerini sağlayabilirsiniz.
Görsel – 3
Delayed Durability özelliğini aktifleştirmeden önce veri tabanı üzerindeki işlemlerin memory ‘den diske yazılma işleminin tamamlanmasını tetiklemek için aşağıda belirtmiş olduğum stored procedure kullanabilirsiniz.
use DatabaseName exec sys.sp_flush_log
Delayed Durability özelliğini aktifleştirme önce kendi ortam ve senaryolarınıza göre değerlendirmenizi tavsiye ederim, Always On bulunan bir ortamınızda bunu uygulayabilirsiniz veya bulk insert yaptığınız işlemlerde kullanabilirsiniz ancak performans olarak size bir katkıda bulunmasını istiyorsanız insert işlemlerinizin daha küçük hacimli olması gerekir ki bu özellikten maksimum faydayı sağlayabilesiniz.
İlişkisel veri tabanlarının ortak bir özelliği olan Delayed Durability den bahsettik, bir sonraki makalede görüşünceye dek iyi ki varsınız, sevgiler 😊
0 Yorum