メモリ最適化テーブルでのシステム バージョン管理されたテンポラル テーブル
適用対象: 
SQL Server 2016 (13.x) 以降 Azure SQL Database Azure SQL Managed Instance
メモリ最適化テーブルのシステム バージョン管理されたテンポラル テーブルには、インメモリ OLTP ワークロードで収集されたデータに加えて、データ監査および特定時点分析が必要なシナリオにコスト効果の高いソリューションが用意されています。
概要
システム バージョン管理されたテンポラル テーブルは、完全なデータ変更履歴を自動的に保持し、特定時点分析用に便利な Transact-SQL 拡張機能を公開します。 一般的なシナリオでは、データの履歴は、定期的に照会されなくても、長い期間 (複数月、場合によっては複数年) 保持されます。
データ監査と時間ベースの分析は、さまざまな環境で要求されることがあります。非常に大量の要求を処理し、インメモリ OLTP テクノロジが使用されている OLTP システムでは特にそうです。 ただし、テンポラル シナリオでメモリ最適化テーブルを使用するのは、生成される大量の履歴データが一般に使用可能な RAM の制限を超えるため、困難です。 また、古くなるほどアクセスされなくなる読み取り専用の履歴データを格納するために RAM を使用するのは、最適なソリューションではありません。
メモリ最適化テーブルのシステム バージョン管理されたテンポラル テーブルは、高いトランザクション スループットとロックフリーのコンカレンシーを提供します。 現在のデータ (テンポラル テーブル) を格納するためのインメモリ テーブルと、履歴データ用のディスク ベース テーブルを使用して、大量の履歴データを格納できます。 内部的に自動生成されるメモリ最適化ステージング テーブルを使用して、最近の履歴を格納し、ネイティブ コンパイル コードから DML を実行できるようにすることで、DML 操作への影響は削減されます。
次の図に、このアーキテクチャを示します。
実装詳細
システム バージョン管理されたメモリ最適化テーブルを作成する場合は、次の考慮事項に注意してください。 構文のオプションおよび例については、「CREATE TABLE」を参照してください。
システム バージョン管理できるのは、持続性のあるメモリ最適化テーブルだけです (
DURABILITY = SCHEMA_AND_DATA)。メモリ最適化されてシステム バージョン管理されたテーブルの履歴テーブルは、エンド ユーザーまたはシステムのどちらによって作成される場合でも、ディスク ベースでなければなりません。
現在のインメモリ テーブルのみに影響するクエリは、ネイティブ コンパイル T-SQL モジュールで使用できます。
FOR SYSTEM TIME句を使用したテンポラル クエリは、ネイティブ コンパイル モジュールではサポートされません。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>;
内部スケジュールでシステムによってデータ フラッシュ タスクが実行されるときと同じデータ移動プロセスが呼び出されます。