Hekaton是如何影响你数据库的目标恢复时间（RTO）的

这个周末我发现了SQL Server 2014里Hekaton的一个有趣副作用，很遗憾它会负面影响你数据库的目标恢复时间（Recovery Time Objective，RTO）。你已知道，对于每个本地编译表和存储过程，Hekaton都会创建一个DLL，这些都是以C语言代码实现的。这些DLL文件载入sqlservr.exe的执行空间。你可以用下列的查询通过DMV sys.dm_os_loaded_modules来查看当前载入的Hekaton表：

 SELECT * FROM sys.dm_os_loaded_modules
 WHERE description LIKE 'XTP%'

在CTP2里，我遇到的副作用是：当你删除对应表后存储过程时，载入的Hekaton的DLL文件并没有卸载掉。假设你创建了一个本地编译的存储过程，在一定时间后你想删除那个存储过程来重建，为了获得更好的本地编译执行计划（在Hekaton里的当前执行时间并不支持重编译）。在那个情况下，你的存储过程的老实现方式还在sqlservr.exe的执行空间里，在消耗额外的内存。当你删除表时也会同样发生，DLL本身还在内存里！

去除这些额外不需要的DLL文件的唯一方法是让你的整个数据库离线，再联机。然后当你查询DMV sys.dm_os_loaded_modules时，你会看到只有当前实现的本地编译表和存储过程被载入sqlservr.exe。当你没有特定的可用维护界面时，这是你Hekaton第一个遇到的糟糕问题。

但事情变得更加糟糕：当你重启SQL server，SQL Server会编译和链接每个原先已经生成的DLL。编译和链接每个Hekaton的DLL会占用一些CPU时间，在此期间你的数据库是处理恢复阶段，从用户角度来说，意味着你的数据库是不能访问的！即使当你尝试访问基于传统硬盘的表，在此期间，你会得到类似如下的错误信息：

Msg 922, Level 14, State 1, Line 1
Database ‘HashCollisions’ is being recovered. Waiting until recovery is finished.

你也可以在C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\DATA\xtp目录里看到原先老的.c,.obj和.dll还在，因为对于下次SQL Server的启动它们是需要。

假设你创建50个本地编译表和存储过程并立即删除。在那个情况下你在结束100个DLL文件，这些文件会在SQL Server启动期间编译和连接。我在虚拟机上测试SQL Server 2014的CTP2，我的数据库在69秒后才联机！

因此请留意这些副作用，因为它们会大幅度降低你的目标恢复时间（RTO）！设想下你在群集故障转移，在那个情况下，每个DLL必须在你另外的群集点编译和链接好，对于的终端用户，你的数据库才会联机。我说过，这是我在SQL Sever 2014 CTP2里遇到的问题，因为我希望在RTM版本发布时，微软对这方面会有所改进！

感谢关注！

参考文章：

https://www.sqlpassion.at/archive/2013/11/25/how-hekaton-will-impact-the-rto-of-your-database/