次の方法で共有

Azure SQL Managed Instanceでインメモリ OLTPを使用して、アプリケーションのパフォーマンスを向上させます。

  • [アーティクル]

適用対象: Azure SQL Managed Instance

Iインメモリ OLTP は、Premium Azure SQL データベースで、価格レベルを上げることなくトランザクション処理、データの取り込み、一時的なデータ シナリオのパフォーマンスを向上させるために使用できます。 Business Critical サービス レベルには、一定量の 最大インメモリ OLTP メモリが含まれています。これは、 仮想コアの数によって決まる制限です。

Azure SQL Managed Instanceでの既存のデータベースでインメモリ OLTP を採用するには、以下の手順に従います。

手順 1: インメモリ OLTP に移行するオブジェクトを特定します

SQL Server Management Studio（SSMS） には、アクティブなワークロードがあるデータベースに対して実行できる トランザクション パフォーマンス分析の概要 レポートが用意されています。 このレポートを使用して、インメモリ OLTP への移行の候補となるテーブルとストアド プロシージャを特定できます。

SSMS でこのレポートを生成するには、

  • オブジェクト エクスプローラーでデータベース ノードを右クリックし、
  • [レポート]>[標準レポート]>[トランザクション パフォーマンス分析の概要] の順に選択します。

インメモリ OLTPの利点を評価するための詳細については、「 テーブルまたはストアド プロシージャをインメモリ OLTP に移植する必要があるかどうかの確認」を参照してください。

手順 2: 比較用のテスト データベースを作成する

メモリ最適化テーブルに変換するとメリットが得られるテーブルがデータベース内にあるとレポートに記載されていたとします。 このような場合は、まずテストを実施して、指摘された点について確認することをお勧めします。

そのためには、運用データベースのテスト コピーが必要です。 テスト データベースは、運用データベースと同じレベルのサービス層（Business Critical）および仮想コア数に配置する必要があります。

テストを容易にするために、テスト データベースを次のように調整します。

  1. SQL Server Management Studio (SSMS) を使用してデータベースに接続します。

  2. クエリでWITH (SNAPSHOT)使用しなくても済むように、次の T-SQL ステートメントに示すように現在のデータベースMEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT オプションを設定します。

    ALTER DATABASE CURRENT
 SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT = ON;

手順 3: テーブルを移行する

テストするテーブルのメモリ最適化コピーを作成し、データを入力する必要があります。 次のいずれかを使用して作成できます。

SSMS のメモリ最適化ウィザード

この移行オプションを使用する手順は、以下のとおりです。

  1. SSMS を使用して、テスト データベースに接続します。

  2. オブジェクト エクスプローラーで、テーブルを右クリックし、[メモリ最適化アドバイザー] を選択します。

    テーブル メモリ オプティマイザー アドバイザー ウィザードが表示されます。

  3. ウィザードで、[移行の検証] (または [次へ]) を選択し、メモリ最適化テーブルでサポートされていない機能がテーブルに含まれているかどうかを確認します。 詳細については、以下を参照してください:

  4. サポートされていない機能がテーブルになければ、アドバイザーで実際のスキーマとデータの移行を実行できます。

手動による T-SQL の実行

この移行オプションを使用する手順は、以下のとおりです。

  1. SSMS (または同様のユーティリティ) を使用して、テスト データベースに接続します。
  2. 使用するテーブルとそのインデックスに対応した完全な T-SQL スクリプトを取得します。
    • SSMS で、テーブル ノードを右クリックします。
    • [テーブルをスクリプト化]>[CREATE To (作成先)]>[新しいクエリ ウィンドウ] の順に選択します。
  3. スクリプト ウィンドウで、WITH (MEMORY_OPTIMIZED = ON) ステートメントに CREATE TABLE を追加します。
  4. CLUSTERED インデックスがある場合は、NONCLUSTERED に変更します。
  5. sp_renameを使用して、既存のテーブルの名前を変更します。
  6. 編集した CREATE TABLE スクリプトを実行して、テーブルのメモリ最適化コピーを新規作成します。
  7. INSERT...SELECT * INTO を使用して、このメモリ最適化テーブルにデータをコピーします。
    INSERT INTO [<new_memory_optimized_table>]
        SELECT * FROM [<old_disk_based_table>];

手順 4 (省略可能): ストアド プロシージャを移行する

インメモリ機能では、ストアド プロシージャに変更を加えて、パフォーマンスを向上することもできます。

ネイティブ コンパイル ストアド プロシージャに関する考慮事項

ネイティブ コンパイル ストアド プロシージャでは、T-SQL WITH 節に次のオプションが必要です。

  • NATIVE_COMPILATION: プロシージャ内の Transact-SQL ステートメントはすべて、効率的な実行のためにネイティブ コードにコンパイルされます。
  • SCHEMABINDING: これを指定されたテーブルでは、ストアド プロシージャにより、そのストアド プロシージャを削除しない限り、ストアド プロシージャに影響を与えるような変更を列の定義に加えることができません。

ネイティブ モジュールでは、トランザクション管理用に大きな ATOMIC ブロック を 1 つ使用する必要があります。 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_LEVELSNAPSHOT がネイティブ コンパイル ストアド プロシージャで最も一般的な値です。 ただし、その他の値のサブセットもサポートされています。
    • REPEATABLE READ
    • SERIALIZABLE
  • LANGUAGE 値は、sys.syslanguages ビュー内の name列に存在する 必要があります。 たとえば、N'us_english' のようにします。

ストアド プロシージャを移行する方法

移行の手順は次のとおりです。

  1. 通常の解釈されたストアド プロシージャを作成する CREATE PROCEDUREスクリプトを取得します。
  2. 前述のテンプレートと一致するようにヘッダーを書き直します。
  3. ネイティブ コンパイル ストアド プロシージャでサポートされていない機能がこのストアド プロシージャの T-SQL コードで使用されているかどうかを決定します。 必要な場合は、回避策を実装します。 詳細については、「ネイティブ コンパイル ストアド プロシージャ」を参照してください。
  4. sp_rename を使用して、元のストアド プロシージャの名前を変更します。 または、削除します。
  5. 編集したCREATE PROCEDURET-SQLスクリプト を実行します。

手順 5: ワークロードをテスト実行する

運用データベースで実行するワークロードと同様のワークロードをテスト データベースで実行します。 これにより、テーブルとストアド プロシージャにインメモリ機能を使用したことでパフォーマンスがどれほど向上したかがわかります。

ワークロードの主な属性は次のとおりです。

  • コンカレント接続数
  • 読み取り/書き込みの比率

テスト ワークロードを調整して実行するには、 便利な ツールの使用を検討してください。

ネットワーク待ち時間を最小限に抑えるために、データベースが存在するのと同じ Azure リージョンでテストを実行してください。

手順 6: 実装後の監視

運用環境でインメモリ機能の実装によるパフォーマンスへの影響を監視することを検討してください。

関連するコンテンツ