這個周末我發現了SQL Server 2014里Hekaton的一個有趣副作用，很遺憾它會負面影響你數據庫的目標恢復時間（Recovery Time Objective，RTO）。你已知道，對于每個本地編譯表和存儲過程，Hekaton都會創建一個DLL，這些都是以C語言代碼實現的。這些DLL文件載入sqlservr.exe的執行空間。你可以用下列的查詢通過DMVsys.dm_os_loaded_modules來查看當前載入的Hekaton表：

1 SELECT * FROM sys.dm_os_loaded_modules2 WHERE description LIKE 'XTP%'

在CTP2里，我遇到的副作用是：當你刪除對應表后存儲過程時，載入的Hekaton的DLL文件并沒有卸載掉。假設你創建了一個本地編譯的存儲過程，在一定時間后你想刪除那個存儲過程來重建，為了獲得更好的本地編譯執行計劃（在Hekaton里的當前執行時間并不支持重編譯）。在那個情況下，你的存儲過程的老實現方式還在sqlservr.exe的執行空間里，在消耗額外的內存。當你刪除表時也會同樣發生，DLL本身還在內存里！

去除這些額外不需要的DLL文件的唯一方法是讓你的整個數據庫離線，再聯機。然后當你查詢DMVsys.dm_os_loaded_modules時，你會看到只有當前實現的本地編譯表和存儲過程被載入sqlservr.exe。當你沒有特定的可用維護界面時，這是你Hekaton第一個遇到的糟糕問題。

但事情變得更加糟糕：當你重啟SQL server，SQL Server會編譯和鏈接每個原先已經生成的DLL。編譯和鏈接每個Hekaton的DLL會占用一些CPU時間，在此期間你的數據庫是處理恢復階段，從用戶角度來說，意味著你的數據庫是不能訪問的！即使當你嘗試訪問基于傳統硬盤的表，在此期間，你會得到類似如下的錯誤信息：

Msg 922, Level 14, State 1, Line 1Database ‘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版本發布時，微軟對這方面會有所改進！

感謝關注！