表和儲存過程的本機編譯

記憶體中OLTP將本機編譯的概念引入到了SQL Server 2014中。SQL Server可以在本機編譯訪問記憶體優化表的儲存過程，而且實際上，也本地編譯了記憶體優化表本身。本機編譯比起傳統的解釋型Transact-SQL可以提供更快的資料訪問和更高效的查詢執行。

什麼是本機編譯？

本地編譯是指將變程式設計結構轉換為原生代碼，包括可以由CPU直接執行的處理器指令，而不需要進一步的編譯或解釋的過程。

Transact-SQL語言由高層次的結構所組成，例如CREATE TABLE和SELECT... FROM。記憶體中OLTP編譯器分析這些結構，並將其編譯成原生代碼，以進行資料訪問和查詢執行的快速執行時間。SQL Server 2014中的記憶體中OLTP編譯器將表和儲存過程的定義做為輸入。它生成C語言程式碼，並利用Visual C編譯器來生成原生代碼。

表和儲存過程編譯的結果為DLL檔案，這些檔案被載入到記憶體中並連結到SQL Server程序上。

SQL Server在建立記憶體優化表和本地編譯的儲存過程時，將它們編譯成本地DLL檔案。另外，資料庫或伺服器在重新啟動後，會重新編譯表和儲存過程的DLL檔案。重建DLL檔案所需的資訊儲存在資料庫的元資料中；DLL檔案本身並不是資料庫的一部分。因此DLL檔案並不是資料庫備份的一部分。

DLL檔案的維護

記憶體優化表和本地編譯儲存過程的DLL檔案，以及其他為了故障診斷和可支援性而儲存的生成的檔案，都儲存在檔案系統中。

以下查詢顯示了當前伺服器上載入到記憶體中的所有表和儲存過程的DLL檔案：

SELECT name, description FROM sys.dm_os_loaded_modules
WHERE description = 'XTP Native DLL'

資料庫管理員不需要維護由本機編譯生成的檔案。例如在表和儲存過程的刪除過程中，以及在刪除的資料庫中， SQL Server會自動刪除不再需要的生成檔案，而且伺服器或資料庫重新啟動時也會自動刪除。

表的本地編譯

使用CREATE TABLE語句建立記憶體優化表，表資訊寫入到資料庫中的元資料中，表和索引的結構在記憶體中建立，並且表還被編譯成一個DLL檔案。

請參考以下的示例指令碼，這個指令碼建立了一個數據庫和一個記憶體優化表：

USE master 
GO 
create database db1 
GO 
ALTER DATABASE db1 ADD FILEGROUP db1_mod CONTAINS memory_optimized_data 
GO 
-- adapt filename as needed 
ALTER DATABASE db1 ADD FILE (name='db1_mod', filename='c:\data\db1_mod') 
    TO FILEGROUP db1_mod 
GO 
USE db1 
GO 
CREATE TABLE dbo.t1 
(c1 int not null primary key nonclustered, 
c2 int) 
WITH (MEMORY_OPTIMIZED=ON) 
GO 
-- retrieve the path of the DLL for table t1 
SELECT name, description FROM sys.dm_os_loaded_modules 
WHERE name LIKE '%xtp_t_' + cast(db_id() AS varchar(10))
                + '_' + cast(object_id('dbo.t1') AS varchar(10)) + '.dll' 
GO

表的建立會編譯表的DLL檔案，並將這個DLL檔案載入到記憶體中。緊接著CREATE TABLE語句之後的查詢檢索出表的DLL檔案的路徑。

表t1的DLL檔案能夠解析表的索引結構和行格式。 SQL Server使用這個DLL檔案遍歷索引和檢索行，以及行中的內容。

儲存過程的本機編譯

標有NATIVE_COMPILATION選項的儲存過程是本機編譯的。這意味著，為了效能要求較高的業務邏輯的執行效率，在儲存過程中的Transact-SQL語句都被編譯為原生代碼。

