管理更新多个数据库的迁移的最佳实践？

Question

我的团队正在评估用于管理数据库迁移/数据库重构的工具和流程，如Martin Fowler，Pramod Sadalage等人所述。阿尔。我们对自动化、可重复、可测试的流程感兴趣，所以我们对每次部署时手动运行SQL Compare之类的技术不感兴趣。我们目前正在使用CruiseControl.NET进行持续集成。

我们的生产环境有多个SQL Server 2000数据库服务器，它们之间有复制。因此，我们的迁移将对源数据库服务器和目标数据库服务器上的模式进行更改。

要使用诸如dbdeploy之类的工具执行这样的迁移，我们似乎需要在其中一台服务器上运行迁移，并且我们必须将其他服务器添加为链接服务器。因此，针对主服务器运行的单个脚本可以针对任何链接服务器执行DDL。

我的问题是:这种方法是否被认为是最佳实践，或者是否有更好的技术来应用涉及多个数据库服务器的迁移？

Answer 1

我看不出这种方法本质上有什么问题，但是在设置它时，一定要测试当其中一个链接服务器宕机时会发生什么。如果某个服务器碰巧关闭，并且您确实想知道更改未应用于该服务器，则您不希望回滚所有其他服务器。

当然，对于任何迁移来说，第一个也是最重要的最佳实践是确保在开始迁移更改之前有一个可靠的备份流程。

Answer 2

Visual Studio2008(团队版，特别是GDR)可以根据定义的模式/元数据文件处理模式的自动部署，您可以将其部署到服务器上。这可以包含在您的build /deploy过程中。然而，我认为在复制和模式更改方面仍然存在一个问题--没有能够理解/感知您的复制设置的包。

例如，我们在订阅服务器上使用自定义复制过程，尽管架构更改是从发布服务器传播的，但有时我们必须手动编写更改脚本，这取决于我们已有的任何自定义复制。如果您不使用自定义复制过程，我会说这是可行的方法。

Answer 3

您可以尝试Chinchillin和Wizardby的组合:在DB服务器上安装Chinchillin代理，并让它在您的部署过程中执行Wizardby迁移脚本。

不过，这种集成正在进行中:)