存在 AWS 云中从 Oracle 迁移到 PostgreSQL 可能是一个复杂的多阶段过程，从评估阶段到切换阶段，涉及多种不同的技术和技能。本系列博文介绍了源 Oracle 数据库、AWS Database Migration (AWS DMS) 服务和目标 PostgreSQL 数据库的环境和配置设置。本系列博文侧重于生产、开发、测试和暂数据库环境迁移所用源数据和目标数据库基础设施、设置、工具和配置。我们将首先介绍从 Oracle 迁移到 Amazon RDS for PostgreSQL 数据库或兼容 PostgreSQL 的 Amazon Aurora 数据库。

尽管这些都属于不同的环境，它们之间仍有一些共同的特点。本系列博文将简要介绍数据库迁移需要考虑的组件。这些博文不会探讨应用程序组件和不同场景的复杂性，因为这在很大程度上取决于具体的使用案例。要更好地了解所涉及的复杂性，请参阅AWS 数据库博客文章：AWS Database Blog post Database Migration—What Do You Need to Know Before You Start?

本系列共有三篇博文，分别涉及迁移的三个阶段：

第 1 阶段：迁移流程和基础设施注意事项。此博文将讨论源服务器的基础设施设置。它还将简要介绍整个迁移过程，需要在适当时访问 Oracle 数据库和客户端硬件和操作系统。
第 2 阶段：Oracle 源数据库和 AWS DMS CDC 环境注意事项。第二篇博文涉及使用 DMS 服务设置 Oracle 源数据库环境，这适用于一次性迁移和持续更改数据捕获 (CDC) 复制。
第 3 阶段：PostgreSQL 环境的目标数据库注意事项。最后一篇博文介绍了为 AWS DMS 设置 PostgreSQL 目标数据库环境。
本系列博文涉及以下几个方面：
迁移过程不同阶段的设置工具
针对源环境、迁移工具和目标环境的恰当实例类型和数据库版本。
构建和测试 Oracle、AWS DMS 以及 PostgreSQL 环境。
有关要迁移哪些数据以及如何帮助确定必要的环境以开发恰当的解决方案的规划决策。本系列博文仅介绍了从 Oracle 向 PostgreSQL 迁移的过程，不讨论数据库迁移的手动工作，例如应用程序依赖项等。有关如何手动将特定的 Oracle 数据库对象和功能迁移到 Aurora PostgreSQL 的更多信息，请参阅从 Oracle 数据库 11g/12c 迁移到兼容 PostgreSQL 的 Amazon Aurora 迁移操作手册。

迁移过程

在任何企业，数据库迁移都是一项极为关键的操作，一旦失败则可能导致严重的后果。如果失败，企业推行新技术的能力将会嘎然而止。同时已经花费的巨大支出也会收获甚微，甚至毫无收获。迁移过程包含许多活动的部分，要求小心简化流程。因此，在计划将数据从 Oracle 迁移到 PostgreSQL 时，您必须考虑多种可用的选项。这包括您的网络、CPU、内存以及操作系统。此外还包括您的迁移工具和流程。例如，是否要使用 AWS Glue 等 ETL 工具，是否要将数据导出为文件，或者使用 DMS 来提取数据并使用 CDC 将数据导入 PostgreSQL。

一个关键的流程步骤是使用工作负载量化框架 (WQF) 进行技术评估。WQF 包括自助工具、一份调查问卷以及设计评审指南。AWS 解决方案架构师、合作伙伴以及咨询师可以使用这些工具对工作负载进行分类，从而恰当确定迁移的范围、工时消耗以及要迁移的 AWS 服务。如下表所示，WQF 将 OLTP 和 DW 这两个主要类型的数据库工作负载分为五个独立的类别，从而确定在迁移数据时需要的工作。

类别	工作负载类型	迁移难易度	工时消耗
1	ODBC/JDBC 工作负载	容易	少量
2	轻型 Oracle 功能工作负载	容易	中量
3	重型 Oracle功能工作负载	较难	大量
4	Oracle特定应用程序框架	难以迁移	无数据
5	OCI工作负载	较难	大量

