SQL Server 2019 Yenilikleri – Accelerated Database Recovery (ADR)

Bu yazıda SQL Server ailesinin en yeni üyesi SQL Server 2019 ile beraber gelen yeni bir özellikten bahsedeceğim. Bu özellik veritabanının daha hızlı geri dönüş ve kurtarmasını sağlayan Accelerated Database Recovery (ADR) özelliğidir.

SQL Server’ın yeniden başlatıldığı veya kurtarılma gerçekleştiği anda Transaction Log yapısı üç adım ile hareket eder. Her bir adımdan kısaca değinmek gerekirse;

Analysis: Bu adımda son checkpoint işleminden yeniden başlatılma anına kadar veritabanındaki transactionlar taranır ve analiz edilir.

Redo: Bu adımda log en eski işlemden okumaya başlayarak commit edilmemiş transactionları log üzerinde commit eder.

Undo: Bu adımda ise sondan geriye doğru okuma yapılır ve açık veya commit edilmemiş bir transaction olması durumunda bu işlem rollback yani geri alınır.

Resim – 1

Eğer sistem üzerinde uzun süren işlem anında beklenmedik bir kapanma veya kitlenme durumu söz konusu olduğunda veritabanını kurtarma süresi yukarıdaki adımlar baz alındığında en son çalışan işler ile doğru orantılıdır. Özellikle büyük tablolar üzerinde yapılacak DML işlemleri sırasında böyle bir kesinti durumu ile karşılaşıldığında geri dönüş süreleri bir hayli uzun olmaktadır.

Accelerated Database Recovery (ADR)
Bu özellik adından anlaşılacağı üzere hızlandırılmış bir Transaction Log mimarisini ortaya çıkmaktadır. ADR özelliği ile beraber artık transaction bağımsız bir kurtarma durumu ortaya çıkmaktadır. Bu sayede problem anında veritabanı daha hızlı onarılmakta ve geri dönüş senaryolarını gerçekleştirmektedir. ADR özelliği temel 4 bileşen ile gerçekleşir.

Persisted version store (PVS): PVS, işlem anında değiştirilen verilerin önceki sürümlerini içerir. Örneğin, bir satır üzerinde güncelleme yapıldığında, her satırın önceki sürümü PVS’ye yazılır. Bunu yapmak için veritabanının her satırına 14 baytlık bir işaretçi eklenir.

Logical Revert: İşlemin geri alınması yani rollback anında aktif transaction veriyi PVS’den okur ve daha hızlı bir şekilde rollback işlemi gerçekleşmiş olur.

sLog: sLog’da belirtilen “s” harfi Secondary yani ikincil anlamına gelir. İkincil log olarak tanımlanmaktadır. PVS’ye yazılamayan işlemler In-Memory olarak burada tutulur.

Cleaner: Belli aralıklarla PVS üzerindeki gereksiz satır sürümlerini silme işlemidir.

Resim – 2

ADR’ın çalışma yapısı ile ilgili daha detaylı bilgiye buradan ulaşabilirsiniz.

Şimdi uygulamamıza geçelim. Öncelikle bu uygulamada veritabanı olarak Microsoft’un WideWorldImportersDW isimli test veritabanını kullanacağım. İlgili veritabanına buradan ulaşabilirsiniz.

Veritabanını Restore ettikten sonra aşağıdaki script ile çalışma yapacağım tabloyu oluşturuyorum.

IF DB_NAME() != 'WideWorldImportersDW'

USE WideWorldImportersDW

SET NOCOUNT ON

GO

IF EXISTS (SELECT [object_id] FROM sys.objects (NOLOCK) WHERE [object_id] = OBJECT_ID(N'[Fact].[OrderHistory]') AND [type] IN (N'U'))

DROP TABLE [Fact].[OrderHistory];

GO

IF NOT EXISTS (SELECT [object_id] FROM sys.objects (NOLOCK) WHERE [object_id] = OBJECT_ID(N'[Fact].[OrderHistory]') AND [type] IN (N'U'))

BEGIN

SELECT [Order Key], [City Key], [Customer Key], [Stock Item Key], [Order Date Key], [Picked Date Key], [Salesperson Key], [Picker Key], [WWI Order ID], [WWI Backorder ID], [DeScription], Package, Quantity, [Unit Price], [Tax Rate], [Total Excluding Tax], [Tax Amount], [Total Including Tax], [Lineage Key]

INTO [Fact].[OrderHistory]

FROM [Fact].[Order];

END;

ALTER TABLE [Fact].[OrderHistory]

ADD CONSTRAINT PK_Fact_OrderHistory PRIMARY KEY CLUSTERED([Order Key] ASC, [Order Date Key] ASC) WITH (DATA_COMPRESSION = PAGE);

GO

-- Enlarge Table

