次の方法で共有

インメモリ OLTP を使用して アプリケーション パフォーマンスを向上させる

  • [アーティクル]

適用対象: Azure SQL Database

インメモリ OLTP は、データベースやエラスティック プールのサービス目標を増やすことなく、トランザクション処理、データ インジェスト、一時的なデータ シナリオのパフォーマンスを向上させるために使用できます。

  • Premium (DTU) サービス レベルおよび Business Critical (仮想コア) サービス レベルのデータベースとエラスティック プールは、インメモリ OLTP をサポートします。
  • Hyperscale サービス レベルは、インメモリ OLTP オブジェクトのサブセットをサポートしますが、メモリ最適化テーブルは含みません。 詳細については、「Hyperscale の制限事項」を参照してください。

既存のデータベースでインメモリ OLTP の使用を開始するには、次の手順に従います。

手順 1: Premium または Business Critical レベルのデータベースを使用していることを確認する

次のクエリの結果が (0ではなく) 1 の場合、インメモリ OLTP がサポートされます。

SELECT DATABASEPROPERTYEX(DB_NAME(), 'IsXTPSupported');

XTP は、インメモリ OLTP 機能の非公式な名前である Extreme Transaction Processing (大量トランザクション処理) を表します。

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

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

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

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

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

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

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

そのためには、運用データベースのテスト コピーが必要です。 テスト データベースは、運用データベースと同じレベルのサービス層に配置する必要があります。

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

  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;

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

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

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>];

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

インメモリ OLTP では、ネイティブ コンパイル ストアド プロシージャもサポートされており、T-SQL のパフォーマンスを向上させることができます。

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

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

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

ネイティブ コンパイルされたモジュールでは、トランザクション管理用に ATOMIC ブロック を 1 つ使用する必要があります。 明示的な BEGIN TRANSACTION または ROLLBACK TRANSACTION ステートメントは使用されません。 このコードは、ビジネス規則違反を検出した場合などに、 THROW ステートメントによってアトミックブロックを終了することができます。

ネイティブコンパイルストアドプロシージャの例

ネイティブ コンパイル ストアド プロシージャを作成する 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' のようにします。

ネイティブ コンパイルを使用するようにストアド プロシージャを移行する方法

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

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

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

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

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

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

テスト ワークロードを調整して実行するには、RML Utilities ツール グループの ostress.exe ツールの使用を検討してください。 詳細については、「Azure SQL データベースのインメモリ サンプル」を参照してください。

ネットワーク待ち時間を最小限に抑えるために、データベースと同じ Azure リージョンで ostress.exe を実行します。

手順 7:実装後の監視

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

関連するコンテンツ