是否有推出数据库架构更改的标准方法？

Question

一位开发人员说我应该简单地将所有数据库升级脚本包装在一个事务中。如果失败，只需回滚所有更改。我的直觉告诉我这是错误的，尤其是在处理大量数据和/或过程和函数时。

我通常按​​如下方式对单实例数据库进行升级：

• 协商维护窗口
• 准备升级脚本
• 将数据库置于受限用户模式
• 禁用通常会在此窗口期间访问数据库的计划作业/进程
• 执行完整备份
• 应用升级脚本
• 让开发人员或测试团队确认应用程序按预期运行
• 将数据库恢复到多用户模式
• 释放数据库以供正常使用

但是，当涉及对数百个实例进行更改时，我已将流程更改如下：

• 我使升级脚本更加健壮：它们可以在同一台服务器上多次运行而不会造成损害，数据库版本号是正确的，如果它们针对运行版本运行，脚本将终止等。

• 为每个服务器生成一个进程（使用 powershell、osql 等）

• 运行适当的升级脚本
• 报告成功或失败

Answer 1

没有标准流程，因为每个系统都不同。如果将所有内容都包装在一个事务中，我会做的最后一件事。如果我需要移动 500 GB 数据会怎样？这是一笔巨大的交易。

最近我一直在使用数据库快照作为我的回滚。

基本上拍摄快照，进行更改。签核后删除快照。如果升级失败，则回滚快照，然后重试。

回滚快照比恢复数据库要快得多（假设数据库很大）。