عملکرد Checkpoint در سیستم‌های Disk-Based و In-Memory OLTP

مقدمه

SQL Server بعد از یک خاموشی غیر منتظره یا Crash و در طی پروسه Recovery، اعمال تغییراتی که درون لاگ فایل ثبت شده اند را از چه نقطه‌ایی آغاز می‌نماید؟ از LSN مربوط به آخرین Checkpoint که در Database Boot Page ثبت شده است.
Checkpoint به عنوان یک نقطه خوب شناخته شده است، که SQL Server می‌تواند در هنگام پروسه Recovery اعمال تغییراتی که درون لاگ فایل ثبت شده‌اند را از آن نقطه آغاز نماید.
جهت افزایش سرعت SQL Server تغییرات مربوط به Database Pages را درون Memory و Buffer Cache انجام می‌دهد و بعد از هر تغییر، Pageها را روی Disk نمی‌نویسد. در عوض Database Engine به صورت دوره ایی دستور Checkpoint را صادر می‌نماید.
هدف Checkpoint کاهش مدت زمان Database Recovery در صورت رخ دادن Crash می‌باشد.
هنگامی که Checkpoint رخ می‌دهد صرف نظر از اینکه چگونه این دستور صادر شده است (به صورت Manual، Automatic و … انواع Checkpoint در ادامه توضیح داده خواهد شد.) مجموعه اعمال زیر انجام می‌شوند:
۱- همه صفحات تغییر یافته داده یا اصطلاحا Dirty Data File Pages بر روی Disk نوشته می‌شوند. در واقع همه صفحات تغییر یافته درون Memory از زمانی که از روی Disk خوانده شده‌اند و در Memory قرار گرفته‌اند، یا در Memory بوده‌اند و از زمان آخرین Checkpoint به بعد تغییر یافته‌اند، بدون توجه به وضعیت Transaction که آن‌ها را تغییر داده است روی Disk نوشته می‌شوند.
۲- قبل از اینکه یک Page روی Disk نوشته شود همه لاگ رکوردها، شامل آخرین لاگ رکوردی که اخیرا ایجاد شده و تغییرات Page را توصیف می‌کند بر روی Disk نوشته می‌شوند. (لاگ رکوردها هم ابتدا درون Memory قرار دارند.) در واقع هر تغییر Data Page قبل از اینکه نهایی شود و انجام آن تغییر به کاربر اعلام گردد ابتدا لاگ رکورد مربوط به آن روی Disk نوشته می‌شود.
به این مکانیسم Write Ahead-Logging یا WAL گفته می‌شود و این مکانیسم Recovery را تضمین می‌نماید.
۳- به ازای خود Checkpoint نیز لاگ رکورد ایجاد می‌گردد.
۴- LSN مربوط به Checkpoint در درون Data Boot Page و فیلدی به نام dbi_checkptLSN ثبت می‌گردد.
۵- در حالت Simple Recovery Model در واقع VLFهای درون Log File بررسی می‌شوند تا مشخص گردد که کدام VLFها می‌توانند Inactive در نظر گرفته شوند.
Checkpointها واقعا از درون Transaction Log ردیابی نمی‌شوند. نوشته شدن اطلاعات مربوط به آن‌ها در لاگ، در واقع به خاطر نگهداری اطلاعات مربوط به Active Transactions (تراکنش‌های فعال) در هنگام Checkpoint می‌باشد.

LSN مربوط به آخرین Checkpointدر درون Database Boot Page ثبت می‌شود. این جایی است که Recovery آغاز می‌شود و اگر این Page در دسترس نباشد Database نمی‌تواند Attach شود، Open شود یا هر پردازش دیگری روی آن صورت گیرد. Boot Page شامل اطلاعاتی مربوط به اینکه Database به صورت Clean در واقع Shut Down شده است یا خیر، نیز می‌باشد

Database Recovery Process

