Oracle RMAN增量迁移Windows单机到Linux Oracle RAC

本案例根据真实案例整理，但是文档中目录与环境均在虚拟机环境中模拟，不涉及任何敏感信息，由于经过了多次修改，所以存在不同部分，目录与文件不对应情况，但是不影响整体阅读。

• 数据库版本11.2.0.4

1. 基础数据备份恢复

由于Windows与Linux同属于little endian平台，所以Windows平台RMAN数据库备份可以在Linux直接使用，但是Windows平台下的归档日志无法在Linux平台直接用于recover database，所以需要使用增量备份解决增量问题，使用增量恢复，可以在不借助第三方复制软件时，最大限度减少停机时间。

1.1 源端Windows 做0级备份

# 下面仅给出示例，实际命令与并行度需要根据实际服务器负载以及磁盘能力配置。
RMAN> backup as compressed backupset incremental level 0 database format 'd:\rmanbak\full_level0_%d_%T_%s_%p' tag 'full_level_0';
RMAN> backup current controlfile format 'd:\rmanbak\ctl_level0_%d_%T_%s_%p' tag 'ctl_bak_1';

1.2 Linux端恢复0级备份

# 恢复spfile与修改pfile中参数、上传备份集到Linux服务器等基础步骤略过，下面仅演示恢复过程
RMAN> startup nomount;
RMAN> restore controlfile from '/home/oracle/oradata/CTL.BAK';
RMAN> alter database mount;
RMAN> crosscheck backup;
RMAN> delete noprompt expired backup;
RMAN> catalog start with '/home/oracle/oradata/';
RMAN> run{
set newname for database to '+dgdata';
set newname for tempfile 'C:\APP\ORADATA\TEST\TEMP01.DBF' to '+dgdata/test/temp01.dbf';
restore database;
switch datafile all;
switch tempfile all;
}

2. 增量数据恢复

2.1 源端Windows做1级备份

增量备份与level 0之间不能有其他类似第三方备份进行level 0备份，即使通道类型是SBT_TAPE也会干扰DISK的增量，会干扰level 1备份，导致无法恢复增量，由于真实案例中未仔细检查客户是否有第三方增量备份，导致第一次在快到变更时间时，发现增量恢复无法恢复，经过排查，发现备份软件在恢复的level 0之后又发起了level0，导致后面level 1实际是根据备份软件的level 0进行的，导致无法recover，紧急取消变更，都是泪啊

• 检查是否在0级备份之后有无别的0级备份

# 可以根据自己需求以及时间进行查询判断
RMAN> list backupset;
SQL> SELECT PIECE#,DEVICE_TYPE,COMPLETION_TIME FROM V$BACKUP_PIECE WHERE COMPLETION_TIME > SYSDATE-5 AND DEVICE_TYPE='SBT_TAPE';

# 通过change命令，删除生产库中干扰增量备份的0级备份信息
SQL> SELECT 'CHANGE BACKUPPIECE '||RECID||' UNCATALOG;' FROM V$BACKUP_PIECE WHERE COMPLETION_TIME > SYSDATE- 3 AND DEVICE_TYPE='SBT_TAPE' AND DELETED='NO';
RMAN> CHANGE BACKUPPIECE XXX UNCATALOG;
...

• 确认无其他0级备份信息干扰后，增量备份即可

RMAN> backup as compressed backupset incremental level 1 database format 'd:\rmanbak\incr_level0_%d_%T_%s_%p' tag 'incr_level_1';

2.2 Linux端恢复1级备份

# 增量恢复，只应用增量备份即可
RMAN> catalog start with '/home/oracle/oradata/';
RMAN> recover database;

2.3 停机窗口Windows最后一次1级备份

停机窗口前，可以根据需要，每天，每隔几小时定时将源端增量恢复一次，可以大幅度减少最后一次增量备份以及恢复的时间，缩短停机时间。

# 由于Linux无法直接应用Windows平台下归档，所以需要在停机窗口干净关闭数据库，启动到mount状态
SQL> create table test as select * from dba_users;   # 创建测试表，以便最后验证数据是否完全恢复
RMAN> shutdown immediate;
RMAN> startup mount;
RMAN> backup as compressed backupset incremental level 1 database format 'd:\rmanbak\incr_level0_%d_%T_%s_%p' tag 'incr_level_1';

# 需要在mount下重新备份最新的控制文件
RMAN> backup current controlfile format 'd:\rmanbak\ctl_level0_%d_%T_%s_%p' tag 'ctl_bak_final';

2.4 检查是否在全量之后有无增加数据文件（非常重要）