請參考以下的示例儲存過程，這個儲存過程將行插入到之前示例的表t1中：

CREATE PROCEDURE dbo.p1
WITH NATIVE_COMPILATION, SCHEMABINDING, EXECUTE AS OWNER
AS
BEGIN ATOMIC
WITH (TRANSACTION ISOLATION LEVEL=snapshot, LANGUAGE=N'us_english')
    DECLARE @i int = 1000000
    WHILE @i > 0
    BEGIN
    INSERT dbo.t1 VALUES (@i, @i+1)
    SET @i -= 1
    END
END
GO
EXEC dbo.p1
GO
-- reset
DELETE FROM dbo.t1
GO

儲存過程p1的DLL檔案可以直接與表t1的DLL檔案以及記憶體中OLTP的儲存引擎進行互動，以便儘可能快的插入行。

記憶體中OLTP編譯器充分利用了查詢優化器為儲存過程中的每個查詢建立高效的執行計劃。需要注意的是，對於本機編譯的儲存過程，查詢執行計劃被編譯成DLL檔案。由於SQL Server 2014不支援本機編譯的儲存過程的自動重新編譯，對錶資料的修改可能需要刪除並重新建立一些儲存過程，將新的查詢計劃合併到儲存過程的DLL檔案中。需要注意的是，在伺服器重新啟動以及故障轉移到一個AlwaysOn副本後，本機編譯的儲存過程在第一次執行時進行重新編譯，這意味著查詢優化器將建立新的查詢計劃，新的查詢計劃隨後會被編譯到儲存過程的DLL檔案中。

編譯和查詢處理

圖15顯示了本機編譯的儲存過程的編譯過程：

圖15 儲存過程的本地編譯

1. 使用者向 SQL Server 發出一條 CREATE PROCEDURE 語句

2. 分析器和 algebrizer 為該儲存過程建立處理流程，併為儲存過程中的 Transact-SQL 查詢建立查詢樹

3. 優化器為儲存過程中的所有查詢建立優化的查詢執行計劃

4. 記憶體中 OLTP 編譯器通過嵌入的優化查詢計劃接管處理流程，並生成一個 DLL，其中包含執行儲存過程的機器程式碼

5. 生成的 DLL 載入到記憶體中，並連線到SQL Server程序

本機編譯的儲存過程的呼叫轉換為對 DLL 中函式的呼叫，如圖16所示

圖16 本地編譯的儲存過程的執行

1. 使用者發出一條’ EXEC myproc’語句

2. 分析器提取名稱和儲存過程引數

3. 記憶體中 OLTP 執行時查詢儲存過程DLL檔案的 入口點

4. DLL檔案執行儲存過程邏輯，結果會返回到客戶端

引數嗅探

解釋型 Transact-SQL 儲存過程在首次執行（呼叫）時編譯成直接的物理執行計劃，而本機編譯的儲存過程在建立時編譯。當在呼叫時對解釋型儲存過程進行編譯，優化器使用為此呼叫提供的引數值生成執行計劃。這種編譯期間的引數用法稱為“引數嗅探”。

引數嗅探不適用於編譯本機編譯的儲存過程。此類儲存過程的所有引數都視為具有 UNKNOWN 值。

SQL Server的功能支援

許多SQL Server功能都支援記憶體中OLTP和含記憶體優化表的資料庫，但不是所有SQL Server功能都支援。比如，AlwaysOn元件，日誌傳送和資料庫的備份和恢復都完全支援記憶體中OLTP。事務複製部分支援，允許記憶體優化表作為一個訂閱使用，但不能作為釋出專案。但是，不支援資料庫映象。可以使用SQL Server Management Studio來管理記憶體優化表，也支援SSIS。

有關支援和不支援功能的完整列表，請參閱SQL Server記憶體中OLTP的文件。

管理經驗