هنگامی که یک Instance از SQL Server استارت می‌شود پروسه Recovery را بر پایه Last Checkpoint به ازای هر Database اجرا می‌نماید.پروسه Recovery شامل سه فاز است:
۱- Analysis: در این قسمت ابتدا Log Log File از آخرین Checkpoint به جلو خوانده می‌شود و قدیمی ترین Dirty Page و نیز وضعیت همه تراکنش‌ها در هنگامی که سرویس SQL Server متوقف شده است تعیین می‌گردد.
۲- Redo: تمامی تراکنش‌هایی که در لاگ فایل Commit شده‌اند اما در Data File نوشته نشده‌اند، در Data File نیز نوشته می‌شوند. (اصطلاحا Rollforward)
۳- Undo: در این قسمت از انتهای لاگ فایل به سمت عقب خوانده می‌شود و همه تراکنش‌هایی که هنوز باز هستند و یا Commit نشده‌اند Rollback می‌گردند

انواع CheckPoint

۱- Automatic Checkpoint:به صورت خودکار و در Background صادر می¬شود. Automatic Checkpoint زمانی اتفاق می‌افتد که Database Engine تخمین بزند تعداد لاگ رکوردها به میزانی رسیده است که مدت زمان مورد نیاز جهت پردازش آن‌ها نزدیک به مدت زمان تعیین شده در در قسمت Recovery Interval می‌باشد.
Recovery Interval یک گزینه است که به ازای Instance تنظیم می‌شود و تعیین می¬نماید که یک Database برای Recover شدن چقدر باید زمان بگیرید. مقدار پیش فرض برای این گزینه برابر با صفر است و بدین معنی است که Database Engine به صورت اتوماتیک تنظیم مربوط به Recovery Interval را انجام می‌دهد. عموما Automatic Checkpoint هر یک دقیقه به ازای دیتابیس‌های فعال رخ می‌دهد و بنابراین مدت زمان Recovery کمتر از یک دقیقه خواهد بود.
با استفاده از SP_Configure می‌توان مقدار پیش فرض را به ازای Recovery Interval تغییر داد اما این کار توصیه نمی‌شود مگر اینکه به تجربه دریابیم که تغییر این گزینه می‌تواند به بهبود Performance کمک نماید. در صورت تغییر نیز باید میزان تغییر کم باشد و جهت تغییر مجدد باید ارزیابی صورت گیرد.

نکته مهم: در یک سیستم با تراکنش‌های کوتاه Recovery Interval فاکتور اصلی جهت تعیین نمودن مدت زمان Database Recovery می‌باشد. Recovery Interval تاثیری بر مدت زمان مورد نیاز جهت Undo نمودن Long-Running Transaction ندارد. Recovery شدن یک دیتابیس با وجود Long-Running Transaction می‌تواند مدت زمان بسیار بیشتری نسبت به زمان تعیین شده در قسمت Recovery Interval نیاز داشته باشد.
نکته: Automatic Checkpoint فقط به ازای دیتابیس‌هایی در نظر گرفته می‌شود که Default Target Recovery Time به ازای آن‌ها برابر صفر باشد.
۲- Indirect Checkpoint: در SQL Server 2012 معرفی شد و این امکان را فراهم می‌سازد که تنظیم مربوط به Checkpoint به ازای دیتابیس قابل انجام باشد و این کار با مشخص نمودن Target Recovery Time به ازای یک Database امکان پذیر است. Indirect Checkpoint در صورت رخ دادن Crash مدت زمان مورد نیاز جهت Recovery را با دقت بالاتر قابل پیش بینی می‌سازد.
Recovery Interval از تعداد Transactionها جهت تعیین مدت زمان Recovery استفاده می‌نماید اما Indirect Checkpoint از تعداد Dirty Pageها استفاده می‌کند و اطمینان می‌دهد که مدت زمان Recovery در محدوده تعیین شده می‌باشد. البته بحث مربوط به Long-Running Transactionها در اینجا نیز وجود دارد.
نکته: در سیستم‌های که عملیات DML به شدت در آن‌ها زیاد است Background Writer به شدت داده‌های تغییر یافته در Buffer را بر روی دیسک می‌نویسد، به منظور اینکه مدت زمان Recovery در محدوده Target Recovery Time تعیین شده برای Database باشد. این موضوع می‌تواند در سیستم باعث مشکلات مربوط به I/O شود )در صورتی که میزان I/O سیستم به حد آستانه نزدیک گردد.)

