BACKUP THREAD, LATCH_EX ve PREEMPTIVE_OS_WRITEFILEGATHER Bekleme Tipleri

SQL Server’ın en kritik yapılarından biri olan Lock Mekanizması, ACID yapısını korumak için kritik önem taşımaktadır. Bu yazımızda günlük rutin işlerimizden birini yaparken bu mekanizmanın devreye girmesinin sebep ve sonuçları üzerinde konuşacağız.

Birçoğumuzun günlük, saatlik yada ihtiyaçlarına göre aldığı backuplar bulunmaktadır. Bu backupları ne zaman ve hangisi olacağı konusunda karar verirken veri tabanının Recovery Mode’u ile ilişkilidir. Yazıda bahsi geçen veri tabanımızın recovery modeli Full Mode ve Always On mimarisinde kullanılmaktadır. Bu problem SQL Server 2017 – CU 27 – Enterprise Edition ve Windows Server 2019 üzerinde yaşanmıştır. Aşağıdaki sunmuş olduğumuz çözüm adımları kritik adımlar olduğundan işlemleri başlatmadan önce bir profesyonelden teknik destek alınız ve danışınız.

Sisteminizde PB (Petabayt) boyutlarına yakın büyük veri tabanına sahip olduğunuzda ve bu verinin büyük kısmı imaj verisi olduğunda backup süreniz günler sürebilmektedir. Ek olarak sisteminizde gün içerisinde yoğun transaction işlemleri gerçekleşiyorsa backup süreniz daha da uzayacaktır.

Sistemimizde Backup başladıktan sonra VERIFY süresi ile birlikte aşağıdaki görselde de gördüğünüz gibi günler sürmekte ve wait type BACKUPTHREAD olarak görülmektedir. Bu bekleme tipinin sebebi ise 5 gün önce başlatmış olduğumuz backup’ın thread açarak 1’den fazla CPU’yu işgal etmesidir.

Başlatmış olduğumuz backup sistemimizde 8 adet CPU kullanmaktadır. Bu değer bizim sistemimizi configure ederken belirlemiş olduğumuz MAXDOP ayarımız ile ilişkili olmasından kaynaklıdır. Sistem hesaplamış olduğu Cost Threshold of Paralelism değerinin üzerinde ise thread değerimiz 8 olarak setlenecektir. Bu bilgiler şuanda konumuzun dışında konu hakkında detaylı bilgi öğrenmek isterseniz SQL SERVER NUMA AYARLARI adlı makaleyi inceleyebilirsiniz.

 

 

Backup işlemleri normalde sistemlerimizde kolay kolay sorun çıkarmamaktadır. Fakat bu durum diskleriniz size beklenilen I/O değerlerini karşıladığı durumda geçerlidir. Disklerinizde Yaşanılan Response Time’in çok yüksek olduğu zaman, mdf ve ldf blokları içerisinden okunan bilgiler bak dosyası içine yazılırken yavaşlık meydana gelecektir. Bu durumda hem okumada hem yazmada problem yaşamanıza sebep olacaktır.

Yazımızda bahsi geçen veri tabanının diskleri ve backupını aldığımız diskler farklı lokasyonlarda tutulmaktadır. Yaşamız olduğumuz sıkıntıda backup aldığımız diskler üzerinde response sürelerinin veri tabanının bulunduğu disklere oranla çok yüksek olduğunu gördük. Özellikle veri tabanının bulunduğu diskler üzerinde ldf disklerinin I/O yaptığını gözlemledik. Buda bize Full Backup alınırken ldf file içindeki bilgilerin yoğun bir şekilde okunduğunu göstermektedir.

Disklerin bu kadar yüksek I/O yapmasının sebebi olarak SQL Server ldf file’larını autogrowth ederken (bizde bu değer 1024MB) uzun süre beklediğini ve bunun sistemi dar boğaza soktuğunu Error Log’larından görüntüledik.

