VMware替代的Oracle数据库迁移挑战，深信服有对策！

深信服推出的数据库管理平台（DMP）是为关系型数据库量身打造的运维管理解决方案，它整合了数据库日常运维所需的各项功能，包括但不限于数据库的创建、实时监控、数据备份以及灾难恢复等。此外，DMP还配备了先进的数据库迁移工具DTS，使企业能够将数据库从VMware平台或物理服务器无缝迁移至深信服的云计算环境中，确保迁移过程的高效率、安全性和可靠性。

深信服为满足用户不同场景下的迁移需求，提供丰富的Oralce迁移方案：

• SCMT信服云迁移工具能够实现主机级别的数据迁移，也包括单机数据库的整机迁移，但是无法对Oracle RAC数据库集群进行迁移。

• DTS数据库迁移工具是深信服数据库管理平台DMP针对迁移场景开发的专用工具，支持通过数据泵（全量迁移）和 RMAN（全量+增量）两种方式对数据库单机或集群进行迁移，相较于传统的手动迁移，能提供更为简洁和流畅的操作体验。

• DMP提供数据库容灾工具来完成迁移，使用Oracle Data Guard技术在目标端创建备库来完成数据的复制和迁移切换，适用于停机要求非常短的场景。

• RMAN / DG迁移：面对DMP平台无法满足特定的迁移条件或要求时，深信服将协调专业的数据库专家DBA来制定和执行定制化的RMAN / DG迁移方案。

本文重点介绍使用DMP的DTS工具对Oracle数据库进行全量加增量的数据迁移方式，也是目前较为推荐的Oracle迁移方式。它利用Oracle官方提供的RMAN技术，通过与数据库内部组件的紧密协作，实现数据的高效迁移。

迁移支持版本：

迁移架构支持：

RMAN（Recovery Manager）是Oracle数据库提供的备份和恢复工具，它可以帮助数据库管理员实现数据库备份和恢复操作，完成Oracle数据库的全量加增量迁移。RMAN的原理是基于Oracle数据库的架构和内部机制，它可以通过与数据库内部组件的交互来实现备份和恢复操作。RMAN的备份和恢复原理如下：

• RMAN通过Oracle数据库的控制文件和数据文件，获得数据库的结构和状态信息。

• RMAN通过Oracle数据库的恢复目录，获得备份集和备份策略的信息。

• RMAN通过Oracle数据库的恢复目录和控制文件，获得恢复需求和恢复策略。

• RMAN通过Oracle数据库的恢复目录和控制文件，生成备份集和备份信息。

• RMAN通过Oracle数据库的恢复目录和控制文件，执行恢复操作。

在迁移过程中，DTS扮演NFS服务器的角色，将数据盘通过网络进行共享。源数据库和目标数据库分别将NFS共享目录挂载到本地文件系统，源端通过RMAN完成数据库的备份任务，并将备份数据存储于NFS共享目录。随后，目标端从NFS共享目录中提取数据，执行RMAN恢复操作，以完成数据迁移过程。完整的迁移过程如下：

• DTS-VM虚拟机将自身数据盘格式化为NFS文件系统

• 在源数据库和目标端数据库挂载DTS-VM提供的NFS目录

• DTS通过SSH通道对源数据库进行RMAN全量备份

• DTS通过SSH通道在目标端数据库RESTORE全量备份

• 定时/手动对源数据库进行RMAN增量备份

• 在目标端数据库RESTORE增量备份

• 来到切换时间段，停止源端业务系统，确保不会有数据写入

• 在DMP界面手动进行数据库切换，可选择是否关闭源库

• 进行最后的增量备份数据传输和恢复动作，完成后目标端自动开机

• 目标端数据库开机成功后进行数据验证与业务验证

• 在进行RMAN数据迁移的过程中，必须确保源数据库与目标数据库实例名的一致性。若两者名称不一致，可能会导致迁移过程中出现兼容性问题。因此，在新建目标数据库时，必须确认其实例名与源数据库相匹配。DMP平台会对此进行检查，并在发现不一致时，提供错误提示和修改措施。