检查是否新增数据文件，对后面处理比较重要，我的真实案例中，由于增加了数据文件，但是管理员并未告诉我，我也并未检查，导致最终验证数据时，报错ORA-01135 ORA-01111 ORA-01110，由于已经open resetlogs，最后无奈只能使用bbed修改文件头，由于生产库已经静止，所以不存在数据丢失问题，只是比较曲折

生产库关闭，mount之后，最后一次增量备份恢复完成之后，理论上数据库数据文件自身已经完全一致，但是由于控制文件有以下几种情况，导致了需要注意是否在全量之后有新增加数据文件情况，不同情况处理方法也不相同。

1. 生产库关闭，mount之后，备份增量同时，备份控制文件恢复到目标端，由于windows文件系统目录特殊字符限制在更改redo位置时，使用alter database rename file时无法识别，所以恢复了最后一次控制文件之后，还需要重建一次控制文件，更改windows路径，而恢复了控制文件之后，还需要重新备份生产库新增的数据文件，在目标端进行restore。
2. 生产库关闭，mount之后，只备份增量，目标库采用重建控制文件方式，重建基准以原生产库的控制文件内容为基准，这种方式，就需要编辑所有数据文件，redo位置，这种方式与第一种相似，重建之后，重新在原生产库备份一次新增的数据文件，目标库restore即可。
3. 未确认是否新增文件，直接使用未记录新数据文件控制文件或重建控制文件open resetlogs，导致文件名变为MISSING，由于这种MISSING未进行restore，导致物理文件并不存在，所以无法通过ALTER DATABASE rename file …子句解决问题，需要使用原库备份+bbed修改新数据文件文件头即可正常恢复。

SELECT FILE#, CREATION_TIME
  FROM V$DATAFILE
 WHERE CREATION_TIME >
       TO_DATE('2022-03-05 14:00:00', 'yyyy-mm-dd hh24:mi:ss');
-- 时间为全备份开始的时间。

后面会有对这三种不同情况恢复的详细说明

2.5 Linux端恢复

下面以2.4章节中三种情况，新增数据文件进行详细说明解决方案

未新增数据文件情况不再详细说明，只需要恢复增量备份，恢复控制文件、switch database to copy或重建控制文件都可以，即可正常打开数据库。

1. 生产库关闭，mount之后，备份增量同时，备份控制文件恢复到目标端
2. 生产库关闭，mount之后，只备份增量，目标库采用重建控制文件方式，以原生产库控制文件为基准重建，由于物理上并不存在新增的数据库文件，而创建控制文件时需要控制文件语句中所有数据文件在指定的物理位置真实存在，完成校验后，才能成功创建控制文件，但是由于现有控制文件无新增文件记录，目标库无法直接使用RMAN restore新增的数据文件备份，所以这种办法需要借助DBMS_BACKUP_RESTORE包来恢复新增的数据文件，然后按照恢复的新数据文件，修改CREATE CONTROLFILE语句之后，创建控制文件之后即可成功恢复完整数据库。
3. 目标库未确认是否新增文件，由于windows目录无法识别，已经通过重建控制文件解决redo路径，并且已经open resetlogs，新增的文件变为MISSING，可以使用restore+bbed修改文件头方法恢复完整数据库，由于原库已经静止，所以数据并不会丢失。

2.5.1 第一种情况

恢复原生产库最新的控制文件

# 直接恢复最后一次增量
RMAN> catalog start with '/home/oracle/oradata/';
# 一定要先recover，如果恢复了控制文件，则由于检查点靠后，无法使用最后一次增量备份。
RMAN> recover database;

# datafile应用完最后一次增量之后，重新恢复最新控制文件，保证数据文件与控制文件记录SCN保持一致。
RMAN> shutdown immediate;
RMAN> startup nomount;
RMAN> restore controlfile from '/home/oracle/oradata/CTL_FINAL.BAK';
RMAN> alter database mount;

# 修正备份片状态
RMAN> crosscheck backup;
RMAN> delete noprompt expired backup;

# 切换控制文件中数据文件记录
RMAN> catalog start with '+dgdata/test/datafile/';
# 由于在全备之后新增了数据文件，重新恢复控制文件后，新控制文件有新增的记录，所以switch时会报如下错，这个错误，只需要重新恢复新增的数据文件即可。
RMAN> switch database to copy;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of switch to copy command at 02/18/2022 14:42:31
RMAN-06571: datafile 5 does not have recoverable copy

# 处理
-- 原生产库重新备份新增数据文件，由于为mount状态，备份出来即与现有文件一致
RMAN> backup as compressed backupset datafile 5 format 'C:\app\backup\datafile5_%U.bak';
-- 新目标库注册备份片，restore，由于mount状态备份，业务需recover，即与其他数据文件一致
RMAN> catalog start with '/home/oracle/oradata';
RMAN> run{
   
set newname for datafile 5 to '+dgdata';
restore datafile 5;
}