有关更多信息，请参阅 AWS Database Freedom 计划网站。

数据库迁移过程的各个阶段都需要大量的规划。这将有利于确保有效提前解决不同环境之间的所有不兼容性和配置问题。例如，如果您要从本地网络迁移 100GB 的数据并且可以停机几个小时，则事情将会较为简单。但假设您要从本地硬件将 5TB 的数据库迁移到云环境，而维护窗口期只有两个小时。在这种情况下，从 Oracle 迁移到 PostgreSQL 可能会极具挑战。

数据库迁移过程的四个主要阶段如下所列：

迁移步骤

###第 1 阶段：基础设施
在此阶段，您需要执行如下操作：

配置将源数据库和目标数据库连接到某个 AWS DMS 复制实例 (RI) 的网络。这一步可能非常简单，例如将同一 VPC 中的两个 AWS 资源作为复制实例连接。当然也可以包含更为复杂的配置，例如通过 VPN 将本地数据库连接到某个 Amazon RDS 数据库实例。网络速度可以是普通的互联网服务速度，也可以使用 AWS Direct Connect 实现更高的速度。
进行目标数据库和 RI 容量规划。
此阶段将在本博文中讨论。

第 2 阶段：设置 Oracle 环境以使用 AWS Schema Conversion Tool (AWS SCT) 获取源数据

在此阶段，您需要执行如下操作：

正确设置 Oracle 数据库环境以确保更加的性能以及与 AWS 工具和服务的集成。
设置 AWS SCT 已将现有 Oracle 数据库架构和数据转换为 PostgreSQL 数据库。您可以转换关系 OLTP 架构和数据仓库架构。SCT 会迁移您的第二索引、序列、默认值、存储的流程、触发器、同义词、视图以及非与数据迁移有特定关系的其他架构对象。它会根据转换后的模型对象生成数据定义语言 (DDL) 语句来创建新的 PostgreSQL 数据库。运行 DDL 语句会创建 PostgreSQL 数据库中的对象。
开始启动项目前请在 SCT 中查看迁移评估报告来了解不兼容性问题以及技术挑战。
查看不受支持的数据类型和对象。一些源数据类型需要转换为目标数据库中同等的数据类型。有关支持的数据类型的更多信息，请参阅从 Oracle 数据库 11g/12c 迁移到兼容 PostgreSQL 的 Amazon Aurora 迁移操作手册。
此阶段将在第二篇博文“Oracle 和 AWS DMS CDC 环境的源数据库注意事项”中讨论。

第 3 阶段：设置 DMS 以迁移数据

在此阶段，您将设置 AWS DMS 以迁移数据。

AWS DMS 会将数据从 Oracle 源数据库迁移到 PostgreSQL 目标数据库。AWS DMS 还会获取源数据库上的数据操纵语言 (DML) 和支持的 DDL 更改，并将这些更改应用到目标数据库，从而确保了目标数据库与源数据库的同步。

此阶段将在第二篇博文“Oracle 和 AWS DMS CDC 环境的源数据库注意事项”中讨论。

第 4 阶段：PostgreSQL 数据库环境设置

在此阶段，您将设置 PostgreSQL 数据库环境以确保最佳的迁移性能以及与 AWS 工具的集成。此阶段是迁移过程的最后一步。此阶段将在本系列的最后一篇博文“PostgreSQL 环境的目标数据库注意事项”中讨论。一般而言，数据库迁移过程还将包括生产环境切换发生问题时的回滚流程和方法。但在本系列博文中我们不会讨论回滚策略。

数据库迁移过程

将数据库从 Oracle 迁移到 RDS PostgreSQL 或 Aurora PostgreSQL 涉及对所有表结构、数据、相关索引、触发器和存储的流程的完整迁移。完成所有这些元素的迁移后，新的 RDS 数据库或 Aurora PostgreSQL 数据库将使用数据复制的方法保持与源数据库的同步，直到完成切换为止。

您可以使用多种方式来实时这些异构数据库之间的数据迁移，包括数据库供应商提供的专用数据迁移工具。您也可以将 AWS 数据库迁移工具与专为设计和实施跨平台数据迁移而开发的流程结合使用。