• 为确保数据迁移流程的顺畅执行，必须在源数据库端采取一系列关键的预备措施：启用归档日志功能，这有助于跟踪数据库的变更历史，确保数据的可恢复性；开启强制日志功能，保证数据的完整性和一致性；此外，还需开启SSH服务实现远程连接，安装NFS客户端实现数据中转。

• 在进行数据迁移时，需要采用NFS协议进行备份及数据中转。需要确保源数据库、DTS-VM以及目标数据库之间的网络通信畅通无阻，特别是端口2049和111，必须保持可访问状态。在迁移操作前，建议暂时解除所有端口的访问限制策略，以避免影响迁移传输。

• 在执行首次全量数据迁移的过程中，为保证迁移数据的一致性和完整性，RMAN对源数据库的表空间、数据文件、临时文件以及PDB实施了严格的操作限制，禁止在迁移期间进行创建或删除。如果确实需要执行这些操作，请在迁移任务启动之前完成。

• 在数据库迁移的过程中，源数据库和目标数据库的服务IP地址是不同的。在业务切换阶段，必须考虑到数据库访问客户端可能需要进行相应的访问变更。如果客户端的变更成本较高，建议在数据库切换完成后，再对目标数据库进行IP地址的修改。这包括停止源端数据库的服务并将其下线，然后将目标端数据库的IP地址更新为与源端相同的地址，确保客户端可以正常访问业务数据库。

• 在Oracle数据库12.1C的CDB模式下，将RAC迁移至单机环境时，可能会遇到目标端无法成功还原的现象。这是由Oracle的一个已知BUG（编号19503821）引起的。在进行此类迁移操作时，需要特别注意此问题，并根据Oracle官方提供的解决方案或补丁来规避或解决这一BUG带来的影响。

核心业务系统数据库在迁移至深信服云计算平台时，可能存在CPU和内存配置紧张，或资源过剩的情况，需要对原服务器进行配置变更评估。评估原则如下：

• 在正式执行数据迁移之前，建议将源库克隆出测试库进行一次迁移测试。这一步骤至关重要，因为不同的物理环境可能会导致迁移所需的时间出现差异。通过测试迁移，不仅可以评估迁移过程中可能遇到的时间问题，而且可以验证迁移方案的可行性和有效性。此外，迁移测试还有助于识别潜在的问题和风险，从而在正式迁移之前采取相应的预防措施。

• 数据库切换前必须确认业务系统已完全停止对数据库的访问和写入。在进行切换时，DMP 允许用户选择是否在切换过程中自动关闭源数据库。通常情况下，为了确保业务顺利上线，我们会在业务系统上线前连接源数据库进行数据验证，此时无需自动关闭源数据库。然而，如果无法确保源数据库的数据写入操作已完全停止，或者在切换过程中担心源数据有变化，那么在进行切换时选择自动关闭源数据库将是一个更为稳妥的措施。

• 数据库迁移完成后，应更新业务系统连接地址，以确保通过目标数据库的服务IP进行访问。在网络环境中，如果存在访问控制策略，应在迁移前调整策略，以避免影响业务访问。如果是白名单模式，应允许最底层的全禁止策略；如果是黑名单模式，则应在最上层添加允许所有策略。待业务系统完全迁移后，再重新启用相应的访问控制策略。

• 在数据库成功迁移并经过业务验证之后，建议立即进行全面备份。这样，在目标数据库遇到无法迅速解决的问题时，可以迅速恢复到迁移后的状态。同时，建议保留源数据库的运行状态（但不要关闭服务器），以便在新平台出现问题时，能够迅速切换回源数据库继续提供服务。

• 在数据库迁移和切换过程中，必须确保源数据库环境的完整性不受破坏。如果在切换过程中遇到异常，或者在业务验证阶段发现问题，应立即联系深信服产品线专家和数据库管理员（DBA）寻求支持。在允许的时间范围内，应优先诊断问题，调整迁移参数或系统配置，以迅速恢复迁移流程。

