Hekaton是如何影響你資料庫的目标恢複時間（RTO）的

這個周末我發現了SQL Server 2014裡Hekaton的一個有趣副作用，很遺憾它會負面影響你資料庫的目标恢複時間（Recovery Time Objective，RTO）。你已知道，對于每個本地編譯表和存儲過程，Hekaton都會建立一個DLL，這些都是以C語言代碼實作的。這些DLL檔案載入sqlservr.exe的執行空間。你可以用下列的查詢通過DMV sys.dm_os_loaded_modules來檢視目前載入的Hekaton表：

1 SELECT * FROM sys.dm_os_loaded_modules
2 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/

注：此文章為

WoodyTu

學習MS SQL技術，收集整理相關文檔撰寫，歡迎轉載，請在文章頁面明顯位置給出此文連結！

若您覺得這篇文章還不錯請點選下右下角的推薦，有了您的支援才能激發作者更大的寫作熱情，非常感謝！