服務器和應用系統遷移方案

2020-02-14 14:52 作者：艾銻無限 瀏覽量：

 
一、遷移方案總體思路
 
新舊系統的遷移是一個整體系統工程。遷移必須保證用戶系統建設的相關要求，在遷移過程中，我們需要重點考慮幾個問題：
 
1、數據遷移如何保障“業務中斷停機時間”。業務中斷對用用戶無論是生產環境還是測試環境均存在較大的恢復風險，這樣的風險特別是對于時間敏感型數據還是對于數據完整性業務都是不可以接受的。我們基于這樣的要求，考慮到如何將停機時間最小，能否實現0停機的建設目標？
 
i. 對于服務器操作系統而言，我們可以采用P2V的方式，利用操作系統的Volume Shadow Copy卷影副本復制服務作為基礎，來實現在舊系統環境下的系統無修改，無停機的情況下，將數據和應用軟件、操作系統環境、系統環境變量等全部以“快照”形式遷移到新服務器中。由此實現服務器環境的整體遷移。
 
ii. 對于應用IIS和其他應用服務器來說，我們可以基于應用服務器的動態業務擴展集群方式，來實現服務器不停機環境下的增加業務節點操作，這樣可以實現應用服務器“熱添加”到新環境中的故障轉移/負載均衡集群系統中，在部分應用服務中我們可以使用session會話復制來實現舊系統的全局環境變量和會話請求狀態也遷移到新環境中來。考慮到會話復制和狀態的快速實時，我們可以采用會話內存復制，考慮到會話復制和狀態的安全性，我們可以采用會話數據庫復制管理。
 
iii. 對于數據庫而言，我們可以基于數據庫本身自帶的數據庫鏡像技術、數據庫日志傳遞技術來實現各自的分庫、遷移庫的構建，數據庫鏡像技術可以讓我們不但保證數據庫遷移的不停機，而且還可以保證萬一遷移中出現停機故障也不影響源數據庫，而日志傳遞技術構建的遷移可以保證系統數據庫遷移以異步方式進行，這樣可以讓我們的系統環境在網絡出現故障的情況依然可以進行遷移任務窗口的正常工作。
 
2、遷移涉及到的除了應用、實例、數據庫的操作以外，還涉及到遷移前規劃、遷移后測試的完整性測試。這些測試包括但不限于數據一致性測試、數據完整性測試、應用會話狀態完整性測試、連接中斷測試、數據恢復測試。只有這樣才能保證遷移的安全性和有效性。
 
二、服務器硬件環境遷移方案
 
1. 遷移評估
 
遷移前，對遷移方案進行評估以確保遷移成功。首先需要勘察現有系統的架構和資源使用狀況，評估過程必須包含以下信息和內容：
 
 現有系統支撐的服務數量以及在服務器中的分布情況
 
 現有物理服務器資源占用狀況，包括CPU、內存、磁盤和網絡連接狀況，為保證遷移成功，目標虛擬機規格應不低于原物理機標準
 
 當前的物理環境是否支持虛擬化，是否支持資源擴展，因為在遷移之前須在物理服務器上完成虛擬化
 
 對當前的存儲容量和資源利用率進行評估，需在目標系統中規劃好遷移需要的存儲空間。需明確現有存儲如何利用，比如有些服務器是在本地磁盤上創建系統盤和用戶盤，有些服務器則在本地磁盤上創建系統盤而在SAN/NAS上創建用戶盤。
 
2. 遷移計劃
 
通過對現有網絡環境的評估，我們對現有資源利用率，服務以及系統需求非常清晰。評估后才能開始對遷移進行計劃，步驟如下：
 
一、確定遷移步驟，包括所有服務器的遷移先后順序，其順序按風險的高低降序排列。
 
二、確定備份方案，由于現有系統會被加固，某些服務器通過虛擬化重復利用，而在虛擬化前需要清除所有的數據，因此需要對這些服務器進行備份保證服務的連續性。
 
三、確定并準備好遷移所需的工具，包括工具在遷移中必備的一系列功能和使用工具所需具備的網絡環境。
 
四、在實際遷移開始之前確定額外的測試環境，該測試環境能夠引導測試從而確保遷移成功。因此，測試環境需明確設計的服務器和存儲數量。
 
五、規劃網絡環境，由于網絡中的服務器各處不同位置，因此在遷移中需考慮到網絡連接情況、數據備份方式，以及網絡流量來源，確定網絡流量是否會引發網絡擁塞
 
六、確定遷移周期以及參與人員，包括遷移起止時間，團隊能力建設以及團隊成員的角色。
 
3. 測試計劃
 
遷移計劃后，執行小批量的測試遷移方案，這里會涉及到首批遷移的測試和審核，步驟如下：
 
 準備用于測試遷移的測試系統環境，在測試時，第一批服務器將會遷移到該系統環境中。
 
 安裝并核實遷移工具，此時要執行第一批服務器的P2V遷移。
 
 對第一批服務器，需分析存儲系統，不管該服務器在存儲遷移中采用本地磁盤存儲還是遠端SAN/NAS存儲系統。
 
4. 遷移測試
 
在第一批服務器和服務的小批量測試遷移后，需對遷移后的服務器進行測試，包括單元測試和性能測試。
 
5. 遷移實施
 
在遷移實施過程中，所有的服務器都會被遷移到虛擬化系統下。執行步驟如下：
 
 確保批量遷移的整個網絡環境已準備完畢，并通過遷移工具完成源系統和目標系統之間的連通。此處的目標系統屬于中轉系統。
 
 對遷移系統進行性能審核和健康檢查，如果系統狀態監視則停用舊系統并將其服務暫時轉移到新的虛擬化系統中。
 
 進行利舊，對于一部分可用的舊硬件可在服務器虛擬化中重新再利用，一些軟件資源需擴展，如內存和硬盤。這些服務器構成最終的虛擬化基礎設施，即最終系統。
 
 最后，在目標系統和最終系統之間進行V2V遷移。這樣，最終系統完成了現存硬件的重復利用。
 
a. 服務器虛擬化前進行備份
 
為了對舊系統中的物理服務器進行虛擬化，需考慮服務器虛擬化帶來的影響。例如，現有服務器的重復利用，服務器虛擬化時會對這些服務器的CPU，內存以及硬盤資源進行再利用，然而這些服務器上存在某些服務仍在運行，若無備份則會影響現有業務。因此，在執行遷移和虛擬化之前，必須先對需利舊的服務器進行備份。
 
遷移步驟如下圖所示。
 
