数据库级迁移的基础是Oracle归档日志、其中包含数据库更改的日志。大多数情况下、归档日志是备份和恢复策略的一部分。恢复过程首先会还原数据库、然后重播放一个或多个归档日志、以使数据库达到所需状态。这种基本技术也可用于执行迁移、操作中断极少甚至不会中断。更重要的是、此技术支持迁移、同时保持原始数据库不变、并保留一条回退路径。

迁移过程从将数据库备份还原到二级服务器开始。您可以通过多种方式执行此操作、但大多数客户都使用其常规备份应用程序来还原数据文件。还原数据文件后、用户将建立日志传送方法。目标是为主数据库生成的归档日志创建一个持续源、并在还原的数据库中重放这些日志、以使它们接近相同的状态。转换时间到后、源数据库将完全关闭、最终归档日志(在某些情况下、重做日志)将被复制并重排。重做日志也要予以考虑、这一点非常重要、因为它们可能包含已提交的某些最终事务。

在传输和回显示这些日志后、两个数据库将保持一致。此时、大多数客户都会执行一些基本测试。如果在迁移过程中发生任何错误、则日志重放应报告错误并失败。仍然建议根据已知查询或应用程序驱动型活动执行一些快速测试、以验证配置是否最佳。在关闭初始数据库之前创建一个最终测试表、以验证迁移的数据库中是否存在该表、这也是一种常见做法。此步骤可确保在最终日志同步期间不会发生任何错误。

可以针对原始数据库配置简单的日志传送迁移、这对于任务关键型数据库尤其有用。源数据库不需要更改配置、迁移环境的还原和初始配置对生产操作没有影响。配置日志传送后、它会对生产服务器提出一些I/O需求。但是、日志传送包含对归档日志的简单顺序读取、这不太可能对生产数据库性能产生任何影响。

事实证明、日志传送对于远距离、高变更率的迁移项目特别有用。在一个实例中、一个220 TB的数据库迁移到了大约500英里以外的新位置。更改率极高、而且安全限制阻止了使用网络连接。日志传送是使用磁带和信使执行的。源数据库的副本最初是使用下面概述的过程进行还原的。然后、派送员每周发送一次日志、直至转换时交付最后一组磁带并将日志应用于副本数据库。

在某些情况下、需要一个完整的DataGuard环境。使用术语DataGuard来指代任何日志传送或备用数据库配置是不正确的。Oracle DataGuard是一种用于管理数据库复制的全面框架、但它不是一种复制技术。在迁移过程中、完整的DataGuard环境的主要优势是可以从一个数据库透明地切换到另一个数据库。此外、如果发现问题(例如新环境的性能或网络连接问题描述)、Dataguard还可以透明地切回原始数据库。完全配置的DataGuard环境不仅需要配置数据库层、还需要配置应用程序、以便应用程序能够检测到主数据库位置的更改。一般来说、不需要使用DataGuard完成迁移、但一些客户在内部拥有丰富的DataGuard专业知识、并已依赖它来执行迁移工作。

如前文所述、利用存储阵列的高级功能有时需要更改数据库布局。此外、存储协议的更改(例如从ASM迁移到NFS文件系统)也必然会更改文件系统布局。

日志传送方法(包括DataGuard)的主要优势之一是、复制目标不必与源匹配。使用日志传送方法从ASM迁移到常规文件系统时没有问题、反之亦然。可以在目标位置更改数据文件的精确布局、以优化可插拔数据库(PDB)技术的使用、或者有选择地对某些文件设置QoS控制。换言之、基于日志传送的迁移过程可让您轻松安全地优化数据库存储布局。

数据库级迁移的一个限制是需要另一台服务器。可以通过两种方式使用第二台服务器：

第一种选择最简单、但在需要非常强大的服务器的超大型环境中使用它可能并不可行。第二个选项需要额外的工作才能将文件系统重新定位回原始位置。这可能是一个简单的操作、其中会使用NFS作为存储协议、因为文件系统可以从暂存服务器上卸载、然后重新挂载到原始服务器上。

基于块的文件系统需要额外的工作才能更新FC分区或iSCSI启动程序。使用大多数逻辑卷管理器(包括ASM)时、系统会自动检测LUN、并在原始服务器上提供这些LUN后将其置于联机状态。但是、某些文件系统和LVM实施可能需要更多的工作才能导出和导入数据。确切的操作步骤可能有所不同、但通常很容易建立一个简单、可重复的操作步骤来完成迁移并将数据重新归位到原始服务器上。

