您计划数据迁移的工作流程是什么？

Question

很多次我在软件开发工作结束时被引入并被告知“好吧，我们已经有了所有这些新代码，它需要更改表并迁移数据”。

似乎每次都是一次性的，从臀部射门，最好的猜测场景。我觉得这是我作为 DBA 最弱的技能。

我想了解一些接近、管理和测试数据迁移的模式。

请告诉我一些最佳实践和/或我可以从哪里获得学习材料以帮助我在这方面做得更好。

Answer 1

每次我完成它，我们都走了两次......

1. 拍摄快照，并在不同的服务器上工作，使用它来确定迁移必须完成的操作，并编写脚本。
2. 一旦他们掌握了脚本，snapshop 就会在测试系统上恢复，并且定时查看它是否会在要求的时间内运行，或者对其进行调整和修改直到可以运行。
3. 让利益相关者签字确认测试系统上的数据没有任何问题。

然后，在一个周末，您有一个预定的中断：

1. 周五晚上，使用数据库的系统被关闭，进行完整的冷备份，并运行脚本来迁移/修改/任何数据
2. 系统在某个私人地址下恢复或以某种方式设置，因此它不对任何人开放，除了利益相关者进行验收测试
3. 如果利益相关者同意，则系统上线并公开；如果没有，数据库将从周五晚上的备份中恢复，然后您重新开始该过程。

根据我们的日程安排，数据库人员通常从周五下午 6 点到周六上午 10 点运行备份和迁移脚本，所以我们的目标是他们在 8 小时内运行（其中约 6 小时是备份），所以我们在发布给利益相关者之前，我们有一些时间进行测试和更正。

利益相关者提前获得了他们的时间窗口，因此他们知道在窗口开始时让他们的周末开放进行测试。他们还会被告知他们的窗口结束，通常是周日下午，如果每个人都没有签字，我们将不得不开始回滚。

哦，当然......如果有人在任何一个验收测试中进行了更改，而我们进行了更改，则意味着所有利益相关者的签字都作废，他们必须重新测试......所以我们会尝试给它们一段时间来查找问题并批量运行任何更正，而不是一次应用它们。

幸运的是，我唯一遇到过这样一种情况，我们不能有大量停机时间，我正在迁移的系统是由脚本提供的，而不是用户输入，所以我可以让两个并行系统运行，然后将它们换掉当事情得到批准时。（只有一次出现问题，当我的老板坚持要我们进行完整备份时，我不明白整个事情仍然会在不同的 IP 上在线......糟糕的一天变成了 5 小时的停电。）

Answer 2

这完全取决于数据量与支持数据库的硬件的能力以及系统可用性的协议。您是否碰巧有一些停机时间，还是应该全部在线完成？开始清理数据，尽可能多地清除过时的行。这本身就是一个项目。如果数据干净且有价值，则让用户决定停机时间。如果停机时间可用，则相当简单，如果停机时间是已知的转换，应应用于现有数据以形成更新的集合。如果没有——或很少——停机时间允许，挑战就开始了。Oracle 以多种方式支持这一点，例如在线表重定义和 - 11g 中的新功能 - 基于版本的重定义。通过在线表格重新定义，您可以准备表格以采用新形式。这可以在应用程序在旧表格 [s] 上运行时完成。如果他们都准备好了，你可以切换到表格的新形式[s]。这也将是引入新应用程序代码的时刻，同时标志着将新应用程序部署到位所需的停机时间的开始。可以在迁移实时数据之前准备较旧的历史数据，并使用 Oracle Golden Gate 等工具保持同步。在这种情况下，您可以有效地构建一个新数据库来接管旧数据库的角色。如果不需要更改表，则基于版本的重新定义更适合。有很多选择需要考虑，我认为很难给出一个始终有效的好规则。这也将是引入新应用程序代码的时刻，同时标志着将新应用程序部署到位所需的停机时间的开始。可以在迁移实时数据之前准备较旧的历史数据，并使用 Oracle Golden Gate 等工具保持同步。在这种情况下，您可以有效地构建一个新数据库来接管旧数据库的角色。如果不需要更改表，则基于版本的重新定义更适合。有很多选择需要考虑，我认为很难给出一个始终有效的好规则。这也将是引入新应用程序代码的时刻，同时标志着将新应用程序部署到位所需的停机时间的开始。可以在迁移实时数据之前准备较旧的历史数据，并使用 Oracle Golden Gate 等工具保持同步。在这种情况下，您可以有效地构建一个新数据库来接管旧数据库的角色。如果不需要更改表，则基于版本的重新定义更适合。有很多选择需要考虑，我认为很难给出一个始终有效的好规则。可以在迁移实时数据之前准备较旧的历史数据，并使用 Oracle Golden Gate 等工具保持同步。在这种情况下，您可以有效地构建一个新数据库来接管旧数据库的角色。如果不需要更改表，则基于版本的重新定义更适合。有很多选择需要考虑，我认为很难给出一个始终有效的好规则。可以在迁移实时数据之前准备较旧的历史数据，并使用 Oracle Golden Gate 等工具保持同步。在这种情况下，您可以有效地构建一个新数据库来接管旧数据库的角色。如果不需要更改表，则基于版本的重新定义更适合。有很多选择需要考虑，我认为很难给出一个始终有效的好规则。

这是一个有趣的话题，罗纳德。

Answer 3

到目前为止很好的答案。我会再补充几点以供考虑。

首先，当您可以使用简单的 SQL DML 进行迁移时，您可以在很大程度上依赖您的 SQL 引擎来确保成功处理所有行。不过，我参与了迁移，其中一些迁移稍微复杂一些——当数据被移动到新结构时，会有实际的数据转换。在这些情况下，重要的是您有一个可以处理以下项目的流程：

• 计数记录与处理的记录。
• 在转换过程中检测错误并以允许转换继续并在确定修复后重新处理“坏”记录的方式处理它们。
• 记录计数应包括“坏”记录——即记录输入 = 记录输出好 + 坏记录
• 如果您的转换更改了记录计数（例如，一个输入记录变成了多个输出记录），则有一种方法可以预测您最终会得到的输出记录数，然后根据该计数测试您的结果。

我要补充的另一点是，如果/当事情没有按计划进行时，为你将要做的事情制定一个计划很重要。这确实是整个部署的一个功能，但它似乎经常被掩盖，我认为值得一提。