記憶體中OLTP已完全整合到SQL Server的管理經驗中。正如上面提到的，SQL Server Management Studio中能夠管理記憶體優化表，檔案組和本地編譯的儲存過程。還可以使用SQL Server管理物件（SMO）和PowerShell來管理您的記憶體優化物件。

元資料

一些已有的元資料物件已經得到增強，可提供關於記憶體優化表和儲存過程的資訊，新的物件也已經增加。

有一個函式得到了增強：

• OBJECTPROPERTY - 現在包括一個屬性TableIsMemoryOptimized

目錄檢視

以下的系統檢視得到增強：

• sys.tables 有三個新列：
  • durability（0或1）
  • durability_desc（SCHEMA_AND_DATA和SCHEMA_ONLY）
  • is_memory_optimized（0或1）
• sys.table_types  現在有一個is_memory_optimized列
• sys.indexes  現在有一個可能為7的type值和一個對應為NONCLUSTERED HASH的type_desc值。 （像一個非聚集的B-tree索引一樣，非聚集索引有一個為2的 type_value和為NONCLUSTERED的type_desc）。
• sys.index_columns列is_descending_key現在有不同的語義，對於雜湊索引，這個值是無意義的，可以忽略。
• sys.data_spaces  現在有一個可能為FX的type值和一個對應為MEMORY_OPTIMIZED_DATA_FILEGROUP的type_desc值
• sys.sql_modules和sys.all_sql_modules - 現在包含一個uses_native_compilation列

此外，還有一些專門提供記憶體優化表資訊的幾個新的元資料物件。

增加了一個新的目錄檢視來支援雜湊索引：sys.hash_indexes。這個檢視是基於sys.indexes，因此具有和sys.indexes相同的列，並有一個額外新增的列。這個bucket_count列顯示了為索引所指定的雜湊桶的數量，而且如果沒有刪除和重建索引的話，這個值不會被改變。

動態管理物件

以下SQL Server動態管理檢視是為記憶體中OLTP所新增的。 （xtp識別符號代表“極限事務處理（eXtreme transaction processing）”。）sys.dm_db_xtp_*開頭的那些動態管理檢視提供了關於啟用記憶體中OLTP的各個資料庫的資訊， sys.dm_xtp_*開頭的那些動態管理檢視提供了例項級別的資訊。您可以在文件中讀到關於這些物件的詳細資訊。這些動態管理檢視中的一些在本文較早的相關章節已經提到過。

關於支援記憶體優化表的動態管理檢視的詳細資訊，請參閱記憶體優化表的動態管理檢視。

• sys.dm_db_xtp_checkpoint
• sys.dm_db_xtp_checkpoint_files
• sys.dm_db_xtp_gc_cycles_stats
• sys.dm_xtp_gc_stats
• sys.dm_xtp_system_memory_consumers
• sys.dm_xtp_threads
• sys.dm_xtp_transaction_stats
• sys.dm_db_xtp_index_stats
• sys.dm_db_xtp_memory_consumers
• sys.dm_db_xtp_object_stats
• sys.dm_db_xtp_transactions
• sys.dm_db_xtp_table_memory_stats

XEvents

記憶體中OLTP引擎提供了xEvents來幫助監控和故障排除。您可以執行以下查詢來檢視當前可用的xEvents：

SELECT p.name, o.name, o.description
FROM sys.dm_xe_objects o JOIN sys.dm_xe_packages p
ON o.package_guid=p.guid
WHERE p.name = 'XtpEngine';
GO

效能計數器

記憶體中OLTP引擎提供了效能計數器來幫助監控和故障排除。您可以執行以下查詢來檢視當前可用的效能計數器：

SELECT OBJECT_NAME，counter_name
from sys.dm_os_performance_counters
WHERE OBJECT_NAME LIKE'XTP%';
GO

還提供了名為XTP使用記憶體的資料庫計數器物件，用於跟蹤在資料庫級別的記憶體優化表的記憶體使用情況。