提供物理備份服務器，并已進行虛擬化，數據和服務器已備份到虛擬化系統。
 
 首先，對于要被遷移的服務器上，一般會存在多種服務正在運行，而且這些服務器在遷移評估后認為在虛擬化場景下可再利用的。但是，遷移過程中不允許存在較長的停機時間，因此需要準備一臺采用虛擬化平臺的備份虛擬機，通過P2V將該服務器備份到虛擬機上。
 
 備份完所有需要進行虛擬化的服務器之后，這些服務器上安裝虛擬化軟件進行虛擬化，根據評估階段確定的容量規劃，在虛擬化平臺上創建相應規格的虛擬機，其計算資源用于承接舊系統中的服務。
 
 準備好所有的虛擬機后，規劃和安裝相關遷移工具，將備份系統中的服務遷移到虛擬化系統的虛擬機中。虛擬機遷移是指將備份的虛擬化系統中的應用服務遷移到最終的虛擬化系統中。
 
 虛擬機遷移完畢后，要對這些服務進行測試，最后停用舊系統，所有服務切換到虛擬化系統中。
 
b. 遷移的詳細操作步驟
 
遷移的具體步驟及描述如下圖所示:
 
A. 在評估階段，虛擬化和遷移之前需收集的信息如下：
 
 性能統計：包括CPU使用率，內存使用率，硬盤IOPS和硬盤使用情況；
 
 物理服務器配置：包括CPU規格，內存容量，硬盤容量
 
 統計物理服務器部署位置，分析是否支持虛擬化，累計支持虛擬化的服務器數量，并規劃出虛擬化中需新增的硬件情況；
 
通過上述無代理收集和代理收集兩種場景收集當前系統的使用和配置情況。可采用華為信息收集工具或者第三方工具。
 
B. 分析現有服務的依賴條件，對當前系統進行備份。
 
上圖描述了一種應用系統下的依賴關系，可作為遷移參考，確定所有服務器的遷移優先級順序。
 
在確定各服務的依賴條件后，對需進行虛擬化的服務器進行備份。具體備份過程參見本小節遷移實施方案中 “服務器虛擬化前進行備份”部分的內容。
 
C. 容量規劃和虛擬化執行
 
根據當前的資源使用和需求情況，計算虛擬化所需的容量。
 
D. 規劃應用服務
 
在華為虛擬化解決方案中，同類虛擬機部署在同一個計算資源池中，在同一個池中可相互共享存儲/計算資源，一個集群的故障不會影響其他資源池。
 
E. 虛擬化規劃和虛擬機分配
 
建立虛擬化平臺后，要準備最終的遷移資源。遷移前，如果服務器a具備雙核CPU和2G內存，那么在虛擬化平臺中就創建一個2核/2G內存的虛擬機，并分配相應的硬盤。
 
F. 規劃遷移工具
 
采用遷移工具從物理或虛擬的服務器向最終的虛擬化系統中進行磁盤復制。
 
G. 通過工具執行在線遷移
 
準備好源系統，目標虛擬機以及目標系統后，決定遷移時需使用的遷移工具和遷移策略。
 
H. 遷移測試
 
遷移后，需進行測試來驗證遷移是否成功，測試場景如下：
 
 應用服務遷移后對虛擬化基本功能的監測；
 
 遷移前后應用服務的特性功能是否幾乎相同；
 
 虛擬化系統的性能監控；
 
 ….
 
I. 停用舊系統
 
截至目前現有的服務器已經被虛擬化和重復使用，其他一些不支持虛擬化的服務器上對應的服務也已經遷移到虛擬化平臺，那么現在可將應用服務切換到虛擬系統并停用舊系統，其步驟如下：
 
 
 
三、應用系統數據庫遷移方案
 
1. 應用服務器遷移到群集環境
 
為滿足企業不斷的成長需求，實現企業服務器的高可伸縮性、高可用、高可靠性和高性能，提升服務器的SLA，Microsoft到目前為止，提出了五種解決方案：
 
我們對于IIS等應用環境以及.net應用程序框架我們提出構建IIS環境的NLB群集，將當前系統不停機加入到NLB群集中，使之成為群集中的一個節點，而新環境則為另外一個節點。實施完成后再退出此遷移群集，將新環境加入到新的構建的NLB群集。
 
微軟的網絡負載平衡可以提供最多32臺主機的負載平衡，當我們的Web站點需要分擔更多用戶訪問請求的時候，負載均衡無疑是值得考慮的一個解決方案。當然NLB也有相應的限制，像廣域網環境中，我們就不能使用NLB進行設置，因為其網絡不允許使用同一個MAC地址，也就違反了NLB的基本要求。   在安全方面，除了我們進行的端口規則設定，Windows 2003 Server本身基于TCP/IP 堆棧的集成是動態的，不用進行任何人工干預，這種設置有效的防止了DOS攻擊等惡意攻擊。除此之外，企業結合自身的網絡安全，確保NLB站點的高效運作。
 
NLB不但能實現均衡負載，而且還能實現多種形式的冗余。NLB主要用于那些文件改動不大，并且不常駐內存的環境，比如WEB服務、FTP服務、和VPN服務等。NLB不適合用于數據庫、郵件等服務，因為不能保證每個節點的數據是一樣的。
 
當用戶訪問集群的時候，集群能將訪問請求分攤到集群中的每個服務器上，以達到均衡負載的效果。這些服務器被稱為集群節點。在負載平衡中，每個節點的文件一般都要求是一樣的。這樣每個節點返回給客戶的結果都是一致的。一般來說組建一個NLB要求至少兩個節點，其中一個節點不能使用，這全部負載將落入到剩下的那個節點上，即全載。Windows server 2003 最多支持32個節點。節點越多，可用性，可靠性就越高。
 
NLB能提供三種冗余功能，軟件冗余、硬件冗余、站點冗余。
 
基于NLB集群的Web網站
 
數據庫設計
 
    1.MSCS，提供后端服務與應用程序的容錯移轉，可提升系統的可用性。常見的應用有SQL Server與Exchange Server等。
 
    MSCS是由客戶端來決定由誰來處理服務請求，所有服務器共享一個共享存儲器來儲存會話狀態。當主動服務器掛了，則繼續由被動服務器接手。被動服務器會從共享存儲器取出會話狀態，繼續未完成的工作，以達到容錯移轉的目的。
 
    2.數據庫是數據管理最有效的手段，要使用它來高效地管理和存取各種數據資源，必須設計出結構合理、功能完善的數據庫。數據庫設計時一項復雜的工作，它是一項涉及多學科的綜合技術，要求數據庫管理員既要懂得數據庫知識，又要充分了解應用領域的專業知識。
 
    在進行數據庫設計時，要根據企業組織中各類用戶的信息要求和處理需求來對數據庫進行設計。數據庫設計的主要內容包過機構性設計和行為特性設計，設計的過程主要包括需求分析、概念設計、邏輯設計和物理設計四個階段。
 
   （1）需求分析
 
    需求分析就是對現實世界要處理的對象進行詳細調查，在了解原系統的概況、確定新系統功能的過程中，獲得用戶對數據庫的數據要求、功能要求、安全要求和完整性要求。
 
   （2）概念設計
 
    概念設計時將需求說明中關于數據的要求，綜合為一個統一的概念模型。概念模型是表達概念模型設計結果的工具，是設計人員對系統的抽象的概括，它能表達用戶的需求，且獨立于支持數據庫的數據庫的管理系統和硬件系統。
 
   （3）邏輯設計
 
    概念設計的結果是得到一個與數據庫的管理系統無關的概念模型，而邏輯設計的目的是吧概念設計的概念模型，轉換成與選用的具體機器上的DBMS所支持的數據模型相符合的邏輯結構。
 
   （4）物理設計
 
    物理設計的任務是確實數據庫的存儲結構，主要包括確定數據庫文件和索引文件的記錄格式和物理結構，懸著存取方法，決定訪問路徑和外存儲器的分配策略，實現完整性和安全性以及程序設計等。
 
