将20多个数据库移动到新的数据库服务器的最佳方法是什么? SQL 2005

当前数据库服务器:SQL Server 2005 – Windows Server 2003新目标数据库服务器:SQL Server 2005 – Windows Server 2003 Enterprise – VM Ware映像

当前的数据库服务器上有20多个数据库,一些应用程序数据库…其他基础结构types数据库(Citrix)。 我们希望将所有这些数据库移动到一个新build的虚拟化框中。

所以在进一步的总结 – 是的,这是物理的虚拟。 – 20多个数据库转移到这个新的虚拟SQL 2005框。 – 这个盒子上的应用需要最less的停机时间。

我能想到的几种方法(全部都会被testing):1.第三方物理到虚拟转换器 – 然后closures旧盒子。
– 关注= SID关联,Windows或SQL Server不喜欢这个。

  1. 将所有数据库同时移至新服务器 – closures旧服务器,将新虚拟框上的主机名更改为旧主机名。

  2. 一次移动全部,但是使用不同的主机名用于新的盒子 – 这允许在事件中断的情况下并行运行 – challenge =必须在每个应用程序内改变主机名称 – 可能有问题。

  3. 逐步移动每个数据库 – 这个woudl意味着一个新的主机名以及更长的项目。

其他人有类似的情况?

我们从单个SQL服务器移动到新的SQL群集(所有新硬件)。 大约70个数据库。 我们这样做的方式是分离数据库,复制文件,然后将数据库附加到新的SQL节点。

我们被迫更新主机名,但我会把旧的主机名脱机,并使用相同的主机名。 你可以随时切换回来。

减less停机时间的一种方法是使用从一台服务器到另一台服务器的日志传送。 这需要重新configuration应用程序configuration,但它具有减less停机时间的好处。 一般来说,过程如下:

  1. 创build新的服务器并移动作业/login/ SSIS等
  2. 设置日志传送的源数据库并开始传送。
  3. 停止应用程序并将数据库设置为只读。
  4. 备份数据库的最后一个转储日志。
  5. 恢复新服务器上的最后一个tran日志,设置为no-recovery。
  6. 将新的数据库设置回读/写。
  7. 将重新命名的应用程序重新在线。

一对夫妇笔记:

  • 数据库镜像是一个类似的解决scheme。
  • SAN级复制也类似,但它需要特殊的SAN(如HP EVA)。

优点:

  • 最小的停机时间。
  • 日志传送很容易设置。
  • 回滚计划相当简单。

缺点:

  • 更多的手动步骤。
  • 必须检查应用程序,以确保它被正确地重新命名(更多的系统pipe理员/ DBA的工作)。

所以,这是一个权衡,但是这个方法是有效的,这是一个普通的技术。

埃里克 –

并行运行会使数据在您复制和更新副本之间发生变化。 更新应用程序以指向新的主机名也会导致悲伤。

我会build议使用并行设置来testing每个应用程序,但是一旦满足testing,我可能会使用分离/附加: 如何通过使用SQL Server中的分离和附加函数将SQL Server数据库移动到新的位置

从我的经验来看,p2v是一个非常好的select,但是如果你想减less停机时间,这是不理想的。 只有当现有的服务器不是一团糟时,我才会使用它,虚拟化只是为了硬件合理化。 (即你不重命名的盒子,把它放在一个新的AD等)。

如果您使用p2v,则SQL Server和Windows将会正常工作,但在启动p2v之前您需要停止SQL Server服务。 Windows SID的等都将保持不变,而Windows不会将物理和虚拟服务器连接到同一networking。

如果你去附加/分离的方法,那么确保你也复制:

  • sql服务器login
  • SQL Server代理作业(包括备份作业)
  • 链接服务器
  • 扩展存储过程

build立新的基础设施和切入意味着更less的停机时间,但需要更多的工作。 正如所讨论的,对于服务器“切换”来说,logshipping是最快的方法,尤其是如果你有大的数据库。

如果你有几个美元的花费,如300.00左右,请查看iderapipe理工具集。 一个优秀的软件。 我在最近的一个项目中使用它。 它移动了数据库和任何相关对象,包括用户。 这是值得的。 在3次点击中,我移动了所有的数据库。 我仍然使用它来回移动数据库。 我相信他们有一个试用版。 你还可以获得许多其他的工具,比如在数据库中移动用户或对象等。