In-Memory：記憶體優化數據的持久化和還原

數據持久化是還原的前提，沒有數據的持久化，就無法還原記憶體優化表的數據，SQL Server In-Memory OLTP的記憶體數據能夠持久化存儲，這意味著記憶體數據能夠在SQL Server實例重啟之後自動還原。在創建持久化的記憶體優化表時，必須設置選項：memory_optimized=on，durability=schema_and_data。記憶體優化表的持久化由兩個進程實現：Checkpoint和事務日誌記錄，在伺服器重啟之後，SQL Server通過存儲在磁碟上的事務日誌和Checkpoint數據，能夠將記憶體優化表還原到任意一個事務一致性的時間點。Checkpoint進程用於將數據更新寫入CheckPoint文件，縮短數據還原的時間；將數據更新寫入事務日誌文件實現事務的持久化存儲，由於任何已經提交的數據更新都被持久化存儲，因此，記憶體資料庫通過Checkpoint和事務日誌，能夠將數據寫入到持久化存儲設備，實現數據持久化，並能通過已存儲的數據還原記憶體優化表。

一，數據持久化的特性

流（Stream）是數據的Bytes流，以Append-Only方式寫入數據，這意味著，流寫入文件只能在流的末尾寫入數據。記憶體優化表的Checkpoint流和事務日誌流都是流寫入文件，流寫入方式的特點是寫入速度極快，減少了持久化數據的時間延遲。SQL Server通過把記憶體優化表的Checkpoint數據流和事務日誌流寫入Disk，實現數據的持久化存儲。

日誌流是在執行數據行版本的更新（插入和刪除）操作時，由已經提交的事務更新產生的Log Records，事務日誌流有如下特性：

• 事務日誌寫入到事務日誌文件(.ldf)中；
• 和硬碟表（Disk-based Table）不同的是，記憶體優化表的事務日誌經過優化，減少日誌記錄的數量，只存儲已提交的事務日誌，用於事務的redo操作，不存儲undo的事務日誌；
• 在事務提交時，產生事務日誌，只記錄插入和刪除的行版本事務；
• 不記錄記憶體優化表的Index Operation的事務日誌，除了Columnstore Index的壓縮階段；所有的Index都在還原時重新創建；

Checkpoint數據流由三部分組成：

• Data Stream包含插入操作的行版本數據；
• Delta Stream包含刪除操作的行版本數據；
• LOB流（Large Data Stream）包含創建ColumnStore Index時，對LOB Column進行壓縮的數據；

記憶體優化表數據存儲在一個單獨的FileGroup中，在該FileGroup下創建的File實際上是一個Directory或Container，用於存儲Checkpoint流文件；Checkpoint流文件在文件尾端順序寫入新的數據；在SQL Server中，Checkpoint文件以 FileStream方式存儲，由SQL Server負責管理文件的創建，刪除和歸併。

二，事務日誌的優化

記憶體優化表產生的事務日誌經過優化，減少了日誌記錄的數量和寫入次數。SQL Server只將最小數量的日誌寫入到事務日誌文件（.ldf）中，這體現在，事務日誌只執行Redo操作，不記錄undo事務；SQL Server把一組事務日誌合併，在一個大的Log Record中包含多條更新操作，減少了日誌寫入的次數。

1，事務日誌文件只能執行Redo操作，不記錄undo事務

SQL Server對於記憶體記憶體優化表，只將已提交事務更新寫入事務日誌文件，這樣，行版本的插入和刪除操作都被寫入到磁碟文件中，用於執行事務的redo操作，還原資料庫。由於日誌記錄在事務提交時產生，未提交的事務日誌沒有不會產生日誌記錄，事務日誌文件也不會記錄undo事務，這就減少日誌記錄的數量。

2，合併事務日誌，在一個Log Record中包含多個數據更新操作

對於記憶體優化表事務，SQL Server不使用預寫日誌機制（WAL，Write-Ahead Logging），日誌記錄只在事務提交時產生。對於WAL，SQL Server在將數據更新寫入Disk之前，先將Log Record寫入到事務日誌文件；在Checkpoint事件發生時，SQL Server會將尚未提交的事務日誌寫入到事務日誌文件中；對於記憶體優化表，未提交的日誌記錄永遠不可能寫入到磁碟，這是對日誌記錄的一個優化；此外，記憶體優化對多個數據更新分組，在一個log record中記錄多條數據更新操作，這樣做，既減少了事務日誌的總體大小和管理開銷，也減少事務日誌的寫入次數。

三，Checkpoint進程