對于一個比較大的網站來說，數據庫集群也應該是以集群的方式建立，這樣可以增強網站的性能，提高網站的可靠性。數據庫可分為三類：故障切換集群、分布式數據庫系統、共享磁盤系統。
 
NLB集群系統的總體設計
 
（1）環境下實現Windows 2003服務器集群；
 
（2）在域內環境內的windows2003 web server群集；
 
（3）利用IIS搭建了一個WEB站點，域名為dzx.com。由于業務的逐漸增加，網站速度也越來越慢，而且經常出現故障，為公司的利益帶來了很多的不便；公司決定使用兩臺WEB站點為客戶機提供訪問。因此采用了網絡負載均衡技術。
 
NLB集群工作原理及算法
 
1.NLB的工作原理
 
    當客戶向NLB群集（NLB的虛擬IP地址）發起請求時，其實客戶的請求數據包是發送到所有的NLB節點，然后運行在NLB節點上的NLB服務根據同樣的NLB算法來確定是否應該由自己進行處理，如果不是則丟棄客戶的請求數據包，如果是則進行處理。 如何將請求數據包發送到所有的NLB節點是NLB運行的關鍵之處，單播和多播這兩種操作模式就是用于實現這一需求。NLB不支持單個NLB群集中的單播/多播的混合環境；在每一個NLB群集中，該群集中的所有節點都必須配置為多播或單播，否則，此NLB群集將無法正常工作。
 
2.負載平衡算法
 
    一個負載平衡算法都包含以下三個組成部分：
 
    策略：制定任務放置策略的制定者使用的負載和任務量，以及分配的方式。 傳送策略：基于任務和計算機負載，判定是否要把一個任務傳送到其它計算機上處理。 放置策略：對于適合傳送到其它計算機處理的任務，選擇任務將被傳送的目的計算機。
 
    負載平衡的上述三個部分之間是以不同的方式相互作用的。放置策略利用策略提供的負載，僅當任務被傳送策略判定為適于傳送之后才行動。
 
    總之，負載平衡的目標是：提供最短的平均任務響應時間；能適于變化的負載；是可靠的負載平衡機制。
 
（1）策略
 
    人們用來描述負載采用的參數有：
 
    運行隊列中的任務數、系統調用的速率、CPU上下文切換率、空閑CPU時間百分比、空閑存儲器的大小（K字節）、1分鐘內的平均負載。
 
    對于這些單個的負載描述參數，第（1）個，即采用運行隊列中的任務數作為描述負載的參數被證實是最有效的，即它的平均任務響應時間最短，并且已經得到廣泛應用。但是，假如為了使系統更全面而采集了更多的參數，則往往由于增加了額外開銷，卻得不到所希望的性能改善。例如，采用將六個參數中的某兩個進行"AND"或"OR"組合，得到的平均響應時間反而比單個參數的平均響應時間還要差一些。
 
（2）傳送策略
 
    為了簡單起見，在選用傳送策略時，多選用閥值策略。例如，Eager等人的方法是：在判定是否要在本地處理一個任務時，無需交換計算機之間的狀態，一旦服務隊列或等待服務隊列的長度大于閥值時，就傳送這個任務，而且傳送的是剛剛接收的任務。而進程遷移能夠遷移正在執行的任務，是對這種只能傳送剛剛接收的任務的一種改進。
 
    在模擬研究七個負載平衡算法時，其傳送策略都采用閥值策略。它的閥值策略基于兩個閥值∶計算機的負載閥值Load和任務執行時間閥值TCPU。假如計算機的負載超過Load并且任務的執行時間超過TCPU時，就把此任務傳送到其它計算機執行。
 
（3）放置策略
 
    經過總結，共有以下四種放置策略
 
    ①集中策略。每隔P秒，其中一個計算機被指定為"負載中心"（LIC），接受所有其它負載的變更值，并把它們匯集到一個"負載向量"中，然后把負載向量廣播給所有其它的計算機。當一臺計算機認為一個任務適于傳送到其它計算機上執行時，它就給LIC發送一個請求，并告知當前負載的值。LIC選一臺具有最短運行隊列長度的計算機，并且通知任務所在的計算機把任務發送給它，同時，它把目的主機負載值增加1。
 
    ②閥值策略。隨機選擇一臺計算機，判定若把任務傳送到那臺計算機后，那臺計算機的任務隊列長度是否會超過閥值。假如不超過閥值，就傳送此任務；否則，隨機選擇另一臺計算機，并以同樣方式判定，繼續這樣做直到找到一臺合適的目的計算機，或探測次數超過一個靜態值限制LP，當任務真正到達計算機以后，不管狀態如何，必須處理該任務。
 
    ③最短任務隊列策略。隨機選擇LP臺不同的計算機，察看每臺計算機的任務隊列長度，任務被傳送到具有最短任務隊列長度的計算機。當任務真正到達計算機，無論狀態如何，目的計算機必須處理該任務。對此策略的一個簡單改進時，無論何時，碰到一臺隊列長度為0的計算機時，不再繼續探測，因為可以確定此計算機是一臺可以接受的目的計算機。
 
    ④保留策略。當一個任務從一臺計算機離開時，該計算機檢查本地負載，假如負載小于閥值T1，就探測其它計算機，并在R個負載大于T1的計算機中登記該計算機的名字，并把登記的內容保留到一個棧中。當一個任務到達一臺超載的計算機時，就把這個任務傳送到此臺計算機棧頂的計算機上。假如一個計算機的負載低于T1，就清空棧里保留的所有計算機名。
 
    從論文中，比較了②和③兩種策略，結論是：以簡單（計算不昂貴）的方式，利用少量狀態，第②中方法往往獲得比第③種方法更好的效果。第③中方法比較復雜，它必須用性能的改善來補償額外花費，所以取得的效果會稍差一些。
 
