インメモリ OLTP を使用した SQL Database のアプリケーション パフォーマンスの向上Use In-Memory OLTP to improve your application performance in SQL Database

インメモリ OLTP は、Premium および Business Critical レベルのデータベースで、価格レベルを上げることなくトランザクション処理、データ インジェスト、一時的なデータ シナリオのパフォーマンスを向上させるために使用できます。In-Memory OLTP can be used to improve the performance of transaction processing, data ingestion, and transient data scenarios, in Premium and Business Critical tier databases without increasing the pricing tier.

既存のデータベースでインメモリ OLTP を採用するには、以下の手順に従います。Follow these steps to adopt In-Memory OLTP in your existing database.

手順 1:Premium および Business Critical レベルのデータベースを使用していることを確認するStep 1: Ensure you are using a Premium and Business Critical tier database

インメモリ OLTP は、Premium および Business Critical レベルのデータベースでのみサポートされています。In-Memory OLTP is supported only in Premium and Business Critical tier databases. 返された結果が (0 ではなく) 1 である場合は、インメモリがサポートされています。In-Memory is supported if the returned result is 1 (not 0):

SELECT DatabasePropertyEx(Db_Name(), 'IsXTPSupported');

XTP は、Extreme Transaction Processing (大量トランザクション処理) の略です。XTP stands for Extreme Transaction Processing

手順 2:インメモリ OLTP に移行するオブジェクトを特定するStep 2: Identify objects to migrate to In-Memory OLTP

SSMS には、アクティブなワークロードがあるデータベースに対して実行できる トランザクション パフォーマンス分析の概要 レポートが用意されています。SSMS includes a Transaction Performance Analysis Overview report that you can run against a database with an active workload. このレポートを使用して、インメモリ OLTP への移行の候補となるテーブルとストアド プロシージャを特定できます。The report identifies tables and stored procedures that are candidates for migration to In-Memory OLTP.

SSMS でこのレポートを生成するには、In SSMS, to generate the report:

  • オブジェクト エクスプローラーでデータベース ノードを右クリックし、In the Object Explorer, right-click your database node.
  • [レポート] > [標準レポート] > [トランザクション パフォーマンス分析の概要] の順にクリックします。Click Reports > Standard Reports > Transaction Performance Analysis Overview.

詳細については、「 テーブルまたはストアド プロシージャをインメモリ OLTP に移植する必要があるかどうかの確認」を参照してください。For more information, see Determining if a Table or Stored Procedure Should Be Ported to In-Memory OLTP.

手順 3:比較用のテスト データベースを作成するStep 3: Create a comparable test database

メモリ最適化テーブルに変換するとメリットが得られるテーブルがデータベース内にあるとレポートに記載されていたとします。Suppose the report indicates your database has a table that would benefit from being converted to a memory-optimized table. このような場合は、まずテストを実施して、指摘された点について確認することをお勧めします。We recommend that you first test to confirm the indication by testing.

そのためには、運用データベースのテスト コピーが必要です。You need a test copy of your production database. テスト データベースは、運用データベースと同じレベルのサービス層に配置する必要があります。The test database should be at the same service tier level as your production database.

テストを容易にするために、テスト データベースを次のように調整します。To ease testing, tweak your test database as follows:

  1. SSMS を使用して、テスト データベースに接続します。Connect to the test database by using SSMS.

  2. クエリで WITH (SNAPSHOT) オプションを使用しなくても済むように、次の T-SQL ステートメントに示すようにデータベース オプションを設定します。To avoid needing the WITH (SNAPSHOT) option in queries, set the database option as shown in the following T-SQL statement:

    ALTER DATABASE CURRENT
     SET
         MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT = ON;
    

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

テストするテーブルのメモリ最適化コピーを作成し、データを入力する必要があります。You must create and populate a memory-optimized copy of the table you want to test. 次のいずれかを使用して作成できます。You can create it by using either:

  • SSMS の便利なメモリ最適化ウィザードThe handy Memory Optimization Wizard in SSMS.
  • 手動による T-SQL の実行Manual T-SQL.