虽然可以在单个服务器环境中设置日志传送和复制数据库、但新实例必须具有不同的进程SID才能重放日志。可以使用不同的SID临时启动另一组进程ID下的数据库、并在以后进行更改。但是、这样做可能会导致许多复杂的管理活动、并使数据库环境面临用户错误的风险。

不应低估简单复制操作的价值。现代网络基础架构可以按每秒千兆字节的速率移动数据、文件复制操作基于高效的顺序读写I/O与日志传送相比、主机复制操作不可避免地会造成更多中断、但迁移不仅仅是数据移动。它通常包括对网络连接、数据库重新启动时间以及迁移后测试的更改。

复制数据所需的实际时间可能不多。此外、复制操作会保留有保障的回退路径、因为原始数据不会受到影响。如果在迁移过程中遇到任何问题、可以重新激活包含原始数据的原始文件系统。

重新平台是指CPU类型的变化。将数据库从传统Solaris、AIX或HP-UX平台迁移到x86 Linux时、由于CPU架构发生更改、必须重新格式化数据。SPARC、IA64和POWER CPU称为大的恩第处理器、而x86和x86_64架构称为小恩第处理器。因此、根据所使用的处理器、Oracle数据文件中的某些数据的顺序会有所不同。

过去、客户一直使用DataPump跨平台复制数据。数据缓冲是一种实用程序、用于创建特殊类型的逻辑数据导出、可以在目标数据库中更快地导入。由于DataPump会为数据创建一个逻辑副本、因此会将处理器数据存储单的依赖关系置于身后。某些客户仍在使用数据缓冲区进行回滚、但Oracle 11g提供了一个速度更快的选项：跨平台可传输表空间。这种高级允许将表空间转换为不同的在位的字符格式。这是一种物理转换、其性能优于DataPump导出、DataPump导出必须先将物理字节转换为逻辑数据、然后再转换回物理字节。

有关DataPump和可传输表空间的完整讨论不在NetApp文档的讨论范围内、但NetApp根据我们在使用新CPU架构向新存储阵列日志迁移期间为客户提供帮助的经验提供了一些建议：

LVM的工作原理是、创建一组LUN (由一个或多个LUN组成)并将其拆分为通常称为块区的小单元。然后、块区池将用作源、用于创建从本质上进行虚拟化的逻辑卷。此虚拟化层可通过多种方式提供价值：

使用LVM进行迁移的工作方式有两种：移动块区或镜像/取消块区镜像。LVM迁移使用高效的大型块顺序I/O、很少会产生任何性能问题。如果这确实成为问题描述、通常可以选择限制I/O速率。这样做不仅会增加完成迁移所需的时间、还会减轻主机和存储系统的I/O负担。

Oracle ASM是逻辑卷管理器和文件系统的组合。从较高层面来看、Oracle ASM会获取一组LUN、将其划分为多个小的分配单元、并将其呈现为一个称为ASM磁盘组的卷。ASM还可以通过设置冗余级别来镜像磁盘组。卷可以是未镜像(外部冗余)、镜像(正常冗余)或三向镜像(高冗余)。配置冗余级别时必须小心、因为创建后无法更改。

ASM还提供文件系统功能。尽管文件系统不会直接从主机中显示、但Oracle数据库可以在ASM磁盘组上创建、移动和删除文件和目录。此外、还可以使用asmcmd实用程序来导航此结构。

与其他LVM实施方式一样、Oracle ASM通过在所有可用LUN之间对每个文件的I/O进行条带化和负载平衡来优化I/O性能。其次、可以重新定位底层块区、以便调整ASM磁盘组的大小以及进行迁移。Oracle ASM可通过重新平衡操作自动执行此过程。新的LUN将添加到ASM磁盘组、而旧的LUN将被丢弃、这将触发块区重新定位、并随后将清空的LUN从磁盘组中删除。此过程是经验证的迁移方法之一、ASM在提供透明迁移方面的可靠性可能是其最重要的功能。

几乎可以使用NetApp SnapMirror数据复制软件在NetApp系统之间执行数据库迁移。此过程涉及到为要迁移的卷设置镜像关系、允许这些卷进行同步、然后等待转换窗口。到达后、源数据库将关闭、并执行一次最终镜像更新、同时镜像将断开。然后、可以通过挂载包含的NFS文件系统目录或发现包含的LUN并启动数据库来准备好使用副本卷。

