----------------------------我是分割線-------------------------------

本文翻譯自微軟白皮書《In-Memory OLTP – Common Workload Patterns and Migration Considerations》：http://technet.microsoft.com/en-us/library/dn673538.aspx

譯者水平有限，如有翻譯不當之處，歡迎指正。

----------------------------我是分割線-------------------------------

內存中OLTP集成到SQL Server中的同時，也具備不同于傳統關系型數據庫系統特別是SQL Server的一些獨特功能。本節的目的是向讀者提供一些這樣的注意事項。本節并不提供有關遷移的綜合指導，許多關于具體需求，支持功能和外圍應用的深入討論已超出了本文的范圍。

如先前所討論的，許多應用程序已經從實施內存中OLTP中受益頗豐。然而，不同的工作負荷可能會獲得不同程度的改進。有些應用程序可能只需要極小的更改，而其他可能需要更大量的代碼修改，例如將某些Transact-SQL轉換成本地編譯的存儲過程。也有一些場景并不適合于內存中OLTP。因此，關鍵是要了解工作負荷和環境的特征。這項評估將幫助你確定一個應用程序對于內存中OLTP是否是一個可行的候選。以下章節將提出審核應用程序工作負荷的方法，并提供了有關這些內存中OLTP實施的可行性意見。

在遷移到內存中OLTP之前，確保你徹底了解應用程序的需求和目標。此外，確定性能瓶頸是否可以由內存中OLTP解決。如下圖表明， SQL Server引擎其中某些方面可以為內存中OLTP提供收益。其他與引擎交互的組件有可能不能從遷移到內存中OLTP獲得收益。

圖6 內存中OLTP的性能收益范圍

如圖6所示，內存中OLTP位于數據訪問層（表和索引對象）和查詢執行的引擎組件。如果當前的瓶頸位于這個領域，將這些數據集或者Transact-SQL遷移到內存中OLTP引擎中則可以提高性能。內存中OLTP比起基于磁盤的表產生的日志量也更少，因為不需要為索引分配或者UNDO需求寫入日志記錄。在任何情況下，到磁盤子系統I/O的日志延遲仍然是事務提交的一部分。比如SCHEMA_ONLY表（非持續）和延遲的持續性這樣的功能能夠消除或盡可能減少這方面的開銷。另外，客戶端連接層沒有任何增強。有一些方式能夠處理這個問題，但內存中OLTP并不能直接處理或解決這一瓶頸。

確定基線是了解系統的當前性能和在做出更改后衡量改進或退化的關鍵。你可以以多種方式來實現這一點。許多工具和方法論在“監視和優化性能”這篇文章中都進行了討論。很多工具可以用來幫助確定一個基線，但選擇一個度量充當基線是非常重要的。基線度量的一些例子有：

• 系統組件的利用率和性能，比如：磁盤，CPU，內存，網絡。
• SQL Server代碼執行時間。
• 事務吞吐量。
• 什么系統正在等待，以及等待多長時間。比如sys.dm_os_wait_stats這樣的動態管理視圖可以幫助確定SQL Server的資源等待。

應用程序的整體性能也應該被視為基線的一部分。確定基線還要考慮以下因素：

• 衡量業務事務吞吐量。
• 事務往返時間。
• 用戶體驗。
• 擴展。

使用這些衡量可以幫助定義成功遷移的標準。

在某些情況下，數據庫引擎之外的因素可能會導致應用程序中的瓶頸。因此，遷移到內存中OLTP可能不會改善這種狀況。了解當前的性能瓶頸在整體應用架構是至關重要的。一旦你確定了數據庫中的瓶頸，則為遷移重點關注這些特定的組件。

內存中OLTP產品提供了一些工具來幫助遷移過程。這些工具都集成到了Management Studio中。我們有時提到的工具集是指分析，遷移和報表（Analyze, Migrate, and Reporting , AMR）工具集。為了幫助瓶頸分析，可以使用新的數據收集器（事務性能收集組）。它們幫助收集性能數據和工作負荷特性。它們還能建議將頻繁使用的或者有爭用的表和代碼遷移到內存中OLTP。

數據收集器比起運行單個查詢來為內存中OLTP遷移確定一個很好的候選要更有意義得多。收集器使用管理數據倉庫（MDW）對時間段內收集的數據執行數據聚合。收集器能夠提供關于遷移到內存中OLTP帶來的性能提升的預估。這個信息出現在SQL Server 2014 Management Studio中附帶的“事務性能分析”報表中。有關配置和使用這些工具的詳細討論，請參閱網頁“遷移到內存中OLTP”，其中有關于這一功能的詳細介紹。

如果你不能利用數據收集和報告工具，還有其他方式來幫助理解SQL Server中的爭用點。 SQLDiag，PSSDiag和SQL Nexus是你可以用來確定與閂鎖，鎖，自旋鎖和存儲過程的執行次數統計相關的爭用問題的工具。 SQL Nexus能夠確定等待資源，閂鎖，鎖和阻塞。如果SQL跟蹤作為捕獲的一部分運行，SQL Nexus還可以捕獲執行次數最多的存儲過程和Transact-SQL語句。