AWS 特别提供了 AWS SCT 和 AWS DMS 这两个工具来支持简单方便的异构数据库迁移，例如从 Oracle 迁移到 PostgreSQL。

AWS SCT 可帮助您将 Oracle 词典和第二对象转换到任何支持的目标数据库，需要您执行的工作极少。AWS SCT 会创建一份迁移评估报告，识别需要手动更改或重做的对象和代码。

AWS DMS 使用更改数据捕获 (CDC) 工具，以存储基础设施为 Oracle ASM 或非 ASM 时处理 Oracle 源终端节点，从而完成数据库迁移。

使用 DMS 和 SCT 从 Oracle 迁移到 PostgreSQL 的过程分为多个阶段，您必须考虑多个依赖项因素。这时您需要解决技术性问题和非技术性问题，例如项目规划、资源、培训、测试流程等等。

如要制定稳妥的迁移策略，请考虑使用 DMS 和 SCT 时的下列技术问题：

源数据库、复制实例和目标数据库的服务器容量规划
源操作系统（例如 Linux）和网络的调整
架构和数据迁移流程
源 Oracle 数据库参数，包括下列参数：
存档日志记录
补充日志记录
存储
目标 PostgreSQL 数据库参数
数据库服务器容量规划要求我们了解数据平台的架构、性能参数、外部依赖项、数据库版本版次、迁移路径、硬件、虚拟化、非功能要求、许可证等信息。在估计新数据库平台的容量需求时，一个关键点是了解各个性能参数的趋势。例如，Oracle 实例的 RAM 和 CPU 使用量趋势、数据库 IOPS 以及日志和数据文件的大小。此外，您还应能够根据最契合的趋势推导时间序列，然后将它们进行季节性比较。这种推导适用于目标数据库或 Amazon EC2 实例。

对于 CPU 使用量等性能参数，您必须了解如果通过从本地环境迁移到 AWS 云而对底层进行进行更改，将会发生什么。例如，源硬件平台和目标硬件平台的性能可能存在极大的差异。因此，您必须能够计算当前源服务器配置和假象的目标服务器配置之间的 CPU 性能比率等参数。通过这些操作，您可以将实例或数据库级别的性能参数时序推导至新的高度。

此外，对于 CPU 和内存，您必须了解异构迁移中的存储要求。为了优化目标存储而需要对源系统进行评价或评估的点包括下列方面：

审计源 Oracle 数据库。评估每个架构以及各个架构内的所有对象，以确定是否有任何对象不再使用。剔除源 Oracle 数据库中的未使用对象，因为您不需要迁移未使用的对象。
如果负载容量允许，然后获得源数据库中每个 LOB 类型的最大大小 (KB)。在流程的后期阶段我们将需要此信息。
将含 LOB（BLOB、CLOB、NCLOB）、LONG、LONG RAW 和 XMLTYPE 的移动到 Amazon S3、Amazon DynamoDB 或任何其他外部数据库。
外部 LOB 数据对象在数据库表空间以外作为操作系统文件存储。在本例中，仅 LOB 定位符（指针）存储在 Oracle 数据库中。对于 LOB、LONG 或 LONG RAW 的实际值，整个数据都在外部存储。这种方法减少了 Oracle 数据库的存储要求，提高了查询性能。

例如，您可以将 can store the CLOB（XML 文件）或 BLOB（二进制数据对象）存储在 Amazon S3 中，然后将指向 S3 对象的 URL 参考存储在您的数据库中。对完整性和持久性的支持由操作系统管理的底层存储来提供。这种方法简化了源 Oracle 数据库，更加方便迁移。此外，它也降低了目标 PostgreSQL 数据库的容量需求。

操作系统和网络

在考虑迁移数据库平台时，我们发现用户通常会检查源数据库的 CPU 利用率、内存大小以及 IO 模式等，而往往会忽视网络性能的重要性，尤其是在迁移到 AWS 时。因此，我们在本博文中更深入探讨了网络验证主题，尽管我们也建议您委托网络工程师和系统工程师。