對於硬碟表（Disk-Based Table），Checkpoint操作的作用是減少資料庫還原的時間，保持事務日誌中活動事務儘可能少；對於持久化的記憶體優化表，Checkpoint進程的作用是使數據更新被持久化寫入到磁碟，這樣，在伺服器重啟時，SQL Server能夠利用存儲在Disk上的數據還原記憶體優化表。在查詢處理的過程中，事務不會去讀取Disk上的數據，Disk上的數據只有一個作用，就是當伺服器重啟時，將數據填充到記憶體中，還原記憶體優化表。

Checkpoint進程的特點：

• 持續性（Continuous）：Checkpoint 關聯的IO操作隨著日誌活動積累而持續增加；
• 流IO（Streaming I/O）：Checkpoint文件使用流寫入方式，將數據順序寫入到文件的末尾；

Checkpoint進程同時作用在硬碟表和記憶體優化表上，執行Checkpoint操作的方式有兩種：

• 手動執行Checkpoint操作：在SSMS中顯式執行checkpoint命令，SQL Server同時對硬碟表（Disk-Based Table）和記憶體優化表（Memory-Optimized Table）執行Checkpoint操作；
• 自動執行Checkpoint操作：從上一次Checkpoint事件結束後，如果事務日誌的Size增長大約1.5GB，那麼SQL Server執行一次Checkpoint操作；事務日誌的增長用於記錄新的Log Records，在事務對硬碟表和記憶體優化表執行更新操作產生的日誌記錄；有可能，Checkpoint事件完全是由硬碟表數據的更新觸發的；

四，Checkpoint 文件

SQL Server將Checkpoint數據存儲在四種類型的文件中，分別是Data文件，Delta文件，Large Object文件和Root文件，這些文件存儲在Checkpoint文件的Container中，這個Container實際上是一個包含Memory_Optimized_Data的FileGroup的"File"。在第一次創建記憶體優化表時，SQL Server預先創建16個不同大小的空閑文件（Free Files），大小是2MB的N次方，最小8MB，最大1GB，這些文件的初始State是PreCreated。當需要使用文件時，SQL Server從Free Files集合中獲取一個大小適當的Free File，將文件的狀態由PreCreated轉換為適當的State。如果文件的State是PreCreated，文件的類型是Free。

1，初始文件的大小

在初始狀態下，SQL Server為每個文件類型至少創建3個足夠大小的Free files，共12個Free Files，每個文件類型的初始大小取決於跟伺服器的配置，不同文件的初始大小如圖：

2，Data/Delta文件對

Data 文件 和 Delta 文件是最主要的Checkpoint文件，包含了對記憶體優化表執行操作的所有更新操作的信息。由於它們總是成對出現，稱作data/delta文件對，也稱作CFP（Checkpoint File Pair），CFP只會在文件末尾順序寫入新的數據，即以Append-Only方式寫入數據，唯一的區別是寫入的行版本數據不同：

• Data 文件只存儲數據行的插入版本，在執行Insert 和Update操作時，會產生插入版本數據；
• Delta文件只存儲數據行的插入版本，在執行Delete和Update操作，會產生刪除版本數據；

Data文件和Delta文件都會覆蓋一定的時間戳範圍，從begin timestamp開始的所有行版本數據都包含在相同的Data文件和Delta文件中，在還原階段，從Data文件中讀取數據，同時，從Delta文件讀取數據，用於從Data文件中過濾數據行，避免將已經刪除的行版本重新載入到記憶體中。由於data文件和delta文件是1：1對應的，數據還原的最小單位是data/delta文件對，不同的data/delta文件對能夠併發處理。

3，LOB文件和Root文件

Large Data 文件用於存儲LOB Column的數據值，或者ColumnStore Index的行組（RowGroup）內容，如果沒有LOB column或 Columnstore Index，SQL Server仍然會預先創建Large Data文件，但是，這些文件將保持FREE狀態。

Root文件用於追蹤Checkpoint事件，每當發生Checkpoint事件時，一個新的Active root 文件將會被創建。

4，Checkpoint文件的狀態

Checkpoint 文件的5種狀態分別是：PRECREATED，UNDER CONSTRUCTION，ACTIVE，MERGE TARGET和WAITING FOR LOG TRUNCATION。SQL Server預先創建12個Free Files，初始狀態是PreCreated。在使用這些文件時，SQL Server將文件的狀態轉換為Under Construction 或 Merge Target，文件狀態的轉換過程如下圖：

通過DMV:sys.dm_db_xtp_checkpoint_files (Transact-SQL) 查看Checkpoint文件的State和類型。

