在 Azure SQL 資料庫 中使用記憶體內部 OLTP 來改善應用程式效能
記憶體內部 OLTP 可用來改善事務處理、數據擷取和暫時性數據案例的效能,進階版 和 業務關鍵 層資料庫,而不需要增加定價層。
請遵循下列步驟,在現有的資料庫中採用記憶體內部 OLTP。
步驟 1:確定您使用 進階版 或 業務關鍵 層資料庫
記憶體內部 OLTP 僅支援 Azure SQL 資料庫 進階版 (DTU) 和 業務關鍵 (虛擬核心) 層。 如果傳回的結果為 1
,則支援記憶體內部 OLTP (不是 0
):
SELECT DatabasePropertyEx(Db_Name(), 'IsXTPSupported');
XTP 代表 極端事務處理。
步驟 2:識別要移轉至記憶體內部 OLTP 的物件
SQL Server Management Studio (SSMS) 包含交易效能分析概觀報表,您可以針對具有作用中工作負載的資料庫執行。 報表會識別要移轉至記憶體內部 OLTP 的數據表和預存程式。
在 SSMS 中,產生報告:
- 在 物件總管 中,以滑鼠右鍵按下您的資料庫節點。
- 選取 [報告>標準報表>交易效能分析概觀]。
如需評估記憶體內部 OLTP 優點的詳細資訊,請參閱 判斷數據表或預存程式是否應移植到記憶體內部 OLTP。
步驟 3:建立可比較的測試資料庫
假設報表指出您的資料庫具有可受益於轉換成記憶體優化數據表的數據表。 建議您先進行測試,以透過測試來確認指示。
您需要生產資料庫的測試複本。 測試資料庫應該與您的生產資料庫位於相同的服務層級。
若要簡化測試,請調整測試資料庫,如下所示:
若要避免在查詢中需要
WITH (SNAPSHOT)
選項,請設定目前資料庫MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT
的選項,如下列 T-SQL 語句所示:ALTER DATABASE CURRENT SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT = ON;
步驟 4:移轉數據表
您必須建立並填入您想要測試之數據表的記憶體優化複本。 您可以使用下列其中一項來建立它:
SSMS 中的記憶體優化精靈
若要使用此移轉選項:
使用SSMS連線至測試資料庫。
在 物件總管 中,以滑鼠右鍵按兩下數據表,然後選取 [記憶體優化建議程式]。
[ 數據表記憶體優化器建議程序 精靈] 隨即顯示。
在精靈中,選取 [移轉驗證 ] (或 [ 下一步 ] 按鈕,以查看數據表是否有記憶體優化數據表中不支援的任何不支援功能。 如需詳細資訊,請參閱
- 記憶體優化建議程式中的記憶體優化檢查清單。
- 記憶體內部 OLTP 不支援 Transact-SQL 建構。
- 移轉至記憶體內部 OLTP。
如果數據表沒有不支援的功能,Advisor 可以為您執行實際的架構和數據遷移。
手動 T-SQL
若要使用此移轉選項:
- 連線 使用 SSMS(或類似的公用程式)對測試資料庫。
- 取得數據表及其索引的完整 T-SQL 腳本。
- 在 SSMS 中,以滑鼠右鍵按下您的資料表節點。
- 選取 [將數據表腳本為>CREATE 至>新的查詢視窗]。
- 在文稿視窗中,將 新增
WITH (MEMORY_OPTIMIZED = ON)
至CREATE TABLE
語句。 - 如果有 CLUSTERED 索引,請將它變更為 NONCLUSTERED。
- 使用 sp_rename 重新命名現有的數據表。
- 執行編輯
CREATE TABLE
的腳本,以建立數據表的新記憶體優化複本。 - 使用
INSERT...SELECT * INTO
將資料複製到記憶體最佳化資料表:INSERT INTO [<new_memory_optimized_table>] SELECT * FROM [<old_disk_based_table>];
步驟 5 (選擇性):移轉預存程式
記憶體內部功能也可以修改預存程式,以改善效能。
原生編譯預存程序的考慮
原生編譯預存程式在其 T-SQL WITH
子句上必須具有下列選項:
- NATIVE_COMPILATION:這表示程式中的 Transact-SQL 語句都會編譯成原生程式代碼,以有效率地執行。
- SCHEMABINDING:這表示除非卸除預存程式,否則預存程式不能以任何方式變更其數據行定義。
原生模組必須使用一個大型 ATOMIC 區塊 來進行交易管理。 明確BEGIN TRANSACTION
ROLLBACK TRANSACTION.
或如果您的程式代碼偵測到違反商務規則,則它可以使用 THROW 語句終止不可部分完成的區塊。
原生編譯的一般 CREATE PROCEDURE
通常建立原生編譯預存程式的 T-SQL 類似於下列範本:
CREATE PROCEDURE schemaname.procedurename
@param1 type1, ...
WITH NATIVE_COMPILATION, SCHEMABINDING
AS
BEGIN ATOMIC WITH
(TRANSACTION ISOLATION LEVEL = SNAPSHOT,
LANGUAGE = N'<desired sys.syslanuages.sysname value>'
)
...
END;
TRANSACTION_ISOLATION_LEVEL
針對,SNAPSHOT 是原生編譯預存程式最常見的值。 不過,也支援其他值的子集:- REPEATABLE READ
- SERIALIZABLE
- 值
LANGUAGE
必須存在於數據行的sys.syslanguages
檢視中name
。 例如:N'us_english'
。
如何移轉預存程式
移轉步驟如下:
CREATE PROCEDURE
取得腳本至一般解譯預存程式。- 重寫其標頭以符合先前的範本。
- 判斷預存程式 T-SQL 程式代碼是否使用原生編譯預存程式不支援的任何功能。 視需要實作因應措施。 如需詳細資訊,請參閱 原生編譯預存程式的移轉問題。
- 使用 sp_rename 重新命名舊的預存程式。 或者,只要卸除它即可。
- 執行已編輯
CREATE PROCEDURE
的 T-SQL 腳本。
步驟 6:在測試中執行工作負載
在測試資料庫中執行工作負載,類似於在生產資料庫中執行的工作負載。 這應該會顯示針對數據表和預存程式使用記憶體內部功能所取得的效能提升。
工作負載的主要屬性包括:
- 並行連線數目。
- 讀取/寫入比率。
若要量身打造並執行測試工作負載,請考慮使用方便的ostress.exe工具。 如需詳細資訊,請參閱 Azure SQL 資料庫 中的記憶體內部範例。
若要將網路等待時間降到最低,請在資料庫所在的相同 Azure 地理區域中執行您的測試。
步驟 7:實作後監視
請考慮在生產環境中監視記憶體內部實作的效能影響:
- 監視記憶體內部記憶體。
- 使用動態管理檢視進行監視。
相關內容
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應