Indirect Checkpoint به ازای Databaseهایی که در SQL Server 2016 ایجاد می‌شوند به صورت پیش فرض فعال است اما به ازای Databaseهایی که از ورژن‌های قبل بر روی SQL Server 2016 ریستور می‌شوند رفتار به صورت Automatic Checkpoint می‌باشد یعنی Target Recovery Time برابر با صفر است.
با استفاده از دستور زیر می‌توان Indirect Checkpoint را به ازای یک Database فعال نمود

ALTER DATABASE Test SET TARGET_RECOVERY_TIME = 60 SECONDS WITH NO_WAIT

۳- Internal Checkpoint: در پاسخ به رویدادهایی مانند اجرای دستور Backup،حذف و اضافه نمودن فایل به دیتابیس، ایجاد Database Snapshot و … رخ می‌دهد.
۴- Manual Checkpoint
تا اینجا ما به معرفی Checkpoint، هدف و کارهایی که انجام می‌دهد و نیز بررسی انواع Checkpoint پرداختیم. اکنون می‌خواهیم به بررسی Checkpoint در سیستم‌های In-Memory OLTP بپردازیم.

نحوه ذخیره سازی داده‌ها در Memory Optimized Tables

داده‌هایی که در جداول Durable Memory Optimized ذخیره می‌شوند اصطلاحا Dual Nature هستند، یعنی علاوه بر Memory روی Disk نیز ذخیره می‌شوند.
داده‌های این جداول جدا از داده‌های جداول Disk-Based ذخیره می‌گردند. SQL Server از مکانیسمی جهت ذخیره سازی داده‌های جداول Memory Optimized استفاده می‌کند که بر پایه تکنولوژی Filestream است. اگر چه In-Memory OLTP و Filestream هر کدام Filegroup خودشان را نیاز دارند.
جداول Disk-Based آخرین نسخه یک رکورد را نگه می‌دارند اگر چه آن رکورد چندین بار در زمان‌های مختلف بروزرسانی شود.
عمل Delete، رکورد را از Database پاک می‌کند و درج نیز رکورد را به Database اضافه می‌نماید.
In-Memory OLTP چندین نسخه از رکورد را روی دیسک ذخیره می‌نماید. بروزرسانی‌های متعدد یک ردیف داده چندین ردیف ایجاد می‌نماید که هر کدام Lifetime متفاوت دارند و SQL Server آن‌ها را به فایل‌هایی که در Container مربوط به In-Memory OLTP Filegroup قرار دارند در واقع Append می‌نماید. به هر جفت از این فایل‌ها یک Checkpoint File Pairs (CFP) گفته می‌شود.
CFP ها جهت افزایش Performance لود داده از دیسک به Memory در هنگام بالا آمدن Database و همچنین جهت ماندگاری (Durability) داده ها مورد استفاده قرار می‌گیرند.
همان طور که گفته شد هر CFP شامل دو فایل است که عبارتند از Datafile و Deltafile.
هنگامی که یک رکورد را درج می‌نماییم این رکورد در Data File ذخیره می‌شود.
هنگامی که یک رکورد حذف می‌شود اطلاعات رکورد حذف شده در Delta File ذخیره می‌گردد.
Update یک رکورد شامل دو عملیات است، یک درج و یک حذف که اطلاعات مربوط به آن‌ها در هر دو فایل ذخیره می‌شود.
همانطور که قبلا اشاره شد SQL Server جهت افزایش Performance تغییرات مربوط به داده‌ها را درون Memory انجام می‌دهد و بعد از هر تغییر، دادها را روی Disk نمی‌نویسد و نیز جهت ایجاد ماندگاری برای داده‌ها، قبل از اینکه Dataها را روی Disk بنویسد ابتدا لاگ مربوط به آن ها را می‌نویسد.