4.3  地址分配
 
在NLB群集中，每臺服務器都會有一個屬于自己的靜態IP地址，同時NLB群集中的所有服務器還有一個共同的IP地址—NLB群集地址；
 
當客戶向NLB群集（NLB的虛擬IP地址）發起請求時，其實客戶的請求數據包是發送到所有的NLB節點，即：NLB算法需要NLB群集中的所有主機都能看到發往群集的每一個數據包。然后運行在NLB節點上的NLB服務根據同樣的NLB算法來確定是否應該由自己進行處理，如果不是則丟棄客戶的請求數據包，如果是則進行處理。
 
網絡負載平衡使得單個子網上的所有群集主機可以同時檢測群集 IP 地址的傳入網絡通信。在每個群集主機上，網絡負載平衡驅動程序充當群集適配器驅動程序和 TCP/IP 堆棧間的過濾器，以便在主機間分配通信。
 
在配置負載均衡的時候步驟主要有三個
 
（1）啟用網絡負載平衡；
 
（2）連接到現存的群集；
 
（3）添加主機到群集。
 
1.啟用網絡負載平衡：在開始——運行中輸入nlbmgr，單擊“確定”按鈕，打開“網絡負載平衡管理器”窗口。如圖所示
 
網絡負載均衡管理器
 
2.右擊“網絡負載均衡群集”，然后單擊“新建群集”命令，然后在彈出如圖5-2的對話框中的IP地址和其他群集信息，選擇群集操作模式為“多播”，然后單擊“下一步”按鈕。在這里添加的IP地址是和DC所在在同一個網段的，在這里使用一個多播的原因是在客戶端是同時能收到信息。
 
3.在“群集IP地址”的對話框中可以添加IP地址，如果有多個群集的IP地址也可以來添加多個IP地址，如圖5-3是添加的端口的IP地址，在本次實驗中只有一個網絡群集的IP地址所以在下面選擇自動添加而不是選擇所有的端口，而在解析的時候是通過DNS服務器解析而沒有使用其他的協議因此所采用TCP協議的端口HTTP80；所以在這里選擇80即可。
 
4.在完成上面群集IP地址的規劃之后，會出現如圖5-4所示的端口規則：端口規則是可以按照群集中每一個成員的負載量來分派客戶端的通信。當然在下面如圖所示的界面中也可以來刪除端口規則。刪除端口規則也可以更加明顯的看出群集的效果，刪除端口規則可以按照端口的優先級來響應客戶機請求，假設當優先級高的出現故障那么優先級低的主機會提供服務。當然對于客戶機來說是感覺不到那個到底出現故障。
 
5.完成上面的步驟在“連接”的對話框中來輸入和服務器相連的IP地址；及192.168.120.1，點擊“連接”就會彈出如圖5-5所示的對話框。然后在下面的接口中選擇服務器的網絡適配器（IP地址）。
 
6.完成上面的步驟基本在DC上的配置就完成了，在這里所采用系統默認的自動狀態，單擊完成即可。但是要明白在配置優先級的時候最多可以配置32位，因為NLB網絡負載均衡做多支持32臺主機。默認情況下他的初始狀態是“已啟動”，設置更高的優先級的原因是當把“端口規則”刪除的并且當其中的一臺的出現故障的時候，優先級就會在這時候起到作用。如圖5-6所示，把第一臺主機的優先級設為1。
 
7.啟動網絡負載平衡后，在下圖中5-7所示：在群集cluster.domain.com中已經有了一臺主機。根據實驗的需求還需要添加一臺主機到群集：如果在第二臺上添加的時候首先會連接到“現存的群集”。
 
8.把第二臺主機連接到現存的群集，在這里連接時候是在第二個服務器上面添加。在第二臺服務器上（IP地址為192.168.20.2）的開始——運行中輸入“nlbmgr”,單擊確定單開“網絡負載均衡管理器”窗口，右擊“網絡負載均衡平衡群集”，然后“選擇連接到現存的”命令。在彈出的的對話框中輸入第一臺計算機的IP地址“192.168.120.2”單擊“連接”然后完成就可了！
 
9. 添加主機到群集；在使用“網絡負載平衡管理器“，右擊“cluster.domain.com”。在彈出的對話框中選擇“添加主機到群集”，添加主機的真正原因就是達到網絡負載平衡的原因，如圖5-9所示：
 
10.在完成上面的配置后，在下面圖的界面中添加將要成為群集成員的IP地址（或者主機的名稱）單擊連接按鈕，將在底部的對話框中會彈出可以用的網絡適配器。選擇要用網絡負載平衡的網絡適配器，即可完成。
 
11.在保持主機參數為默認狀態，注意優先級是“2”它是默認的：一切按照默認的即可。
 
12.添加主機到群集后，在群集cluster.domain.com中會有兩臺服務器，最多可以有32臺主機。在圖5-12中可以知道兩臺主機的IP地址是192.168.20.1和192.168.20.2；這樣就完成了網絡負載均衡的配置了。
 
 
 
網絡負載均衡的最佳操作
 
1.正確保護網絡負載平衡主機和經過負載平衡的應用程序；
 
2. 在每一個群集主機上至少配置兩個網絡適配器，但是并非必要；
 
3.在群集適配器上只使用TCP/IP協議；
 
4.保證群集中的所有主機屬于同一個子網并且客戶機能夠訪問該子網；
 
5.使用網絡負載均衡管理器配置NLB群集；
 
6.不要啟用網絡負載平衡遠程訪問控制；
 
7.啟用日志記錄；
 
8.獨立使用NLB群集和服務器群集。
 
 
 
2. 數據庫遷移實施
 
一、實施概述
 
在做SQL Server數據庫維護的時候，當上司要求我們把幾十G的數據文件搬動到其它服務器，并且要求最小宕機時間的時候，我們有沒什么方案可以做到這些要求呢？
 
在這里我們假設這兩臺機器并不是在一個機房上，這樣看起來我們的解決方案才更有意義，如果你那么好運這兩臺機器在同一個局域網，那么恭喜你，你可以多很多的方案可以做到。
 
二、分析與設計思路
 
其實我們假設的環境有兩個特點：第一個是數據庫文件比較大；第二個就是我們的傳送文件的速度可能會比較慢。也許這傳送速度我們是沒有辦法了，但是我們可以就從文件的大小這個問題出發，結合SQL Server的特性，這樣就有了下面的解決方案了。
 
為了使宕機時間最短，我們這里使用了完整備份和差異備份來遷移數據庫，在白天的時候對需要遷移的數據庫進行一次完整備份（XXX_full.bak），并把備份文件拷貝（這里可以使用FTP軟件進行斷點續傳）到目標服務器進行還原，等到下班時間之后再進行一次差異備份（XXX_diff.bak），再把這個差異備份拷貝到目標服務器，在完整還原的基礎上再進行差異還原。
 
