このトピックでは、変更の追跡を管理する方法について説明します。 また、セキュリティを構成し、変更の追跡を使用するときのストレージとパフォーマンスへの影響を判断する方法についても説明します。
変更の追跡の管理
次のセクションでは、変更の追跡の管理に関連するカタログ ビュー、アクセス許可、および設定の一覧を示します。
カタログ ビュー
変更追跡が有効になっているテーブルとデータベースを特定するには、次のカタログ ビューを使用できます。
また、 sys.internal_tables カタログ ビューには、ユーザー テーブルに対して変更の追跡が有効になっているときに作成される内部テーブルが一覧表示されます。
安全
変更追跡関数を使用して 変更追跡情報にアクセスするには、プリンシパルに次のアクセス許可が必要です。
クエリ対象のテーブルに対する変更追跡テーブルの少なくとも主キー列に対する SELECT 権限。
変更が取得されているテーブルに対する VIEW CHANGE TRACKING 権限。 VIEW CHANGE TRACKING 権限は、次の理由で必要です。
変更追跡レコードには、削除された行に関する情報、特に削除された行の主キー値が含まれます。 一部の機密データが削除された後、変更追跡テーブルに対する SELECT 権限がプリンシパルに付与されている可能性があります。 この場合、変更の追跡を使用して、そのプリンシパルが削除された情報にアクセスできないようにします。
変更追跡情報には、更新操作によって変更された列に関する情報を格納できます。 機密情報を含む列に対するプリンシパルのアクセス許可が拒否される可能性があります。 ただし、変更追跡情報を使用できるため、プリンシパルは列の値が更新されたことを判断できますが、プリンシパルは列の値を特定できません。
変更追跡のオーバーヘッドを理解すること
テーブルに対して変更の追跡が有効になっている場合、一部の管理操作が影響を受けます。 次の表に、考慮する必要がある操作と効果を示します。
オペレーション | 変更の追跡が有効になっている場合 |
---|---|
DROP TABLE (テーブルを削除する) | 削除されたテーブルのすべての変更追跡情報が削除されます。 |
テーブル変更 制約削除 | PRIMARY KEY 制約を削除しようとすると失敗します。 PRIMARY KEY 制約を削除するには、変更の追跡を無効にする必要があります。 |
テーブルを変更して列を削除する (ALTER TABLE DROP COLUMN) | 削除される列が主キーの一部である場合、変更の追跡に関係なく、列の削除は許可されません。 削除される列が主キーの一部でない場合、列の削除は成功します。 ただし、このデータを同期しているアプリケーションへの影響を最初に理解する必要があります。 テーブルに対して列変更の追跡が有効になっている場合、削除された列は変更追跡情報の一部として返される可能性があります。 削除された列を処理するのはアプリケーションの役割です。 |
テーブルを変更して列を追加する | 変更履歴テーブルに新しい列が追加された場合、列の追加は追跡されません。 新しい列に加えられた更新と変更のみが追跡されます。 |
ALTER TABLE ALTER COLUMN | 主キー以外の列のデータ型の変更は追跡されません。 |
ALTER TABLE SWITCH | テーブルの一方または両方で変更追跡が有効になっている場合、パーティションの切り替えは失敗します。 |
DROP INDEX または ALTER INDEX DISABLE | 主キーを適用するインデックスを削除または無効にすることはできません。 |
TRUNCATE TABLE | テーブルの切り捨ては、変更の追跡が有効になっているテーブルに対して実行できます。 ただし、操作によって削除された行は追跡されず、有効な最小バージョンが更新されます。 アプリケーションがバージョンを確認すると、バージョンが古すぎて再初期化が必要であることが確認されます。 これは、変更の追跡が無効になり、テーブルに対して再度有効になるのと同じです。 |
変更の追跡を使用すると、操作の一部として格納されている変更追跡情報が原因で、DML 操作にオーバーヘッドが発生します。
DML への影響
変更の追跡は、DML 操作のパフォーマンス オーバーヘッドを最小限に抑えるために最適化されています。 テーブルでの変更追跡の使用に関連するパフォーマンスの増分オーバーヘッドは、テーブルのインデックスが作成され、維持する必要がある場合に発生するオーバーヘッドに似ています。
DML 操作によって変更された行ごとに、行が内部変更追跡テーブルに追加されます。 DML 操作に対するこの影響は、次のようなさまざまな要因によって異なります。
主キー列の数
ユーザー テーブル行で変更されるデータの量
トランザクションで実行されている操作の数
スナップショットの分離を使用すると、変更の追跡が有効かどうかに関係なく、すべての DML 操作のパフォーマンスにも影響します。
記憶域への影響
変更追跡データは、次の種類の内部テーブルに格納されます。
内部変更テーブル
変更の追跡が有効になっているユーザー テーブルごとに 1 つの内部変更テーブルがあります。
内部トランザクション テーブル
データベースには 1 つの内部トランザクション テーブルがあります。
これらの内部テーブルは、次の方法でストレージ要件に影響します。
ユーザー テーブルの各行に対する変更ごとに、行が内部変更テーブルに追加されます。 この行には、小さな固定オーバーヘッドと、主キー列のサイズと同じ可変オーバーヘッドがあります。 この行には、アプリケーションによって設定されたオプションのコンテキスト情報を含めることができます。 また、列の追跡が有効になっている場合、変更された各列には追跡テーブルに 4 バイトが必要です。
コミットされたトランザクションごとに、行が内部トランザクション テーブルに追加されます。
他の内部テーブルと同様に、 sp_spaceused ストアド プロシージャを使用して、変更追跡テーブルに使用される領域を決定できます。 内部テーブルの名前は、次の例に示すように 、sys.internal_tables カタログ ビューを使用して取得できます。
sp_spaceused 'sys.change_tracking_309576141'
sp_spaceused 'sys.syscommittab'
こちらもご覧ください
データ変更の追跡 (SQL Server)
テーブル変更 (Transact-SQL)
[データベースのプロパティ] ([ChangeTracking] ページ)
ALTER DATABASE SET のオプション (Transact-SQL)
sys.change_tracking_databases (Transact-SQL)
sys.change_tracking_tables (Transact-SQL)
データ変更の追跡 (SQL Server)
変更の追跡について (SQL Server)
変更データの管理 (SQL Server)