网络涉及可能加剧处理延迟的开销。为了优化性能，请确保您拥有较快的网络吞吐量。此外，请尽量减少通过网络发生的消息数量。最后，请注意网络所加剧的延迟程度可能难以衡量。如果可能，请在验证过程中尽早咨询网络工程师或系统工程师。从源系统或数据中心开始的网络问题可能导致性能问题，降低迁移速度。

在解决网络性能问题时，请通过网络嗅探器线索来分析性能降级问题。为此，请将数据加载到网络分析器（例如 Wireshark 或类似的商业分析器）中，然后在分析器中检查具体数据包以获取线索。

此外，使用网络监控工具来确保您的源数据库已经做好了迁移准备：

网络带宽监控器可以识别超过网络、客户端或服务器带宽性能极限的问题。监控器可以确定问题是否与以下任何方面有关：
节流 — 根据请求的类别以及客户在该类别发出的调用数量对请求进行节流。
显示物理限制的带宽利用模式图。
检查以太网冲突、掉包或错误等等。
检查 WAN 链路的稳定性。WAN 优化解决导致关键应用程序无响应或者整个 WAN 不可靠的延迟、丢包和带宽问题。
检查服务质量 (QoS) 或数据包，确定优先级别。
检查遍历路径中的防火墙，看它是否封锁了特定的端口或协议。
源数据库服务器可能采用 Windows、SunOS、IBM AIX、HP UX、Linux 或任何其他主要供应商的操作系统。我们不计划在此详细介绍每个操作系统的每条可用命令。在整个系列博文中，我们都假设是从流行的开源 Linux 系统实施数据库迁移。

因此，您需要熟悉一些 Linux 命令以有效地管理系统，一些重要的命令列举如下。我们强烈建议您在使用之前进行测试。

网络命令

netstat、traceroute、ipconfig 和端口扫描器等多种使用工具都可用于排查问题或检查连接以诊断异常。一些重要的命令包括：

ifconfig 命令显示了系统中定义的网络接口详细信息。
最常用的选项是 -a (ifconfig –a)，利用此选项可显示所有接口和查找掉包、错误、MTU 大小等信息。
主以太网网络接口的常用名称为 eth0。如需 eth0等具体接口的详细信息，您可以使用命令：# ifconfig eth0
/proc/net/dev、netstat、mii-tool，所有这些命令都涉及端口速度。
使用 netstat –s 或 netstat –su 命令并查找 udpInOverflows、数据包 receive errors 或 fragments dropped 的情形。如果您发现这些指标持续增加，则说明存在问题。
NIC Version : ethtool –driver eth0 涉及端口和数据包速度设置。
下列命令为您提供了有关当前网络驱动程序和 BIOS 版本的信息。有时，简单搜索当前版本即可能说明发生性能问题的原因是需要升级。查找网络适配器名称手动操作说明如下（您必须拥有在 Linux 中运行这些命令的权限）：
输入 lspci -v | grep Ethernet -A 1
识别适配器的名称以确保子系统中的适配器和驱动程序正确。以 Intel PRO/1000 PT 双端口服务器适配器为例：

MyServer:/home/MyUser # lspci -v | grep "Ethernet" -A 1
02:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)
Subsystem: Intel Corporation PRO/1000 PT Dual Port Server Adapter
--
02:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)
Subsystem: Intel Corporation PRO/1000 PT Dual Port Server Adapter

我们强烈建议您安装最新和最佳的驱动程序以确保最佳性能。根据如下命令手动检查驱动程序版本并在必要时替换：
输入 ethtool -i ethx，其中 ethx 为以太网端口
读取驱动程序名称和版本（确认您拥有最新最佳版本）。以第一个以太网端口 eth0 为例：

MyServer:/home/MyUser # ethtool -i eth0
driver: e1000
version: 7.6.5-NAPI
firmware-version: 5.6-2
bus-info: 0000:02:00.0

为了提高源服务器的网络吞吐量，您可以使用 9000 的持久 MTU 大小（在重启后继续生效）来设置主机网络适配器的巨型帧。但您必须确保从始至终的网络路径都支持巨型帧，以避免包碎片化现象。