如果在一段時間內監視和收集這些信息的開銷過大，你有另一個選擇。你可以手動執行查詢來檢測經常訪問的表，閂鎖爭用或者存儲過程執行次數的統計。這些查詢的執行提供了自從上次服務器重啟以來位于內存中的快照值。在某些情況下，捕捉兩個時間點的輸出并確定它們之間的增量可能更加準確。收集這些信息的查詢在稍后的章節中提供。

這個查詢提供了自從SQL Server實例被重置或者性能數據被清除以來數據庫中訪問最頻繁的表的一個列表。在確定進行轉換的候選時，可考慮靠前的檢索數和掃描數。通過評估以下查詢的singleton_lookup_count和range_scan_count，你可以對使用率有一些了解。對于遷移到內存中OLTP，可考慮將頻繁訪問的表或表中的部分數據遷移到內存優化對象中。

SELECT TOP (5)     b.name AS TableName,            a.database_id,            a.singleton_lookup_count,            a.range_scan_count    FROM     sys.dm_db_index_Operational_stats(DB_ID(), NULL, NULL, NULL) AS a        INNER JOIN sys.objects b on a.object_id = b.object_idWHERE     b.type <> 'S'        AND         (a.singleton_lookup_count > 0 OR a.range_scan_count > 0)ORDER BY     a.singleton_lookup_count DESCGO

通過審核sys.dm_db_index_operational_stats動態管理視圖中的page_latch_wait 和 page_lock_wait列來評估閂鎖爭用?？紤]將具有大量閂鎖或鎖爭用的表遷移到內存中OLTP。以下查詢將提供自從SQL Server實例被重置或者性能數據被清除以來累計的閂鎖和鎖等待。

SELECT TOP (5)    a.database_id,            so.object_id,            so.name AS TableName,            a.page_latch_wait_count    ,            a.page_latch_wait_in_ms,            a.page_lock_wait_count,            a.page_lock_wait_in_msFROM    sys.dm_db_index_operational_stats(DB_ID(), NULL, NULL, NULL) a        INNER JOIN sys.objects AS so         ON a.object_id = so.object_idWHERE    so.type = 'U' AND a.page_io_latch_wait_count > 0ORDER BY     a.page_latch_wait_count DESC;

內存中OLTP提供本地編譯的存儲過程。通過本地編譯Transact-SQL成一個DLL文件并盡可能減少在執行時需要被處理的指令，從而極大的改善存儲過程的執行時間。如果你無法使用Management Studio中的工具，以下這兩個查詢將提供類似的信息。然而，這些查詢只能檢索到這個調用執行時存在于計劃緩存中的存儲過程和Transact-SQL數據。有可能有更好的候選存儲過程存在，但它們已經不在計劃緩存中。可考慮在一天或一周中多次運行這些查詢，以確定是否存在其他的候選。

以下查詢將提供總工作時間最多的存儲過程名稱。如果最近性能數據已經清零，計劃緩存會失效，或者如果SQL Server實例已被重置，則此刻計劃緩存可能不具有足夠多有價值的信息。

SELECT TOP (10)    sp.database_id,            so.name AS StoredPRocName,            sp.total_worker_time,            sp.execution_count,            sp.total_logical_reads,            sp.total_logical_writes,            sp.total_logical_readsFROM    sys.dm_exec_procedure_stats AS sp        INNER JOIN sys.objects AS so         ON (sp.object_id = so.object_id)WHERE    so.type = 'P' AND sp.database_id = DB_ID()ORDER BY sp.total_worker_time DESC;

以下查詢檢索出的數據在Management Studio工具中并不可用。但是，它可能有助于確定存儲過程中的哪個語句是資源最多的消耗者。在決定哪些存儲過程遷移到內存中OLTP時，知道哪些語句最多消耗資源是有價值的。這可能對只將一些高資源消耗的語句而不是整個存儲過程遷移到本地編譯的存儲過程中有益。

SELECT TOP (50)    sp.database_id,            dbname= DB_NAME (qt.dbid),            so.name AS StoredProcName,            sp.total_worker_time,            sp.execution_count AS StoredProcedureExecCount,            qs.execution_count AS StatementExecCount,            SUBSTRING(qt.text,qs.statement_start_offset / 2 + 1,                (CASE WHEN qs.statement_end_offset = -1                THEN LEN(CONVERT(NVARCHAR(MAX), qt.text)) * 2 ELSE qs.statement_end_offset END - qs.statement_start_offset) / 2                 ) AS query_textFROM    sys.dm_exec_query_stats AS qs         CROSS APPLY         sys.dm_exec_sql_text(qs.sql_handle) AS qt         INNER JOIN sys.dm_exec_procedure_stats AS sp            ON (sp.sql_handle = qs.sql_handle)        INNER JOIN sys.objects so         ON (sp.object_id = so.object_id) and sp.database_id = DB_ID()ORDER BY sp.total_worker_time DESC, qs.execution_count DESC

