在几天前的一次会议中，有人说“使用Hekaton增加了事务日志的大小，这增加了故障转移的时间”，同时描述了使用Hekaton内存表的AlwaysOn SQL集群的挑战。我不是一个SQL专家，所以想知道这是否是一个真实的陈述，如果是这样，是什么让Hekaton事务日志变得比没有Hekaton时更大呢？
答案 0 :(得分：1)
我认为情况正好相反。事务记录是描述事务的逻辑事务，而不是对非内存表中的索引的所有修改。
日志包含已提交事务的逻辑效果 足以重做交易。更改记录为 插入和删除用表标记的行版本 他们属于。没有记录撤消信息。
未记录Hekaton索引操作。所有索引都重建 恢复。
检查点实际上是一个压缩表示 登录。检查点允许截断日志并进行改进 崩溃恢复性能。
由于事务日志的尾部通常是瓶颈，因此减少 附加到日志的日志记录数可以改善 可扩展性和显着提高效率。而且 每个事务的日志内容比系统需要更少的空间 每次操作生成一个日志记录
有关Hekaton的Microsoft文档包含这些详细信息。
http://research.microsoft.com/pubs/193594/Hekaton%20-%20Sigmod2013%20final.pdf
答案 1 :(得分：1)
我同意检查点应该可以改善崩溃恢复。
话虽如此，恢复Hekaton日志记录的速度非常快，因为该进程执行内存分配，并且某些计算比执行磁盘操作要小得多。
Hekaton可在Azure（2015年11月）中预览，因此您可以在那里尝试工作量。 https://azure.microsoft.com/en-us/blog/azure-sql-database-in-memory-oltp-real-time-operational-analytics-now-in-public-preview/