随着SQL Server 2005的发布,许多DBA将会想要把他们的现存的数据库升级至新的发布以使用它的所有的新特性。作为这个任务的一部分,DBA必须清楚升级至SQL Server 2005的可行的方法并且必须制定一个策略,它包括升级由于某些问题需要被回滚时的恢复计划。在本课中,我们会探讨2种可行的升级类型,你可以用来把文件从旧的数据库移动到新的数据库的不同的方法,制定用来确认升级成功的测试标准的方法,以及升级的最佳实践。
[@more@]确定适合的升级策略
升级至SQL Server 2005的一个必要任务是选择升级策略,它是你用来升级当前环境的处理过程。这个策略不仅确定你将使用的升级类型——原位升级或并行迁移——而且确定你使用的升级方法,你怎样测试升级,以及升级成功的标准是什么。升级策略结合了这些项以及如果在升级过程中你遭遇无法修正的问题时用来回滚升级的恢复计划。
原位升级
没有可用资源来放置多个数据库环境的组织通常使用原位升级。原位升级使用SQL Server 2005的安装覆盖以前的SQL Server 7.0或SQL Server 2000的安装。在原位升级的过程中,安装过程覆盖以前版本的SQL Server的程序文件。升级过程保留所有存储在以前的SQL Server的实例中的用户数据,这让DBA可以执行升级而不需要移动或恢复现存的用户数据库。
并行迁移
拥有额外的服务器资源的数据库环境可以把他们的SQL Server 7.0或SQL Server 2000的安装并行迁移至SQL Server 2005。并行迁移包含在与你以前的SQL Server的安装所在的相同的服务器或不同的服务器上安装SQL Server 2005。在升级过程中仍然使旧环境保持活动允许在你安装和测试升级后的环境时对原来的数据库环境的持续操作。并行迁移常常可以最小化SQL Server环境的停机时间。表1-4显示了当从不同版本的SQL Server升级至SQL Server 2000 (32位和64位)和SQL Server 2005 (32位和64位)时对并行迁移的支持。
以前版本的SQL Server | SQL Server 2000 (32位) | SQL Server 2000 (64位) | SQL Server 2005 (32位) | SQL Server 2005 (64位) IA64 | SQL Server 2005 (64位) X64 |
---|---|---|---|---|---|
SQL Server 7.0 | Yes | No | Yes | No | No |
SQL Server 2000 (32位) | Yes | No | Yes | No | Yes |
SQL Server 2000 (64位) | No | Yes | No | Yes | No |
SQL Server 2005 (32位) | Yes | No | Yes | No | Yes |
SQL Server 2005 (64位) IA64 | No | Yes | No | Yes | No |
SQL Server 2005 (64位) X64 | Yes | No | Yes | No | Yes |
并行迁移不覆盖你的当前安装上的SQL Server文件,它也不把数据库移动到你的新的SQL Server 2005安装上。DBA需要在通过使用本课下一节中讨论的升级方法之一进行的并行安装之后,把他们的数据库手动移动到新的SQL Server 2005安装上。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/757608/viewspace-900370/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/757608/viewspace-900370/