假设有一个包含100多个表的数据库并且添加了一个主要功能，这需要修改20个现有表并添加30个表。这些更改是由开发数据库上的多个开发人员在很长一段时间（6个月）完成的。让我们假设这些更改不会使任何现有的生产数据无效（例如，添加的列允许使用默认值/ null，没有新的关系或约束无法实现）。
将架构中的这些更改发布到生产数据库的最简单方法是什么？最好不要长时间关闭数据库。
答案 0 :(得分：6)
编写执行所需更改的T-SQL脚本。在生产数据库的副本上进行测试（从最近的备份恢复以获取副本）。修复测试将发现的不可避免的错误。重复直到脚本完美运行。
然后，当实际迁移的时候：锁定数据库，这样只有管理员才能登录。进行备份。运行脚本。验证结果。将数据库重新联机。
最长的部分将是备份，但你不会这样做疯了。您应该知道备份需要多长时间，整个过程不会花费更长的时间，因此您的停机时间需要多长时间。半夜适合大多数企业。
答案 1 :(得分：3)
没有关于如何在没有停机的情况下进行“更改”的通用答案。答案实际上取决于具体情况，具体取决于具体的变化。一些更改对停机时间没有影响（例如，添加新表），一些更改的影响最小（例如，向现有表添加列而不更改数据大小，例如新的可空列，使得snot增加空位图大小）和其他更改将破坏停机时间（任何将更改数据大小的操作都将强制进行索引重建并在持续时间内锁定表）。如果没有*重大*停机时间，则无法应用某些更改。我知道并行应用更改的情况：创建数据库的副本，设置复制以使其保持最新，然后更改副本并保持同步，最后将操作移动到修改后的副本，该副本将成为主数据库。在PASS 2009 given by Michelle Ufford 有一个演示文稿提到了godaddy经历了持续周的这种变化。
但是，在较小的范围内，必须通过经过良好测试的脚本应用更改，并衡量对测试评估的影响。
但真正的问题是：这将是您对架构进行的最后更改吗？最后，您发现了应用程序的完美模式，生产数据库永远不会改变？恭喜你，一旦你把它拉下来，你就可以休息了。但实际上，你将在6个月内遇到同样的问题。真正的问题是您的开发过程，开发人员和从SSMS或从VS Server Explored直接进入数据库的更改。您的开发过程必须有意识地采用基于版本控制和T-SQL脚本的模式更改策略，如Version Control and your Database中所述。
答案 2 :(得分：2)
使用工具创建diff脚本并在维护窗口期间运行它。我为此使用了RedGate SQL Compare，对此非常满意。
答案 3 :(得分：1)
我已经成功使用dbdeploy几年了。它允许您的开发人员创建小的sql更改增量，然后可以对您的数据库应用。数据库中的更改日志表会跟踪更改，以便它知道要应用的内容。