這里的宕機時間 = 差異備份時間 + 傳送差異備份文件時間 + 還原差異備份文件時間，這宕機時間是不是讓你感覺這時間很短呢？
 
 三、參考腳本
 
注意修改下面腳本中數據庫的名稱，還有絕對路徑。
 
--1：完整備份
 
declare @dbname varchar(100)
 
declare @sql nvarchar(max)
 
set @dbname = 'DataBaseName'
 
set @sql = '
 
--'+@dbname+'_full
 
BACKUP DATABASE ['+@dbname+']
 
TO DISK = ''D:\DBBackup\'+@dbname+'_full.bak''
 
WITH NOFORMAT, NOINIT, NAME = '''+@dbname+'-完整數據庫備份'',
 
SKIP, NOREWIND, NOUNLOAD, STATS = 10
 
GO'
 
print @sql
 
 
 
--生成的SQL
 
--DataBaseName_full
 
BACKUP DATABASE [DataBaseName]
 
TO DISK = 'D:\DBBackup\DataBaseName_full.bak'
 
WITH NOFORMAT, NOINIT, NAME = 'DataBaseName-完整數據庫備份',
 
SKIP, NOREWIND, NOUNLOAD, STATS = 10
 
GO
 
 
 
--2：完整備份還原
 
declare @dbname varchar(100)
 
declare @sql nvarchar(max)
 
set @dbname = 'DataBaseName'
 
set @sql = '
 
--RESTORE '+@dbname+'_full
 
RESTORE DATABASE ['+@dbname+']
 
FROM DISK = ''D:\DBBackup\'+@dbname+'_full.bak'' WITH FILE = 1,
 
MOVE N''DataBase_Name'' TO N''D:\DataBase\'+@dbname+'.mdf'',
 
MOVE N''DataBase_Name_log'' TO N''D:\DataBase\'+@dbname+'_log.ldf'',
 
NORECOVERY, NOUNLOAD, REPLACE, STATS = 10
 
GO'
 
print @sql
 
 
 
--生成的SQL
 
--RESTORE DataBaseName_full
 
RESTORE DATABASE [DataBaseName]
 
FROM DISK = 'D:\DBBackup\DataBaseName_full.bak' WITH FILE = 1,
 
MOVE N'DataBase_Name' TO N'D:\DataBase\DataBaseName.mdf',
 
MOVE N'DataBase_Name_log' TO N'D:\DataBase\DataBaseName_log.ldf',
 
NORECOVERY, NOUNLOAD, REPLACE, STATS = 10
 
GO
 
 
 
--3：差異備份
 
declare @dbname varchar(100)
 
declare @sql nvarchar(max)
 
set @dbname = 'DataBaseName'
 
set @sql = '
 
--'+@dbname+'_diff
 
BACKUP DATABASE ['+@dbname+']
 
TO DISK = N''D:\DBBackup\'+@dbname+'_diff.bak''
 
WITH DIFFERENTIAL , NOFORMAT, NOINIT, NAME = N'''+@dbname+'-差異數據庫備份'',
 
SKIP, NOREWIND, NOUNLOAD, STATS = 10
 
GO
 
'
 
print @sql
 
 
 
--生成的SQL
 
--DataBaseName_diff
 
BACKUP DATABASE [DataBaseName]
 
TO DISK = N'D:\DBBackup\DataBaseName_diff.bak'
 
WITH DIFFERENTIAL , NOFORMAT, NOINIT, NAME = N'DataBaseName-差異數據庫備份',
 
SKIP, NOREWIND, NOUNLOAD, STATS = 10
 
GO
 
 
 
--4：差異備份還原
 
declare @dbname varchar(100)
 
declare @sql nvarchar(max)
 
set @dbname = 'DataBaseName'
 
set @sql = '
 
--RESTORE '+@dbname+'_full
 
RESTORE DATABASE ['+@dbname+']
 
FROM DISK = ''D:\DBBackup\'+@dbname+'_diff.bak'' WITH FILE = 1,
 
NOUNLOAD, STATS = 10
 
GO'
 
print @sql
 
 
 
--生成的SQL
 
--RESTORE DataBaseName_full
 
RESTORE DATABASE [DataBaseName]
 
FROM DISK = 'D:\DBBackup\DataBaseName_diff.bak' WITH FILE = 1,
 
NOUNLOAD, STATS = 10
 
GO
 
 
 
四、后記
 
以測試的700G的數據文件，我是通過數據庫的作業進行愚公移山的，搬數據到新的服務器上的，這樣的好處就是對之前的數據庫進行優化，比如進行數據庫參數的設置，比如表分區，在對之前數據庫影響盡量小的情況進行數據搬遷。
 
 
 
四、遷移重難點分析及措施
 
1. 如何保證數據遷移過程中的安全性和操作可審計性？
 
回答：數據遷移中的安全性不可忽略，我們基于多重數據審計功能實現遷移安全性和操作審計性。
 
若要將登錄和密碼從服務器 A 上的 SQL Server 實例傳輸到服務器 B 上的 SQL Server 實例，請執行以下步驟：
 
1 在服務器 A 上，啟動 SQL Server Management Studio，然后連接到要從中移動數據庫的 SQL Server 實例。
 
2 打開新的查詢編輯器窗口，然后運行以下腳本。
 
USE master
 
GO
 
IF OBJECT_ID ('sp_hexadecimal') IS NOT NULL
 
  DROP PROCEDURE sp_hexadecimal
 
GO
 
CREATE PROCEDURE sp_hexadecimal
 
    @binvalue varbinary(256),
 
    @hexvalue varchar (514) OUTPUT
 
AS
 
DECLARE @charvalue varchar (514)
 
DECLARE @i int
 
DECLARE @length int
 
DECLARE @hexstring char(16)
 
SELECT @charvalue = '0x'
 
SELECT @i = 1
 
SELECT @length = DATALENGTH (@binvalue)
 
SELECT @hexstring = '0123456789ABCDEF'
 
WHILE (@i <= @length)
 
BEGIN
 
  DECLARE @tempint int
 
  DECLARE @firstint int
 
  DECLARE @secondint int
 
  SELECT @tempint = CONVERT(int, SUBSTRING(@binvalue,@i,1))
 
  SELECT @firstint = FLOOR(@tempint/16)
 
  SELECT @secondint = @tempint - (@firstint*16)
 
  SELECT @charvalue = @charvalue +
 
    SUBSTRING(@hexstring, @firstint+1, 1) +
 
    SUBSTRING(@hexstring, @secondint+1, 1)
 
  SELECT @i = @i + 1
 
END
 
SELECT @hexvalue = @charvalue
 
