了解极大型数据库迁移
迁移到 Azure 云的 SAP 系统现在通常包括大型跨国企业的“单一全球实例”系统。 这些系统比 Azure 平台首次通过 SAP 工作负载认证时部署的第一个客户系统大很多倍。
非常大的数据库 (VLDB) 现在通常会移到 Azure。 如果数据库大小超过 20 TB，则需要采用一些附加的技术和过程，才能在可接受的停机时间范围内以较低风险从本地迁移到 Azure。
综合概述
完全优化的极大型数据库迁移应达到每小时 2 TB 左右甚至更高的迁移吞吐量。 这意味着，可以在大约 10 小时内迁移 20 TB 的数据传输组件。 需要完成各种后处理和验证步骤。 一般来说，在准备和测试时间充足的情况下，可以将任何大小的几乎任何客户系统迁移到 Azure。
VLDB 迁移需要掌握大量技能，注重细节并学会分析。 例如，必须衡量和分析表拆分的实质影响。 将一个大型表拆分为 50 多个并行导出可以大大减少导出该表所需的时间，但过多的表拆分可能导致导入时间大幅增加。 因此，必须计算并测试表拆分的实质影响。 专家许可的 OS/DB 迁移顾问应熟悉概念和工具。 我们将重点介绍一些有关 VLDB 迁移的 Azure 特定内容。
具体而言，我们将介绍如何使用 R3load 和 Migmon 之类的工具，以 SQL Server 为目标数据库，将异构 OS/数据库迁移到 Azure。 迁移步骤不适用于同构系统副本，即 DBMS 和处理器体系结构（端序）保持不变的副本。 一般情况下，无论 DBMS 大小如何，同构系统副本都应具有较短的停机时间，因为日志传送可用于同步 Azure 中的数据库的副本。
要点后面提供了演示典型 VLDB OS/数据库迁移并转移到 Azure 的框图：
当前的源 OS/DB 通常是 AIX、HPUX、Solaris 或 Linux；以及 DB2 或 Oracle。
目标 OS 是 Windows、Suse 12.3、Redhat 7.x 或 Oracle Linux 7.x。
目标 DB 通常是 SQL Server 或 Oracle 12.2。
IBM pSeries、Solaris SPARC 硬件和 HP Superdome 的线程性能远低于低成本的新式 Intel 市售服务器，因此 R3load 在单独的 Intel 服务器上运行。
VMware 需要特殊的优化和配置，实现良好、稳定和可预测的网络性能。 通常将物理服务器用作 R3load 服务器而不是虚拟机。
尽管对于导出服务器的数量没有限制，但通常使用四个导出 R3load 服务器。 典型配置是：
- 导出服务器 1 – 专用于最大的 1-4 表（根据数据在源数据库上的分布倾斜程度）
- 导出服务器 2 – 专用于带有表拆分的表。
- 导出服务器 3 – 专用于带有表拆分的表。
- 导出服务器 4 – 所有剩余的表。
通过公共互联网使用 AzCopy 将导出转储文件从基于 Intel 的 R3load 服务器中的本地磁盘传输到 Azure。 此方法通常比通过 ExpressRoute 传输更快。
导入的控制和顺序是完成所有导出包后自动生成的信号文件 (SGN)。 这可以实现半并行导出/导入。
导入到 SQL Server 或 Oracle 的结构与导出类似，使用四个导入服务器。 这些服务器可以是具有加速网络的单独的专用 R3load 服务器。 建议不要在此任务中使用 SAP 应用程序服务器。
VLDB 数据库通常使用 E64v3、m64 或具有高级存储的 m128 虚拟机。 可以将事务日志放置本地 SSD 磁盘，提高事务日志的写入速度并从虚拟机配额删除事务日志 IOPS 和 IO 带宽。 应在迁移后将事务日志放置于永久磁盘上。
