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