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

在软件开发工作的最后阶段，我被吸引了很多次，并被告知诸如“好吧，我们已经拥有了所有这些新代码，并且需要更改表和迁移数据”。

似乎每次都是一次性的，最好的猜测。我觉得这是我作为DBA的最薄弱的技能。

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

请为我提供一些最佳实践和/或在哪里可以获取学习材料的帮助，以帮助我在这一领域变得更好。

每次我做完之后，我们就走了两遍...

1. 拍摄快照，然后在另一台服务器上工作，使用该快照来确定迁移必须执行的操作并编写脚本。
2. 一旦掌握了脚本，即可在测试系统上恢复快照商店，并定时查看它是否将在所需时间内运行，或者对其进行调整和修改直到可以。
3. 让利益相关者签字表明测试系统上的数据看起来没有问题。

然后，在一个周末内，您将有计划的停机时间：

1. 星期五晚上，关闭使用数据库的系统，进行完整的冷备份，并运行脚本以对数据进行迁移/修改/其他操作
2. 将系统备份到某个私有地址下或以某种方式进行设置，因此除了利益相关者以外，其他任何人都不能进行验收测试
3. 如果利益相关者批准，则该系统将联机并公开；如果不是，则从星期五晚上进行的备份还原数据库，然后重新开始该过程。

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

利益相关者已提前获得了时间窗口，因此他们知道在窗口开始时将周末留给测试。他们还被告知窗口结束时，通常是周日下午，如果每个人都没有签字，我们必须开始回退。

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

幸运的是，我仅有几次遇到无法长时间停机的情况，我迁移的系统是由脚本（而不是用户输入）提供的，所以我只需要运行两个并行系统，然后将它们交换出去当事情签署的时候。（只有一次出现问题，当我的老板坚持要求我们进行完整备份时，却不了解整个事情仍然会在不同的IP上在线...所以应该在5分钟内中断一次糟糕的一天造成了5小时的停机。）

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

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

到目前为止，很好的答案。我将再考虑几点。

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

• 计数记录与已处理的记录。
• 在转换过程中检测错误，并以允许转换继续进行的方式进行处理，并在识别出错误后允许重新处理“不良”记录。
• 记录计数应包括“不良”记录-即，记录输入=记录输出良好-不良记录
• 如果您的转换更改了记录计数（例如，一个输入记录变成一个输出记录以上），则可以预测最终要使用的输出记录的数量，然后根据该计数测试结果。

我要补充的另一点是，如果/如果事情没有按计划进行，那么为您将要做的事情制定计划很重要。这实际上是整个部署的功能，但似乎经常被掩盖，以至于我认为值得一提。

概述方法

从开始

• 您在测试/ UAT中拥有“之后”数据库，无论“正在工作的数据库”如何
• 您在生产中拥有“之前”数据库。因此，使用它在“参考数据库”某处创建生产副本。另一个称为“脚本测试数据库”
• 我也希望您有一堆带有ALTER等的开发脚本。如果是这样，那么干净整洁且按顺序应用了另一个带有您的开发脚本的生产副本=“ change DB”

接下来，下载下Redad Compare工具或类似Embarcadero SQL Change manager的工具。没有它，您将无法轻松迁移。成本与节省的时间无关紧要。最重要的是，生成的脚本可在单个事务中进行更改，这意味着干净的部署

现在，

• 使用在“参考”和“变更”之间进行比较的工具生成变更和回滚脚本
• 将更改脚本应用于“脚本测试”，然后与“工作数据库”进行比较
• 将回滚脚本应用于“脚本测试”，然后与“进行比较”，然后与“正在工作的数据库”进行比较

现在，您已经安全且经过了测试，可以随时应用更改和回滚脚本。

当然，您在进行任何更改之前都要备份数据库，因为从统计上讲，最终将总是发生这种情况。

Red Gate工具还可以与源控制下的文件夹进行比较。然后，我们将源代码控件中的ALTER等捕获到实际的更改脚本中。