SSMS のメモリ最適化ウィザードMemory Optimization Wizard in SSMS

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

  1. SSMS を使用して、テスト データベースに接続します。Connect to the test database with SSMS.

  2. オブジェクト エクスプローラーで、テーブルを右クリックし、 [メモリ最適化アドバイザー] をクリックします。In the Object Explorer, right-click on the table, and then click Memory Optimization Advisor.

    • テーブル メモリ オプティマイザー アドバイザー ウィザードが表示されます。The Table Memory Optimizer Advisor wizard is displayed.
  3. ウィザードで、 [移行の検証] (または [次へ] ) をクリックし、メモリ最適化テーブルでサポートされていない機能がテーブルに含まれているかどうかを確認します。In the wizard, click Migration validation (or the Next button) to see if the table has any unsupported features that are unsupported in memory-optimized tables. 詳細については、次を参照してください。For more information, see:

  4. サポートされていない機能がテーブルになければ、アドバイザーで実際のスキーマとデータの移行を実行できます。If the table has no unsupported features, the advisor can perform the actual schema and data migration for you.

手動による T-SQL の実行Manual T-SQL

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

  1. SSMS (または同様のユーティリティ) を使用して、テスト データベースに接続します。Connect to your test database by using SSMS (or a similar utility).

  2. 使用するテーブルとそのインデックスに対応した完全な T-SQL スクリプトを取得します。Obtain the complete T-SQL script for your table and its indexes.

    • SSMS で、テーブル ノードを右クリックします。In SSMS, right-click your table node.
    • [テーブルをスクリプト化] > [CREATE To (作成先)] > [新しいクエリ ウィンドウ] の順にクリックします。Click Script Table As > CREATE To > New Query Window.
  3. スクリプト ウィンドウで、WITH (MEMORY_OPTIMIZED = ON) を CREATE TABLE ステートメントに追加します。In the script window, add WITH (MEMORY_OPTIMIZED = ON) to the CREATE TABLE statement.

  4. CLUSTERED インデックスがある場合は、NONCLUSTERED に変更します。If there is a CLUSTERED index, change it to NONCLUSTERED.

  5. SP_RENAME を使用して、既存のテーブルの名前を変更します。Rename the existing table by using SP_RENAME.

  6. 編集した CREATE TABLE スクリプトを実行して、テーブルのメモリ最適化コピーを新規作成します。Create the new memory-optimized copy of the table by running your edited CREATE TABLE script.

  7. INSERT...SELECT * INTO を使用して、このメモリ最適化テーブルにデータをコピーします。Copy the data to your memory-optimized table by using INSERT...SELECT * INTO:

INSERT INTO <new_memory_optimized_table>
        SELECT * FROM <old_disk_based_table>;

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

インメモリ機能では、ストアド プロシージャに変更を加えて、パフォーマンスを向上することもできます。The In-Memory feature can also modify a stored procedure for improved performance.

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

ネイティブ コンパイル ストアド プロシージャでは、T-SQL WITH 句に次のオプションが必要です。A natively compiled stored procedure must have the following options on its T-SQL WITH clause:

  • NATIVE_COMPILATIONNATIVE_COMPILATION
  • SCHEMABINDING: これを指定されたテーブルでは、ストアド プロシージャにより、そのストアド プロシージャを削除しない限り、ストアド プロシージャに影響を与えるような変更を列の定義に加えることができません。SCHEMABINDING: meaning tables that the stored procedure cannot have their column definitions changed in any way that would affect the stored procedure, unless you drop the stored procedure.