نوشتن لاگ رکوردها در In-Memory OLTP نسبت به Storage Engine بسیار کارآمدتر است. در نگاه اول In-Memory OLTP می‌تواند Throughput مربوط به Transactionها را به شکل قابل ملاحظه‌ایی افزایش دهد و این موضوع به نوبه خود ممکن است باعث Bottleneck شدن IO لاگ شود.
اما موضوع به همین جا ختم نمی‌شود فرمت نوشتن لاگ رکوردها و نیز الگوریتم مربوط به آن‌ها در سیستم In-Memory OLTP متفاوت است.
هنگامی که یک رکورد را به جدول Disk-Based که شامل Clustered Index و NonClustered Index می‌باشد درج می‌کنیم لاگ مربوط به آن رکورد به ازای هر ایندکس به صورت جداگانه نوشته می‌شود. بعلاوه به ازای عملیات‌های Internal مانند تخصیص فضا و Page Split نیز لاگ نوشته می‌شود. به ازای هر تغییر در جداول Disk-Based لاگ مربوط به آن تغییر به صورت Synchronous نوشته می‌شود، اگر چه هر Database دارای یک Log Buffer می‌باشد که از آن جهت نوشتن Log Recordها به صورت Batch استفاده می‌نماید، اما ظرفیت Log Buffer محدود است (۶۰ KB) و نیز عملیات‌هایی مانند Commit و Checkpoint در واقع داده‌های Log Buffer را بدون توجه به پر نبودن آن بر روی دیسک می‌نویسند.
در جداول Disk-Based اگر یک رکورد را آپدیت نماییم SQL Server ورژن قبل از آپدیت رکورد را جهت عملیات Undo و ورژن بعد از آپدیت رکورد را جهت عملیات Redo در لاگ فایل ثبت می‌نماید.
کد و تصویر زیر نشان می‌دهند که در جداول Disk-Based همزمان (Synchronous) با هر تغییر لاگ مربوط به آن تغییر نوشته می‌شود.

Use Master
GO
Create Database DiskBaseDB
GO
Use DiskBaseDB
GO
Create Table Employees
(ID Int Not Null, Fname Varchar(10) Not Null)
GO
Insert Into Employees Values (1, 'Mehdi')
GO
CheckPoint
GO 3
Begin Transaction
 Insert Into Employees Values (2, 'Paul')
Select [Current LSN], Operation, Context, [Transaction Name], [Transaction ID], AllocUnitName From sys.fn_dblog(Null, Null)

در In-Memory OLTP لاگ رکوردها در زمان Commit شدن تراکنش ایجاد و ذخیره می‌شوند و بنابراین Rollback نمودن یک تراکنش هیچ لاگ رکوردی را ایجاد نمی‌نماید. کد و تصویر زیر این موضوع را به خوبی نمایش می‌دهد:

Use Master
GO
Create Database OLTPDB On Primary
(Name = OLTPDB, FileName = N'D:\Databases\Data\OLTPDB.mdf'),
Filegroup FGInmom Contains Memory_Optimized_Data
(Name = OLTPDBInmom, FileName = N'D:\Databases\OLTPDB')
Log On
(Name = OLTPDBLog, FileName = N'D:\Databases\Data\OLTPDB.ldf')
GO
Use OLTPDB
GO
Create Table Employees
(ID Int Not Null Identity (1,1) Primary Key Nonclustered Hash With (Bucket_Count = 8),
 Fname Varchar(10) Not Null)