記憶體使用情況報表

要獲得記憶體優化表和索引當前使用記憶體的實時報表，您可以執行SQL Server Management Studio中提供的報表。在物件資源管理器中，右鍵單擊包含記憶體優化表的資料庫的名稱，選擇報表|標準報表|記憶體優化物件的記憶體使用情況。您會看到類似圖17的報表。

圖17記憶體優化物件的記憶體使用情況報表

這個報表顯示錶的行和索引所使用的空間，以及少量由系統使用的空間。請記住，一旦建立了雜湊索引，這些索引就會擁有分配給已宣告的雜湊桶數量的記憶體，因此這個報表將顯示在插入任何行之前，這些索引的記憶體使用情況。對於非聚集索引，在新增行之前不會分配記憶體，並且記憶體需求將依賴於索引鍵的大小和行的數量。

記憶體需求

當執行記憶體中OLTP時，SQL Server需要配置足夠的記憶體來儲存所有的記憶體優化表。未能分配足夠的記憶體會導致在需要額外記憶體的操作執行時事務失敗。通常這會在INSERT或UPDATE操作時發生，但在一個記憶體優化的非聚集索引上的刪除操作也有可能發生。正如上一節所介紹的，刪除可能導致產生頁合併，而且由於索引頁永遠不會被更新，合併操作將會分配新頁。記憶體中OLTP的記憶體管理器與SQL Server的記憶體管理器完全整合，並在可能的情況下，通過更積極地清理舊行版本來對記憶體壓力進行反應。

在預測記憶體優化表所需的記憶體數量時，一個經驗法是，應該擁有資料佔用量兩倍的記憶體。除此之外，總記憶體需求還取決於工作負荷；如果由於OLTP操作有大量的資料修改，則需要更多的記憶體供給行版本使用。如果大量讀取現有的資料，則可能需要更少的記憶體。

對於規劃索引所需的空間，雜湊索引則非常簡單。每個桶需要8個位元組，所以您可以計算桶的數量乘以8位元組數。記憶體優化非聚集索引的大小取決於索引鍵的大小和表中行的數量。可以假設每個索引行是8個位元組加上索引鍵的大小（假設為k位元組），因此，適合於一個頁面的最大行數將是8176/（K +8）。預計的行數除以這個結果將得到一個初步的估計。請記住，並不是所有的索引頁都是8K，也不是所有的頁都是全滿的。由於頁需要拆分和合並，創建出新的頁，需要為這些頁留出空間，直到垃圾收集程序將它們刪除。

用資源調控器管理記憶體

SQL Server的資源調控器是一種讓您可以主動管理記憶體的工具。與CTP2版本開始，資料庫可以繫結到一個資源池上，您可以分配一定量的記憶體到這個池中。這個資料庫中的記憶體優化表使用的記憶體不能超過這個量。有一個可分配記憶體的80%的固定限制，以確保系統在記憶體壓力下仍然穩定。事實上，記憶體優化表及其索引佔用的任何記憶體都是由資源調控器管理，除此之外，並沒有其他型別的記憶體是由資源調控器管理。如果資料庫沒有顯式對映到一個資源池，它會隱式地對映到預設池。

為記憶體中OLTP資料庫建立一個記憶體池的第一步是指定MAX_MEMORY_PERCENT值。這個值指定了可以被分配給與這個池關聯資料庫中記憶體優化表的SQL Server記憶體的百分比。

例如：

CREATE RESOURCE POOL HkPool WITH (MAX_MEMORY_PERCENT=50);
ALTER RESOURCE GOVERNOR RECONFIGURE;

建立了資源池之後，需要使用儲存過程sp_xtp_bind_db_resource_pool將希望管理的資料庫繫結到各自的池中。注意，一個池可以包含多個數據庫，但資料庫在任何時間點只能與一個池關聯。

以下是一個示例：

