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

Question

假设有一个包含100多个表格的数据库，并且添加了一个主要功能，这需要修改20个现有表格并添加30个。开发人员在开发数据库上进行了很长时间（6个月）的更改。假设这些更改不会使任何现有生产数据无效（例如，在添加的列上允许默认值/空值，不存在无法实现的新关系或约束）。

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

Answer 1

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

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

但是真正的问题是：这会是最后您对模式所做的更改吗？最后，你已经发现了应用程序的完美模式，生产数据库永远不会改变？祝贺，一旦你把这个关掉，你可以休息。但实际上，6个月后你将面临同样的问题。真正的问题在于您的开发过程，开发人员将其从SSMS或VS Server Explored进行更改直接导入数据库。您的开发过程必须有意识地采用基于版本控制和T-SQL脚本的模式更改策略，如Version Control and your Database中所述。

Answer 2

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

然后，在实际迁移时：锁定数据库，以便只有管理员才能登录。进行备份。运行脚本。验证结果。将DB重新在线。

最长的部分将是备份，但你会发疯，不这样做。你应该知道备份需要多长时间，整个过程不会花费太多时间，所以这就是你的停机时间需要多长时间。对于大多数企业来说，深夜很适合。

Answer 3

我几年来一直在使用dbdeploy。它允许你的开发人员创建小的sql变更增量，然后可以将其应用于数据库。更改由数据库中的更改日志表进行跟踪，以便它知道要应用什么。

Answer 4

使用工具来创建一个diff脚本，并在维护期间运行它。我为此使用RedGate SQL Compare，并对此非常满意。