With (Memory_Optimized = On)
GO
Checkpoint
GO 10
Begin Transaction
 Insert Into Employees Values ('Mehdi')
Rollback
Select [Current LSN], Operation, Context, [Transaction Name], [Transaction ID], AllocUnitName From sys.fn_dblog(Null, Null)

همان گونه که در تصویر زیر مشاهده می‌نمایید هیچ لاگ رکوردی به ازای تراکنش Rollback شده ثبت نشده است.همچنین مثال فوق ثابت می‌نماید که به ازای تغییرات Commit نشده هیچ اطلاعاتی در Log File جهت استفاده در مرحله Undo ثبت نمی‌شود و در In-Memory OLTP اصلا مرحله Undo در هنگام Recovery وجود ندارد، بنابراین فرمت نوشتن لاگ رکوردها در In-Memory OLTP متفاوت است. در واقع همه تغییرات داده در In-Memory OLTP در یک یا تعداد کمی لاگ رکورد ترکیب می‌شوند ( بستگی به اندازه رکوردها دارد).
کد و تصویر زیر نشان می‌دهند که به ازای درج هزار رکورد در یک جدول Memory Optimized تعداد کمی لاگ رکورد درون لاگ فایل ثبت می گردد.

Use OLTPDB
GO
CREATE TABLE PHONENUMBERS
(
ID INT NOT NULL,
PHONENUMBER INT NOT NULL,
CONSTRAINT PK_PHONENUMBERS PRIMARY KEY NONCLUSTERED HASH(ID) WITH (BUCKET_COUNT = 4096),
)
WITH (MEMORY_OPTIMIZED=ON, DURABILITY=SCHEMA_AND_DATA);
GO
CHECKPOINT
GO 6
SET NOCOUNT ON
GO
DECLARE
@I INT = 1
BEGIN TRAN
WHILE @I <= 1000
BEGIN
INSERT INTO PHONENUMBERS WITH (SNAPSHOT)
(ID, PHONENUMBER)
VALUES(@I, Cast(RAND() * 10000 as int) );
SET @I += 1
END
COMMIT
GO
SELECT [Current LSN], Operation, Context, [Transaction ID], AllocUnitName FROM SYS.FN_DBLOG(NULL, NULL)
ORDER BY [CURRENT LSN];

اکنون مثال فوق را به ازای یک جدول Disk-Based انجام می‌دهیم و مشاهده خواهید نمود که لاگ رکوردهای زیاد ایجاد خواهد شد.

Use OLTPDB
GO
Drop Table If Exists PHONENUMBERS_DiskBased
CREATE TABLE PHONENUMBERS_DiskBased
(
ID INT NOT NULL,
PHONENUMBER INT NOT NULL,
CONSTRAINT PK_PHONENUMBERS_DiskBased PRIMARY KEY Clustered (ID),
)
GO
CHECKPOINT
GO 6
SET NOCOUNT ON
GO
DECLARE
@I INT = 1
BEGIN TRAN
WHILE @I <= 1000
BEGIN
INSERT INTO PHONENUMBERS_DiskBased
(ID, PHONENUMBER)
VALUES(@I, Cast(RAND() * 10000 as int) );
SET @I += 1
END
COMMIT
GO
SELECT [Current LSN], Operation, Context, [Transaction ID], AllocUnitName FROM SYS.FN_DBLOG(NULL, NULL)
ORDER BY [CURRENT LSN];

نکته مهم: در جداول Memory Optimized ایندکس‌های Regular یا ایندکس‌هایی که به شکل Columnstore نیستند روی Disk ذخیره نمی‌شوند و در واقع هر زمانی که داده‌های مربوط به جداول Memory Optimized به دورن حافظه Load شوند این ایندکس ها Re-Create می‌گردند.

عملکرد Checkpoint در سیستم In-Memory OLTP

