推薦：解讀SQL Server小知識：Processor Affinity
SQL Server通常都運(yùn)行在多處理器的服務(wù)器上，這一點(diǎn)在現(xiàn)在尤為普遍。原因是多內(nèi)核的處理器越來越普及。 那么，在多處理器環(huán)境下，Windows操作系統(tǒng)(事實(shí)上是從2000開始的)通常都會將

ALTER TABLE dbo.Product ADD Description nvarchar(100);

提交完這句命令后，只會在ddl_history表中看到一條新的記錄。

10、然后再試試DML

UPDATE dbo.Product SET Description = N'NA';

提交完這句語句后，所有cdc架構(gòu)下的表中都沒有看到新記錄。說明新增的列Description不跟蹤更新了......估計(jì)有人會說(細(xì)心的人哦！)：“這次當(dāng)然看不到新記錄了，因?yàn)樵谇懊娴?步我們已經(jīng)刪除了所有的記錄，因此這次的UPDATE語句沒有影響到任何記錄，當(dāng)然CDC的表中不會有任何記錄了。”那么到底對Description更新會不會記錄呢，經(jīng)過測試確實(shí)是不記錄的。

那么如果我們想對Description也進(jìn)行更新跟蹤應(yīng)該怎么辦呢？很簡單的，由另外一個存儲過程叫做sp_cdc_disable_table_change_data_capture可以禁用對某張表的更新跟蹤，可以使用這個存儲過程先對Product表禁用更新跟蹤，然后再重新啟用對Product表的更新跟蹤就可以了。

11、最后試一下DROP命令

DROP TABLE dbo.Product;

dbo.Product表消失了，同時(shí)cdc.dbo_Product_CT表也消失了。

12. 評估結(jié)束。

一定有人問，捕獲到的更新怎么用呢，還有一堆系統(tǒng)函數(shù)和存儲過程可以幫助用戶，但是那段測試的過程就不詳細(xì)寫了。

其中最重要的應(yīng)該就是cdc.fn_cdc_get_all_changes_和cdc.fn_cdc_get_net_changes_兩個函數(shù)了，這兩個函數(shù)可以幫助我們獲取dbo_Product_CT表中數(shù)據(jù)，其中cdc.fn_cdc_get_all_changes_是用于獲取所有更新，而cdc.fn_cdc_get_net_changes_則是用于獲取精簡后的更新，在精簡的更新中有一些重復(fù)的更新就會被合并成一條記錄，比如說我們把產(chǎn)品類型由A改為B，然后又改回A，在cdc.fn_cdc_get_all_changes_中應(yīng)該有3條記錄，而在cdc.fn_cdc_get_net_changes_中則只有1條記錄。兩個函數(shù)的范例如下(你會發(fā)現(xiàn)精簡結(jié)果集的函數(shù)運(yùn)算相當(dāng)慢，至少在CTP4中是這樣的，不知道以后的版本會不回有改進(jìn))：

CDC功能的IO開銷

很明顯，CDC功能是會產(chǎn)生一定的IO和存儲開銷的，為了評估CDC功能產(chǎn)生的這些開銷。我又進(jìn)行了一段評測。

整個評估的思路是這樣的：

1、創(chuàng)建兩個數(shù)據(jù)庫

2、在兩個數(shù)據(jù)庫中分別創(chuàng)建一張結(jié)構(gòu)完全相同的表，一個數(shù)據(jù)庫啟用CDC功能，而另外一個禁用CDC功能

3、向兩張表中寫入相同行數(shù)的數(shù)據(jù)

4、視圖sys.dm_io_virtual_file_stats來獲得兩個數(shù)據(jù)庫文件上的

5、利用sysindexes來獲得兩個數(shù)據(jù)庫中數(shù)據(jù)表的存儲消耗情況

因?yàn)槭窃谔摂M機(jī)中進(jìn)行的測試，所以選取了比較小的數(shù)據(jù)表(AdventureWorks數(shù)據(jù)庫中的SalesOrderDetails)，大約有12萬行數(shù)據(jù)。

分享：看Sql server 2005 找出子表樹
同事在準(zhǔn)備新老系統(tǒng)的切換，清空一個表的時(shí)候往往發(fā)現(xiàn)這個表的主鍵被另一個表用做外鍵，而系統(tǒng)里有太多層次的引用.所以清起來相當(dāng)麻煩 用下面這個腳本可以做到找出一個特定表的引用