変更の追跡の管理 (SQL Server)

適用対象:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceMicrosoft Fabric の SQL データベース

この記事では、変更の追跡を管理する方法について説明します。 また、セキュリティを構成する方法、および変更の追跡を使用する場合のストレージとパフォーマンスへの影響を判断する方法について説明します。

変更の追跡の管理

ここでは、変更の追跡の管理に関連するカタログ ビュー、権限、および設定の一覧を示します。

カタログビュー

変更追跡が有効になっているテーブルとデータベースを特定するには、次のカタログ ビューを使用します。

また、 sys.internal_tables カタログ ビューには、ユーザー テーブルの変更の追跡を有効にしたときに作成された内部テーブルが表示されます。

セキュリティ

変更追跡関数を使用して変更追跡情報にアクセスするには、プリンシパルに次の権限が必要です。

  • SELECT 変更追跡テーブルの少なくとも主キー列に対するアクセス許可。クエリ対象のテーブルに対するアクセス許可。

  • VIEW CHANGE TRACKING 変更を取得する対象のテーブルに対するアクセス許可。 次の理由により、 VIEW CHANGE TRACKING アクセス許可が必要です。

    • 変更追跡レコードには、削除された行に関する情報が含まれます。 レコードでは、削除された行の主キー値が使用されます。 一部の機密データが削除された後、変更追跡テーブルの SELECT アクセス許可がプリンシパルに付与される場合があります。 この場合、そのプリンシパルが変更追跡を使用して削除された情報にアクセスしないようにします。

    • 変更追跡情報には、更新操作によって変更される列に関する情報を格納できます。 機密情報を含む列に対するプリンシパルのアクセス許可が拒否される場合があります。 ただし、変更追跡情報を使用できるため、プリンシパルは列の値が更新されたことを判断できますが、プリンシパルは列の値を決定できません。

変更追跡のオーバーヘッドについて

テーブルの変更の追跡を有効にすると、一部の管理操作に影響します。 次の表に、考慮する必要がある操作と影響を示します。

操作 変更の追跡が有効になっている場合
DROP TABLE 削除するテーブルのすべての変更追跡情報が削除されます。
ALTER TABLE DROP CONSTRAINT PRIMARY KEY制約を削除しようとすると失敗します。 PRIMARY KEY制約を削除するには、変更の追跡を無効にする必要があります。
ALTER TABLE DROP COLUMN 削除する列が主キーの一部である場合、変更の追跡に関係なく、列の削除は許可されません。

削除する列が主キーの一部でない場合、列の削除は成功します。 ただし、まず、このデータを同期しているアプリケーションへの影響を理解する必要があります。 テーブルで列の変更の追跡が有効になっている場合、削除した列がまだ変更追跡情報の一部として返される場合があります。 削除された列を処理するのはアプリケーションの役割です。
ALTER TABLE ADD COLUMN 変更履歴テーブルに新しい列を追加した場合、列の追加は追跡されません。 新しい列に加えられた更新および変更のみが追跡されます。
ALTER TABLE ALTER COLUMN 主キー以外の列のデータ型の変更は追跡されません。
ALTER TABLE SWITCH 一方または両方のテーブルで変更追跡が有効になっている場合、パーティションの切り替えは失敗します。
DROP INDEX, or ALTER INDEX DISABLE 主キーを適用するインデックスを削除したり無効にしたりすることはできません。
TRUNCATE TABLE 変更の追跡が有効になっているテーブルを切り捨てることもできます。 ただし、操作によって削除される行は追跡されず、有効な最小バージョンが更新されます。 アプリケーションがそのバージョンをチェックすると、バージョンが古すぎるため再初期化が必要であることが示されます。 この条件は、変更の追跡が無効になり、テーブルに対して再度有効になるのと同じです。

変更の追跡を使用すると、操作に変更追跡情報が格納されるため、DML 操作にオーバーヘッドが発生します。

DML への影響

変更の追跡は、DML 操作のパフォーマンス オーバーヘッドを最小限に抑えるために最適化されています。 テーブルに対する変更追跡の使用に伴うパフォーマンスの増分オーバーヘッドは、テーブルのインデックスを作成して管理するときに発生するオーバーヘッドに似ています。

DML 操作が変更される各行について、システムは内部変更追跡テーブルに行を追加します。 このアクションの効果は、DML 操作に関連して、次のようなさまざまな要因によって異なります。

  • 主キー列の数

  • ユーザー テーブル行で変更されたデータの量

  • トランザクションで実行された操作の数

スナップショットの分離を使用すると、変更の追跡が有効かどうかに関係なく、すべての DML 操作のパフォーマンスにも影響します。

ストレージへの影響

変更追跡データは、次の種類の内部テーブルに格納されます。

  • 内部変更テーブル

    変更の追跡が有効になっている各ユーザー テーブルは、独自の内部変更テーブルを取得します。

  • 内部トランザクション テーブル

    データベースには、1 つの内部トランザクション テーブルがあります。

これらの内部テーブルは、ストレージ要件に次のような影響を与えます。

  • ユーザー テーブルの各行に対する変更ごとに、変更の追跡によって内部変更テーブルに行が追加されます。 この行には、わずかな固定オーバーヘッドに加えて、主キー列のサイズに等しい可変オーバーヘッドがあります。 この行には、アプリケーションによって設定されるオプションのコンテキスト情報が含まれる場合があります。 列の追跡を有効にした場合、変更された各列には追跡テーブルに 4 バイトが必要です。

  • コミットされたトランザクションごとに、変更追跡によって内部トランザクション テーブルに行が追加されます。

その他の内部テーブルと同様に、変更追跡テーブルに使用される領域は、 sp_spaceused ストアド プロシージャを使用して確認できます。 次の例に示すように、 sys.internal_tables カタログ ビューを使用して内部テーブルの名前を取得できます。

sp_spaceused 'sys.change_tracking_309576141'  
sp_spaceused 'sys.syscommittab'

関連コンテンツ

  • Last updated on