Disk-Based Checkpoint و In-Memory OLTP Checkpoint دو پردازش کاملا جدا از هم هستند اگر چه هدف هر دو آن ها ذخیره تغییرات داده روی Disk و کاهش مدت زمان Recovery می‌باشد. آخرین Checkpoint مشخص می‌نماید که تا کدام نقطه داده‌های تغییر یافته روی دیسک ذخیره شده‌اند و کدام لاگ رکوردها نیاز به پردازش دارند. (مراحل Database Recovery توضیح داده شد. توجه داشته باشید که در In-Memory OLTP مرحله Undo وجود ندارد).
در In-Memory OLTP عمل Checkpoint به طور مداوم Transaction Log را Scan و تغییرات را به Checkpoint File Pairs در واقع Append می‌نماید.
هر ردیف جدید (نسخه جدید از یک ردیف) به Data File و هر ردیف حذف شده به Delta File ضمیمه می‌گردد.
پس توجه داشته باشیم که In-Memory OLTP Checkpoint بر پایه Transaction Log Recordها عمل می‌نماید و این متفاوت است از Storage Engine Checkpointکه Dirty Pages را ازBuffer Pool تشخیص می‌دهد و آن‌ها را بر روی Disk می‌نویسد.

In-Memory OLTP در واقع عمل Continuous Checkpoint را پیاده سازی می‌کند که این عمل در SQL Server 2014 به صورت Single-Threaded و در SQL Server 2016 به صورت Multithreaded می‌باشد که این حالت بسیار کارآمدتر است.
Automatic Checkpoint برای Memory Optimized Table زمانی اتفاق می‌افتد که میزان Log ایجاد شده برابر با ۱.۵ GB از زمان آخرین Checkpoint باشد. (ما درباره سیستم OLTP بحث می‌نماییم که به شدت زیر بار عملیات Insert و DML است و شرط مذکور مدام رخ می‌دهد).
در Disk-Based Table به ازای Recovery Model Full بعد از گرفتن Transaction Log Backup لاگ فایل Truncate می‌شود. (جزئیات این بحث خارج از موضوع مقاله می‌باشد).
اما اگر Memory Optimized Table داشته باشیم Transaction Log Backup لزوما باعث Truncate شدن لاگ فایل نمی‌شود بلکه Checkpoint هم نیاز است.
بیاید این قضیه را اثبات نماییم؛ برای اثبات این موضوع ما از Manual Checkpoint استفاده می‌کنیم و ابتدا یک Database که فقط دارای جدول Disk-Based است ایجاد می‌نماییم

CREATE DATABASE [InMemoryOLTP] ON PRIMARY
(NAME = N'IMOLTP', FILENAME = N'D:\Databases\Data\InMemoryOLTP.mdf'),
FILEGROUP [IMOLTP_InMemory] CONTAINS MEMORY_OPTIMIZED_DATA DEFAULT
(NAME = N'IMOLTPInMemory', FILENAME = N'D:\Databases\Data\InMemoryOLTP')
LOG ON
(NAME = N'IMOLTPLog', FILENAME = N'D:\Databases\Data\InMemoryOLTP.ldf')
GO
USE InMemoryOLTP
GO
CREATE TABLE SalesOrder_Diskbased
(
order_id int identity not null Primary Key Clustered,
order_date datetime not null,
order_status tinyint not null,
amount float not null
)

سپس جهت اینکه Log Chain ایجاد شود و Log Recordها تا زمان Transaction Log Backup نگه داشته شوند یک Full Backup از Database می‌گیریم:

Backup Database InMemoryOLTP To Disk = N'D:\Databases\Backup\InMemoryOLTP.bak'

اکنون با استفاده از داده های فرضی جدول SalesOrder_Diskbased را پر می‌نماییم:

