使用内存优化表恢复或还原数据库的基本机制与仅基于磁盘的表的数据库类似。 但与基于磁盘的表不同，在数据库可供用户访问之前，必须将内存优化表加载到内存中。 这会在数据库恢复中添加一个新步骤。 数据库恢复中的修改步骤将如下所示：
当 SQL Server 重新启动时，每个数据库都会经历一个恢复阶段，其中包含以下三个阶段：
分析阶段。 在此阶段，对活动的事务日志进行扫描以检测已提交和未提交的事务。 In-Memory OLTP 引擎标识要加载和预加载其系统表日志条目的检查点。 它还将处理一些文件分配日志记录。
重做阶段。 此阶段同时在基于磁盘的表和内存优化表上运行。
对于基于磁盘的表，数据库调整到当前时间点，并获取未提交事务已获取的锁。
对于内存优化表，数据对和增量文件对中的数据将加载到内存中，然后使用基于最后一个持久检查点的活动事务日志更新数据。
当对基于磁盘的表和内存优化表执行上述作完成后，数据库可供访问。
撤消阶段。 在此阶段，将回滚未提交的事务。
将内存优化表加载到内存中可能会影响恢复时间目标（RTO）的性能。 为了改进数据和增量文件中内存优化数据的加载时间，In-Memory OLTP 引擎并行加载数据/增量文件，如下所示：
创建Delta映射筛选器。 Delta文件存储对已删除行的引用。 每个容器一个线程读取增量文件并创建增量映射筛选器。 （内存优化数据文件组可以有一个或多个容器。
流式传输数据文件。 创建增量映射筛选器后，将使用与逻辑 CPU 数目相同的线程读取数据文件。 读取数据文件的每个线程都会读取数据行，检查关联的增量映射，并且仅当此行尚未标记为已删除时，才会将该行插入表中。 恢复的这一部分在某些情况下可能受到 CPU 限制，具体如下所示。
内存优化表通常以 I/O 的速度加载到内存中，但在某些情况下，将数据行加载到内存中的速度会变慢。 具体情况包括：
哈希索引的桶计数较低可能导致冲突过多，从而使数据行插入变慢。 这通常会导致 CPU 利用率很高，尤其是在恢复结束时。 如果正确配置了哈希索引，则它不应影响恢复时间。
具有一个或多个非聚集索引的大型内存优化表，与在创建时调整存储桶计数的哈希索引不同，非聚集索引会动态增长，从而导致 CPU 使用率高。
使用内存优化表还原数据库
你知道服务器上有足够的内存来还原数据库，但要求将数据库所需的内存作为现有资源池的一部分进行考虑。 你知道，在数据库存在之前，无法创建资源池的绑定，因此执行恢复操作时使用 NORECOVERY 选项。 这会导致还原数据库的磁盘映像并创建数据库，但不会使用 In-Memory OLTP 内存，因为数据库未联机。
此时，您可以创建资源池与数据库的绑定，然后使用 RESTORE WITH RECOVERY 来使还原后的数据库上线。 由于绑定操作在数据库上线之前已就位，因此其 In-Memory OLTP 内存消耗得到正确记录。 这只需要还原数据库一次。 第一个 RESTORE 命令是一个仅读取备份标头的信息性命令，最后一个命令只会触发恢复，而无需实际还原任何位。