IF (SELECT COUNT(*) FROM [Fact].[OrderHistory]) < 3702592

BEGIN

    DECLARE @i smallint

    SET @i = 0

    WHILE @i < 4

    BEGIN

        INSERT INTO [Fact].[OrderHistory] ([City Key], [Customer Key], [Stock Item Key], [Order Date Key], [Picked Date Key], [Salesperson Key], [Picker Key], [WWI Order ID], [WWI Backorder ID], DeScription, Package, Quantity, [Unit Price], [Tax Rate], [Total Excluding Tax], [Tax Amount], [Total Including Tax], [Lineage Key])

        SELECT [City Key], [Customer Key], [Stock Item Key], [Order Date Key], [Picked Date Key], [Salesperson Key], [Picker Key], [WWI Order ID], [WWI Backorder ID], DeScription, Package, Quantity, [Unit Price], [Tax Rate], [Total Excluding Tax], [Tax Amount], [Total Including Tax], [Lineage Key]

        FROM [Fact].[OrderHistory];

        SET @i = @i +1

    END;

END

GO

Tabloyu oluşturduktan sonra ADR özelliğini kapatıp ardından tüm tablo içeriğini silecek bir transaction açıyorum.

Resim – 3

Henüz commit edilmemiş açık bir transaction var. Bu sırada log kullanımına bakıyoruz. Aktif bir transaction olduğundan log kullanımının yüksek olduğunu görmekteyiz.

Resim – 4

Hatta checkpoint alıp yeniden log büyüklüğüne baktığımızda kullanımda herhangi bir değişiklik olmadığı görülmektedir.

Resim – 5

Şimdi açık olan bu transaction’I Rollback ettiğimizde işlemin 36 saniye sürdüğünü görüyoruz.

Resim – 6

İlgili silme işlemini geri aldığımız için log kullanımına baktığımızda aktif transaction ile doldurduğu alanı boşalttığını ve kullanımın düştüğünü göreceğiz.

Resim – 7

Aynı işlemi ADR özelliğini aktif ederek yapacağız. Aşağıdaki script ile ADR özelliğini açıp PVS Filegroup ekliyoruz.

USE master

GO

-- Add a new filegroup specific for the Persistent Version Store (optional)

ALTER DATABASE [WideWorldImportersDW] ADD FILEGROUP [PVS]

GO

DECLARE @adrdatafilepath VARCHAR(8000) = CAST(SERVERPROPERTY('InstanceDefaultDataPath') AS VARCHAR(4000)) + 'ADR.mdf'

DECLARE @sqlcmd VARCHAR(8000) = 'ALTER DATABASE [WideWorldImportersDW] ADD FILE ( NAME = N''ADR'', FILENAME = ''' + @adrdatafilepath + ''', SIZE = 1GB , FILEGROWTH = 65536KB ) TO FILEGROUP [PVS]'

EXEC (@sqlcmd)

GO

-- Enable ADR

ALTER DATABASE WideWorldImportersDW SET ACCELERATED_DATABASE_RECOVERY = ON ( PERSISTENT_VERSION_STORE_FILEGROUP = [PVS])

GO

Tekrar aynı silme işlemini gerçekleştiren bir transaction açıyorum.

Resim – 8

Transaction açıldıktan sonra log kullanımını kontrol ediyorum ve checkpoint işlemi gerçekleştirip yeniden kontrol sağlıyorum. Görüldüğü gibi checkpoint sonrası log kullanımında bir azalma yani log truncate işlemi gerçekleşti. Aktif bir transaction olmasına rağmen log dosyasını truncate edebildik. ADR özelliğini açtığımız ve PVS Filegroup eklemesi yaptığımız için buradaki transaction işlemindeki kayıtlar PVS file da tutuldu.

Resim – 9

Ve son olarak tekrar Rollback işlemi gerçekleştiriyorum. Aşağıda görüldüğü gibi bu işlem saniye bile sürmeden gerçekleşti.

Resim – 10

Bu yazıda SQL Server 2019 ile beraber gelen Accelerated Database Recovery (ADR) özelliğini uygulamalı olarak gösterdim. Veritabanı kurtarma ve işlem geri alma senaryolarında nasıl etkili olduğunu birlikte gördük. Gelecek yazılarda SQL Server 2019’un diğer öne çıkan yeniliklerini incelemeye ve uygulamaya devam edeceğiz.

Bu konuyla ilgili sorularınızı alt kısımda bulunan yorumlar alanını kullanarak sorabilirsiniz.

Referanslar

https://www.mshowto.org

https://docs.microsoft.com/en-us/sql/relational-databases/accelerated-database-recovery-concepts?view=sql-server-ver15

TAGs: SQL Server 2019, SQL Server 2019 yenilikleri, SQL 2019, ADR, Accelerated Database Recovery, Transaction, Rollback, Transaction-log, log, sLog