メモリ最適化テーブルを使用したシステム バージョン管理されたテンポラル テーブル

適用対象:AZURE SQL Managed Instance SQL Server 2016 (13.x) 以降のバージョン

メモリ最適化テーブル向けのシステムバージョン対応時間テーブル は、 インメモリOLTPワークロードで収集されたデータに加えてデータ 監査やポイントインタイム解析 が必要なシナリオにおいて、コスト効率の高いソリューションを提供します。

Note

メモリ最適化テンポラル テーブルは、SQL Server と Azure SQL Managed Instance でのみ使用できます。 メモリ最適化テーブルとテンポラル テーブルは、Azure SQL Database で個別に使用できます。

Overview

システム バージョン管理されたテンポラル テーブルは、完全なデータ変更履歴を自動的に保持し、特定時点分析用に便利な Transact-SQL 拡張機能を公開します。 典型的なシナリオでは、データ履歴は定期的に照会されなくても長期間(数ヶ月、場合によっては数年)保持されます。

データ監査や時間ベースの分析は、特に非常に大量のリクエストを処理するOLTPシステムや、インメモリOLTP技術が使用される環境によって求められることがあります。 ただし、テンポラル シナリオでメモリ最適化テーブルを使用するのは、生成される大量の履歴データが一般に使用可能な RAM の制限を超えるため、困難です。 また、古くなるほどアクセスされなくなる読み取り専用の履歴データを格納するために RAM を使用するのは、最適なソリューションではありません。

メモリ最適化テーブル用のシステムバージョン制御時時テーブルは、高いトランザクションスループットとロックフリーの同時実行性を提供します。 大量の履歴データを保存するには、現在のデータを保存するためにインメモリテーブル(テンポラルテーブル)を使い、過去データにはディスクベースのテーブルを使うことができます。 内部的に自動生成されるメモリ最適化ステージング テーブルを使用して、最近の履歴を格納し、ネイティブ コンパイル コードから DML を実行できるようにすることで、DML 操作への影響は削減されます。

次の図は、このアーキテクチャを示しています。

テンポラル インメモリ アーキテクチャの図。

実装の詳細

システム バージョン管理されたメモリ最適化テーブルを作成する場合は、次の考慮事項に注意してください。 構文オプションと例については、 CREATE TABLEを参照してください。

  • システム バージョン管理できるのは、持続性のあるメモリ最適化テーブルだけです (DURABILITY = SCHEMA_AND_DATA)。

  • メモリ最適化されたシステムバージョン付きテーブルのヒストリーテーブルは、あなたが作成するものでもシステムが作成するものでも、ディスクベースでなければなりません。

  • ネイティブにコンパイルされたT-SQLモジュールでは、現在のメモリ内テーブルにのみ影響するクエリを使うことができます。 ネイティブにコンパイルされたモジュールは FOR SYSTEM TIME 節をサポートしませんが、アドホッククエリや非ネイティブモジュールはメモリ最適化されたテーブルに対してこの節を使用できます。

  • SYSTEM_VERSIONING = ONを用いると、システムは自動的に内部メモリ最適化されたステージングテーブルを作成し、最新のシステムバージョン変更を受け入れます。これは、現在のメモリ最適化テーブルに対する更新および削除操作によって生じるものです。

  • 非同期データフラッシュタスクは、定期的に内部メモリ最適化されたステージングテーブルからディスクベースの履歴テーブルへデータを移動させます。 このデータ フラッシュ メカニズムは、親オブジェクトによる内部メモリ バッファーのメモリ使用量を 10% 未満に維持します。 メモリ最適化されたシステムバージョン付き時間テーブルの総メモリ消費量は、 sys.dm_db_xtp_memory_consumersクエリを行い、内部メモリ最適化ステージテーブルと現在の時間テーブルのデータを要約することで追跡できます。

  • 手動でデータフラッシュを行うには 、sp_xtp_flush_temporal_historyを実行してください。

  • SYSTEM_VERSIONING = OFFや、システムバージョン対応テーブルのスキーマをカラムの追加、削除、変更によって変更すると、内部ステージングバッファの全内容がディスクベースのヒストリーテーブルに移動します。

  • 履歴データのクエリは実質的にスナップショット分離レベルであり、メモリ内ステージング バッファーとディスク ベース テーブルの重複がない和集合を常に返します。

  • ALTER TABLE テーブルスキーマを内部で変更する操作はデータフラッシュを行う必要があり、これにより操作が長引くことがあります。

内部メモリ最適化ステージング テーブル

システムでは、DML の操作を最適化するために、内部メモリ最適化ステージング テーブルが作成されます。

  • テーブル名は以下の形式で使われます: Memory_Optimized_History_Table_<object_id><object_id> は現在の時間テーブルの識別子です。

  • このテーブルは現在の時間テーブルのスキーマと1つの bigint 列を再現しています。 この追加の列は、内部履歴バッファに移動された行の一意性を保証します。

  • 追加列の名前は、Change_ID[<suffix>] という形式です。<suffix> はオプションであり、Change_ID 列がテーブルに既にある場合に追加されます。

  • システム バージョン管理メモリ最適化テーブルの最大行サイズは、ステージング テーブルに追加される bigint 列のため、8 バイト減少します。 最大容量は現在8,052バイトです。

  • 内部メモリ最適化されたステージングテーブルは、SQL Server Management Studioのオブジェクト エクスプローラーには表示されません。

  • このテーブルと現在の時間テーブルとの接続に関するメタデータは sys.internal_tablesで見つけることができます。

データ フラッシュ タスク

データフラッシュタスクは定期的に実行され、メモリ最適化されたテーブルがデータ移動のためのメモリサイズ条件を満たしているかどうかを確認します。 データ移動は、内部ステージングテーブルのメモリ消費が現在の時間テーブルのメモリ消費の8%に達した時点で始まります。

データ フラッシュ タスクは、既存のワークロードに基づいて変化するスケジュールで、定期的にアクティブ化されます。 ワークロードが多い場合、タスクは 5 秒ごとに実行されます。 ワークロードが軽い場合、頻度は 1 分ごとにまで上昇します。 クリーンアップが必要な内部メモリ最適化ステージング テーブルごとに 1 つのスレッドが生成されます。

データ フラッシュは、現在実行している最も古いトランザクションより古いメモリ内内部バッファーからすべてのレコードを削除して、ディスク ベースの履歴テーブルにこれらのレコードを移動します。

データ フラッシュを実行するには、sp_xtp_flush_temporal_history を実行し、スキーマとテーブル名を指定します。

EXEC sys.sp_xtp_flush_temporal_history <schema_name>, <object_name>;

内部スケジュールでシステムによってデータ フラッシュ タスクが実行されるときと同じデータ移動プロセスが呼び出されます。