設定和管理變更追蹤
此主題描述如何啟用、停用和管理變更追蹤。此外，它也會描述如何設定安全性，以及判斷使用變更追蹤對儲存和效能產生的影響。
為資料庫啟用變更追蹤
在您可以使用變更追蹤之前，必須先在資料庫層級啟用變更追蹤。下列範例將示範如何使用 ALTER DATABASE 來啟用變更追蹤：
ALTER DATABASE AdventureWorks2008R2
SET CHANGE_TRACKING = ON
(CHANGE_RETENTION = 2 DAYS, AUTO_CLEANUP = ON);
您也可以使用資料庫屬性 (變更追蹤頁面) 對話方塊，以啟用 SQL Server Management Studio 中的變更追蹤。
當您啟用變更追蹤時，可以指定 CHANGE_RETENTION 和 AUTO_CLEANUP 選項，而且您可以在啟用變更追蹤之後的任何時間變更這些值。
變更保留值會指定保存變更追蹤資訊的期間。早於此期間的變更追蹤資訊會定期遭到移除。當您設定這個值時，應該考量應用程式與資料庫資料表同步處理的頻率。指定的保留期間至少必須與同步處理之間的期間上限一樣長。如果應用程式在較長的間隔上取得變更，所傳回的結果可能會不正確，因為變更資訊的某部分可能已遭到移除。為了避免取得不正確的結果，應用程式可以使用 CHANGE_TRACKING_MIN_VALID_VERSION 系統函數來判斷同步處理之間的間隔是否已經過長。
您可以使用 AUTO_CLEANUP 選項來啟用或停用移除老舊變更追蹤資訊的清除工作。當有暫時性的問題阻礙應用程式同步處理時，這樣的處理方式會很實用，而且在問題解決之前，必須先暫停用來移除早於保留期間之變更追蹤資訊的程序。
如果是使用變更追蹤的任何資料庫，請注意以下事項：
若要使用變更追蹤，資料庫相容性層級必須設定為 90 以上 (含)。如果資料庫的相容性層級低於 90，您也可以設定變更追蹤。不過，用來取得變更追蹤資訊的 CHANGETABLE 函數將會傳回錯誤。
若要確保所有變更追蹤資訊都一致，使用快照隔離是最簡單的方式。基於這個原因，我們強烈建議您將資料庫的快照隔離設定為 ON。如需詳細資訊，請參閱＜使用變更追縱＞。
為資料表啟用變更追蹤
您必須針對您要追蹤的每一個資料表啟用變更追蹤。啟用變更追蹤時，系統會針對資料表中受到 DML 作業影響的所有資料列維護變更追蹤資訊。
下列範例示範如何使用 ALTER TABLE 來為資料表啟用變更追蹤：
ALTER TABLE Person.Person
ENABLE CHANGE_TRACKING
WITH (TRACK_COLUMNS_UPDATED = ON);
您也可以使用資料表屬性 (變更追蹤頁面) 對話方塊，以啟用 SQL Server Management Studio 中的資料表變更追蹤。
當 TRACK_COLUMNS_UPDATED 選項設定為 ON 時，SQL Server Database Engine 會將哪些資料行已更新的相關額外資訊儲存到內部變更追蹤資料表。資料行追蹤只能讓應用程式同步處理已經更新的那些資料行。這樣可以改善效率與效能。但是，由於維護資料行追蹤資訊會增加額外的儲存負擔，所以此選項預設為 OFF。
停用變更追縱
在可以針對資料庫將變更追縱設定為 OFF 之前，必須先針對所有變更追蹤的資料表停用變更追蹤。若要判斷已針對資料庫啟用變更追蹤的資料表，請使用 sys.change_tracking_tables 目錄檢視。
下列範例示範如何使用 ALTER TABLE 來為資料表停用變更追蹤：
ALTER TABLE Person.Person
DISABLE CHANGE_TRACKING;
當資料庫中沒有任何資料表追蹤變更時，您可以為此資料庫停用變更追蹤。下列範例將示範如何使用 ALTER DATABASE 來為資料庫停用變更追蹤：
ALTER DATABASE AdventureWorks2008R2
SET CHANGE_TRACKING = OFF;
管理變更追縱
下列章節列出與管理變更追蹤有關的目錄檢視、權限和設定。
目錄檢視
若要判斷哪些資料表和資料庫已啟用變更追蹤，您可以使用下列目錄檢視：
此外，當針對使用者資料表啟用變更追蹤時，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 或 ALTER INDEX DISABLE |
強制主索引鍵的索引無法加以卸除或停用。 |
TRUNCATE TABLE |
截斷資料表的作業可以在已啟用變更追蹤的資料表上執行。但是，不會追蹤此作業所刪除的資料列，而且會更新最小的有效版本。當應用程式檢查它的版本時，這項檢查會指示此版本太舊，而且需要重新初始化。這與針對資料表停用變更追蹤然後重新啟用相同。 |
使用變更追蹤並不會對 DML 作業造成額外負擔，因為變更追蹤資訊會儲存成作業的一部分。
對 DML 的影響
變更追蹤已經最佳化，可讓 DML 作業的效能負擔降到最低。與在資料表上使用變更追蹤有關的累加效能負擔，類似於針對資料表建立索引而且需要進行維護時所產生的負擔。
對於 DML 作業變更的每一個資料列而言，會將一個資料列新增到內部變更追蹤資料表。這項作業 (相對於 DML 作業) 的影響取決於各種因素，如下列所示：
主索引鍵資料行的數目
在使用者資料表資料列中變更的資料數量
在交易中執行的作業數目
如果您使用了快照隔離，它也會影響所有 DML 作業的效能 (不論是否啟用變更追蹤)。
對儲存的影響
變更追蹤資料會儲存在下列內部資料表類型中：
內部變更資料表
啟用變更追蹤的每個使用者資料表都會有一個內部變更資料表。
內部交易資料表
每個資料庫都有一個內部交易資料表。
這些內部資料表會以下列方式來影響儲存需求：
對於使用者資料表內每一個資料列的每一項變更而言，會將一個資料列新增到內部變更資料表。這個資料列有少量固定的負擔，再加上等於主索引鍵資料行大小的變動負擔。此資料列可以包含應用程式所設定的選擇性內容資訊。此外，如果啟用了資料行追蹤，則每一個變更的資料行在追蹤資料表內都需要 4 個位元組。
針對每個認可的交易，內部交易資料表都會加入一個資料列。
如果是其他內部資料表，您可以使用 sp_spaceused 預存程序來判斷用於變更追蹤資料表的空間。您可以使用 sys.internal_tables 目錄檢視來取得內部資料表的名稱，如下列範例所示：
sp_spaceused 'sys.change_tracking_309576141';
sp_spaceused 'sys.syscommittab';