例如，您可以使用 ifconfig -mtu 9000，然后再使用 ifconfig -a 来显示所完成的设置。如要进行测试以确认巨型包全程完好，请使用如下命令：

[node01] $ traceroute -F node02-priv 9000
traceroute to node02-priv (10.10.10.2), 30 hops max, 9000 byte packets
1 node02-priv (10.10.10.2) 0.232 ms 0.176 ms 0.160 ms

[node01] $ traceroute -F node02-priv 9001
traceroute to node02-priv (10.10.10.2), 30 hops max, 9001 byte packets
traceroute: sendto: Message too long
1 traceroute: wrote node02-priv 9001 chars, ret=-1

此外，您可以执行如下操作：

1.使用 iperf 工具来检查网络吞吐量，以确定网络带宽的利用率是否接近所观察的最大吞吐量。
将网络参数值设置为大致支持最大网络吞吐量的水平。找到带宽延时积 (BDP) 值并相应设置网络缓冲区大小。带宽延时积等于链路带宽乘以往返行程时间的积。例如：如果网带宽为 1Gb/s，往返行程时间为 0.1 秒，则 BDP 为 (0.1 * 10^9)/8。对于此种网络，在文件 /etc/sysctl.conf 中设置如下参数值：

net.core.rmem_max = 12500000
net.core.wmem_max = 12500000
net.ipv4.tcp_rmem = 4096 87380 12500000
net.ipv4.tcp_wmem = 4096 65536 12500000

2.此外，请增加下列参数：

net.core.netdev_max_backlog = 30000
net.ipv4.tcp_max_syn_backlog = 4096

3.如果带宽延迟和利用看似正常，则检查从客户端到目标服务器的网络路由。了解网络的行程时间可以让您了解一项事务需要的大致时间。客户端-服务器通信需要许多小的数据包。由于发送请求和获得响应之间的时间间隔原因，高网络延迟会降低事务处理速度。有时，遍历路径属于次优方法。例如，由于设置错误的原因，事务可能必须跳过许多不必要的路径。或者路径中存在中继器问题，或者路由配置问题或其他因素。如要获得路径中各个设备的地址信息，请从客户端向服务器发出 traceroute 或类似命令。
##系统性能指标
有关系统性能指标的一些有用命令如下：

如要检查磁盘 I/O 和内存使用率，请使用 sar、vmstat 和 iostat 命令。
检查 CPU 利用率可使用 /proc/cpuinfo、mpstat 和 top 命令。
内存利用率可使用 /proc/meminfo、/proc/slabinfo 和 free 命令检查。
内核版本和发布号可使用 cat /proc/version 查看。
I/O 卡类型的版本和驱动程序可使用 lspci -vv 查看。
如需列举所有硬件 PCI 设备，请使用 lspci –v 命令。
如需查看有关明显问题的内核消息，请使用 /var/log/messages 和 /var/log/dmesg 命令。

小结

在此博文中，我们从设计的角度深入介绍了网络问题。我们经常发现用户关注 CPU、内存和 I/O 主题而忽视网络性能问题。有时，网络性能可能是数据库迁移策略成败的一个关键因素，并且通常情况下任何生产系统的 CPU、内存和 I/O 状况都会得到良好的监控和了解。

本博文最后讨论了在设置数据库迁移的基础实施时需要考虑的系统和网络管理任务。对于下一阶段，也就是为了迁移而准备源 Oracle 数据库的设置和配置的阶段，请参见下一篇博文 Oracle 源数据库和 AWS DMS CDC 环境注意事项。

作者介绍：
Mahesh Pakala 自 2014 年 4 月起一直在 Amazon 工作。在加入亚马逊之前，他曾在 Ingres、Oracle Corporation 和 Dell Inc. 等公司工作，为具有战略意义的大型客户提供高可用性可扩展应用程序设计、异构云应用程序迁移的建议，并协助其调优系统性能。

本文转载自AWS技术博客。

原文链接：
https://amazonaws-china.com/cn/blogs/china/oracle-postgresql-migration-aws-dms-postgresql-migration-process-infrastructure-considerations/

创作场景

云中的 Oracle 到 PostgreSQL 迁移：迁移流程和基础设施注意事项