適用対象:
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 操作に対するこの影響は、次のようなさまざまな要因によって異なります。
主キー列の数
ユーザー テーブル行で変更されるデータの量
トランザクションで実行される操作の数
スナップショット分離を使用している場合も、変更の追跡が有効になっているかどうかに関係なく、すべての DML 操作のパフォーマンスに影響します。
ストレージへの影響
変更追跡データは、次の種類の内部テーブルに格納されます。
内部変更テーブル
変更の追跡が有効になっているユーザー テーブルごとに 1 つずつ内部変更テーブルがあります。
内部トランザクション テーブル
データベースごとに 1 つずつ内部トランザクション テーブルがあります。
これらの内部テーブルは、ストレージ要件に次のような影響を与えます。
ユーザー テーブル内の各行が変更されるごとに、行が内部変更テーブルに追加されます。 この行によって、一定のわずかなオーバーヘッドおよび主キー列のサイズと同じ可変のオーバーヘッドが生じます。 この行には、アプリケーションによって設定されるオプションのコンテキスト情報が含まれる場合があります。 また、列の追跡が有効になっている場合、列が変更されるごとに追跡テーブルで 4 バイトが必要になります。
トランザクションがコミットされるごとに、行が内部トランザクション テーブルに追加されます。
その他の内部テーブルと同様に、変更追跡テーブルに使用される領域は、 sp_spaceused ストアド プロシージャを使用して確認できます。 内部テーブルの名前は、次の例に示すように、 sys.internal_tables カタログ ビューを使用して取得できます。
sp_spaceused 'sys.change_tracking_309576141'
sp_spaceused 'sys.syscommittab'