EXEC sp_xtp_bind_db_resource_pool 'HkDB', 'HkPool';

因為是在分配記憶體時，才將記憶體指派到一個資源池中，只是將資源池與一個數據庫關聯並不能轉移已分配記憶體的指派。要做到這一點，您需要將資料庫離線，再把它重新聯機。當資料被讀入到記憶體優化表，記憶體將關聯到新的資源池中。

例如：

ALTER DATABASE [HkDb] SET OFFLINE;
ALTER DATABASE [HkDb] SET ONLINE;

如果您想要移除一個數據庫和一個資源池之間的繫結，則可以使用儲存過程sp_xtp_unbind_db_resource_pool。例如，您可能希望將資料庫移動到另一個資源池中，或者徹底刪除資源池，來將其替換成其他的資源池。

EXEC sp_xtp_unbind_db_resource_pool 'HkPool';

通過分析，遷移和報表工具集（AMR）來幫助遷移

安裝SQL Server2014（只要您已經選擇安裝了完整的管理工具集）之後，分析，遷移和報表工具集（Analyze, Migrate and Report , AMR）可用於提供關於可能要考慮將哪些表和儲存過程遷移到記憶體中OLTP的建議。

該工具集的分析和報表方面使用一組新的資料收集器與管理資料倉庫相結合，以獲取工作負荷瓶頸和效能指標。這些資料可以用來生成報表，可通過右擊管理資料倉庫的資料庫並選擇報表|管理資料倉庫來使用。然後有一個選項可以選擇“事務效能分析概述”。

其中一個報表包含了如果轉換成記憶體優化表，哪些表可能提供最大效能增益的建議。該報表也將基於表中同時使用了多少不支援的功能，說明進行轉換將需要多少代價。另一份報表包含為了記憶體優化表的使用，哪些儲存過程可能會從轉換為本機編譯的儲存過程中受益的建議。

一旦關鍵表確定，該工具集的遷移方面包含的記憶體優化顧問可以幫助您遷移它們。在右擊基於磁碟的表彈出的上下文選單中，點選“記憶體優化顧問”。這個顧問將確定物件中已有的不相容性，並生成概述了這些不相容問題的報表，並且還能對有限的一組表進行有指導的遷移。

記憶體優化表可以由解釋型的Transact-SQL和本地編譯儲存過程進行訪問，並且記憶體優化表可以與基於磁碟的表在同一個查詢中使用，這就意味著遷移到一個記憶體中OLTP的環境可以逐步迭代地來完成。根據管理資料倉庫報表中提供的建議，您可以開始將錶轉換成記憶體優化表，一次一個，可以從記憶體中優化結構中受益最多的表開始。當您開始看到轉換成記憶體優化表的好處，您可以繼續轉換越來越多的表，但訪問它們使用常規的Transact-SQL介面，如果有的話，應用程式只需要極少的更改。

一旦您的表已經完成轉換，您就可以開始計劃將程式碼重寫成本地編譯的儲存過程，可以再次從資料倉庫報表表明將提供最大收益的那些儲存過程開始。利用本機編譯顧問（另一種工具，可以通過右擊Management Studio中的儲存過程找到）來確定Transact-SQL中的不相容性，可以幫助遷移這些物件。

總結

SQL Server的記憶體中OLTP特性提供了建立和使用記憶體中優化表的能力，並可以極其有效的對其進行管理，為 OLTP工作負荷提供了效能優化。記憶體優化表可採用真正的多版本樂觀併發控制進行訪問，在處理過程中不需要鎖或閂鎖。所有記憶體中OLTP的記憶體優化表必須至少有一個索引，並且所有的訪問都需要通過索引。記憶體中OLTP的記憶體優化表可以與基於磁碟的表在同一個事務中被引用，只是稍有些限制。本機編譯的儲存過程是訪問記憶體優化表和高效業務邏輯演算法最快的方式。