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