服务器和应用系统迁移方案

一、迁移方案总体思路

新旧系统的迁移是一个整体系统工程。迁移必须保证用户系统建设的相关要求，在迁移过程中，我们需要重点考虑几个问题：

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 中生成的输出脚本。

备注

在对服务器 B 的实例上运行输出脚本之前，请检查以下信息：

· 仔细检查输出脚本。如果服务器 A 和服务器 B 处在不同的域中，则必须修改输出脚本。然后，必须在 CREATE LOGIN 语句中使用新的域名来替换原始域名。新的域中授予访问权限的集成登录不会具有与原始域中的登录相同的 SID。因此，用户会从这些登录中孤立出来。 有关如何解决这些孤立用户的更多信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：

240872

(http://support.microsoft.com/kb/240872/ )

如何解决在运行 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。

CDC的工作原理

我们前面说过CDC是通过分析日志获得数据操作历史信息的，那么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数据库上的更新捕获功能；

执行了存储过程sp_cdc_enable_db_change_data_capture后，就会在数据库TestCDC中看到有一些新的表被创建了，分别是ddl_history，change_tables，captured_columns，index_columns和lsn_time_mapping，并且这5张表都是在cdc架构下。

3、然后在TestCDC数据库中创建测试表

4、在dbo.Product表上激活更新跟踪

成功提交上述命令后，就可以在数据表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语句

提交完了这条命令后，就会在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语句

提交完这条命令后，当然也会在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

提交完这条命令后，在dbo_Product_CT中又看到两条新记录了。其中dbo_Product_CT表中的_$operation字段的值是第一条是3，第二条是4，_$update_mask字段的值两条都是0x04。(看来CDC确实会记录下数据的每次修改。)

8、继续在Product表上提交DML语句

提交完了这条命令后，就会在lsn_time_mapping和dbo_Product_CT中分别看到一条新记录。

其中dbo_Product_CT表中的_$operation字段的值是1，_$update_mask字段的值是0x07。

9、提交一个DDL试试看

提交完这句命令后，只会在ddl_history表中看到一条新的记录。

10、然后再试试DML

提交完这句语句后，所有cdc架构下的表中都没有看到新记录。说明新增的列Description不跟踪更新了……估计有人会说(细心的人哦！)：“这次当然看不到新记录了，因为在前面第7步我们已经删除了所有的记录，因此这次的UPDATE语句没有影响到任何记录，当然CDC的表中不会有任何记录了。”那么到底对Description更新会不会记录呢，经过测试确实是不记录的。

那么如果我们想对Description也进行更新跟踪应该怎么办呢？很简单的，由另外一个存储过程叫做sp_cdc_disable_table_change_data_capture可以禁用对某张表的更新跟踪，可以使用这个存储过程先对Product表禁用更新跟踪，然后再重新启用对Product表的更新跟踪就可以了。

11、最后试一下DROP命令

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中是这样的，不知道以后的版本会不回有改进)：

CDC功能的IO开销

很明显，CDC功能是会产生一定的IO和存储开销的，为了评估CDC功能产生的这些开销。我又进行了一段评测。

整个评估的思路是这样的：

1、创建两个数据库 2、在两个数据库中分别创建一张结构完全相同的表，一个数据库启用CDC功能，而另外一个禁用CDC功能 3、向两张表中写入相同行数的数据 4、视图sys.dm_io_virtual_file_stats来获得两个数据库文件上的 5、利用sysindexes来获得两个数据库中数据表的存储消耗情况

因为是在虚拟机中进行的测试，所以选取了比较小的数据表(AdventureWorks数据库中的SalesOrderDetails)，大约有12万行数据。

评估的结果如下：

从上面两张表中可以看到，CDC激活后日志文件的读会显著增加。原因是CDC在写更新跟踪表时，需要读取日志。

从上面两张表中可以看到激活CDC后数据文件的写入和日志文件写入都会显著增加，不过需要考虑到CDC激活后会需要多写一张表，在本例中就是dbo_SalesOrderDetails_CT，所以这种增加是可以理解的。当然在生产环境中并不会对数据表的所有列进行CDC监控，所以激活CDC对IO写入的影响还需要针对不同情况进行分析。

从上面这张图可以看出，CDC激活后会生产数据表不会消耗更多的存储空间，但是更新跟踪表会需要俄外的存储空间。另外可以发现的一点是，在本例中dbo_SalesOrderDetail_CT表消耗的空间比SalesOrderDetail表多，这是因为在dbo_SalesOrderDetail_CT表中加入了一些额外的字段，例如_$start_lsn和_$end_lsn，同时注意观察dbo_SalesOrderDetail_CT表会发现，SQL Server在这张表上使用_$start_lsn、_$end_lsn和_$seqval三个字段作为聚簇索引，而SalesOrderDetail表上原来的聚簇索引(SalesOrderID，SalesOrderDetailID)再加上_$start_lsn、_$end_lsn和_$seqval三个字段则被创建为一个非聚簇索引，所以这就导致了dbo_SalesOrderDetail_CT表需要消耗比原始表更多的空间，不过原始数据表上的非聚簇索引不会在CDC跟踪表上被创建，这也就说明了原始数据表聚簇索引的大小也会对CDC引发的IO产生影响。

CDC对存储的消耗

为了进一步理解CDC功能对存储的消耗，特别整理了一下CDC的数据开销。首先CDC功能对数据库存储空间产生显著影响的两张表是cdc._CT表和cdc.lsn_time_mapping表，这里简称为表1和表2。

下面是对表1和表2作的一些较为深入地剖析：

1、表1和表2的数据

表1主要由3个binary(10)字段、1个int字段、1个varbinary(128)字段以及所有被选定更新跟踪的原始表字段构成。因此表1每行数据的尺寸大概是在30 + 4 + 5 (因为通常一张表需要监控的字段会在16个以内，所以暂定为2bytes的binary然后加上varbinary数据2个bytes的固定开销)，也就是 39 + x(假定原始表需要监控的字段键总尺寸为x个字节)个字节。

表2则有1个binary(10)字段、2个datetime字段和1个varbinary(10)字段构成。因此表2每行数据应该是20 + 16 + 12 = 48个字节。

2、表1和表2的索引(这个不太好估算，因为不同的表聚簇索引的键值密度是不一样的，一般按照1/4的数据尺寸估算，只有多没有少啦！)

表1的3个binary(10)字段构成了聚簇索引，同时3个binary(10)字段加上原始数据表的聚簇索引构成一个非聚簇索引，同上面一样，我们假定原始表聚簇索引键是x个字节，那么表1的非聚簇索引每行是(30 + y(假定原始表聚簇索引键尺寸为y个字节) + 4(指向聚簇索引的内部指针))个字节。

而表2中的binary(10)字段构成了聚簇索引，其中1个datetime字段构成了非聚簇索引。因此表2的非聚簇索引每行是8 + 4 = 12个字节。
3、对原始数据表的一行数据进行UPDATE操作，会在表1中添加2行数据，而DELETE操作和INSERT操作则会增加1行数据；而对于表2则是每笔事务增加1行数据。

因此我们作如下假定，典型的OLTP环境：

1、原始数据表的聚簇索引为1个整型字段，同时需要监控的字段总尺寸为50字节(约为5个decimal(19)或5个char(10))。 2、对原始表提交100,000个事务。 3、产生1,000,000行次数据操作，其中UPDATE占60%，INSERT和DELETE占40%。 4、那么最终CDC产生的额外数据存储空间应该为(39 + 4 + 50) * (1000000 * 1.2 + 1000000 * 0.4) + 48 * 100000 = 153,600,000个字节，约为164MB(假定数据页填充率为90%)。 5、因此约合200MB左右。

经过这样的对比我们可以知道，CDC在生产环境特别是OLTP环境对存储空间的影响不算太明显的，当然这个还要取决于DBA在原始数据表上选取多少字段进行监控，以及这些字段的数据尺寸，同时还有原始数据表的聚簇索引键值密度。另外需要说明的是表1和表2都是由一个异步的进程通过读取日志来完成的，因此表1和表2的数据刷新和原始数据表的刷新会有一定的延时。

对部署CDC的建议，经过以上测试，我们可以发现以下情况：

◆CDC激活会显著增加日志文件的读操作。 ◆CDC激活后更新跟踪表会产生额外的写入，并消耗存储空间。 ◆CDC激活后，原数据表的聚簇索引尺寸会影响到CDC产生的IO数据量，而原始数据表上的非聚簇索引则不会。 ◆CDC激活后，被选定进行更新跟踪的列键值属性同样会影响到CDC产生的IO数据量和存储空间。

因此如同微软建议的一样，在CDC激活的环境下，应该将更新跟踪表写入与原始表不同的文件组并存放在不同的存储设备上，注意控制需要监控的数据列尺寸，同时应该注意为日志文件选取可提高读取性能的存储硬件上，比如RAID10。

博客摘自：《服务器和应用系统迁移方案》