推荐的方法如何修改生产SQL数据库的模式？

Question

假设有一个包含100多个表的数据库,并且添加了一个主要功能,这需要修改20个现有表,并添加30个.这些更改是由开发数据库上的多个开发人员在很长一段时间(6个月)完成的.假设这些更改不会使任何现有的生产数据无效(例如,在添加的列上允许使用默认值/ null,没有新的关系或约束无法实现).

将模式中的这些更改发布到生产数据库的最简单方法是什么？优选地,不将数据库关闭延长的时间量.

Answer 1

编写一个执行所需更改的T-SQL脚本.在生产数据库的副本上进行测试(从最近的备份恢复以获取副本).修复测试将发现的不可避免的错误.重复直到脚本完美运行.

然后,当实际迁移时:锁定数据库,以便只有管理员才能登录.进行备份.运行脚本.验证结果.将DB重新联机.

最长的部分将是备份,但你不会这样做疯了.您应该知道备份需要多长时间,整个过程不会花费更长的时间,因此您的停机时间需要多长时间.半夜适合大多数企业.

Answer 2

对于如何在不停机的情况下进行“改变”，没有通用的答案。答案实际上取决于具体情况，具体取决于具体的变化。有些更改对停机时间没有影响（例如添加新表），有些更改影响很小（例如向现有表添加列而不更改数据大小，例如不会增加空位图大小的新可为空列）其他更改会严重破坏停机时间（任何会更改数据大小的操作都将强制重建索引并在持续时间内锁定表）。如果没有*大量*停机时间，某些更改是不可能应用的。我知道并行应用更改的情况：创建数据库的副本，设置复制以使其保持最新，然后更改副本并保持同步，最后将操作移至修改后的副本，该副本将成为主数据库。Michelle Ufford在 PASS 2009 上做了一次演讲，其中提到了 godaddy 如何经历持续数周的变化。

但是，在较小的规模上，您必须通过经过良好测试的脚本应用更改，并衡量对测试评估的影响。

但真正的问题是：这将是您对架构所做的最后一次更改吗？最后，您是否发现了应用程序的完美架构并且生产数据库永远不会改变？恭喜你，一旦你成功了，你就可以去休息了。但实际上，6 个月后你将面临同样的问题。真正的问题是您的开发过程，与开发人员一起从 SSMS 或从 VS Server Explored 直接进入数据库进行更改。您的开发过程必须有意识地努力采用基于版本控制和 T-SQL 脚本的模式更改策略，如版本控制和数据库中描述的策略。