Accelerated database recovery (ADR) – New feature in SQL 2019

SQL Engine’in kurtarma işlemi (recovery processing) uzun süreli transaction’lar için gözden geçirilmiş ve yeniden yapılandırılmıştır.

ADR kullanılmadığında rollback işleminin nasıl yapılır?

Rollback işlemi için, son commit edilmemiş işlemden itibaren log dosyası taranarak, yapılan değişiklikler geri alınmaktadır.

*Görsel orjinal microsoft dökümanından alınmıştır.

Accelerate database recovery nedir?

ADR rollback işlemlerinin daha hızlı tamamlanması için 4 yeni bileşeni kapsayan bir yapıdır. Bu bileşenler üzerinden recovery proccesing’in nasıl hızlandırıldığını inceleyelim.

  • Persisted version store (PVS): ADR ile birlikte SQL Engine yapılan DML işlemleri üzerinde ilgili veritabanında satır versiyonlama (row versioning) işlemi yapılmaktadır, PVS ise bu versiyonların tutulduğu kısımdır. PVS sayesinde üzerinde rollback yapılan işlemlerin kilitlenmeden okunabilirliği sağlanmaktadır.
  • Logical Revert: PVS üzerindeki satır versiyonlama yapılmış işlemleri geri alan asenkron process.
  • sLog (secondary in-memory log): Normal log dosyası akışı yanı sıra memory üzerinde ikincil bir log’lamanın yapıldığı kısımdır. Satır versiyonlama yapılmamış veriler tutulmaktadır.
  • Cleaner: Belirli aralıklarla versiyonlanan satırların, satır versiyonlarını kaldıran process.

*Görsel orjinal microsoft dökümanından alınmıştır.

Bileşenler sayesinde log dosyası üzerinde son checkpoint’e kadar olan (non-row-versioning data) kayıtlar sLog üzerinden, son checkpoint’ten son commit edilmemiş işleme kadar olan kısımdaki (row-versioning data) kayıtlar PVS üzerinden okunarak recovery işlemi tamamlanır.

Demo

Demo script’ine buradan ulaşabilirsiniz.

Yeni bir veritabanı oluşturuyor ve ADR özelliğini kapalı hale getiriyorum.

Bir transaction başlatarak, (sürelerde belirgin farklar olması için) 10m+ satır update ediyorum.

43~ saniyede işlem tamamlandı ancak henüz commit etmedim ve geri alma işlemini görmek için ROLLBACK komutunu çağırıyorum.

ROLLBACK işlemimiz 53~ saniyede tamamlandı.

Şimdi de başka bir veritabanı oluşturarak ADR özelliğini aktif ederek aynı işlemleri tekrarlıyorum.

Aynı kayıt sayısı güncellemiş olmamıza rağmen okunan sayfalar ve işlem süresi (ADR açık olduğunda) artmaktadır.

Ancak ROLLBACK işlemimiz çok işi bir şekilde optimize edilerek 0ms’de tamamlanmıştır.

Aynı update işlemlerini transaction açarak yaptıktan sonra ROLLBACK yerine SQL Service’i restartlayıp, olası bir down durumunu simüle ettiğimde;

ADR açık olmayan veritabanı için:

ADR açık olan veritabanı için:

İşlemler sonrasında Data ve Log dosyalarımızın durumları aşağıdaki gibidir.

ADR beraberinde getirdiği bileşenlerle birlikte veritabanı üzerinde uygulanan transaction’ların maliyetinin artmasına sebep olurken ve recovery işleminin hızlanmasını sağlamaktadır.

Hangi tip veritabanlarında ADR kullanılmalıdır?

  • Uzun süreli DML işlemlerinin uygulandığı
  • Aktif transaction’ların log dosyasının büyümesine sebep olduğu,
  • Recovery süresi uzun olduğu için bir süre veritabanı kullanılmaması kabul edilemeyen

veritabanları üzerinde kullanılabilir.

Yorum Gönderin

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

This site uses Akismet to reduce spam. Learn how your comment data is processed.