轉載sqlserver cdc文章，以便有時間自己總結
背景：
在SQLServer2008之前，對資料變更的捕獲通常使用觸發器、時間戳等低效高成本的功能來實現，所以很多系統都沒有做資料變更或者僅僅對核心表做監控。
自從SQLServer2008引入了資料變更捕獲功能（後面簡稱為CDC）後，解決了很多煩惱問題，如客戶2個月前更改了一個數據，但是由於伺服器空間不足，經常只能保留一個月的備份。此時客戶為了逃避因為更改資料帶來的較大負面影響，往往會把責任推給軟體開發商或者運維商，如果此時有變更捕獲的話，就有證據了，當然分析日誌也能實現，但是比較痛苦。適用環境：
詳解：
CDC功能主要捕獲SQLServer指定表的增刪改操作，由於任何操作都會寫日誌（哪怕truncate），所以CDC的捕獲來源於日誌檔案。日誌檔案會把更改應用到資料檔案中，同時也會標記符合要求的資料標記為需要新增跟蹤的項。然後通過一些配套函式，最後寫入到資料倉庫中。大概流程：
步驟：本文中以：AdventureWorks為例
第一步、對目標庫顯式啟用CDC：
在當前庫使用sys.sp_cdc_enable_db。返回0（成功）或1（失敗）。注意，無法對系統資料庫和分發資料庫啟用該功能。且執行者需要用sysadmin角色許可權。
該儲存過程的作用域是整個目標庫。包含元資料、DDL觸發器、cdc架構和cdc使用者。
使用以下程式碼啟用：
| USE AdventureWorks GO EXECUTE sys.sp_cdc_enable_db; GO |
在一開始直接執行時，出現了報錯資訊：
| 訊息22830，級別16，狀態1，過程sp_cdc_enable_db_internal，第193 行 無法更新元資料來指示已對資料庫AdventureWorks 啟用了變更資料捕獲。執行命令'SetCDCTracked(Value = 1)' 時失敗。返回的錯誤為15517: '無法作為資料庫主體執行，因為主體"dbo" 不存在、無法模擬這種型別的主體，或您沒有所需的許可權。'。請使用此操作和錯誤來確定失敗的原因並重新提交請求。 |
這裡引出了另外一個知識點：錯誤號 15517 的錯誤
這種錯誤會在很多地方出現，如還原資料庫的時候也會有可能出現。共同點是：某個/些儲存過程使用了具有WITHEXECUTE AS 的選項。使其在當前庫具有了某個架構，但是當在別的地方執行時，由於沒有這個架構，所以就報錯，解決方法：
| ALTER AUTHORIZATION ON DATABASE::[AdventureWorks] TO [sa] |
| 經過檢查，uspUpdateEmployeeHireInfo這個儲存過程的確有：WITH EXECUTE AS CALLER |
使用sa的原因是即使sa被禁用，sa還是存在的。所以不會報錯。
現在重新執行：
| USE AdventureWorks GO EXECUTE sys.sp_cdc_enable_db; GO |
啟用成功，然後通過以下語句檢查是否成功：
| SELECT is_cdc_enabled,CASEWHEN is_cdc_enabled=0THEN 'CDC功能禁用'ELSE 'CDC功能啟用'END 描述 FROM sys.databases WHERE NAME = 'AdventureWorks' |
建立成功後，將自動新增CDC使用者和CDC架構。
建立這兩個使用者、架構的原因是因為CDC要求獨佔方式使用這兩個架構，所以要單獨建立。如果存在了非CDC功能建立的CDC使用者、架構的話，則需要先刪除該cdc命名的架構，才能開啟。
第二步、對目標表啟用CDC：
使用db_owner角色的成員執行sys.sp_cdc_enable_table為每個需要跟蹤的表建立捕獲例項。然後通過sys.tables目錄檢視中的is_tracked_by_cdc列來判斷是否建立成功。
預設情況下會對錶的全部列做捕獲。如果只需要對某些列做捕獲，可以使用@captured_column_list引數指定這些列。
如果要把更改表放到檔案組裡的話，最好建立單獨的檔案組（最起碼與源表獨立）。
如果不想控制訪問角色，則@role_name必須顯式設定為null。
| sys.sp_cdc_enable_table [ @source_schema = ] 'source_schema', [ @source_name = ] 'source_name' , [ @role_name = ] 'role_name' [,[ @capture_instance = ] 'capture_instance' ] [,[ @supports_net_changes = ] supports_net_changes ] [,[ @index_name = ] 'index_name' ] [,[ @captured_column_list = ] 'captured_column_list' ] [,[ @filegroup_name = ] 'filegroup_name' ] [,[ @partition_switch = ] 'partition_switch' ] |
例子：
把HumanResources.Department 這個表開啟變更捕獲。
| USE AdventureWorks GO EXEC sys.sp_cdc_enable_table@source_schema= 'HumanResources', @source_name = 'Department',@role_name = NULL |
然後查詢是否成功：
| SELECT name , is_tracked_by_cdc , CASE WHEN is_tracked_by_cdc = 0 THEN 'CDC功能禁用' ELSE 'CDC功能啟用' END 描述 FROM sys.tables WHERE OBJECT_ID= OBJECT_ID('HumanResources.Department') |
對錶開啟以後，可以在下圖中看到多了很多cdc架構開頭的表：
啟動之後，可以看到SQLServer代理裡面的作業，也出現了這兩個作業：
下面列出相關的儲存過程：
| Sys.sp_cdc_add_job |
|
| Sys.sp_cdc_generate_wrapper_function |
|
| Sys.sp_cdc_change_job |
|
| Sys.sp_cdc_get_captured_columns |
|
| Sys.sp_cdc_cleanup_change_table |
|
| Sys.sp_cdc_get_ddl_history |
|
| Sys.sp_cdc_disable_db |
說明及例子 建議先禁用表，再禁用庫 |
| Sys.sp_cdc_help_change_data_capture |
|
| Sys.sp_cdc_disable_table |
|
| Sys.sp_cdc_help_jobs |
|
| Sys.sp_cdc_drop_job |
|
| Sys.sp_cdc_scan |
|
| Sys.sp_cdc_enable_db |
|
| Sys.sp_cdc_start_job |
|
| Sys.sp_cdc_enable_table |
|
| Sys.sp_cdc_stop_job |
函式：
| Cdc.fn_cdc_get_all_changes_<capture_instance> |
|
| Sys.fn_cdc_has_column_changed |
|
| Cdc.fn_cdc_get_net_changes_<capture_instance> |
|
| Sys.fn_cdc_increment_lsn |
|
| Sys.fn_cdc_decrement_lsn |
|
| Sys.fn_cdc_is_bit_set |
|
| Sys.fn_cdc_get_column_ordinal |
|
| Sys.fn_cdc_map_lsn_to_time |
|
| Sys.fn_cdc_get_max_lsn |
|
| Sys.fn_cdc_map_time_to_lsn |
|
| Sys.fn_cdc_get_min_lsn |
案例：
下面開始從頭到尾做一個實際案例：
先檢查原庫的內容：可以看到系統表裡面只有一個dbo.sysdiagrams表
然後看看SQLServer代理：可以看到也沒有相關的作業
步驟二：對資料庫啟用CDC資料庫級別功能。必須顯式啟用：
Step1、執行以下語句：
| USE AdventureWorks GO EXEC sys.sp_cdc_enable_db GO |
某些資料庫可能存在一些儲存過程包含有：execute as 等語句，此時會報錯：
文字描述：
| 訊息22830，級別16，狀態1，過程sp_cdc_enable_db_internal，第186 行 無法更新元資料來指示已對資料庫AdventureWorks 啟用了變更資料捕獲。執行命令'SetCDCTracked(Value = 1)' 時失敗。返回的錯誤為15517: '無法作為資料庫主體執行，因為主體"dbo" 不存在、無法模擬這種型別的主體，或您沒有所需的許可權。'。請使用此操作和錯誤來確定失敗的原因並重新提交請求。 訊息266，級別16，狀態2，過程sp_cdc_enable_db_internal，第0 行 EXECUTE 後的事務計數指示BEGIN 和COMMIT 語句的數目不匹配。上一計數= 0，當前計數= 1。 訊息266，級別16，狀態2，過程sp_cdc_enable_db，第0 行 EXECUTE 後的事務計數指示BEGIN 和COMMIT 語句的數目不匹配。上一計數= 0，當前計數= 1。 訊息3998，級別16，狀態1，第1 行 在批處理結束時檢測到不可提交的事務。該事務將回滾。 |
如果出現這個錯誤，目前的解決方法是執行下面語句，原因已在開頭說明，對於沒有使用EXECUTE AS的庫，一般不會有這樣的問題：
| ALTER AUTHORIZATION ON DATABASE::[AdventureWorks] TO [sa] |
然後再次執行，就成功開啟了：
| USE AdventureWorks GO EXEC sys.sp_cdc_enable_db GO |
現在檢查是否成功：
| SELECT is_cdc_enabled , CASE WHEN is_cdc_enabled = 0 THEN 'CDC功能禁用' ELSE 'CDC功能啟用' END 描述 FROM sys.databases WHERE NAME = 'AdventureWorks' |
現在檢查表和作業：
作業沒有改變
角色許可權中多出了：
步驟三：對某些表開啟捕獲：
這裡選擇HumanResources.Department、Person.ADDRESS、Person.Contact 開啟：
先來看開啟之前的樣子：
然後對該表開啟：
| USE AdventureWorks; GO EXECUTE sys.sp_cdc_enable_table @source_schema = N'HumanResources' , @source_name = N'Department' , @role_name = N'cdc_Admin'--可以自動建立 , @capture_instance=DEFAULT GO |
結果如圖:
可以看到在建立的同時,也建立了兩個作業: cdc.AdventureWorks_cleanup和cdc.AdventureWorks_capture
也可以看到多了一個角色CDC_ADMIN，是在上面語句中動態建立的：
按照上面步驟把另外兩個表也開啟了：
| USE AdventureWorks; GO EXECUTE sys.sp_cdc_enable_table @source_schema = N'Person' , @source_name = N'ADDRESS' , @role_name = N'cdc_Admin'--可以自動建立 , @capture_instance=DEFAULT GO EXECUTE sys.sp_cdc_enable_table @source_schema = N'Person' , @source_name = N'Contact' , @role_name = N'cdc_Admin'--可以自動建立 , @capture_instance=DEFAULT GO |
可以從系統表中看到：
了3個表，並且是剛才開啟CDC功能的表。現在來檢查是否開啟成功：
| SELECT name , is_tracked_by_cdc , CASE WHEN is_tracked_by_cdc = 0 THEN 'CDC功能禁用' ELSE 'CDC功能啟用' END 描述 FROM sys.tables WHERE OBJECT_ID IN( OBJECT_ID('HumanResources.Department'), OBJECT_ID('Person.ADDRESS'), OBJECT_ID('Person.Contact') ) |
結果如下：
步驟三：檢驗：
下面來改動資料：
然後把表中的資料複製一份：
| INSERT INTO HumanResources.Department ( Name , GroupName , ModifiedDate ) SELECT Name + '1' , GroupName + '1' , GETDATE() ModifiedDate FROM HumanResources.Department |
結果如下：
然後從 cdc . HumanResources_Department_CT 表查詢：
可以看到的確多了16條記錄。這部分記錄證明了，有16條資料從監控到目前為止做了改動，現在再來改動一下：
| DELETE FROM HumanResources.Department WHERE DepartmentID>17 |
再查詢cdc表，可以看到又多了16條記錄：
現在來做下update的實驗：
| UPDATE HumanResources.Department SET ModifiedDate=GETDATE() |
再檢視：
現在來分析一下這個表：
可以在聯機叢書上檢視：cdc.<capture_instance>_CT 可以看到，這樣命名的表，是用於記錄源表更改的表。對於insert/delete操作，會有對應的一行記錄，而對於update，會有兩行記錄。
對於__$operation列：1 = 刪除、2= 插入、3= 更新（舊值）、4= 更新（新值）
對於__$start_lsn列：由於更改是來源與資料庫的事務日誌，所以這裡會儲存其事務日誌的開始序列號（LSN）
但是微軟不檢查直接查詢這類表，建議使用cdc.fn_cdc_get_all_changes_<捕獲例項> 和cdc.fn_cdc_get_net_changes_<capture_instance> 來查詢
下文開始，來熟悉各種函式、儲存過程的使用，並嘗試一些不正常的操作。
日常使用情景：
1、查詢已經開啟的捕獲例項：
由於可能不記得或者不知道開啟了什麼表的捕獲，所以可以使用以下語句來查詢：
| --返回所有表的變更捕獲配置資訊 EXECUTE sys.sp_cdc_help_change_data_capture; GO |
可以看到以下截圖：
檢視對某個例項(即表)的哪些列做了捕獲監控:
| EXEC sys.sp_cdc_get_captured_columns @capture_instance = 'HumanResources_Department' -- sysname |
得到下圖:
也可以從下面中查詢配置資訊：
| SELECT * FROM msdb.dbo.cdc_jobs |
如圖：
2、檢視當前配置使用sp_cdc_help_jobs：
從上文可以看到，啟用cdc之後會自動建立了兩個作業，可以先使用以下語句來檢視：
| sp_cdc_help_jobs |
對於一個大型的OLTP系統，由於資料更改會非常頻繁，變更表中的資料會非常多，如果存放過久（最久可以存放100年），那對資料庫空間是非常大的挑戰。此時可以調整上圖中cdc.AdventureWorks_cleanup 中retention（單位：分鐘）。
3、修改配置：sp_cdc_change_job：
| --顯示原有配置： EXEC sp_cdc_help_jobs GO --更改資料保留時間為分鐘 EXECUTE sys.sp_cdc_change_job @job_type = N'cleanup', @retention=100 GO --停用作業 EXEC sys.sp_cdc_stop_jobN'cleanup' GO --啟用作業 EXEC sys.sp_cdc_start_jobN'cleanup' GO --再次檢視 EXEC sp_cdc_help_jobs GO |
得到以下結果：
證明修改成功，此處注意，修改後要先停用（如果已經啟用），再啟用，才能生效。
4、停止/啟用、刪除/建立作業：
停止/開始作業，可以使用以下語句：
| --停用作業 EXEC sys.sp_cdc_stop_jobN'cleanup' GO --啟用作業 EXEC sys.sp_cdc_start_jobN'cleanup' GO |
刪除作業：
| EXEC sys.sp_cdc_drop_job@job_type = N'cleanup' -- nvarchar(20) GO --檢視作業 EXEC sys.sp_cdc_help_jobs GO |
可以看到現在只剩下一個作業了:
建立作業：
| EXEC sys.sp_cdc_add_job @job_type = N'cleanup', @start_job = 0, @retention = 5760 --檢視作業 EXEC sys.sp_cdc_help_jobs GO |
下面看到已經建立成功:
5、DDL變更捕獲：
CDC除了捕獲資料變更之外，還能捕獲DDL操作的變化。前提是先要確保SQLServer 代理的啟用，其實CDC功能都需要確保sql 代理正常執行，因為所有操作都通過代理中的兩個作業來實現的。
現在先來對HumanResources.Department 表修改一下，把name的長度加長：
| ALTER TABLE HumanResources.Department ALTER COLUMN Name NVARCHAR(120) ; GO |
然後查詢ddl記錄表：
| SELECT * FROM cdc.ddl_history |
可以看到：
由於在截圖之前已經試了幾次，所以裡面有3條資料，之所以試了幾次，就是因為上面所說的，忘了開SQL代理，所以查不出資料，所以切記要開啟SQL代理。
6、使用CDC的函式來獲取更改：
A、使用cdc.fn_cdc_get_all_changes_HumanResources_Department 函式報告捕獲例項HumanResources_Department 的當前所有可用更改：
| DECLARE @from_lsn binary(10), @to_lsn binary(10) SET @from_lsn = sys.fn_cdc_get_min_lsn('HumanResources_Department') SET @to_lsn = sys.fn_cdc_get_max_lsn() SELECT * FROM cdc.fn_cdc_get_all_changes_HumanResources_Department (@from_lsn, @to_lsn, N'all update old'); GO |
B、獲取某個時間段的更改資訊：
先根據日誌序列號（logsequence number ,LSN）來獲取跟蹤變更資料：
Sys.fn_cdc_map_time_to_lsn獲取變更範圍內的最大、最小LSN值。可以使用：
Smallest greater than;smallest greater than orequal;largest less than;largest less than or equal.
如查詢某個時間段插入的資料：
| --插入資料 INSERT INTO HumanResources.Department(name,GroupName,ModifiedDate) VALUES('test','abc',GETDATE()) INSERT INTO HumanResources.Department(name,GroupName,ModifiedDate) VALUES('test1','abc1',GETDATE()) go --檢查資料 DECLARE @bglsn VARBINARY(10)=sys.fn_cdc_map_time_to_lsn('smallest greater than or equal','2012-10-12 12:00:00.997') DECLARE @edlsn VARBINARY(10)=sys.fn_cdc_map_time_to_lsn('largest less than or equal',GETDATE()) SELECT DepartmentID,GroupName,Name FROM cdc.HumanResources_Department_CT WHERE [__$operation]=2 AND [__$start_lsn] BETWEEN @bglsn AND @edlsn |
得到以下結果：
C、sys.fn_cdc_map_lsn_to_time 查詢變更時間：
| SELECT [__$operation] , CASE [__$operation] WHEN 1 THEN '刪除' WHEN 2 THEN '插入' WHEN 3 THEN '更新（捕獲的列值是執行更新操作前的值）' WHEN 4 THEN '更新（捕獲的列值是執行更新操作後的值）' END [型別], sys.fn_cdc_map_lsn_to_time([__$start_lsn]) [更改時間] , name , DepartmentID , GroupName , ModifiedDate FROM cdc.HumanResources_Department_CT |
結果:
注意,由於該表剛好有一個modfieddate欄位,所以和更改時間相同.
D、獲取LSN邊界：
| SELECT sys.fn_cdc_get_max_lsn()[資料庫級別的最大LSN], sys.fn_cdc_get_min_lsn('cdc.HumanResources_Department_CT')[捕獲例項的lsn] |
這兩個值可以用於上面提到的函式裡面用於篩選資料之用。
以上是一邊測試一邊記錄的結果，可能存在很多片面的地方，歡迎拍磚