• 在数据库迁移过程中，如果遇到无法在停机窗口期内迅速解决的异常问题，应立即回退到源数据库环境。在回退之前，需要分析失败的原因，并根据分析结果重新制定迁移计划。在决定回退时，要确保在迁移过程中没有新的业务数据写入到新数据库，以避免在回退过程中丢失最新的业务数据。

通过DMP平台，用户可以在深信服的云计算环境中迅速搭建Oracle数据库，作为数据迁移的目标库。DMP平台利用深信服提供的数据库优化镜像，实现了从虚拟机操作系统到数据库应用的自动化和高效率部署过程。创建单机数据库只需要15分钟，创建 RAC集群也可以在90分钟到120分钟内完成，数据库实例在云平台自动调优保证最佳性能运行。本文所涉及的迁移过程是从Oracle单机迁移至RAC集群。

DMP平台支持Oracle数据库的11g、12cR2和19c三个主要版本，无论是单机还是Oracle RAC配置，都可以通过以下步骤轻松创建：

导入深信服提供的Oracle部署镜像：深信服的数据库研发团队精心打造了一款经过深度优化的数据库镜像，此镜像针对操作系统和数据库软件进行了全面的调优。部署基于这款优化镜像的系统，可以充分利用云计算平台的强大性能，同时确保数据库应用以最高效率运行。

在DMP平台中，用户可选取预先上传的镜像来创建Oracle RAC节点。通过一个用户友好的向导，用户能够对数据库的网络配置和参数进行详尽的设置和调整。DMP平台内置的Agent插件，嵌入于数据库镜像之中，负责自动化地传递和配置数据库的基本信息。此外，该插件还具备监控数据库状态的功能，使得用户无需直接访问数据库即可完成配置的自动化调整。

数据库创建完成后，作为备库开机，等待DTS创建迁移任务。迁移前请确保源库已开启归档日志、确保SSH处于开启状态且具备管理员权限、确保源端安装好NFS工具。数据库运行过程中可以在DMP监控界面对数据库状态信息进行实时状态监控。注：DMP管理平台仅提供Oracle等数据库的运维能力，并不包含官方license。

数据库迁移的过程利用DTS迁移工具来实现，在迁移工作启动之前，必须确保DTS-VM虚拟机地址具有对源数据库进行SSH连接（默认端口为22）的访问权限，以及源数据库地址能够访问DTS-VM的NFS服务（默认端口为2049和111）。以下是迁移的具体步骤：

使用DTS迁移工具新建迁移任务，若源数据库已使用RMAN工具进行备份，则在执行迁移任务前，暂停已有的RMAN备份策略，否则会对迁移任务造成影响。DTS通过SSH端口来进入到源端进行迁移操作，目标端数据库直接选择已在DMP上创建完成的数据库。

在确认源数据库和目标数据库的配置之后，接下来需要为数据库迁移设置实例参数、数据同步的频率、以及备份数据的压缩和加密策略。当启动DTS工具执行迁移任务时，它将自动进行一系列预检查，包括验证源和目标数据库之间的连通性、时区设置、数据库版本兼容性以及数据校验等。预检查中发现的“不通过项”将直接影响迁移任务的执行，必须在迁移前解决；而“告警项”则通常不会妨碍迁移过程，可以在人工审核后选择忽略，继续执行迁移任务。

首先进行全量迁移过程，DTS会完成以下动作：启动目标端NFS服务、源库挂载NFS、源库备份控制文件和数据库文件、目标库启动至nomount、目标库restore控制文件、目标库启动至mount、目标库restore数据库文件、源库备份归档日志、目标库recover数据库文件、校验未记录的日志文件。全量迁移过程中对源库业务不会产生影响，建议在业务低峰期执行，或者减少并发数并时刻观察对生产业务产生的影响。所有DTS操作过程都会添加时间戳显示在前端，运维人员可实时监控整个迁移过程。

在首次全量备份成功完成后，DTS系统将进入持续性的增量同步阶段。这一过程可以通过手动操作或自动化设置来实现。增量同步的核心任务是定期将源数据库的归档日志备份传输至目标数据库，并执行恢复操作。在增量迁移的过程中RMAN持续拷贝源数据库的增量日志来完成迁移，这种增量同步操作不会对源数据库的业务运行造成任何影响。