ネイティブ モジュールでは、トランザクション管理用に大きな ATOMIC ブロック を 1 つ使用する必要があります。A native module must use one big ATOMIC blocks for transaction management. 明示的 BEGIN TRANSACTION、または ROLLBACK TRANSACTION の役割はありません。There is no role for an explicit BEGIN TRANSACTION, or for ROLLBACK TRANSACTION. コードでビジネス規則違反が検出されると、 THROW ステートメントを含むアトミック ブロックが停止する可能性があります。If your code detects a violation of a business rule, it can terminate the atomic block with a THROW statement.

ネイティブ コンパイル向けの一般的な CREATE PROCEDURETypical CREATE PROCEDURE for natively compiled

ネイティブ コンパイル ストアド プロシージャを作成する T-SQL は、一般的に、次のテンプレートのようになります。Typically the T-SQL to create a natively compiled stored procedure is similar to the following template:

CREATE PROCEDURE schemaname.procedurename
    @param1 type1, …
    WITH NATIVE_COMPILATION, SCHEMABINDING
    AS
        BEGIN ATOMIC WITH
            (TRANSACTION ISOLATION LEVEL = SNAPSHOT,
            LANGUAGE = N'your_language__see_sys.languages'
            )
        …
        END;
  • TRANSACTION_ISOLATION_LEVEL は、SNAPSHOT がネイティブ コンパイル ストアド プロシージャで最も一般的な値です。For the TRANSACTION_ISOLATION_LEVEL, SNAPSHOT is the most common value for the natively compiled stored procedure. ただし、次のような他の値も少数ながらサポートされています。However, a subset of the other values are also supported:

    • REPEATABLE READREPEATABLE READ
    • SERIALIZABLESERIALIZABLE
  • LANGUAGE の値は、sys.languages ビューに存在している必要があります。The LANGUAGE value must be present in the sys.languages view.

ストアド プロシージャを移行する方法How to migrate a stored procedure

移行の手順は次のとおりです。The migration steps are:

  1. 通常の解釈されたストアド プロシージャを作成する CREATE PROCEDURE スクリプトを取得します。Obtain the CREATE PROCEDURE script to the regular interpreted stored procedure.

  2. 前述のテンプレートと一致するようにヘッダーを書き直します。Rewrite its header to match the previous template.

  3. ネイティブ コンパイル ストアド プロシージャでサポートされていない機能がこのストアド プロシージャの T-SQL コードで使用されているかどうかを確認します。Ascertain whether the stored procedure T-SQL code uses any features that are not supported for natively compiled stored procedures. 必要な場合は、回避策を実装します。Implement workarounds if necessary.

  4. SP_RENAME を使用して、元のストアド プロシージャの名前を変更します。Rename the old stored procedure by using SP_RENAME. または、削除します。Or simply DROP it.

  5. 編集した CREATE PROCEDURE T-SQL スクリプトを実行します。Run your edited CREATE PROCEDURE T-SQL script.

手順 6:ワークロードをテスト実行するStep 6: Run your workload in test

運用データベースで実行するワークロードと同様のワークロードをテスト データベースで実行します。Run a workload in your test database that is similar to the workload that runs in your production database. これにより、テーブルとストアド プロシージャにインメモリ機能を使用したことでパフォーマンスがどれほど向上したかがわかります。This should reveal the performance gain achieved by your use of the In-Memory feature for tables and stored procedures.

ワークロードの主な属性は次のとおりです。Major attributes of the workload are:

  • コンカレント接続数Number of concurrent connections.
  • 読み取り/書き込みの比率Read/write ratio.

テスト ワークロードを調整して実行するには、 このページで説明されている、便利な ostress.exe ツールの使用を検討してください。To tailor and run the test workload, consider using the handy ostress.exe tool, which illustrated in here.

ネットワーク待ち時間を最小限に抑えるために、データベースが存在するのと同じ Azure リージョンでテストを実行してください。To minimize network latency, run your test in the same Azure geographic region where the database exists.

手順 7:実装後の監視Step 7: Post-implementation monitoring

運用環境でインメモリ機能の実装によるパフォーマンスへの影響を監視することを検討してください。Consider monitoring the performance effects of your In-Memory implementations in production: