这篇文章是介绍数据库升级的案例记录一系列文章的第三部分，它描述了如何将在Windows 2000服务器上运行的SQL Server 2000 Active/Active群集升级Windows Server2003/SQL Server 2005 Active/Active群集。咨询师Matthew Schroeder将通过IT世界和数据库管理团队的技术方面和决策过程方面进行详细阐述。这篇文章是基于两个在线升级：一个是商业网、另一个是eBay排序系统。由于考虑到机密原因，我们改变了实际方案的某些细节。

在第二部分已经指出，升级到SQL Server 2005和Windows Server 2003的第一步就是将应用程序指向另一个过渡服务器，该服务器在主要群集重建时还能够运行。如果你仅仅是无法负担几个小时的时间，那么这就是一个相当详细的过程，也是最佳的操作过程。步骤顺序也非常重要，因为一些小性能就能使你的操作失败。我在这里将介绍最小停机时间的一般概念以及你需要考虑的一些事情。

服务器迁移步骤

在进入一些细节步骤之前，将数据库迁移到另一台服务器并且成功切换这一过程似乎很简单。以下是你将数据库迁入副服务器之前需要考虑的一些事项：

1、数据库备份和恢复——你能用复制或者是log shipping代替，这取决于你的方案。我们通常对数据库做一些简单的恢复，获取日志的“末端”并且将副服务器更新。

2、安全——将服务器注册程序迁移至副服务器。确保它们在正确的状态下并而且你还知道密码。

3、孤立行——什么的服务器注册程序和什么数据库用户联系在一起？这些联系一定要是正确的。

4、权限——查明需要什么样的权限才能登录server login。

5、创建Database Mail。

6、设置job Operators。

7、作业从一台服务器迁移到另一台服务器。

8、重建SQL Server原程序。

9、对于最近重建的原SQL Server，通过步骤8重复第一步，然后使用数据镜像将数据库迁移至源SQL Server中。

10、将数据库迁移至源SQL Server中。等待数据库变成同步、关闭你的应用程序并且指向拥有镜像数据库的被重建源SQL Server。这时你能够进行手动故障转移，这样重建的源SQL Server就变成了主要服务器。最后恢复数据库，这样应用程序又回到了联机状态。

充分了解如何处理每个步骤，让我们仔细考虑一下每一步。

数据库备份和恢复

这一步是最简单的。数据库的全部备份在源系统里完成，在过渡服务器里恢复，这时应用程序仍然在运行。然后关闭应用程序，最后连日志末尾也进行了备份。末尾事务日志备份接下来被复制到迁移服务器中，并且进行了恢复。这一步使迁移服务器上的数据库更新至最终的产品副本。

安全和孤立行

Server login必须从源系统迁移到过渡服务器，进行这一操作有两种方法。SQL Server Integration Services有一项Transfer Logins任务，针对它你能够采用将login从一台服务器迁移到另一台服务器这种方法。当然还可以用T-SQL代码，这些代码也可以进行编写用来迁移login。

SSIS有一些不好的功能：这一任务使所有的SQL Server登录程序都不能迁到过渡服务器上，它还获取所有的密码、仅留下SQL Server login 所以对于任意SQL Server login而言，你不得不写一些可以登录脚本、将所有的密码都付值、并且将Server logins和数据库用户联系起来（清除孤立行）。考虑到权限，如果你有很多SQL Server login，最好为正在迁移的login简单地写T-SQL编码。剩下的步骤就是就是真正创建server login。

如果你拥有所有或者是绝大部分Active Directory login，SSIS就是理想的方法。这样在迁移SQL Server logins时就不能获取密码、login也变得无效并且自动和数据库用户联系在一起而不是孤立的，如同SSIS一样。SSIS在对login进行增加、更新和删除以后也就变得更加灵活了。

迁移权限

由于服务器的角色是服务器层面上的权限，权限问题就是一个很复杂的问题。Logins上的用户映射联系是基本上和数据层级权限互相关联。当数据库被恢复到任意地方后，它就已经包括了数据库用户和所有关联角色以及在这一数据库里的权限。唯一遗漏的事情就是相关的server login，它可能是Active Directory (AD) login或者是SQL Server login.。一旦server login和数据库用户想关联，该数据库用户就不再是孤立的，并且该server login也继承了和数据库用户相关联的权限。

SSIS 中的Login Transfer任务应该迁移服务器层面的权限，但是在我们从SQL Server 2000迁移至SQL Server 2005时，这一功能就出现了故障并且只是偶然在SQL Server 2005 SP2上面工作。所以在这种情况下，你需要为迁移服务层面权限写一些脚本。

 　　Database Mail的设置和job Operators

任务创建步骤常常要求设置Database Mail和作业运算符。如果你有自定义的工作目录，有时候你还需要迁移工作目录。

工作迁移

SSIS的Job Transfer任务只能将工作从SQL Server 2005 盒中迁移至另一个2005盒里。也就是说，我们不能使用这一任务进行升级到SQL Server 2005。我们不需要手写每项工作的脚本并且在过渡服务器上运行或者编写一系列自定义SSIS代码。

这一步完成之后，你就能够将应用程序指向过渡服务器，并且正常运行你的操作程序。

重建源系统

由于应用程序在过渡服务器上运行很好，所有的时间就都可以用来重建源系统，而不是采取升级和停机几个小时的方式。

迁回到源系统

你迁回至源系统可以按照迁移至第二个服务器的一样的步骤，只有一点不一样。由于这时过渡服务器是SQL Server 2005、源系统已经重建成为Windows Server 2003/SQL Server 2005 box，数据库镜像（SQL Server 2005功能）现在都能用于迁回至源系统。

首先，在应用程序仍然和过渡服务器相对运行时，应该对过渡服务器数据库进行备份并且将该数据库恢复至最近创建的源系统中。当你恢复时不要重新恢复数据库（而是选取非操作系统选项）并保持相同的名字。你不能恢复数据库，因为这样做会修改LSN（日志序号），这些日志序号是SQL Server用来从过渡服务器数据库中申请事务的。

为了设置数据库镜像，你可能想在过渡服务器（主要的）以及重建的源系统（镜像）这两者上创建终点。高安全模式是最好的，因为它保证了数据库同步性会吸引并且确保数据库在过渡数据库和重建源系统之间保持同步。如果这些数据库同步，你就可以进入下一个步骤。

这个时候数据库应该是同步的。你会想将应用程序指向重建的源系统并且镜像数据库仍然是同步的。应用程序现在处于脱机状态，你需要进行“手动转移”数据库镜像。在过渡服务器上的数据库能够手动转移是因为它处于同步的状态。如果对数据库进行了手动转移，在源系统上的镜像数据库就会被恢复并且可以利用。以前的过渡服务器数据库这时就成为了镜像数据库。

在升级到SQL Server 2005时追求最小的停机时间往往会造成解决办法复杂而且是一种冒险。希望这篇文章能够帮组你减少你工作的危险性。按照以上的步骤进行操作，一切都会变得美好。