定義了目標和瓶頸之后，考慮一個測試標準來模擬瓶頸是很重要的。這個測試也將決定你是否能達到目的?？赡苡幸恍﹫鼍?，其中的一個“單元測試”或工作負荷的特定部分的單次執行，將有助于確認目標。例如，值得關注的可能是在隔離下跨單個線程的存儲過程調用的延遲。然而，在許多情況下，只有在負荷下，瓶頸或者性能降低才會暴露出來，尤其是對于大規模下的爭用。

如果你只在大規模的場景下觀察到瓶頸，在產生爭用之前，使用與不使用內存中OLTP執行的測試可能會顯示相似的性能。一旦達到引發爭用的規模，從這時開始，你會觀察到使用內存中OLTP有顯著的改善。在許多情況下，在傳統的數據庫系統中，吞吐量將達到一個平衡或者執行時間將增加。這時，從性能的角度上看，系統上額外的負荷或者規模很可能會造成性能不再提高甚至產生負面的影響。內存中OLTP中這一瓶頸的緩解有助于極好的維持和提高應用程序的整體性能，并跨越這個觀察到的瓶頸。

圖7展示了轉換到內存中OLTP的AdventureWorks示例數據庫的利用。圖像顯示了隨著一個工作負荷一直運行到大規模下出現爭用時引擎的性能提升。你只能通過模擬達到一個典型的RDBMS中規模影響性能的點的測試來認識這些好處。圖中的圓圈表示在這個點，典型RDBMS執行明顯需要花費更多的時間來執行同樣數量的事務數。在這一點后，內存中OLTP工作負荷繼續幾乎呈線性的擴展，而基于磁盤的工作負荷則達到大規模的一個障礙。

圖7從AdventureWorks示例數據庫中執行DemoInsertSalesOrders的完成時間/線程數

最后，需要考慮的是，當你將工作負荷遷移到內存中OLTP，工作負荷的一些特征有可能改變。理想的情況是基于一個穩定的，明確的工作測量來衡量整體應用程序的性能。圖7顯示了基于“N”的理想值，N表示用戶的線程數（針對時間的測量）。比起其范圍在每次執行時可能發生變化的某個值，比如業務事務或者并發用戶數這樣的測量更容易在不同的測試間關聯起來。

我們建議你通過先著重于工作負荷中的特定領域來開始遷移，這部分領域表現出的瓶頸應該是內存中OLTP可以解決的。通常情況下，你可能只需將數據和對象的一個子集遷移到內存中OLTP就能實現顯著的收益。

關鍵表到內存優化結構和Transact-SQL代碼到編譯代碼的一些遷移都非常簡單，只需要極少的變更。其他情況由于外圍應用支持或者部署這些新數據庫對象的能力，可能需要復雜的變更。

集成到SQL Server 2014 Management Studio中的兩個幫助遷移對象的工具是內存優化顧問和本地編譯顧問。這兩種工具可以幫助你評估遷移的難度。它們評估表架構和存儲過程的語法來尋找可能的遷移阻礙，比如不支持的數據類型。然后這些工具可以提供解決這些遷移阻礙的方法的信息。如果內存優化顧問未檢測到遷移的問題，它的向導可以幫助創建內存優化表和數據遷移。

由于內存中OLTP集成到SQL Server中，它可以讓你一起使用內存優化表和基于磁盤的表。內存中OLTP還允許解釋型Transact-SQL和本地編譯的存儲過程來訪問存儲在內存優化表中的數據。如果你最終一定要遷移特定的組件，請使用以下增量遷移的策略：

• 確定限制可擴展性的爭用和瓶頸表。
• 解決不支持的功能，并將關鍵數據遷移到內存優化表。
• 執行使用解釋型Transact-SQL訪問內存優化表所需的最少的代碼變更。

這些步驟應該能夠減緩與鎖和閂鎖相關的大部分可擴展性的問題。如果你需要額外的性能提升，特別是與Transact-SQL執行時間相關，那么需要實施將Transact-SQL遷移到本地編譯的存儲過程。

• 確定訪問這些表及其相關對象的對于性能至關重要的Transact-SQL。
• 解決不支持的語言結構并將這些存儲過程遷移為本地編譯的代碼。

圖8 遷移方法論

當你將特定的瓶頸領域遷移到內存中OLTP，系統的其他部分可能會成為新的瓶頸。當解決一個特定的瓶頸時，考慮采用迭代的方法來遷移，然后分析解決方案的下一個性能瓶頸可能存在的位置。

本節不提供內存中OLTP技術的綜合列表。本節提供采用這項新技術功能的一些關鍵注意事項的指導。我們強調了一些技術或決策點，與傳統的SQL Server實施相比，這些技術或決策點是全新的或者巨大的變革。

性能敏感的工作負荷依賴部署中的所有組件，包括軟件和硬件。在下面的章節中，我們討論了考慮硬件選擇的一些關鍵因素，以及在部署內存中OLTP時，實施的一些注意事項?；谠试S應用程序使用現今市場上可用的已有和商用硬件的概念，微軟開發了內存中OLTP。內存中OLTP并不需要特別多的插槽/內核或者其他硬件組件。內存中OLTP是以 SQL Server中可與標準的商用硬件交互的優化作為目標。

內存優化表完全駐留在內存中，并且不會對于施加于SQL