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