اکنون با استفاده از داده های فرضی جدول SalesOrder_Diskbased را پر می‌نماییم:
Declare @order_status tinyint = 1,
@amount float = 1000,
@OrderNum int = 30000,
@counter int = 1
Set Nocount On
WHILE @counter <= @OrderNum
BEGIN
INSERT INTO SalesOrder_Diskbased values(getdate(),@order_status,@amount)
SET @counter= @counter+1
END
GO

تصویر زیر درصد استفاده از لاگ را به ازای دیتابیس InMemoryOLTP نمایش می‌دهد: (دیتابیس هنوز شامل جدول Memory Optimized نمی‌باشد)همان گونه که در تصویر مشاهده می‌شود درصد استفاده از لاگ به ازای دیتابیس InMemoryOLTP تقریبا ۸۶ درصد می‌باشد.
در این مرحله یک Transaction Log Backup از دیتابیس می‌گیریم و مجدد درصد استفاده از لاگ را مشاهده می‌نماییم:

Backup LOG InMemoryOLTP To Disk = N'D:\Databases\Backup\InMemoryOLTP.trn'

در تصویری که در ادامه می آید مشاهده می‌شود که بعد از گرفتن Transaction Log Backup درصد استفاده از لاگ به ازای دیتابیس InMemoryOLTP به ده درصد کاهش یافته است.در ادامه یک Memory Optimized Table ایجاد می‌نماییم:

CREATE TABLE dbo.SalesOrder_MemOpt
(
order_id int identity not null,
order_date datetime not null,
order_status tinyint not null,
amount float not null,
Constraint PK_SalesOrderID PRIMARY KEY NONCLUSTERED HASH (order_id) WITH (BUCKET_COUNT = 15000000)
) WITH ( MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA)
GO

سپس با استفاده از Natively Compiled Stored Procedure زیر، ده میلیون رکورد را به جدول SalesOrder_MemOpt درج می‌نماییم.

Create Procedure USP_InsertSalesOrder_Native
With Native_Compilation, Schemabinding, Execute As Owner
As
Begin Atomic
 With (Transaction Isolation Level = Snapshot, Language = N'us_english')
Declare @order_status tinyint = 1,
@amount float = 1000,
@OrderNum int = 10000000,
@counter int = 1
WHILE @counter <= @OrderNum
BEGIN
 INSERT INTO dbo.SalesOrder_MemOpt values(getdate(),@order_status,@amount)
 SET @counter= @counter+1
END
End

تصویر زیر حجم لاگ تولید شده را نشان می دهد و درصد میزان استفاده از لاگ تقریبا ۹۳ درصد می‌باشد. همان طور که مشاهده می‌نمایید میزان لاگ ایجاد شده کمتر از ۱.۵ GB است بنابراین Automatic Checkpoint اتفاق نمی‌افتد.اکنون از دیتابیس Log Backup می‌گیریم و درصد استفاده از لاگ را مشاهده می‌نماییم:

Backup LOG InMemoryOLTP To Disk = N'D:\Databases\Backup\InMemoryOLTP_2.trn'

همان طور که در تصویر مشاهده می‌شود برخلاف Disk-Based Table عمل Truncate لاگ فایل رخ نداد.
در In-Memory OLTP عمل Truncate شدن Log File علاوه بر Log Backup به Checkpoint هم نیاز دارد. اکنون ابتدا یک Manual Checkpoint را اجرا و مجدد یک Log Backup می‌گیریم و سپس درصد استفاده لاگ را مشاهده خواهیم نمود. (تصویر زیر)درصد استفاده از Log به دو درصد کاهش یافته است.
نکته: در مثال فوق ما به بررسی وضعیت ستون log_reuse_wait_desc در sys.Databases نمی‌پردازیم. همچنین وضعیت‌های مختلف CFP و جزئیات پروسه Recovery در In-Memory OLTP نیاز به یک مقاله دیگر دارند و مقاله جاری بسیار طولانی شده است