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

評估的結(jié)果如下：

　　圖2

從上面兩張表中可以看到，CDC激活后日志文件的讀會顯著增加。原因是CDC在寫更新跟蹤表時(shí)，需要讀取日志。

　　圖3

　　圖4

從上面兩張表中可以看到激活CDC后數(shù)據(jù)文件的寫入和日志文件寫入都會顯著增加，不過需要考慮到CDC激活后會需要多寫一張表，在本例中就是dbo_SalesOrderDetails_CT，所以這種增加是可以理解的。當(dāng)然在生產(chǎn)環(huán)境中并不會對數(shù)據(jù)表的所有列進(jìn)行CDC監(jiān)控，所以激活CDC對IO寫入的影響還需要針對不同情況進(jìn)行分析。

　　圖5

從上面這張圖可以看出，CDC激活后會生產(chǎn)數(shù)據(jù)表不會消耗更多的存儲空間，但是更新跟蹤表會需要俄外的存儲空間。另外可以發(fā)現(xiàn)的一點(diǎn)是，在本例中dbo_SalesOrderDetail_CT表消耗的空間比SalesOrderDetail表多，這是因?yàn)樵赿bo_SalesOrderDetail_CT表中加入了一些額外的字段，例如_$start_lsn和_$end_lsn，同時(shí)注意觀察dbo_SalesOrderDetail_CT表會發(fā)現(xiàn)，SQL Server在這張表上使用_$start_lsn、_$end_lsn和_$seqval三個(gè)字段作為聚簇索引，而SalesOrderDetail表上原來的聚簇索引(SalesOrderID，SalesOrderDetailID)再加上_$start_lsn、_$end_lsn和_$seqval三個(gè)字段則被創(chuàng)建為一個(gè)非聚簇索引，所以這就導(dǎo)致了dbo_SalesOrderDetail_CT表需要消耗比原始表更多的空間，不過原始數(shù)據(jù)表上的非聚簇索引不會在CDC跟蹤表上被創(chuàng)建，這也就說明了原始數(shù)據(jù)表聚簇索引的大小也會對CDC引發(fā)的IO產(chǎn)生影響。

CDC對存儲的消耗

為了進(jìn)一步理解CDC功能對存儲的消耗，特別整理了一下CDC的數(shù)據(jù)開銷。首先CDC功能對數(shù)據(jù)庫存儲空間產(chǎn)生顯著影響的兩張表是cdc._CT表和cdc.lsn_time_mapping表，這里簡稱為表1和表2。

下面是對表1和表2作的一些較為深入地剖析：

1、表1和表2的數(shù)據(jù)

表1主要由3個(gè)binary(10)字段、1個(gè)int字段、1個(gè)varbinary(128)字段以及所有被選定更新跟蹤的原始表字段構(gòu)成。因此表1每行數(shù)據(jù)的尺寸大概是在30 4 5 (因?yàn)橥ǔＲ粡埍硇枰�監(jiān)控的字段會在16個(gè)以內(nèi)，所以暫定為2bytes的binary然后加上varbinary數(shù)據(jù)2個(gè)bytes的固定開銷)，也就是 39 x(假定原始表需要監(jiān)控的字段鍵總尺寸為x個(gè)字節(jié))個(gè)字節(jié)。

表2則有1個(gè)binary(10)字段、2個(gè)datetime字段和1個(gè)varbinary(10)字段構(gòu)成。因此表2每行數(shù)據(jù)應(yīng)該是20 16 12 = 48個(gè)字節(jié)。

2、表1和表2的索引(這個(gè)不太好估算，因?yàn)椴煌�的表聚簇索引的鍵值密度是不一樣的，一般按照1/4的數(shù)據(jù)尺寸估算，只有多沒有少啦！)

表1的3個(gè)binary(10)字段構(gòu)成了聚簇索引，同時(shí)3個(gè)binary(10)字段加上原始數(shù)據(jù)表的聚簇索引構(gòu)成一個(gè)非聚簇索引，同上面一樣，我們假定原始表聚簇索引鍵是x個(gè)字節(jié)，那么表1的非聚簇索引每行是(30 y(假定原始表聚簇索引鍵尺寸為y個(gè)字節(jié)) 4(指向聚簇索引的內(nèi)部指針))個(gè)字節(jié)。

而表2中的binary(10)字段構(gòu)成了聚簇索引，其中1個(gè)datetime字段構(gòu)成了非聚簇索引。因此表2的非聚簇索引每行是8 4 = 12個(gè)字節(jié)。

3、對原始數(shù)據(jù)表的一行數(shù)據(jù)進(jìn)行UPDATE操作，會在表1中添加2行數(shù)據(jù)，而DELETE操作和INSERT操作則會增加1行數(shù)據(jù)；而對于表2則是每筆事務(wù)增加1行數(shù)據(jù)。

因此我們作如下假定，典型的OLTP環(huán)境：

1、原始數(shù)據(jù)表的聚簇索引為1個(gè)整型字段，同時(shí)需要監(jiān)控的字段總尺寸為50字節(jié)(約為5個(gè)decimal(19)或5個(gè)char(10))。

2、對原始表提交100,000個(gè)事務(wù)。

3、產(chǎn)生1,000,000行次數(shù)據(jù)操作，其中UPDATE占60%，INSERT和DELETE占40%。

4、那么最終CDC產(chǎn)生的額外數(shù)據(jù)存儲空間應(yīng)該為(39 4 50) * (1000000 * 1.2 1000000 * 0.4) 48 * 100000 = 153,600,000個(gè)字節(jié)，約為164MB(假定數(shù)據(jù)頁填充率為90%)。

5、因此約合200MB左右。

經(jīng)過這樣的對比我們可以知道，CDC在生產(chǎn)環(huán)境特別是OLTP環(huán)境對存儲空間的影響不算太明顯的，當(dāng)然這個(gè)還要取決于DBA在原始數(shù)據(jù)表上選取多少字段進(jìn)行監(jiān)控，以及這些字段的數(shù)據(jù)尺寸，同時(shí)還有原始數(shù)據(jù)表的聚簇索引鍵值密度。另外需要說明的是表1和表2都是由一個(gè)異步的進(jìn)程通過讀取日志來完成的，因此表1和表2的數(shù)據(jù)刷新和原始數(shù)據(jù)表的刷新會有一定的延時(shí)。

對部署CDC的建議ITPUB個(gè)人空間，經(jīng)過以上測試，我們可以發(fā)現(xiàn)以下情況：

◆CDC激活會顯著增加日志文件的讀操作。

◆CDC激活后更新跟蹤表會產(chǎn)生額外的寫入，并消耗存儲空間。

◆CDC激活后，原數(shù)據(jù)表的聚簇索引尺寸會影響到CDC產(chǎn)生的IO數(shù)據(jù)量，而原始數(shù)據(jù)表上的非聚簇索引則不會。

◆CDC激活后，被選定進(jìn)行更新跟蹤的列鍵值屬性同樣會影響到CDC產(chǎn)生的IO數(shù)據(jù)量和存儲空間。ITPUB個(gè)人空間

因此如同微軟建議的一樣，在CDC激活的環(huán)境下，應(yīng)該將更新跟蹤表寫入與原始表不同的文件組并存放在不同的存儲設(shè)備上，注意控制需要監(jiān)控的數(shù)據(jù)列尺寸，同時(shí)應(yīng)該注意為日志文件選取可提高讀取性能的存儲硬件上，比如RAID10。