GO
 
 
 
IF OBJECT_ID ('sp_help_revlogin') IS NOT NULL
 
  DROP PROCEDURE sp_help_revlogin
 
GO
 
CREATE PROCEDURE sp_help_revlogin @login_name sysname = NULL AS
 
DECLARE @name sysname
 
DECLARE @type varchar (1)
 
DECLARE @hasaccess int
 
DECLARE @denylogin int
 
DECLARE @is_disabled int
 
DECLARE @PWD_varbinary  varbinary (256)
 
DECLARE @PWD_string  varchar (514)
 
DECLARE @SID_varbinary varbinary (85)
 
DECLARE @SID_string varchar (514)
 
DECLARE @tmpstr  varchar (1024)
 
DECLARE @is_policy_checked varchar (3)
 
DECLARE @is_expiration_checked varchar (3)
 
DECLARE @defaultdb sysname
 
 
 
IF (@login_name IS NULL)
 
  DECLARE login_curs CURSOR FOR
 
      SELECT p.sid, p.name, p.type, p.is_disabled, p.default_database_name, l.hasaccess, l.denylogin FROM
 
sys.server_principals p LEFT JOIN sys.syslogins l
 
      ON ( l.name = p.name ) WHERE p.type IN ( 'S', 'G', 'U' ) AND p.name <> 'sa'
 
ELSE
 
  DECLARE login_curs CURSOR FOR
 
      SELECT p.sid, p.name, p.type, p.is_disabled, p.default_database_name, l.hasaccess, l.denylogin FROM
 
sys.server_principals p LEFT JOIN sys.syslogins l
 
      ON ( l.name = p.name ) WHERE p.type IN ( 'S', 'G', 'U' ) AND p.name = @login_name
 
OPEN login_curs
 
FETCH NEXT FROM login_curs INTO @SID_varbinary, @name, @type, @is_disabled, @defaultdb, @hasaccess, @denylogin
 
IF (@@fetch_status = -1)
 
BEGIN
 
  PRINT 'No login(s) found.'
 
  CLOSE login_curs
 
  DEALLOCATE login_curs
 
  RETURN -1
 
END
 
SET @tmpstr = '/* sp_help_revlogin script '
 
PRINT @tmpstr
 
SET @tmpstr = '** Generated ' + CONVERT (varchar, GETDATE()) + ' on ' + @@SERVERNAME + ' */'
 
PRINT @tmpstr
 
PRINT ''
 
WHILE (@@fetch_status <> -1)
 
BEGIN
 
  IF (@@fetch_status <> -2)
 
  BEGIN
 
    PRINT ''
 
    SET @tmpstr = '-- Login: ' + @name
 
    PRINT @tmpstr
 
    IF (@type IN ( 'G', 'U'))
 
    BEGIN -- NT authenticated account/group
 
      SET @tmpstr = 'CREATE LOGIN ' + QUOTENAME( @name ) + ' FROM WINDOWS WITH DEFAULT_DATABASE = [' + @defaultdb + ']'
 
    END
 
    ELSE BEGIN -- SQL Server authentication
 
        -- obtain password and sid
 
            SET @PWD_varbinary = CAST( LOGINPROPERTY( @name, 'PasswordHash' ) AS varbinary (256) )
 
        EXEC sp_hexadecimal @PWD_varbinary, @PWD_string OUT
 
        EXEC sp_hexadecimal @SID_varbinary,@SID_string OUT
 
 
 
        -- obtain password policy state
 
        SELECT @is_policy_checked = CASE is_policy_checked WHEN 1 THEN 'ON' WHEN 0 THEN 'OFF' ELSE NULL END FROM sys.sql_logins WHERE name = @name
 
        SELECT @is_expiration_checked = CASE is_expiration_checked WHEN 1 THEN 'ON' WHEN 0 THEN 'OFF' ELSE NULL END FROM sys.sql_logins WHERE name = @name
 
 
 
            SET @tmpstr = 'CREATE LOGIN ' + QUOTENAME( @name ) + ' WITH PASSWORD = ' + @PWD_string + ' HASHED, SID = ' + @SID_string + ', DEFAULT_DATABASE = [' + @defaultdb + ']'
 
        IF ( @is_policy_checked IS NOT NULL )
 
        BEGIN
 
          SET @tmpstr = @tmpstr + ', CHECK_POLICY = ' + @is_policy_checked
 
        END
 
        IF ( @is_expiration_checked IS NOT NULL )
 
        BEGIN
 
          SET @tmpstr = @tmpstr + ', CHECK_EXPIRATION = ' + @is_expiration_checked
 
        END
 
    END
 
    IF (@denylogin = 1)
 
    BEGIN -- login is denied access
 
      SET @tmpstr = @tmpstr + '; DENY CONNECT SQL TO ' + QUOTENAME( @name )
 
    END
 
    ELSE IF (@hasaccess = 0)
 
    BEGIN -- login exists but does not have access
 
      SET @tmpstr = @tmpstr + '; REVOKE CONNECT SQL TO ' + QUOTENAME( @name )
 
    END
 
    IF (@is_disabled = 1)
 
    BEGIN -- login is disabled
 
      SET @tmpstr = @tmpstr + '; ALTER LOGIN ' + QUOTENAME( @name ) + ' DISABLE'
 
    END
 
    PRINT @tmpstr
 
  END
 
  FETCH NEXT FROM login_curs INTO @SID_varbinary, @name, @type, @is_disabled, @defaultdb, @hasaccess, @denylogin
 
   END
 
CLOSE login_curs
 
DEALLOCATE login_curs
 
RETURN 0
 
GO
 
3 注意：此腳本會在“master”數據庫中創建兩個存儲過程。兩個存儲過程分別命名為“sp_hexadecimal”存儲過程和“sp_help_revlogin”存儲過程。
 
4 運行下面的語句。
 
EXEC sp_help_revlogin
 
5 由“sp_help_revlogin”存儲過程生成的輸出腳本是登錄腳本。此登錄腳本創建具有原始安全標識符 (SID) 和原始密碼的登錄。
 
6 在服務器 B 上，啟動 SQL Server Management Studio，然后連接到您將數據庫移動到的 SQL Server 實例。 重要信息：在執行步驟 5 之前，請檢查“備注”一節中的信息。
 
7 打開新的查詢編輯器窗口，然后運行步驟 3 中生成的輸出腳本。
 
如何解決在運行 SQL Server 的服務器之間移動數據庫時的權限問題
 
· 如果服務器 A 和服務器 B 處于同一域中，則使用相同的 SID。因此，用戶不可能是孤立的。
 
· 在輸出腳本中，通過使用加密密碼來創建登錄。這是因為 CREATE LOGIN 語句中使用了 HASHED 參數。此參數指定在 PASSWORD 參數后輸入的密碼已經過哈希處理。
 
