Oracle 11g RAC 异机恢复实战（漫画版）

前言

节后刚到公司，业务那边就来了一个需求：有一套测试库的数据太老了，需要从生产库恢复一份数据过去。

生产库和测试库都是 Oracle 11g RAC，准备使用 RMAN DUPLICATE 完成恢复。原本以为很简单，就是清理旧库、恢复数据、配置 RAC，没想到过程中还是遇到了几个问题：

RMAN DUPLICATE 成功后，修改参数时报 ORA-01565，找不到 SPFILE；
RAC 第二节点启动后一直停留在 STARTED 状态；
登录第二节点时，又遇到了 ORA-09925 报错。

好在最后都解决了，两个实例正常 OPEN，完整启停测试也顺利通过。

这类生产库恢复到测试环境的需求应该挺常见，索性就把这次从旧库清理、RMAN 恢复到 RAC 重建的完整操作过程记录下来，方便以后遇到类似需求时直接参考。

一、环境及恢复方案

先看一下环境：

项目	源端生产库	目标测试库
Oracle 版本	11.2.0.4	11.2.0.4
数据库架构	双节点 RAC	双节点 RAC
DB_NAME	PRODDB	PRODDB
DB_UNIQUE_NAME	proddb	testdb
实例名称	proddb1 / proddb2	testdb1 / testdb2
节点名称	生产 RAC 节点	rac-test01 / rac-test02
数据存储	ASM	+DATA
FRA	ASM	+FRA
恢复方式	RMAN 备份	Backup-Based DUPLICATE

目标端 Oracle Home：

Bash

1/u01/app/oracle/product/11.2.0/dbhome_1

RMAN 备份目录：

Bash

1/backup/rman

本次采用 Backup-Based DUPLICATE，直接使用已有的 RMAN 备份恢复，不需要连接生产库。

主要分为三个步骤：

清理原测试库，保留现有 RAC 和 ASM 环境。
执行 RMAN DUPLICATE，先恢复为单实例数据库。
配置 RAC 参数及 Clusterware，恢复双节点运行。

源端和目标端的 DB_NAME 均为 PRODDB，目标端使用独立的 DB_UNIQUE_NAME：testdb。

二、恢复前检查

1. 检查 RMAN 备份目录

这套生产库的 RMAN 备份是通过 NFS 挂载到目标服务器作为存储，先检查：

Bash

1df -h /backup/rman
2mount | grep /backup
3ls -ld /backup/rman
4ls -lh /backup/rman | head

确认 Oracle 用户可以正常读取备份文件，并检查数据文件、控制文件及归档日志备份是否齐全。

如果可以连接源库，可通过 RMAN 查看备份信息：

RMAN

1LIST BACKUP SUMMARY;
2LIST BACKUP OF DATABASE;
3LIST BACKUP OF ARCHIVELOG ALL;

本次使用 Level 0 备份，结合归档日志恢复，最终恢复至 SCN 73594150946。

2. 检查目标 RAC 集群

首先确认目标 RAC 环境正常，使用 grid 用户执行：

Bash

1crsctl stat res -t

重点检查 ASM、监听、VIP、SCAN 等资源，再检查 ASM 磁盘组：

Bash

1asmcmd lsdg

确认 +DATA、+FRA 正常挂载，并且有足够的可用空间，需要注意：ASM 磁盘组的 Free_MB 不一定等于实际可用空间，特别是 NORMAL、HIGH 冗余磁盘组，还要关注 Usable_file_MB。

接着查看当前 Clusterware 中注册的数据库：

Bash

1srvctl config database

如果已经存在 testdb，还需要进一步检查：

Bash

1srvctl config database -d testdb -a
2srvctl status database -d testdb
3srvctl config service -d testdb

这次目标端原本就有一套测试数据库，所以不能直接启动 DUPLICATE，必须先处理旧数据库。

3. 检查 Oracle 软件环境

两个节点都要确认 Oracle Home 和软件版本：

Bash

1echo $ORACLE_HOME
2echo $ORACLE_SID
3which sqlplus
4which rman
5sqlplus -v

本次使用 Oracle 11.2.0.4，恢复阶段先在第一个节点操作：

Bash

1export ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1
2export ORACLE_SID=testdb1
3export PATH=$ORACLE_HOME/bin:$PATH

第二节点后续使用：