在单个ONTAP集群中重新定位卷不会视为迁移、而是一项例行操作 volume move 操作。SnapMirror用作集群中的数据复制引擎。此过程完全自动化。当卷的属性(例如LUN映射或NFS导出权限)随卷本身一起移动时、无需执行其他迁移步骤。重新定位不会中断主机操作。在某些情况下、必须更新网络访问、以确保以尽可能最高效的方式访问新重新定位的数据、但这些任务也不会造成中断。

FLI功能允许运行8.3或更高版本的Data ONTAP系统从另一个存储阵列迁移现有LUN。操作步骤非常简单：ONTAP系统像任何其他SAN主机一样分区到现有存储阵列。然后、Data ONTAP会控制所需的原有LUN并迁移底层数据。此外、导入过程会在迁移数据时使用新卷的效率设置、这意味着可以在迁移过程中对数据进行实时压缩和重复数据删除。

首次在Data ONTAP 8.3中实施FLI时、仅允许脱机迁移。虽然传输速度非常快、但这仍意味着在迁移完成之前LUN数据不可用。联机迁移是在Data ONTAP 8.3.1中推出的。此类迁移可使ONTAP在传输过程中提供LUN数据、从而最大限度地减少中断。重新分区主机以通过ONTAP使用LUN时、会发生短暂中断。但是、一旦进行了这些更改、数据就可以再次访问、并且在整个迁移过程中始终可以访问。

读取I/O会通过ONTAP代理、直到复制操作完成、而写入I/O会同时写入外部LUN和ONTAP LUN。这两个LUN副本将以这种方式保持同步、直到管理员执行完全转换以释放外部LUN且不再复制写入。

FLI可与FC结合使用、但如果需要更改为iSCSI、则迁移的LUN可以在迁移完成后轻松地重新映射为iSCSI LUN。

FLI的功能包括自动对齐检测和调整。在此上下文中、术语对齐是指LUN设备上的分区。要获得最佳性能、需要将I/O与4K块对齐。如果将分区放置在非4 k倍数的偏移位置、则会影响性能。

对齐的第二个方面无法通过调整分区偏移量(文件系统块大小)来更正。例如，ZFS文件系统通常默认为内部块大小512字节。使用AIX的其他客户偶尔会创建块大小为512字节或1、即1、即1、0 4字节的JFS2文件系统。尽管文件系统可能会与4 k边界对齐、但在该文件系统中创建的文件不会对齐、性能会受到影响。

在这些情况下、不应使用FLI。尽管迁移后可以访问数据、但结果是文件系统存在严重的性能限制。一般来说、在ONTAP上支持随机覆盖工作负载的任何文件系统都应使用4 k块大小。这主要适用于数据库数据文件和VDI部署等工作负载。可以使用相关的主机操作系统命令来确定块大小。

例如、在AIX上、可以使用查看块大小 lsfs -q。使用Linux、 xfs_info 和 tune2fs 可用于 xfs 和 ext3/ext4。使用 zfs，则命令为 zdb -C。

用于控制块大小的参数为 ashift 通常默认为9、表示2^9或512字节。为了获得最佳性能、 ashift 值必须为12 (2^12=4k)。此值在创建zpool时设置、并且无法更改、这意味着数据zpool具有 ashift 应通过将数据复制到新创建的zpool来迁移12以外的文件。

Oracle ASM没有基本块大小。唯一的要求是构建ASM磁盘的分区必须正确对齐。

7-模式过渡工具(7MTT)是一款自动化实用程序、用于将大型7-模式配置迁移到ONTAP。大多数数据库客户发现其他方法更容易、部分原因是他们通常会逐个数据库迁移环境数据库、而不是重新定位整个存储占用空间。此外、数据库通常只是大型存储环境的一部分。因此、数据库通常会单独迁移、然后可以使用7MTT移动其余环境。

有少数客户拥有专用于复杂数据库环境的存储系统、但数量相当多。这些环境可能包含许多卷、快照和大量配置详细信息、例如导出权限、LUN启动程序组、用户权限和轻型目录访问协议配置。在这种情况下、7MTT的自动化功能可以简化迁移。

7MTT可在以下两种模式之一下运行：

这两种方案之间的主要区别在于、无副本过渡是一种大爆炸方法、在这种方法中、连接到原始7-模式HA对的所有磁盘架都必须重新定位到新环境。无法移动部分磁盘架。基于副本的方法允许移动选定卷。此外、无副本过渡的转换窗口可能会更长、因为重新对磁盘架进行转换和转换元数据需要关联。根据现场经验、NetApp建议留出1小时的时间来重新定位磁盘架并重新为其接通网络、而留出15分钟到2小时的时间来进行元数据转换。