記憶體最佳化資料表的還原與復原
復原或還原使用記憶體最佳化資料表之資料庫的基本機制，與僅使用磁碟資料表的資料庫類似。 但是與磁碟資料表不同之處在於，記憶體最佳化資料表必須載入記憶體中，資料庫才能供使用者存取。 這會在資料庫復原中加入一個新步驟。 資料庫復原中修改的步驟變更如下：
當SQL Server重新開機時，每個資料庫都會經歷由下列三個階段組成的復原階段：
分析階段。 在這個階段中，使用中交易記錄上會進行一個行程，用以偵測認可和未認可的交易。 記憶體中 OLTP 引擎會識別要載入的檢查點，並預先載入其系統資料表記錄項目。 另外還會處理一些檔案配置記錄檔記錄。
重做階段。 這個階段會在磁碟資料表和記憶體最佳化資料表上同時執行。
對於磁碟資料表，資料庫會移至目前的時間點，並取得未認可交易所採用的鎖定。
對於記憶體最佳化資料表，資料檔案和差異檔案組中的資料會載入記憶體中，然後根據上一個持久性檢查點更新使用中交易記錄的資料。
上述在磁碟和記憶體最佳化資料表上的作業完成時，資料庫就可供存取。
恢復階段。 在這個階段中，未認可的交易會回復。
將記憶體最佳化資料表載入記憶體中可能會影響復原時間目標 (RTO) 的效能。 為了改善從資料和差異檔案載入記憶體最佳化資料的時間，記憶體中 OLTP 引擎會平行載入資料/差異檔案，如下所示：
建立差異對應篩選。 差異檔案會儲存已刪除資料列的參考。 每個容器會有一個執行緒讀取差異檔案，並建立差異對應篩選 (記憶體最佳化資料檔案群組可包含一個或多個容器)。
將資料檔案做為資料流。 一旦建立差異對應篩選，就會使用與邏輯 CPU 數目相等的執行緒數目讀取資料檔案。 每個讀取資料檔案的執行緒都會讀取資料列、檢查相關聯的差異對應，並且只有在資料列未標示為已刪除時，才會將該資料列插入資料表。 在下述情況下，復原的這個部分可能繫於 CPU。
記憶體最佳化資料表通常能夠以 I/O 速度載入記憶體中，但是在某些情況下將資料列載入記憶體中的速度會變慢。 這些特定情況包括：
雜湊索引的值區計數過低可能會導致過多衝突，造成插入資料列的速度變慢。 這種情況通常會導致整體 CPU 使用量變得非常高，尤其是接近復原結束時。 如果您已正確設定雜湊索引，它應該不會影響復原時間。
具有一個或多個非叢集索引的大型記憶體最佳化資料表，它與值區計數大小已於建立時調整的雜湊索引不同，非叢集索引會動態成長，造成 CPU 使用量增加。
還原含有記憶體最佳化資料表的資料庫
您知道伺服器上有足夠的記憶體可還原資料庫，但需要將資料庫所需的記憶體視為現有資源集區的一部分。 您知道您無法在資料庫存在之前建立資源集區的繫結，因此您會執行使用 WITH NORECOVERY 還原。 這會造成資料庫磁碟映像的還原和資料庫的建立，但因為資料庫尚未連線，所以不會用到記憶體內部 OLTP 記憶體。
到目前為止，您可以建立資源集區與資料庫的繫結，然後使用 WITH RECOVERY 還原將已還原的資料庫連線。 由於是在資料庫連線之前發生繫結，因此會適當地佔用記憶體內部 OLTP 記憶體耗用量。 這只需要還原一次資料庫即可。 第一個 RESTORE 命令是參考用的命令，只會讀取備份標頭，而最後一個命令會在無需實際還原任何位元的情況下觸發復原。