迁移的最佳选择取决于多种因素的组合、包括要迁移的环境的规模、避免停机的需求以及执行迁移所需的整体工作量。大型数据库显然需要更多的时间和精力进行迁移、但这种迁移的复杂性微乎其微。小型数据库可以快速迁移、但是、如果要迁移的数据库有数千个、工作的规模可能会带来复杂性。最后、数据库越大、越有可能成为业务关键型数据库、因此需要在保持备用路径的同时最大限度地减少停机时间。

此处将讨论规划迁移策略时的一些注意事项。

要迁移的数据库的大小显然会影响迁移规划、但大小并不一定会影响转换时间。当需要迁移大量数据时、首要考虑因素是带宽。复制操作通常使用高效的顺序I/O来执行保守地估计、假设复制操作可用网络带宽的利用率为50%。例如、一个8 GB FC端口在理论上可以传输大约800 MBps。假设利用率为50%、则可以以大约400 Mbps的速率复制数据库。因此、以这种速率在大约7小时内即可复制一个10 TB的数据库。

远距离迁移通常需要更具创意的方法、例如中所述的日志传送过程 "联机数据文件移动"。远距离IP网络的带宽很少接近LAN或SAN速度。在一个案例中、NetApp以极高的归档日志生成速率协助远程迁移220 TB数据库。选择的数据传输方法是每天运送磁带、因为这种方法可提供最大可能的带宽。

在许多情况下、移动大量数据的问题不在于数据大小、而在于支持数据库的配置的复杂性。仅仅知道必须迁移50 TB的数据库是不够的。它可以是一个50 TB的任务关键型数据库、4、000个原有数据库的集合、也可以是生产数据和非生产数据的混合。在某些情况下、大部分数据都由源数据库的克隆组成。这些克隆根本不需要迁移、因为它们可以轻松地重新创建、尤其是在新架构设计为利用NetApp FlexClone卷时。

对于迁移规划、您必须了解范围内有多少数据库以及必须如何确定这些数据库的优先级。随着数据库数量的增加、堆栈中的首选迁移选项往往会越来越少。例如、使用RMAN可以轻松复制单个数据库、但会短暂中断。这是主机级复制。

如果有50个数据库、则可能更容易避免设置新的文件系统结构来接收RMAN副本并将数据移动到位。可以通过利用基于主机的LVM迁移将数据从旧LUN重新定位到新LUN来完成此过程。这样、数据库管理员(Database Administrator、DBA)团队就会将职责移交给操作系统团队、因此、数据会相对于数据库透明地进行迁移。文件系统配置保持不变。

最后、如果必须迁移200个服务器中的500个数据库、则可以使用ONTAP外部LUN导入(FLI)功能等基于存储的选项来直接迁移LUN。

通常、必须更改数据库文件布局才能利用新存储阵列的功能；但是、情况并非总是如此。例如、EF系列全闪存阵列的功能主要针对SAN性能和SAN可靠性。在大多数情况下、数据库可以迁移到EF系列阵列、而无需考虑数据布局的特殊注意事项。唯一的要求是高IOPS、低延迟和强大的可靠性。尽管存在与RAID配置或动态磁盘池等因素相关的最佳实践、但EF系列项目很少需要对整体存储架构进行任何重大更改才能利用这些功能。

相比之下、迁移到ONTAP通常需要更多地考虑数据库布局、以确保最终配置实现最大价值。ONTAP本身就可以为数据库环境提供许多功能、即使不需要任何特定的架构工作也是如此。最重要的是、它能够在当前硬件达到使用寿命时无故障迁移到新硬件。一般来说、迁移到ONTAP是您最后一次需要执行的迁移。后续硬件会原位升级、数据会无中断迁移到新介质。

通过一些规划、可以获得更多优势。有关快照的使用、最重要的注意事项是。快照是执行近乎即时的备份、还原和克隆操作的基础。作为快照功能的一个示例、已知的最大用途是在6个控制器上的大约250个LUN上运行一个996 TB的数据库。此数据库可以在2分钟内完成备份、在2分钟内完成还原、在15分钟内完成克隆。其他优势包括：能够根据工作负载的变化在集群中移动数据、以及应用服务质量(QoS)控制、以便在多数据库环境中提供稳定一致的良好性能。

QoS控制、数据重新定位、快照和克隆等技术几乎适用于任何配置。但是、通常需要考虑一些问题才能获得最大的益处。在某些情况下、数据库存储布局可能需要进行设计更改、才能最大程度地提高对新存储阵列的投资。此类设计更改可能会影响迁移策略、因为基于主机或基于存储的迁移会复制原始数据布局。要完成迁移并提供针对ONTAP优化的数据布局、可能还需要执行其他步骤。中所示的过程 "Oracle迁移过程概述" 之后、我们将演示一些方法、这些方法不仅可以迁移数据库、还可以轻松地将数据库迁移到最佳最终布局中。

应确定转换期间允许的最大服务中断时间。假设整个迁移过程会造成中断、这是一个常见错误。许多任务都可以在任何服务中断开始之前完成、而且许多选项都支持在不中断或中断的情况下完成迁移。即使不可避免地发生中断、您仍必须定义允许的最大服务中断、因为转换时间的持续时间因操作步骤而异操作步骤。

例如、复制一个10 TB数据库通常需要大约7小时才能完成。如果业务需求允许中断七小时、则文件复制是一种简单安全的迁移选项。如果五个小时不可接受、则采用简单的日志传送流程(请参见 "Oracle日志传送")、只需极少的工作量即可完成设置、从而将转换时间缩短至大约15分钟。在此期间、数据库管理员可以完成此过程。如果15分钟不可接受、则可以通过脚本自动执行最终转换过程、将转换时间缩短为几分钟。您始终可以加快迁移速度、但这样做会耗费时间和精力。转换时间目标应基于业务部门可接受的内容。

任何迁移都不是完全无风险的。即使技术运行正常、也始终存在用户错误的可能性。必须考虑与所选迁移路径相关的风险以及迁移失败的后果。例如、Oracle ASM的透明联机存储迁移功能是其主要功能之一、而这种方法是已知最可靠的方法之一。但是、使用此方法可以不可逆地复制数据。如果ASM出现问题的可能性极小、则不存在轻松的回退路径。唯一的选择是还原原始环境或使用ASM将迁移反转回原始LUN。如果原始存储系统能够执行快照类型的备份、则可以通过在该系统上执行此类操作来最大程度地降低风险、但无法消除此类风险。

某些迁移过程在执行前必须进行全面验证。迁移和演练转换过程是任务关键型数据库的常见要求、对于这些数据库、迁移必须成功、停机时间必须降至最低。此外、用户验收测试通常会作为迁移后工作的一部分、整个系统只有在这些测试完成后才能恢复生产。

如果需要预演、几项ONTAP功能可以使流程更加简单。特别是、快照可以重置测试环境、并快速为数据库环境创建多个节省空间的副本。