对内存表不了解的同学可以参考我之前写的学习笔记：
学习笔记1--内存优化表介绍
SQL学习笔记2--内存优化表索引简介
- - - - - - - - - - - - - - - - - - - - - - - - -文本开始 - - - - - - - - - - - - - - - - - - - - - - - - - -------------
本来想写内存表的备份和恢复，但是写到一半，发现事务涉及到的部分太多，所以单独开一篇文章写事务，篇幅会比较短，但这是理解内存表备份和恢复机制的基础。
有两种类型的内存表。 一种是内存表，只存在于内存中，与磁盘和日志无关。 此类表在备份和恢复时只处理表结构，不处理数据。 与中的表类似，不同的是，当数据库重新启动时，前者保留表结构，而后者不留下任何渣。
另一种内存表在磁盘上有相应的数据文件用于数据持久化，MS称之为“数据和差异文件”。 这部分文件是通过一个称为“离线检查点”的后台线程定期读取事务日志来写入数据的。 所以，它得到的并不是第一手的变化，而是日志文件中记录的变化。
下面说一下事务日志和内存表的关系。 谈到这种关系，就涉及到2014年的一个新概念：延迟交易。 延迟事务机制允许您在事务提交时通过设置指定选项来选择是否异步写入日志。 这意味着什么？ 传统的磁盘表中，数据页和日志是一起写入的。 当日志写入成功后，事务就提交成功。 在这种机制下，事务的执行时间取决于数据文件的更新（磁盘表是一个页，内存表是一个内存地址）和事务日志的更新。 两部分，当事务日志的更新慢于数据文件的更新时，会减慢事务的提交速度。 延迟交易就是将这两部分分开。 数据文件写入后，事务成功，同时写入日志文件，不影响事务提交。 这种提交方式的优点是减少了可能的提交延迟时间，缺点是牺牲了部分事务的完整性。
当延迟事务与内存表一起使用时，事务日志对内存表性能的影响将最小化：内存表的事务执行完全不受日志影响。 日志异步写入后，检查点线程会定期更新到磁盘。 在数据文件中。 内存表的性能提升了1B，相应的事务完整性略有牺牲。 当数据库崩溃时，未记录的更改将丢失。
延迟事务在两个地方指定：数据库选项中的选项和事务提交时的WITH
数据库级选项可以指定延迟事务关闭/可选/强制，并且只有在可选的情况下才会受该选项的影响。
最后强调一下，当内存表没有选择使用延迟事务时，可以认为与磁盘表的事务完整性一致。
因此，对于我即将写的内存表备份与恢复，需要持久化的内容有：内存表定义、日志文件和数据文件。