Bash

1export ORACLE_SID=testdb2

三、清理原测试数据库

目标端已有一套测试 RAC，本次需要使用生产数据重新恢复，因此需要先清理原测试库，保留现有 GI、ASM 和监听环境，再执行 RMAN DUPLICATE。

1. 保存原数据库信息

先连接旧测试数据库：

Bash

1sqlplus / as sysdba

检查数据库身份：

SQL

1SELECT name,
2       db_unique_name,
3       dbid,
4       open_mode
5FROM v$database;

检查 RAC 实例：

SQL

1SELECT inst_id,
2       instance_name,
3       host_name,
4       status
5FROM gv$instance
6ORDER BY inst_id;

保存 SPFILE 和控制文件位置：

SQL

1SHOW PARAMETER spfile;
2SHOW PARAMETER control_files;

查询数据文件：

SQL

1SELECT file#, name
2FROM v$datafile
3ORDER BY file#;

查询临时文件：

SQL

1SELECT file#, name
2FROM v$tempfile
3ORDER BY file#;

查询 REDO：

SQL

1SELECT group#, member
2FROM v$logfile
3ORDER BY group#;

提前记录原测试库的数据文件、控制文件和 REDO 路径，方便后续清理 ASM 文件时核对，避免误删其他数据库文件。

2. 备份原测试库配置

先导出参数文件：

SQL

1CREATE PFILE='/home/oracle/init_testdb_before_rebuild.ora'
2FROM SPFILE;

再保存 Clusterware 配置：

Bash

1srvctl config database -d testdb -a \
2  > /home/oracle/testdb_srvctl_before_rebuild.txt

如果原测试库的数据还需要保留，应提前做好备份，避免清理后无法恢复。

3. 停止原测试数据库

确认旧测试库已停用、数据允许覆盖后，停止数据库：

Bash

1srvctl stop database -d testdb -o immediate

检查：

Bash

1srvctl status database -d testdb

确认两个实例均已停止：

1Instance testdb1 is not running on node rac-test01
2Instance testdb2 is not running on node rac-test02

两个节点分别检查 PMON 进程：

Bash

1ps -ef | grep '[p]mon'

确认原实例已退出。

4. 注销旧 Clusterware 资源

注销旧数据库的 Clusterware 资源：

Bash

1srvctl remove database -d testdb
2srvctl config database

确认 testdb 已注销。注意，srvctl remove database 不会删除 ASM 中的数据文件。

5. 检查并清理 ASM 文件

使用 grid 用户：

Bash

1asmcmd lsdg
2asmcmd ls +DATA/
3asmcmd ls +FRA/

查看旧数据库目录：

Bash

1asmcmd ls -l +DATA/TESTDB/
2asmcmd ls -l +FRA/TESTDB/

结合前面记录的控制文件、数据文件和 REDO 路径，逐一核对待清理文件的归属。

确认文件已废弃且没有其他资源引用后，再执行：

Bash

1asmcmd rm <已确认废弃文件的完整ASM路径>

清理 ASM 文件前，建议先确认好文件的归属，避免误删。也可以根据实际情况使用 RMAN DROP DATABASE 删除旧库，但要确保不影响现有 GI、ASM、监听、VIP 和 SCAN 等集群资源。

6. 清理旧实例本地配置

两个节点分别检查：

Bash