数据库迁移切换过程需要停库中断业务，在确定了停机时间后，应向各业务部门发布维护通知，停止业务和应用对源数据库的访问，避免产生数据丢失等意外情况产生。同时需协调业务人员、运维人员、应用厂商、深信服厂商等多方工作人员协助保障迁移切换和业务验证工作。

数据库切换的整个流程由DMP平台自动化执行，涵盖了一系列关键步骤：①DMP备份源端数据库的最终归档日志；②在目标端执行数据恢复操作；③启动目标端的数据库服务。在这一过程中，DMP将重新编译所有无效的对象，确保数据库对象的可用性和一致性。最后，DMP将卸载源端和目标端的NFS挂载点，以完成切换过程。

在数据库切换流程完全执行完毕后，所有源端数据将被成功迁移至目标端数据库。此时，可以对源端和目标端数据库进行连接，以进行数据的检查和校验，确保数据库状态的一致性。完成数据校验后，应协调业务团队成员进行业务访问测试。这一测试过程至关重要，从业务角度来看，它确保了系统能够正常工作，满足业务需求。

在使用RMAN执行数据库迁移任务时，DTS依赖于SSH服务来远程访问源数据库服务器，并执行NFS挂载及数据传输命令。如果源端数据库服务器的SSH服务无法正常访问，这将会影响数据库迁移任务的执行。在这种情况下，需要手动登录到源数据库服务器，启动SSH服务，并确保root用户具备SSH登录权限。此外，还应检查并关闭可能限制SSH访问的ACL策略。如果源端数据库已被DMP纳管，可以通过DMP提供的图形界面，按照提示进行相应的SSH服务配置和权限设置。

在使用RMAN执行数据库迁移任务时，必须确保归档日志已被启用，否则会在迁移时影响迁移数据的完整性。DTS在迁移前会检查数据库配置，当发现归档日志未启用时会显示为不通过，并在界面提示开启归档日志的操作命令。

注意：启用归档日志的过程需要在数据库关闭状态下进行配置更改，再重启数据库。因此，必须合理评估这一操作所需的时间，以避免对业务造成不必要的中断。

为了启用归档日志，需要设置数据库初始化参数“log_archive_dest_1”。在设置此参数时，请确保指定的路径存在且具备读写权限，还需要有足够的存储空间来保存归档日志文件。

Oralce单机环境开启归档日志：

Oracle RAC环境开启归档日志：

在使用RMAN执行数据库迁移任务时，必须确保强制日志已被启用。因为当源数据库在迁移期间有大量写入操作时，若未启用强制归档日志，将无法保证所有写入操作都被记录在归档日志中。这可能导致在目标数据库恢复后出现数据块损坏的问题。

根据Oracle文档ID 958181.1所述，使用RMAN增量备份滚动备用数据库时，如果存在未记录日志的更改（nologging changes），则可能导致备用数据库无法正确同步。为避免这种情况，启用强制归档日志是至关重要的。这样做可以确保在迁移过程中，所有的数据库操作都被准确地记录在归档日志中，从而保证了数据的完整性和一致性。

数据库内检查强制日志是否开启：

使用RMAN执行数据库迁移任务时，如果源数据库存在处于offline状态的数据文件，这可能会导致备份和恢复任务遭遇失败。原因在于RMAN无法对offline的数据文件进行备份，这些文件在备份过程中会被忽略，从而导致备份数据的不完整。在恢复阶段，由于缺少这些关键文件，恢复操作也可能无法成功完成。

为了避免这种情况，在进行数据库迁移之前，必须确保所有的数据文件都处于online状态。这可以通过执行相应的SQL命令将offline文件重新激活，以确保它们能够被RMAN正常备份。这一步骤对于保障迁移过程中数据的完整性和恢复任务的成功至关重要。

数据库内将offline数据文件上线：

迁移完成后，把此数据还原为offline：