简体繁体 English

将 SQL 服务器 2000 升级到 2008 R2 并进行复制

[英]Upgrade SQL Server 2000 to 2008 R2 with replication

原文 2011-04-29 20:49:51 5 4 sql-server

I have been looking into this project for a side-by-side upgrade solution.我一直在研究这个项目以寻求并行升级解决方案。 The most widely suggested/used solution is to do a full back of SQL Server 2000 database and restore on SQL Server 2008 with norecovery.最广泛建议/使用的解决方案是完整备份 SQL Server 2000 数据库，并在 SQL Server 2008 上进行恢复，而无需恢复。 Then restore the subsequent transaction log backups with norecovery.然后使用 norecovery 恢复后续的事务日志备份。 When we are ready to switch, change SQL Server 2000 to read-only mode, backup the tail-log and restore it on SQL Server 2008 with recovery.当我们准备好切换时，将 SQL Server 2000 更改为只读模式，备份 tail-log 并在 SQL Server 2008 上恢复并恢复。 Then bring SQL Server 2008 online.然后将 SQL Server 2008 上线。

But, can't the upgrade be done with transactional replication where SQL Server 2000 is the publisher and SQL Server 2008 is the subscriber.但是，不能通过事务复制完成升级，其中 SQL Server 2000 是发布者，SQL Server 2008 是订阅者。 Script all objects such as logins, indexes, etc and apply to SQL Server 2008. When we are ready to switch, we will stop replication, delete all replication jobs, and switch all apps to connect to SQL Server 2008. I haven't found anyone that suggests this method.编写所有对象，如登录名、索引等，并应用于 SQL Server 2008。当我们准备切换时，我们将停止复制，删除所有复制作业，并将所有应用程序切换到连接到 SQL Server 2008。我还没有找到任何建议这种方法的人。 Is there anything wrong with it?有什么问题吗？

4 个解决方案

If you aren't replicating otherwise, creating a replication subscription will change your schema and a few settings.如果您不以其他方式进行复制，则创建复制订阅将更改您的架构和一些设置。 For example, you may end up with GUIDs generated for all your rows just to facilitate the replication.例如，您最终可能会为所有行生成GUIDs ，只是为了便于复制。

The method of data migration you describe is possible to perform using SQL Server Replication.您描述的数据迁移方法可以使用 SQL 服务器复制来执行。

There is nothing wrong with this method or any other data migration method for that matter, so long as the choice you decide upon addresses the specific requirements of your project/application platform.这种方法或任何其他数据迁移方法都没有问题，只要您决定的选择能够满足您的项目/应用程序平台的特定要求。

That said the method you describe is certainly more technically involved in both the configuration and implementation of the actual migration steps.也就是说，您描述的方法在实际迁移步骤的配置和实施中肯定在技术上涉及更多。 If you can accept downtime, a simple backup and restore process is certainly going to be much more straight forward.如果您可以接受停机时间，那么简单的备份和恢复过程肯定会更加直接。 Log shipping would also be another simpler migration method.日志传送也是另一种更简单的迁移方法。

So far, you know that the replication method could work in theory.到目前为止，您知道复制方法在理论上是可行的。 Now is the time to build out a working solution in test in order to validate your data migration strategy and to practice the implementation process.现在是时候在测试中构建一个可行的解决方案，以验证您的数据迁移策略并实践实施过程。

Caution - transactional replication will turn off all IDENTITY columns at the subscriber (the transactional replication SPs actually depend on this fact, as they insert into the IDENTITY columns without first specifying IDENTITY_INSERT ON).注意 - 事务复制将关闭订阅服务器上的所有 IDENTITY 列（事务复制 SP 实际上依赖于这一事实，因为它们在没有首先指定 IDENTITY_INSERT ON 的情况下插入 IDENTITY 列）。 I can only confirm this is the case when the subscriber is SQL 2000 as well - perhaps the subscriber on 2008 will behave differently.我只能确认当订阅者也是 SQL 2000 时就是这种情况 - 也许 2008 年的订阅者会表现不同。

For this reason, transactional replication with SQL 2K doesn't really give you a hot standby.因此，使用 SQL 2K 的事务复制并不能真正为您提供热备用。 We had to do a fair bit of SQL tweaking (re-instating the IDENTITY columns & re-writing the replication SPs with IDENTITY_INSERT wrappers) to get ourselves a situation where the subscriber actually works as a hot standby, ready to have applications pointed at it.我们必须对 SQL 进行相当多的调整（重新设置 IDENTITY 列并使用 IDENTITY_INSERT 包装器重新编写复制 SP），以使订户实际用作热备用，准备好让应用程序指向它. But it certainly wouldn't work out of the box =)但它肯定不会开箱即用 =)

Yes, it will work, provided that you transfer the other objects over.是的，只要您将其他对象转移过来，它就会起作用。