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

【问题标题】：Best practices for managing migrations that update several databases?管理更新多个数据库的迁移的最佳实践？
【发布时间】：2010-10-20 10:27:32
【问题描述】：

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

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

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

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

【问题讨论】：

标签： sql-server continuous-integration linked-server database-migration

【解决方案1】：

在 Red Gate，我们现在有了一个使用 SQL 比较和 SQL 源代码控制的可重复迁移解决方案。因此，SQL Compare 命令行可用于支持持续集成过程。

http://www.red-gate.com/MessageBoard/viewtopic.php?t=14107

它目前是早期访问版本，因此我们渴望获得尽可能多的反馈。

【讨论】：

【解决方案2】：

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

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

【讨论】：

【解决方案3】：

Visual Studio 2008（团队版，特别是 GDR）可以根据定义的架构/元数据文件自动部署架构，您可以将其部署到服务器。这可以包含在您的构建/部署过程中。但是，我认为复制和架构更改仍然存在问题 - 没有包可以理解/知道您的复制设置。

例如，我们在订阅者上使用自定义复制过程，尽管架构更改从发布者传播，但我们有时必须根据我们现有的任何自定义复制手动编写更改脚本。如果您不使用自定义复制过程，我会说这是要走的路。

【讨论】：

【解决方案4】：

我认为这种方法本身没有任何问题，但是在设置它时一定要测试当其中一个链接服务器关闭时会发生什么。如果某个服务器发生故障并且您确实想知道更改未应用于该服务器，您不希望回滚所有其他服务器。

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

【讨论】：