1ls -l $ORACLE_HOME/dbs/*testdb*

主要关注：

1inittestdb1.ora
2inittestdb2.ora
3spfiletestdb1.ora
4orapwtestdb1
5orapwtestdb2

先备份旧配置：

Bash

1mkdir -p /home/oracle/testdb_old_config

将旧 PFILE、SPFILE 和密码文件移入备份目录，核实后再清理原文件。

清理完成后，再确认：

Bash

1srvctl config database
2crsctl stat res -t
3asmcmd lsdg

确认旧库已清理，GI 和 ASM 正常，准备恢复。

四、准备 RMAN 辅助实例

在第一个节点准备 RMAN 辅助实例，恢复阶段暂不启用 RAC。

1. 创建 PFILE

使用 oracle 用户：

Bash

1export ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1
2export ORACLE_SID=testdb1
3export PATH=$ORACLE_HOME/bin:$PATH

创建初始化参数文件：

Bash

1vi $ORACLE_HOME/dbs/inittestdb1.ora
2## 写入以下内容
3db_name='PRODDB'
4db_unique_name='testdb'
5instance_name='testdb1'
6cluster_database=FALSE
7db_create_file_dest='+DATA'
8db_recovery_file_dest='+FRA'
9db_recovery_file_dest_size=100G
10diagnostic_dest='/u01/app/oracle'
11audit_file_dest='/u01/app/oracle/admin/testdb/adump'
12job_queue_processes=0

以上为参考参数，FRA 大小、内存及兼容性参数按实际环境调整；db_name 必须与源库备份一致。

2. 创建审计目录

Bash

1mkdir -p /u01/app/oracle/admin/testdb/adump
2chmod 750 /u01/app/oracle/admin/testdb/adump

两个节点都需要创建审计目录，后面遇到的 ORA-09925 就与此有关。

3. 启动 NOMOUNT

Bash

1sqlplus / as sysdba

执行：

SQL

1STARTUP NOMOUNT
2PFILE='/u01/app/oracle/product/11.2.0/dbhome_1/dbs/inittestdb1.ora';

检查：

SQL

1SELECT instance_name, status
2FROM v$instance;
3
4INSTANCE_NAME STATUS
5------------- -------
6testdb1       STARTED

辅助实例处于 STARTED（NOMOUNT）即可，后续由 RMAN 完成恢复。

五、执行 RMAN DUPLICATE

这里采用 Backup-Based DUPLICATE，直接通过 RMAN 备份恢复，无需连接生产库。

1. 确认备份和恢复目标

恢复前确认备份目录、源库 DBID、数据文件及控制文件路径，以及归档日志和目标恢复 SCN。

本次分配 4 个辅助通道，共恢复 59 个数据文件，最终恢复至 SCN 73594150946，并通过 RESETLOGS 打开数据库。

2. 准备 RMAN 脚本

以下为 RMAN DUPLICATE 参考脚本，实际执行时需根据备份信息、ASM 路径和目标恢复 SCN 调整。

先通过辅助实例连接 RMAN：

Bash

1rman auxiliary /

参考脚本：

RMAN

1RUN {
2  ALLOCATE AUXILIARY CHANNEL a1 DEVICE TYPE DISK;
3  ALLOCATE AUXILIARY CHANNEL a2 DEVICE TYPE DISK;
4  ALLOCATE AUXILIARY CHANNEL a3 DEVICE TYPE DISK;
5  ALLOCATE AUXILIARY CHANNEL a4 DEVICE TYPE DISK;
6
7  DUPLICATE DATABASE 'PRODDB' DBID 1234567890
8    TO 'PRODDB'
9    BACKUP LOCATION '/backup/rman'
10    NOFILENAMECHECK;
11
12  RELEASE CHANNEL a1;
13  RELEASE CHANNEL a2;
14  RELEASE CHANNEL a3;
15  RELEASE CHANNEL a4;
16}

该脚本仅供参考，实际执行前需确认 RMAN 语法、ASM 文件路径及恢复 SCN，避免覆盖其他数据库文件。

3. 执行恢复

将 RMAN 脚本保存为：

1/home/oracle/duplicate_testdb.rman

执行：

Bash

1rman auxiliary / \
2  cmdfile=/home/oracle/duplicate_testdb.rman \
3  log=/home/oracle/duplicate_testdb.log

查看恢复日志：

Bash

1tail -f /home/oracle/duplicate_testdb.log

重点查看数据文件恢复、归档应用及 RESETLOGS 是否成功。

RMAN 日志显示：

1database opened
2
3Finished Duplicate Db
4
5Recovery Manager complete.

DUPLICATE 完成。

4. 检查恢复结果

SQL

1SELECT name,
2       db_unique_name,
3       dbid,
4       open_mode,
5       database_role,
6       resetlogs_time
7FROM v$database;
8
9NAME     DB_UNIQUE_NAME OPEN_MODE  DATABASE_ROLE
10-------- -------------- ---------- -------------
11PRODDB   testdb         READ WRITE PRIMARY

确认目标库 DBID 已更新，再检查数据文件：

SQL

1SELECT file#, name, status
2FROM v$datafile
3ORDER BY file#;

确认数据文件已恢复至目标 ASM，接下来配置双节点 RAC。

六、处理 SPFILE 丢失问题

恢复完成后，准备修改 RAC 参数：

SQL

1ALTER SYSTEM SET cluster_database=TRUE SCOPE=SPFILE SID='*';

结果报错：

1ORA-01565: error in identifying file
2ORA-27037: unable to obtain file status
3Linux-x86_64 Error: 2: No such file or directory

检查：

SQL

1SHOW PARAMETER spfile;

发现当前实例引用的仍然是本地 SPFILE：

1/u01/app/oracle/product/11.2.0/dbhome_1/dbs/spfiletestdb1.ora

但是操作系统上已经没有这个文件：

Bash

1ls -l $ORACLE_HOME/dbs/*testdb*

实例虽然已经 OPEN，但引用的 SPFILE 文件不存在，导致无法写入参数。

重新创建 ASM 共享 SPFILE：

SQL

1CREATE SPFILE='+DATA/TESTDB/spfiletestdb.ora' FROM MEMORY;
2
3File created.

检查 ASM：

Bash

1asmcmd ls -l +DATA/TESTDB/spfiletestdb.ora

在两个节点分别配置 PFILE，指向共享 ASM SPFILE。

rac-test01：

Bash

1cat > $ORACLE_HOME/dbs/inittestdb1.ora <<'EOF'
2SPFILE='+DATA/TESTDB/spfiletestdb.ora'
3EOF

rac-test02：

Bash

1cat > $ORACLE_HOME/dbs/inittestdb2.ora <<'EOF'
2SPFILE='+DATA/TESTDB/spfiletestdb.ora'
3EOF

新 SPFILE 不会自动生效，重启第一个实例：

SQL

1SHUTDOWN IMMEDIATE;
2STARTUP;

再次检查：

SQL

1SHOW PARAMETER spfile;

确认已经指向：

1+DATA/TESTDB/spfiletestdb.ora

确认 SPFILE 已切换。

七、配置双节点 RAC 参数

接下来配置 RAC 参数。

1. 配置集群参数

SQL

1ALTER SYSTEM SET cluster_database=TRUE SCOPE=SPFILE SID='*';
2ALTER SYSTEM SET cluster_database_instances=2 SCOPE=SPFILE SID='*';

2. 配置实例编号

SQL

1ALTER SYSTEM SET instance_number=1 SCOPE=SPFILE SID='testdb1';
2ALTER SYSTEM SET instance_number=2 SCOPE=SPFILE SID='testdb2';

3. 配置 REDO Thread

SQL

1ALTER SYSTEM SET thread=1 SCOPE=SPFILE SID='testdb1';
2ALTER SYSTEM SET thread=2 SCOPE=SPFILE SID='testdb2';

4. 配置 UNDO

SQL

1ALTER SYSTEM SET undo_tablespace='UNDOTBS1' SCOPE=SPFILE SID='testdb1';
2ALTER SYSTEM SET undo_tablespace='UNDOTBS2' SCOPE=SPFILE SID='testdb2';

5. 禁用自动任务

由于数据库来自生产环境，暂时不允许自动执行原生产库的任务：

SQL

1ALTER SYSTEM SET job_queue_processes=0 SCOPE=SPFILE SID='*';

6. 清理遗留参数

检查：

SQL

1SELECT sid, name, value
2FROM v$spparameter
3WHERE name IN (
4  'cluster_database',
5  'cluster_database_instances',
6  'instance_name',
7  'instance_number',
8  'thread',
9  'undo_tablespace',
10  'job_queue_processes'
11)
12AND isspecified = 'TRUE'
13ORDER BY name, sid;
14
15*.instance_name = testdb1

恢复阶段遗留了全局 instance_name，需要清理，避免第二节点继承。

执行：

SQL

1ALTER SYSTEM RESET instance_name SCOPE=SPFILE SID='*';

同时清理全局 UNDO 参数：

SQL

1ALTER SYSTEM RESET undo_tablespace SCOPE=SPFILE SID='*';

最终保留实例级配置：

1*.cluster_database           TRUE
2*.cluster_database_instances 2
3testdb1.instance_number       1
4testdb2.instance_number       2
5testdb1.thread                1
6testdb2.thread                2
7testdb1.undo_tablespace       UNDOTBS1
8testdb2.undo_tablespace       UNDOTBS2
9*.job_queue_processes         0

7. 检查 REDO 和 UNDO

先检查 REDO：

SQL

1SELECT group#,
2       thread#,
3       bytes/1024/1024 mb,
4       status
5FROM v$log
6ORDER BY thread#, group#;

本次两个 Thread 均已配置，每个 Thread 5 组 REDO，每组 300MB。

检查：

SQL

1SELECT thread#, status, enabled
2FROM v$thread
3ORDER BY thread#;

第二节点尚未启动时，Thread 2 可能显示 CLOSED。

再检查 UNDO：

SQL

1SELECT tablespace_name, status
2FROM dba_tablespaces
3WHERE contents='UNDO';

本次 REDO 和两个 UNDO 表空间均已存在，无需重新创建。

八、准备密码文件并注册 Clusterware

1. 准备密码文件

两个节点分别需要：

1rac-test01: $ORACLE_HOME/dbs/orapwtestdb1
2rac-test02: $ORACLE_HOME/dbs/orapwtestdb2

使用 orapwd 创建密码文件，密码应与目标数据库 SYS 密码一致。

Oracle 11g 环境可以使用：

Bash

1orapwd file=$ORACLE_HOME/dbs/orapwtestdb1

设置 SYS 密码后，将密码文件复制到第二节点并调整文件名，确保两个节点保持一致。

2. 注册数据库

使用 oracle 用户执行：

Bash

1srvctl add database \
2  -d testdb \
3  -o /u01/app/oracle/product/11.2.0/dbhome_1 \
4  -p +DATA/TESTDB/spfiletestdb.ora \
5  -r PRIMARY \
6  -s OPEN

注册实例：

Bash

1srvctl add instance -d testdb -i testdb1 -n rac-test01
2srvctl add instance -d testdb -i testdb2 -n rac-test02

添加 ASM 磁盘组依赖：

Bash

1srvctl modify database -d testdb -a "DATA,FRA"

检查：

Bash

1srvctl config database -d testdb -a

确认：

1Database unique name: testdb
2Spfile: +DATA/TESTDB/spfiletestdb.ora
3Database instances: testdb1,testdb2
4Disk Groups: DATA,FRA
5Type: RAC
6Database is enabled

3. 启动 RAC

先确保手工启动的实例已经关闭：

SQL

1SHUTDOWN IMMEDIATE;

然后通过 Clusterware 启动：

Bash

1srvctl start database -d testdb

检查：

Bash

1srvctl status database -d testdb
2
3Instance testdb1 is running on node rac-test01
4Instance testdb2 is running on node rac-test02

继续检查实例状态。

九、第二节点启动后停留在 STARTED

虽然 srvctl 显示两个实例都在运行，但进一步检查：

SQL

1SELECT inst_id,
2       instance_name,
3       host_name,
4       status,
5       thread#
6FROM gv$instance
7ORDER BY inst_id;
8
9INST_ID INSTANCE_NAME HOST_NAME  STATUS  THREAD#
10------- ------------- ---------- ------- -------
111       testdb1       rac-test01 OPEN    1
122       testdb2       rac-test02 STARTED 0

第二节点仍停留在 STARTED。srvctl 显示 running，不代表实例已经 OPEN，继续登录第二节点检查。

Bash

1export ORACLE_SID=testdb2
2
3sqlplus / as sysdba
4
5ORA-09925: Unable to create audit trail file
6Linux-x86_64 Error: 2: No such file or directory

先检查磁盘：

Bash

1df -h

磁盘空间正常，继续看报错：

1No such file or directory

优先检查目录是否存在。

回到第一个节点查询：

SQL

1SHOW PARAMETER audit_file_dest;

发现审计目录：

1/u01/app/oracle/admin/testdb/adump

到第二节点检查：

Bash

1ls -ld /u01/app/oracle/admin/testdb/adump

目录不存在，补齐：

创建目录：

Bash

1mkdir -p /u01/app/oracle/admin/testdb/adump
2chmod 750 /u01/app/oracle/admin/testdb/adump

确保目录属于 Oracle 软件用户。

重新连接数据库：

Bash

1sqlplus / as sysdba

连接恢复正常，继续执行：

SQL

1ALTER DATABASE MOUNT;
2ALTER DATABASE OPEN;

执行成功。

再查：

SQL

1SELECT inst_id, instance_name, status, thread#
2FROM gv$instance
3ORDER BY inst_id;
4
5INST_ID INSTANCE_NAME STATUS THREAD#
6------- ------------- ------ -------
71       testdb1       OPEN   1
82       testdb2       OPEN   2

第二节点正常 OPEN，问题原因是审计目录缺失。

十、数据库最终验收

两个实例 OPEN 后，进行验收检查。

1. 检查数据库身份

SQL

1SELECT name,
2       db_unique_name,
3       dbid,
4       open_mode,
5       database_role
6FROM v$database;

确认数据库名称、DBID、打开状态和角色正确。

2. 检查 RAC 实例

SQL

1SELECT inst_id,
2       instance_name,
3       host_name,
4       status,
5       thread#
6FROM gv$instance
7ORDER BY inst_id;

两个实例均为 OPEN，分别使用 Thread 1 和 Thread 2。

3. 检查数据文件

SQL

1SELECT status, COUNT(*)
2FROM v$datafile
3GROUP BY status;
4
5STATUS   COUNT(*)
6-------- --------
7ONLINE         58
8SYSTEM          1

SYSTEM 为数据文件状态，属于正常结果。

4. 检查表空间

SQL

1SELECT tablespace_name, status
2FROM dba_tablespaces
3ORDER BY tablespace_name;

34 个表空间全部 ONLINE。

5. 检查数据库组件

SQL

1SELECT comp_name, status
2FROM dba_registry
3WHERE status <> 'VALID';
4
5no rows selected

6. 检查监听

两个节点分别执行：

Bash

1lsnrctl services

确认两个实例都注册到本地监听，并且状态为 READY。

再检查 SCAN：

Bash

1srvctl config scan
2srvctl status scan_listener

本地监听和 SCAN Listener 均正常，后续还需验证 SCAN 服务注册及客户端连接。

7. 完整启停测试

最后再做一次完整启停：

Bash

1srvctl stop database -d testdb -o immediate

检查：

Bash

1srvctl status database -d testdb

两个实例均已停止。

然后重新启动：

Bash

1srvctl start database -d testdb

再次检查：

Bash

1srvctl status database -d testdb

两个实例均显示 running。

登录数据库：

SQL

1SELECT inst_id, instance_name, status, thread#
2FROM gv$instance
3ORDER BY inst_id;
4
5INST_ID INSTANCE_NAME STATUS THREAD#
6------- ------------- ------ -------
71       testdb1       OPEN   1
82       testdb2       OPEN   2

完整启停通过，两个实例均由 Clusterware 正常管理。

十一、测试环境隔离

生产库复制到测试环境后，还要检查 DB Link、定时任务和外部接口，避免误连生产系统。

先检查 DB Link：

SQL

1SELECT owner, db_link, username, host
2FROM dba_db_links;

这次发现测试库仍然存在连接外部数据库的 DB Link。

连接地址已脱敏，需确认是否指向生产环境。

检查 Scheduler Job：

SQL

1SELECT owner, job_name, enabled, state
2FROM dba_scheduler_jobs
3WHERE enabled = 'TRUE';

还发现了多个已启用任务，其中包含业务相关任务。

再检查 DBMS_JOB：

SQL

1SELECT schema_user, job, broken, what
2FROM dba_jobs
3ORDER BY schema_user, job;

因此暂时保持：

SQL

1ALTER SYSTEM SET job_queue_processes=0 SCOPE=BOTH SID='*';

完成环境隔离检查前，暂不启用这些任务。

总结

本次恢复从清理原测试库开始，依次完成 RMAN DUPLICATE、共享 SPFILE 创建、RAC 参数配置及 Clusterware 注册，最终恢复双节点 RAC。

RMAN 共恢复 59 个数据文件，过程中主要遇到两个问题：

ORA-01565：恢复完成后，原 SPFILE 文件不存在，导致参数修改失败。通过 CREATE SPFILE FROM MEMORY 重新创建共享 ASM SPFILE，重启后恢复正常。
ORA-09925：第二节点启动后停留在 STARTED，排查发现 audit_file_dest 目录不存在，创建目录后正常 MOUNT、OPEN。

最后通过 srvctl 完成双节点启停验证，两个实例均正常 OPEN。

这次恢复也算再次验证了一点：RMAN DUPLICATE 完成不代表整个恢复结束，后续的 RAC 配置、监听检查和测试环境隔离同样不能少。