五，Checkpoint文件的歸併和刪除

每次Checkpoint操作發生時，Checkpoint文件都會增加，然而，隨著時間的積累，記憶體優化表插入越來越多的行版本，越來越多的行版本被刪除，導致Data 文件和Delta文件記錄的數據量越來越多，使得讀取Data/Delta文件對的時間消耗越來越大，這會嚴重影響資料庫還原操作，增加還原的時間。

解決該問題的方案是把時間戳範圍相鄰的，未刪除數據行比例低於指定閾值的多個Checkpoint文件歸併到一個新的Checkpoint文件對中。例如，有兩個Data文件，DF1和DF2，它們的timestamp範圍相鄰，並且未被刪除的數據行比例低於指定閾值，把這兩個文件合併成一個新的data文件，DF3，該文件的時間戳範圍覆蓋原始文件DF1和DF2，是DF1和DF2時間戳範圍的並集；在做數據歸併時，核對數據文件DF1和DF2對應的delta文件，從DF1和DF2中刪除所有被標記為Delted的行版本，使DF3中只存儲Inserted的行版本數據，在歸併結束後，DF3對應的delta文件是空的。

1，自動歸併（Merge）

Checkpoin文件對歸併操作是自動進行的，SQL Server內部創建一個後臺進程，周期性地檢查所有的Data/Delta文件對，將能夠歸併的Checkpoint文件對劃分到一個集合中，使每個集合包含兩個或多個時間戳範圍連續的data/delta文件對，位於相同集合中的多個文件對必須能夠存儲在單個128MB的Data文件中，歸併的策略如下表所示：

如果兩個時間戳範圍相鄰的數據文件60%是滿的（60% Full，40%的數據行是deleted的)，那麼它們不會被Merge，每個Checkpoint文件中40%的空間將不會被使用。因此，持久化的記憶體優化表占用的總磁碟空間，比記憶體優化數據實際占用的存儲空間要大。在最差的情況下，實際占用的磁碟空間是記憶體優化數據的兩倍。

2，自動垃圾回收（Garbage Collection）

一旦Mege操作完成，原始的Checkpoint文件對將不再使用，轉換到 WAITING FOR LOG TRUNCATION 狀態，只要相應的事務日誌被截斷，那麼垃圾回收進程就開始執行清理操作，物理刪除不再使用的Checkpoint文件對。在一個Checkpoint文件對刪除之前，SQL Server必須保證這些文件不再被使用；垃圾回收進程是自動執行的，不需要任何干預，事務日誌的截斷發生的時機是：

• 備份事務日誌：進行事務日誌備份時，將截斷事務日誌文件；
• 資料庫處於auto_truncate模式：事務日誌文件只記錄活動事務的日誌，一旦事務完成，將自動截斷；

六，記憶體優化表的還原

在SQL Server實例重啟時，SQL Server 以併發執行的方式還原記憶體優化表和硬碟表數據。每一個data文件存儲的是插入的行版本數據，但是插入的行版本數據受到delta文件的過濾，每一個delta文件中存儲不需要從對應的data文件載入的數據行。SQL Server對每一個data/delta文件對進行優化配置，使數據載入進程能夠在多個IO流（IO Steam）中併發執行，每一個IO流都能單獨處理一個data/delta文件對，多個IO流同時載入數據，提高數據還原的速度。

每一個記憶體資料庫都僅有一個包含Memory_Optimized_Data的文件組（FileGroup），在該FileGroup下創建的每一個File，叫做一個Container，主要用於存儲data/delta文件對，SQL Server為每一個Container創建一個delta-map，映射每一個Data 文件中被Delta 文件過濾的數據，這樣，被刪除的數據就不會重新插入到記憶體優化表中。還原操作是流併發的，在對Container下的所有Data/Delta文件對進行流處理時，SQL Server將數據載入任務分配給所有的CPU內核，根據delta-map，併發式處理Data/Delta文件對。

一旦Checkpoint 文件載入完成，SQL Server開始讀取尾事務日誌，從上一次Checkpoing結束的時間戳（timestamp）開始，重新執行事務日誌中記錄的Insert和Delete操作，等到所有的事務日誌重新執行完成，資料庫就還原到伺服器停機的時刻，或備份操作開始的時間。在SQL Server 2016中，事務日誌的讀取和Redo操作是併發執行的，所以，數據和事務日誌都是併發操作，數據還原的過程是非常快的。

參考文檔：

SQL Server In-Memory OLTP Internals for SQL Server 2016