次の方法で共有

テンポラル テーブルの考慮事項と制約

  • [アーティクル]

適用対象: SQL Server 2016 (13.x) 以降 Azure SQL Database Azure SQL Managed Instance

テンポラル テーブルを使用する場合は、システムのバージョン管理の性質の上、注意すべき考慮事項と制約がいくつかあります。

  • テンポラル テーブルには、現在のテーブルと履歴テーブルの間でレコードを関連付けるために主キーが定義されている必要があります。 履歴テーブルに主キーを定義することはできません。

  • ValidFrom と ValidTo の値を記録するために使用する SYSTEM_TIME 期間列は、データ型 datetime2 を使用して定義する必要があります。

  • テンポラル構文は、データベースにローカルに格納されているテーブルまたはビューに対して機能します。 リンク サーバー上のテーブルや外部テーブルなどのリモート オブジェクトである場合は、クエリ内で FOR 句または期間述語を直接使用することはできません。

  • 履歴テーブルの作成時に履歴テーブルの名前を指定すると場合、は、スキーマとテーブルの名前を指定する必要があります。

  • 履歴テーブルには既定では、 PAGE 圧縮します。

  • 現在のテーブルがパーティション分割されている場合、パーティション分割構成が現在のテーブルから履歴テーブルに自動的にレプリケートされないため、履歴テーブルは既定のファイル グループに作成されます。

  • テンポラル テーブルと履歴テーブルでは、FileTable または FILESTREAM を使用できません。 FileTable と FILESTREAM を使用すると、SQL Serverの外部でデータを操作できるため、システムのバージョン管理は保証できません。

  • ノード テーブルまたはエッジ テーブルは、テンポラル テーブルとして作成することも、テンポラル テーブルに変更することもできません。

  • テンポラル テーブルでは、(n)varchar(max)、varbinary(max)、(n)text、image などの BLOB データ型がサポートされていますが、これらは多大なストレージ コストを発生させ、サイズが多いためにパフォーマンスに影響を与えます。 そのため、システムの設計時に、これらのデータ型を使用する場合は注意が必要です。

  • 履歴テーブルは、現在のテーブルと同じデータベースで作成する必要があります。 リンク サーバーに対するテンポラル クエリはサポートされていません。

  • 履歴テーブルには、制約 (主キー、外部キー、テーブル、または列の制約) を含めることはできません。

  • テンポラル クエリ (FOR SYSTEM_TIME 句を使うクエリ) 上では、インデックス付きビューはサポートされていません。

  • システムでバージョン管理されたテンポラル テーブルでは、オンライン オプション (WITH (ONLINE = ON) は ALTER TABLE ALTER COLUMN に影響を与えません。 ALTER オプションに指定された値に関係なく、ONLINE 列はオンライン操作としては実行されません。

  • INSERT および UPDATE ステートメントでは、SYSTEM_TIME 期間列を参照できません。 これらの列に値を直接挿入しようとすると、ブロックされます。

  • TRUNCATE TABLE はサポートされませんが、SYSTEM_VERSIONING は ON です。

  • 履歴テーブルのデータを直接変更することはできません。

  • ON DELETE CASCADE と ON UPDATE CASCADE は、現在のテーブルでは使用できません。 つまり、テンポラル テーブルが外部キー リレーションシップの参照元テーブル (sys.foreign_key の parent_object_id に対応) である場合、CASCADE オプションは使用できません。 この制約を回避するには、アプリケーション ロジックまたは AFTER トリガーを使用して、主キー テーブル (sys.foreign_key の referenced_object_id に対応) での削除の一貫性を維持します。 主キー テーブルがテンポラルで、参照元テーブルが非テンポラルである場合、このような制約はありません。

  • DML ロジックが無効になるのを防ぐために、INSTEAD OF トリガーは現在のテーブルでも履歴テーブルでも許可されません。 AFTER トリガーは、現在のテーブルでのみ許可されます。 DML ロジックが無効になるのを防ぐために、これらのトリガーは履歴テーブルではブロックされます。

  • レプリケーション テクノロジの使用量は制限されています。

    • 可用性グループ: 完全にサポートされています

    • 変更データ キャプチャと変更の追跡: 現在のテーブルでのみサポートされます

    • スナップショットおよびトランザクション レプリケーション: 1 つのパブリッシャー (テンポラルが有効化されない)、および 1 つのサブスクライバー (テンポラルが有効化される) でのみサポートされます。 複数のサブスクライバーの使用は、ローカル システム クロックへの依存によりテンポラル データの一貫性が失われる可能性があるため、サポートされていません。 この場合、パブリッシャーは OLTP ワークロードに使用され、サブスクライバーはオフロード レポート (AS OF クエリを含む) に使用されます。 ディストリビューション エージェントが開始すると、トランザクションが開かれ、ディストリビューション エージェントが停止するまで開かれたままになっています。 ValidFrom と ValidTo は、ディストリビューション エージェントによって開始される最初のトランザクションの開始時刻に設定されます。 ValidFrom と ValidTo が現在のシステム時刻に近い時刻に設定されていることが、アプリケーションまたは組織にとって重要な場合、ディストリビューション エージェントは、継続的に実行する既定の動作ではなく、スケジュールに従って実行することをお勧めします。 詳細については、「テンポラル テーブルの使用シナリオ」を参照してください。

    • マージ レプリケーション: テンポラル テーブルではサポートされません。

  • 定期的なクエリは、現在のテーブルのデータにのみ影響を与えます。 履歴テーブルのデータに対してクエリを実行するには、テンポラル クエリを使用する必要があります。 詳細については、「システム バージョン管理されたテンポラル テーブル内のデータに対してクエリを実行する」を参照してください。

  • 最適なインデックス作成方法では、最適なストレージのサイズとパフォーマンスのために、現在のテーブルにクラスター化列ストア インデックスまたは B ツリー行ストア インデックス、および履歴テーブルにクラスター化列ストア インデックスを含めます。 独自の履歴テーブルを作成または使用する場合は、期間列の終端から始まる期間列で構成される、この種類のインデックスを作成することを強くお勧めします。 このインデックスにより、テンポラル クエリが高速化され、データ整合性チェックの一部であるクエリが高速化されます。 既定の履歴テーブルには、期間列 (終了、開始) に基づいて作成されたクラスター化行ストア インデックスが含まれます。 少なくとも、非クラスター化行ストア インデックスを使用することをお勧めします。

  • 次のオブジェクト/プロパティは、履歴テーブルの作成時に、現在のテーブルから履歴テーブルにレプリケートされません。

    • 期間の定義
    • ID の定義
    • インデックス
    • 統計
    • CHECK 制約
    • トリガー
    • パーティション分割構成
    • アクセス許可
    • 行レベルのセキュリティ述語

  • 履歴テーブルは、履歴テーブルのチェーン内で現在のテーブルとして構成することはできません。

Note

ドキュメントでは、一般的にインデックスに関して B ツリーという用語が使用されます。 行ストア インデックスで、データベース エンジンによって B+ ツリーが実装されます。 これは、列ストア インデックスやメモリ最適化テーブルのインデックスには適用されません。 詳細については、「SQL Server と Azure SQL のインデックスのアーキテクチャとデザイン ガイド」を参照してください。

関連するコンテンツ