· 默認情況下，只有“sysadmin”固定服務器角色的成員可以從“sys.server_principals”視圖運行 SELECT 語句。除非“sysadmin”固定服務器角色的成員授予用戶必需的權限，否則用戶無法創建或運行輸出腳本。
 
· 本文中的步驟不會為特定登錄傳輸默認數據庫信息。這是因為默認數據庫不可能總是存在于服務器 B 上。若要定義某個登錄的默認數據庫，請使用 ALTER LOGIN 語句，并傳入登錄名和默認數據庫作為參數。
 
· 服務器 A 的排序順序可能不區分大小寫，而服務器 B 的排序順序可能區分大小寫。在此情況下，當您將登錄和密碼傳輸到服務器 B 上的實例之后，必須以大寫字母的形式來鍵入密碼中的所有字母。 或者，服務器 A 的排序順序可能區分大小寫，而服務器 B 的排序順序可能不區分大小寫。在此情況下，您將無法使用傳輸到服務器 B 上的實例的登錄和密碼進行登錄，除非滿足下面的條件之一：
 
o 原始密碼不包含字母。
 
o 原始密碼中的所有字母都是大寫字母。
 
· 服務器 A 和服務器 B 的排序順序可能都區分大小寫，或者可能都不區分大小寫。在這些情況下，用戶不會遇到問題。
 
· 已經位于服務器 B 上的實例中的登錄可能具有與輸出腳本中的某個名稱相同的名稱。在此情況下，當對服務器 B 上的實例運行輸出腳本時，會接收到下面的錯誤消息：
 
消息 15025，級別 16，狀態 1，行 1 服務器主體 'MyLogin' 已存在。
 
· 類似地，已經位于服務器 B 上的實例中的登錄可能具有與輸出腳本中的某個 SID 相同的 SID。在此情況下，當對服務器 B 上的實例運行輸出腳本時，會接收到下面的錯誤消息：
 
消息 15433，級別 16，狀態 1，行 1 所提供的參數 sid 正在使用。
 
· 因此，必須執行以下操作：
 
7 仔細檢查輸出腳本。
 
7 檢查服務器 B 上的實例中的“sys.server_principals”視圖的內容。
 
7 相應地解決這些錯誤消息。
 
· 在 SQL Server 2005 中，登錄的 SID 用作實現數據庫級別訪問的基礎。一個登錄可能在服務器的兩個不同數據庫中具有兩個不同的 SID。在此情況下，該登錄只可以訪問具有與“sys.server_principals”視圖中的 SID 匹配的 SID 的數據庫。在從兩個不同的服務器合并這兩個數據庫時，可能會出現此問題。若要解決此問題，可使用 DROP USERT 語句，從具有不匹配的 SID 的數據庫中手動刪除相應的登錄。然后，通過使用 CREATE USER 語句再次添加該登錄。
 
 
 
2. 如何保證數據庫遷移0停機，實時遷移？
 
回答：我們基于CDC技術 + 數據庫鏡像技術 來實現遷移0停機。
 
在常見的企業數據平臺管理中有一項任務是一直困擾SQL Server DBA們的，這就是對數據更新的監控。很多數據應用都需要捕獲對業務數據表的更新。筆者見過幾種解決方案：
 
1、在數據表中加入特殊的標志列； 2、 通過在數據表上創建觸發器； 3、通過第三方產品，例如IBM的Log Explorer。
 
其實第1種和第2中方案都不好，因為第1種方法需要在應用程序編碼的時候尤為小心，如果有一段數據訪問邏輯忘了更新標志位就會導致遺漏某些數據更新，而第2種方法對性能影響過于明顯，因為觸發器的性能開銷是眾所周知的。第3種方法其實屬于一種叫做Log Audit的方案體系。因為SQL Server同其他關系型數據庫一樣，所有數據操作都會在日志中記錄，因此通過分析日志就可以獲得完整的數據操作歷史。SQL Server其實早就有內部的API可供ISV開發者中Log Audit的方案，不過微軟對這套API控制比較嚴格，只有簽署了一堆協議的核心級合作伙伴才能了解這套API。
 
因此，現對業務數據更新的跟蹤在SQL Server平臺上一直是一件非常頭疼的事情，用戶需要在投入大量開發精力和投入額外采購成本之間做出選擇。幸運的事，微軟終于在SQL Server 2008中提供了一套半公開的Log Audit機制，就是我們所說的Change Data Capture，我們后面簡稱CDC。
 
◆當DML提交到應用數據庫時，SQL Server必須寫入日志，并在緩存中更新數據，然后在檢查點將內存中的數據刷回數據文件。 ◆CDC的內部進程根據CDC的設置，在日志文件中提取更新歷史信息，并將這些個更新信息寫入對應的更新跟蹤表。 ◆DBA或開發人員通過調用CDC的函數來訪問更新跟蹤表，提取感興趣的更新歷史信息，并通過ETL應用程序更新數據倉庫。 ◆理論上面更新跟蹤表事會無限制增長的，因此CDC內部有一個清理進程，在默認情況下更新跟蹤信息在寫入跟蹤表三天后會被自動清理。
 
CDC的配置
 
由于CDC是一項比較高端的功能，因此只有在SQL Server 2008的企業版、開發版和評估版中才能找到CDC功能。
 
啟用數據庫級別的CDC
 
要啟用CDC功能，首先需要一個sysadmin服務器角色的成員用戶激活數據庫級別的CDC，這個過程可以通過sys.sp_cdc_enable_db_change_data_capture存儲過程來完成。如果想知道一個數據庫是否啟用了CDC功能，可以通過查詢sys.databases系統目錄的is_cdc_enabled字段。
 
當一個數據庫啟用CDC功能后，SQL Server會自動在這個數據庫中創建cdc架構和cdc用戶，所有CDC相關的數據表和用戶函數都會存放在cdc架構下。
 
CDC功能啟用后，SQL Server會首先在cdc架構下創建五張表用于記錄一些CDC的原數據，分別是ddl_history，change_tables，captured_columns，index_columns和lsn_time_mapping。
 
在數據庫啟用了CDC后，接下來我們就需要在數據表上啟用CDC了。屬于db_owner角色的用戶可以通過存儲過程sys.sp_cdc_enable_table_change_data_capture來啟用對某張數據表的更新跟蹤，一張數據表最多可以設置兩個跟蹤實例。每個跟蹤實例中可以設置對原始數據表的所有列或部分列進行更新跟蹤。如果想知道數據表是否進行了更新跟蹤，DBA可以查詢sys.tables系統目錄的is_tracked_by_cdc字段。
 
對一張數據表啟用CDC跟蹤實例后，SQL Server會在cdc架構下創建一張數據表用于記錄從日志中解析出來的更新歷史信息。
 