Dar boğaz anında Disk ve Error Log bilgilerine ait 3 görseli aşağıda görebilirsiniz.

I – Backup Diskleri Response Time

II – Veri tabanı Diskleri Response Time

III – SQL Server Error Log

 

Disklerde yaşan bu yüksek response süreleri beraberinde sistemde başka problemleri meydana getirdi. Yaşadığımız en büyük problemlerden biride LATCH_EX [LOG_MANAGER]. Bu bekleme türü Insert transaction anında ldf üzerinde işlem yapıldığından SQL Server Insert işlemlerini sıraya koyarak lock mekanizmasını devreye almasından kaynaklanmaktadır. Dar Boğaz anındaki bekleme türlerine baktığımızda LATCH_EX ve PARALEL_REDO_WORKER_WAIT_WORK bekleme türlerinin sistemi en çok dar boğaza soktuğunu görmekteyiz. Yaşanılan bu sıkıntı sürekli olarak artan bir şekilde değil, 1’er dakika aralıklarla ve kesikli olarak meydana gelmekte ve sistem belirli aralıkla dar boğaza girmektedir. Biz yaşanılan bu problemi backup esnasına gördük aynı sorun restore esnasında da yaşanılabilir.

 

Bu problemin çözümü için yaptığımız adımlardan;

1.Çözüm,

ldf file’ının autogrowth değerini SQL Engine tarafından 1024 MB değerinin doldurduktan sonra büyütmesi yerine 8gb, 8gb aralıklı olarak büyütüp boş page’leri hazır hale getirdik. Buradaki amacımız SQL Server’ın büyütme esnasında beklemesinin önüne geçmeye çalıştık. Bu süreç zarfında sa (SessionId = 41) kullanıcısı background işlemi yaptığını ve preemptive_os_writefilegather bekleme türü ile karşılaştığımızı gördük. Yapmış olduğumuz manuel ldf büyütme operasyonunda backup işleminden dolayı çok beklemeler olduğu ve sistemde herhangi bir düzelme olmadığını gördük.

 

2.Çözüm,

Run =>  Local Security Policy => Local Policies => User Rights Assignment => Perform volume maintenance tasks

Ekranı çift tıkla açtıktan sonra Local Security Setting içine SQL Service Hesabını eklemeniz gerekmektedir.

Servis kullanıcısını ekledikten sonra SQL Server Engine Restart gerekmektedir. Bizim sistemimiz yoğun transaction kullanıldığı için ekledikten sonra Restart etmedik. Restart ettikten sonra manuel olarak ldf file büyütme operasyonu sırasında preemptive_os_writefilegather bekleme türü ile karşılaşmayacaksınızdır. Bu operasyonları lütfen dikkatli ve uzmandan yardım alarak yapınız.

3.Çözüm,

Disk ünitesi üzerine giden port sayımız 2 adetti ve bunu 2 katına yani 4’e çıkardık. Bu operasyon sonrası diskler üzerindeki Response Time’lar 3 ms seviyelerine kadar düştü ve backup hızlı bir şekilde alınmaya başladı. Bekleme türlerinde gördüğümüz BACKUPTHREAD yerine ASYNC_IO_COMPLETION bekleme türünü yani CPU da bekleme olmadığını sadece başka bir sunucu üzerine backup almamızdan kaynaklı olarak bu bekleme türü vardı buda bizim beklediğimiz bir durum. Sistem normale döndüğü andaki bekleme tiplerine baktığımızda LATCH_EX bekleme türünün kalmadığını PARALEL_REDO_AT_WORK değerinin de makul seviyelere geldiğini gördük.

Aşağıdaki görsellerde sistemin normale dönmesi sonrası göstermiş olduğu reaksiyonları görebilirsiniz.

IV – Normal Durumda Backup Disk Response Süreleri

V – Normal Durumda Backup Bekleme Türü

 VI – Normal Durumda Bekleme Türleri