一段CDC的評估腳本
 
為了評估CDC功能，我特地寫了一段腳本如下：
 
1、首先創建一個測試數據庫；
 
2、然后激活TestCDC數據庫上的更新捕獲功能；
 
USE TestCDC
GO
EXEC sp_cdc_enable_db_change_date_capture;
GO
執行了存儲過程sp_cdc_enable_db_change_data_capture后，就會在數據庫TestCDC中看到有一些新的表被創建了，分別是ddl_history，change_tables，captured_columns，index_columns和lsn_time_mapping，并且這5張表都是在cdc架構下。
 
3、然后在TestCDC數據庫中創建測試表
 
USE TestCDC GO CREATE TABLE dbo.Product
(
ProductID int PRIMARY KEY NOT NULL,
ProductName nvarchar(100),
Category nvarchar(50)
)
GO
4、在dbo.Product表上激活更新跟蹤
 
EX
EC sp_cdc_enable_table_change_data_capture'dbo',
'Product',
@role_name= NULL,
@supports_net_changes =1;
成功提交上述命令后，就可以在數據表change_tables，captured_columns和index_columns表中看到相應的記錄，其中change_table中一條，capture_column中三條，index_columns中一條。同時cdc架構下有增加了一張新表叫做dbo_Product_CT，這張表的結構和Product表的結構有點相似，Product表中的三列在dbo_Product_CT中都有，同時dbo_Product_CT表中還增加了_$start_lsn，_$end_lsn，_$seqval，_$operation和_$update_mask五個新的字段。-hU:i B%P%B&X 其實在存儲過程sp_cdc_enable_table_change_data_capture中有一系列的參數，在這里我們為了簡化忽略了一個參數就是@captured_column_list，這個參數可以對表中特定的某些字段啟用更新跟蹤。
 
5、在Product表上提交INSERT語句
 
INSERT INTO dbo.Product VALUES (1, N'ABC', N'A');
提交完了這條命令后，就會在lsn_time_mapping和dbo_Product_CT中分別看到一條新記錄。其中dbo_Product_CT表中的_$operation字段的值是2，_$update_mask字段的值是0x07。 _$operation字段是代表DML操作類型，1是delete，2是insert，3是update的舊值，4是update的新值。 $update_mask字段是表示一個字段列表的掩碼，那些在DML操作中被更新了的字段位為1，而沒有更新的字段位為0。在本例中Product表一共有三列被跟蹤，所以應該是一個三位的二進制數，右邊低位第一位是第一列ProductID，低位第二位是第二列ProductName，第三位就是Category了。因為這是一次INSERT，所以更新涉及到了所有的三列，所以_$update_mask字段就應該是0x7了。
 
6、 繼續在Product表上提交UPDATE語句
 
UPDATE dbo.Product SET Category = N'B' WHERE ProductID = 1;
提交完這條命令后，當然也會在lsn_time_mapping和dbo_Product_CT中看到新記錄了。不過這次lsn_time_mapping中是一條，而dbo_Product_CT中則是兩條。(為什么會這樣呢？建議大家自己試一下咯，一試就明白了。)
 
其中dbo_Product_CT表中的_$operation字段的值是第一條是3，第二條是4，_$update_mask字段的值兩條都是0x04。在這次操作中我們更新的是第三列，所以_$update_mask字段就應該是0x4了。(如果我們更新的是ProductID會發現_$update_mask并非是0x1，而同樣是0x7，這估計是因為ProductID是主鍵，更新主鍵應該視同一條新的記錄。)
7、再來一次UPDATE
 
UPDATE dbo.Product SET Category = N'A' WHERE ProductID = 1;
提交完這條命令后，在dbo_Product_CT中又看到兩條新記錄了。其中dbo_Product_CT表中的_$operation字段的值是第一條是3，第二條是4，_$update_mask字段的值兩條都是0x04。(看來CDC確實會記錄下數據的每次修改。)
 
8、繼續在Product表上提交DML語句
 
DELETE dbo.Product WHERE ProductID = 1;
提交完了這條命令后，就會在lsn_time_mapping和dbo_Product_CT中分別看到一條新記錄。
 
其中dbo_Product_CT表中的_$operation字段的值是1，_$update_mask字段的值是0x07。
 
9、提交一個DDL試試看
 
ALTER TABLE dbo.Product ADD Description nvarchar(100);
提交完這句命令后，只會在ddl_history表中看到一條新的記錄。
 
10、然后再試試DML
 
UPDATE dbo.Product SET Description = N'NA';
提交完這句語句后，所有cdc架構下的表中都沒有看到新記錄。說明新增的列Description不跟蹤更新了......估計有人會說(細心的人哦！)：“這次當然看不到新記錄了，因為在前面第7步我們已經刪除了所有的記錄，因此這次的UPDATE語句沒有影響到任何記錄，當然CDC的表中不會有任何記錄了。”那么到底對Description更新會不會記錄呢，經過測試確實是不記錄的。
 
那么如果我們想對Description也進行更新跟蹤應該怎么辦呢？很簡單的，由另外一個存儲過程叫做sp_cdc_disable_table_change_data_capture可以禁用對某張表的更新跟蹤，可以使用這個存儲過程先對Product表禁用更新跟蹤，然后再重新啟用對Product表的更新跟蹤就可以了。
 
11、最后試一下DROP命令
 
DROP TABLE dbo.Product;
dbo.Product表消失了，同時cdc.dbo_Product_CT表也消失了。
 
12. 評估結束。一定有人問，捕獲到的更新怎么用呢，還有一堆系統函數和存儲過程可以幫助用戶，但是那段測試的過程就不詳細寫了。
 
其中最重要的應該就是cdc.fn_cdc_get_all_changes_和cdc.fn_cdc_get_net_changes_兩個函數了，這兩個函數可以幫助我們獲取dbo_Product_CT表中數據，其中cdc.fn_cdc_get_all_changes_是用于獲取所有更新，而cdc.fn_cdc_get_net_changes_則是用于獲取精簡后的更新，在精簡的更新中有一些重復的更新就會被合并成一條記錄，比如說我們把產品類型由A改為B，然后又改回A，在cdc.fn_cdc_get_all_changes_中應該有3條記錄，而在cdc.fn_cdc_get_net_changes_中則只有1條記錄。兩個函數的范例如下(你會發現精簡結果集的函數運算相當慢，至少在CTP4中是這樣的，不知道以后的版本會不回有改進)：
 
SELECT * FROM cdc.fn_cdc_get_all_changes_dbo_Product(0x00000048000001760004, 0x00000048000001F70004, 'all');
SELECT * FROM cdc.fn_cdc_get_net_changes_dbo_Product(0x00000048000001760004,  0x00000048000001F70004, 'all');