Oracle 26ai Data Guard实战：RMAN Active Duplicate搭建物理备库全解析-代码聚汇网

Oracle 26ai Data Guard实战：RMAN Active Duplicate搭建物理备库全解析

周传炽·2026-09-02·阅读 22 GEO检测（免费）

Oracle 26aiData GuardRMAN Active Duplicate

|难度：普通|阅读约 40 分钟

Oracle 26ai上线之后，大家的目光基本都被AI Vector Search、JSON集合、图分析这些新特性吸引过去了，高可用这块反而容易被忽略。但真正跑生产的都清楚，数据平台吹得再牛，底子不稳照样翻车。最近我在26ai环境里完整走了一遍Data Guard搭建，用的是RMAN Active Duplicate方式，整个过程从参数准备、静态监听、duplicate执行到MRP日志应用，踩了不少新版本特有的坑。这篇就把整个流程和排查思路完整记录下来，给要在26ai上做物理备库的人一个可以直接参考的实操手册。

1. 先看26ai的变化：为什么Active Duplicate仍是首选备库创建方式

Oracle AI Database 26ai这个版本，底层架构和23ai相比本质上没有翻天覆地的变化，数据库核心还是多进程架构，Redo、Undo、Data Guard这些经典机制都还在。真正的变化集中在两个方向：一是AI能力全面下沉到数据库内核，比如向量检索、AI SQL、内置的机器学习推理；二是运维自动化程度更高，很多以前要手工调的东西现在变得更智能。但有一点没变——Data Guard依然是官方主推的企业级高可用方案，物理备库依然是RPO=0场景下的标准答案。

创建物理备库有几种常见方式：冷拷贝、从备份集Restore、RMAN Active Duplicate、以及利用Data Guard Broker的自动创建。对比一下就知道为什么Active Duplicate在实际工程里最常用：

冷拷贝需要停库，生产环境基本不可能接受
从备份集Restore，需要先有一套完整的备份，备份策略不完善的系统会卡在这步
Data Guard Broker自动创建，操作简单但出问题后排查链路长，不利于理解底层原理
Active Duplicate从源库在线复制，不需要停库，不需要预先备份，一条命令直接完成数据文件复制和参数配置

Active Duplicate的核心原理是：RMAN连接到一个辅助实例（auxiliary instance），通过网络直接从目标数据库读取数据文件块，复制到辅助实例指定的路径，然后完成恢复和启动。整个过程相当于把备份、传输、Restore三步合为一体，省去了中间环节。而且在26ai上，RMAN的通道压缩和并行度控制比旧版本更稳，大库复制效率有明显提升。

适合通过Active Duplicate搭备库的场景，我总结下来有这几类：生产库在线搭建灾备节点、新购服务器需要快速同步一份数据、版本升级后需要重建备库、测试环境从生产拉一份最新数据。这几类场景我最近在26ai上都验证过，核心流程一致，只是在文件路径和参数上要做适配。

需要提醒一下，Active Duplicate对网络带宽和延迟有一定要求。数据文件全部走网络传输，100GB的库在千兆网下大概要跑20到30分钟，这个时间内源库IO和网络IO都会被拉高，生产环境建议在低峰期操作，或者用RMAN的DURATION参数控制限速。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 主备参数与静态监听：搭建前最容易返工的三个环节

很多人一上来就执行duplicate命令，结果各种报错，问题大部分出在准备阶段。我按顺序讲清楚，照着做基本一次过。

2.1 初始化参数：哪些必须配，哪些可以省

主库和备库的初始化参数，需要根据角色分别设置。这里有个容易犯错的地方：主库和备库的DB_NAME必须一致，DB_UNIQUE_NAME必须不同，这是Data Guard识别的关键。

主库需要的核心参数：

code复制-- 主库 pfile/spfile 关键参数示例
DB_NAME=orcl
DB_UNIQUE_NAME=orcl_pri
LOG_ARCHIVE_CONFIG='DG_CONFIG=(orcl_pri,orcl_stb)'
LOG_ARCHIVE_DEST_1='LOCATION=/u01/app/oracle/oradata/arch VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=orcl_pri'
LOG_ARCHIVE_DEST_2='SERVICE=orcl_stb LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=orcl_stb'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
FAL_SERVER=orcl_stb
FAL_CLIENT=orcl_pri
STANDBY_FILE_MANAGEMENT=AUTO

备库需要的关键参数：

code复制-- 备库 pfile/spfile 关键参数示例
DB_NAME=orcl
DB_UNIQUE_NAME=orcl_stb
LOG_ARCHIVE_CONFIG='DG_CONFIG=(orcl_pri,orcl_stb)'
LOG_ARCHIVE_DEST_1='LOCATION=/u01/app/oracle/oradata/arch VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=orcl_stb'
LOG_ARCHIVE_DEST_2='SERVICE=orcl_pri LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=orcl_pri'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
FAL_SERVER=orcl_pri
FAL_CLIENT=orcl_stb
STANDBY_FILE_MANAGEMENT=AUTO
DB_FILE_NAME_CONVERT='/u01/app/oracle/oradata/orcl/tbs','/u01/app/oracle/oradata/orcl/tbs'
LOG_FILE_NAME_CONVERT='/u01/app/oracle/oradata/orcl/redo','/u01/app/oracle/oradata/orcl/redo'

几个参数背后的逻辑我解释一下：

LOG_ARCHIVE_CONFIG里的DG_CONFIG列表，写的是主备库的DB_UNIQUE_NAME清单，两边保持一致，漏一个就可能导致ORA-16047
LOG_ARCHIVE_DEST_2里用SERVICE指定备库的净服务名，这个名称必须和tnsnames.ora里配置的完全一致，大小写都不能错
FAL_SERVER和FAL_CLIENT是用于日志缺口自动补拉，主库配FAL_SERVER指向备库，备库配FAL_SERVER指向主库，注意是反的
STANDBY_FILE_MANAGEMENT=AUTO自动管理备库端数据文件的增删，这个一定要设，否则主库加数据文件后备库不会自动同步
VALID_FOR参数用于区分日志传输的角色限制，有PRIMARY_ROLE、STANDBY_ROLE、ALL_ROLES几种组合，配置不当会导致日志不归档

26ai版本里，如果使用了数据库闪回区（Fast Recovery Area），需要额外注意DB_RECOVERY_FILE_DEST和DB_RECOVERY_FILE_DEST_SIZE这两个参数，备库的闪回区大小要按主库日志量和归档频率合理规划，否则可能因为空间不足导致日志应用中断。

2.2 静态监听：为什么一定要配SID_LIST

这是最容易被忽视的一环。Active Duplicate过程中，RMAN需要连接辅助实例，而辅助实例在nomount阶段还没有动态注册到监听器，这时候监听器必须通过静态注册才能识别到辅助实例的SID。没有静态监听，duplicate命令就会在连接auxiliary时报ORA-12514。

主备库的listener.ora都建议配置静态SID：

code复制SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = orcl_pri)
      (ORACLE_HOME = /u01/app/oracle/product/26.0.0/dbhome)
      (SID_NAME = orcl)
    )
    (SID_DESC =
      (GLOBAL_DBNAME = orcl_stb)
      (ORACLE_HOME = /u01/app/oracle/product/26.0.0/dbhome)
      (SID_NAME = orcl)
    )
  )

注意这里主备库的SID_NAME它们是一样的（因为DB_NAME一致），但GLOBAL_DBNAME可以不同，对应DB_UNIQUE_NAME。在listener里加两个SID_DESC是为了确保在主备不同机器上都能通过服务名连接到对应的库。实际上主库机器上的监听只需要主库的SID_DESC，备库机器上的监听只需要备库的SID_DESC，但为了角色切换方便，两边都配齐更好。

修改listener.ora后必须重启监听生效：

code复制lsnrctl reload
lsnrctl status

2.3 tnsnames.ora与服务命名

主备库的tnsnames.ora要同时包含主库和备库的连接描述，这样主库才能向备库传日志，备库才能从主库拉日志，同时RMAN才能连接两端。

code复制ORCL_PRI =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.10)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl_pri)
    )
  )

ORCL_STB =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.20)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl_stb)
    )
  )

HOST位置需要填入实际IP，有些环境用主机名解析，如果DNS不稳定建议直接上IP。用tnsping验证网络连通性，能通再往下走。

3. 实战：用RMAN Active Duplicate完成Data Guard备库创建

环境准备好后，就可以开始实操了。我以一个实际项目为例：主库是26ai单实例，DB_UNIQUE_NAME=orcl_pri，备库服务器全新安装的26ai软件，DB_UNIQUE_NAME=orcl_stb，目录结构两边一致。

3.1 备库启动到nomount：先有个空壳实例

在备库服务器上，先用pfile或spfile启动一个空实例。由于还没有数据文件，只能到nomount状态。

code复制-- 设置临时环境变量
export ORACLE_SID=orcl
sqlplus / as sysdba

-- 创建spfile（如果还没有）
CREATE SPFILE FROM PFILE='/u01/app/oracle/product/26.0.0/dbhome/dbs/init.ora';

-- 启动到nomount
STARTUP NOMOUNT;

-- 确认状态
SELECT INSTANCE_NAME, STATUS FROM V$INSTANCE;

这里有一种更省事的做法：直接从主库拷贝一份pfile到备库，修改DB_UNIQUE_NAME、FAL_SERVER等参数后用来启动。好处是避免手写参数漏配置，坏处是要小心改的地方别漏，尤其FAL_SERVER和LOG_ARCHIVE_DEST_2里的SERVICE名。

3.2 主库检查：archivelog和force logging必须开启

从11g开始Active Duplicate就要求主库必须处于archivelog模式。如果主库还在noarchivelog模式，会直接报ORA-00265错误。同时建议开启force logging，确保所有操作都记日志，保证备库一致性。

code复制-- 检查归档模式
ARCHIVE LOG LIST;

-- 如果没开，需要先开（需要停机操作，谨慎执行）
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;

-- 开启force logging，这个可以在线做
ALTER DATABASE FORCE LOGGING;

另外还需要确认主库的密码文件是存在的且设置了REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE，密码文件中SYS用户的密码在备库也必须一致，否则日志传输会报ORA-16191。

code复制-- 检查密码文件参数
SHOW PARAMETER REMOTE_LOGIN_PASSWORDFILE;

如果密码不一致，最简单的办法是把主库的$ORACLE_HOME/dbs/orapw<sid>文件拷贝到备库相同位置。

3.3 执行duplicate：一条命令拉平全库

所有前置条件满足后，在任意一台机器上执行RMAN即可，通常从主库服务器上发起更稳妥，因为对主库环境的依赖最小。

code复制rman TARGET sys/oracle@ORCL_PRI AUXILIARY sys/oracle@ORCL_STB

RMAN> DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE NOFILENAMECHECK;

这条命令的执行逻辑是这样的：RMAN先检查主库状态，然后在辅助实例上创建控制文件、恢复参数文件、复制数据文件，最后执行不完全恢复并把备库置为standby状态。整个过程中RMAN会自动处理归档日志的传输和恢复。

对于大库，建议通过DURATION控制时间窗口，避免长时间占用网络带宽：

code复制RMAN> DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE NOFILENAMECHECK DURATION 02:00;

DURATION参数的意思是尽量在2小时内完成，如果没完成会暂停，下次可以继续，适合生产环境限速场景。

执行过程中可以打开另一个会话查看进度：

code复制SELECT SID, SERIAL#, OPNAME, SOFAR, TOTALWORK, ROUND(SOFAR/TOTALWORK*100,2) PCT
FROM V$SESSION_LONGOPS
WHERE TOTALWORK > 0 AND OPNAME LIKE '%RMAN%';

26ai的RMAN在duplicate时默认会做自动的并行度调优，数据文件多的时候建议手动指定通道并行：

code复制RMAN> RUN {
  ALLOCATE CHANNEL c1 DEVICE TYPE DISK;
  ALLOCATE CHANNEL c2 DEVICE TYPE DISK;
  ALLOCATE AUXILIARY CHANNEL a1 DEVICE TYPE DISK;
  ALLOCATE AUXILIARY CHANNEL a2 DEVICE TYPE DISK;
  DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE NOFILENAMECHECK;
}

手动分配通道的好处是能明确看到每个通道处理了哪些文件，排错时信息更清晰。自动分配的通道在出问题时定位比较费劲。

3.4 duplicate完成后的状态确认

duplicate命令正常结束后，备库会自动启动到mount状态。验证一下：

code复制-- 在备库执行
SELECT DATABASE_ROLE, OPEN_MODE, PROTECTION_MODE, DATABASE_STATUS FROM V$DATABASE;

标准的输出应该是：

code复制DATABASE_ROLE      OPEN_MODE      PROTECTION_MODE
------------------ -------------- --------------------
PHYSICAL STANDBY   MOUNTED        MAXIMUM PERFORMANCE

到这里，一个物理备库的骨架已经建好了。剩下的就是启用日志应用、验证数据同步、测试切换。

4. 目录结构不同怎么办：文件转换参数的正确配置姿势

前面演示的是主备目录结构一致的情况。但实际工程里，主备服务器磁盘规划往往不同，比如主库数据文件在/oradata01/orcl，备库挂载点在/data/oracle/orcl。这时候名称转换参数必须提前配好，否则duplicate会报ORA-01511、ORA-01105之类的错误。

4.1 两个转换参数的区别

DB_FILE_NAME_CONVERT：数据文件路径转换，格式是成对的（源路径，目标路径）
LOG_FILE_NAME_CONVERT：联机日志和备用日志路径转换

code复制DB_FILE_NAME_CONVERT='/oradata01/orcl','/data/oracle/orcl'
LOG_FILE_NAME_CONVERT='/oradata01/orcl/redo','/data/oracle/orcl/redo'

执行duplicate时，RMAN会定期检查主库数据文件的路径，然后自动替换成备库路径。如果在备库上找不到目标目录，或者目录权限不对，会直接报错。所以操作前务必确认目标目录已创建且属主正确：

code复制mkdir -p /data/oracle/orcl
chown oracle:oinstall /data/oracle/orcl

4.2 使用OMF和ASM的场景

如果数据文件用了Oracle Managed Files（OMF），路径转换会更简单，因为路径由数据库自动管理，只需要改db_create_file_dest。但如果在ASM磁盘组之间转换，比如主库在+DATA，备库也要在+DATA，就需要注意两个实例的ASM磁盘组名和路径是否一致，否则转换参数要写成上面那种成对形式。

code复制DB_CREATE_FILE_DEST='+DATA'
DB_CREATE_ONLINE_LOG_DEST_1='+DATA'
DB_CREATE_ONLINE_LOG_DEST_2='+FRA'

这种情况下db_file_name_convert往往不需要，RMAN会自动按OMF规则在目标磁盘组里创建文件。

4.3 nofilenamecheck的含义与风险

我的duplicate命令里加了NOFILENAMECHECK，意思是关闭RMAN对源库和目标库数据文件路径的自动检查。不加这个参数时，如果RMAN发现两边的路径完全相同，可能会认为存在同名文件的冲突风险而报错。加上之后可以规避这类检查，但也意味着你需要自己保证转换参数的准确性。

风险点在于：如果漏配转换参数又加了nofilenamecheck，duplicate可能把数据文件创建到意外位置，或者在备库目录下创建了与主库同路径的目录结构，导致后续维护混乱。建议把转换参数配置好后，在duplicate前用以下SQL验证路径映射是否正确：

code复制-- 主库查看数据文件路径
SELECT FILE#, NAME FROM V$DATAFILE;
SELECT MEMBER FROM V$LOGFILE;

手动检查一遍映射关系后，再执行duplicate。这个步骤花不了两分钟，能帮你省掉一小时的排错时间。

5. 从MRP到角色切换：验证备库不是摆设

备库创建完成只是第一步，能不能正常接收日志、能不能快速切换，才是真正的验证核心。

5.1 启动MRP日志应用进程

备库处于mount状态后，需要启动Managed Recovery Process（MRP）来应用主库传过来的归档日志和联机日志。26ai上MRP的启动方式和旧版本一致：

code复制-- 在备库执行
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

USING CURRENT LOGFILE表示实时应用，备库可以边收边应用当前联机日志，而不是等归档完成后再应用，能显著缩小主备延迟。

启动后的验证：

code复制-- 查看MRP进程状态
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, DELAY_MINS FROM V$MANAGED_STANDBY;

-- 查看主备同步状态
SELECT NAME, VALUE, UNIT FROM V$DATAGUARD_STATS;

重点关注V$DATAGUARD_STATS里的transport lag和apply lag两个指标，正常情况下应该都是0（单位是天+时间格式）。

code复制-- 查看备库的日志应用进度
SELECT THREAD#, SEQUENCE#, APPLIED, FIRST_TIME, NEXT_TIME
FROM V$ARCHIVED_LOG
WHERE RESETLOGS_ID = (SELECT MAX(RESETLOGS_ID) FROM V$ARCHIVED_LOG)
ORDER BY SEQUENCE#;

5.2 主备数据一致性验证

日志应用起来后，可以在主库上做一轮DML操作，再在备库上验证数据是否同步。注意备库是只读的，只能在mount状态下查，开放只读查询需要先ALTER DATABASE OPEN READ ONLY，但这样会暂停MRP，需要再次启动。

更推荐的做法是在备库mount状态下，通过V$DATAGUARD_STATS和V$ARCHIVED_LOG来确认同步，不打断MRP。

code复制-- 主库执行
CREATE TABLE TEST_SYNC AS SELECT * FROM DBA_OBJECTS WHERE ROWNUM <= 1000;
INSERT INTO TEST_SYNC VALUES (1, 'DATA GUARD 26AI TEST');
COMMIT;
ALTER SYSTEM SWITCH LOGFILE;

然后在备库上确认最后应用的日志序列号：

code复制SELECT MAX(SEQUENCE#) AS APPLIED_SEQ FROM V$ARCHIVED_LOG WHERE APPLIED='YES';

如果这个序列号大于等于主库当前日志序列号，说明同步正常。也可以用比较文件的方式验证，但日常运维中通过日志序列号确认就足够了。

5.3 快速演练：备库切换成主库

验证备库能不能真正接管业务，最直接的办法是做一次角色切换。这里演示物理备库的标准Switchover流程：

code复制-- 在主库执行
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;

-- 在备库执行（在切换到主库之前，备库先启动到mount）
-- 在备库执行
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
ALTER DATABASE OPEN;

注意顺序不能乱，主库先切到standby角色，备库再切到primary角色。切换完成后验证：

code复制-- 新主库（原备库）验证
SELECT DATABASE_ROLE, OPEN_MODE FROM V$DATABASE;
-- 期望输出：PRIMARY  READ WRITE

测试完成后可以再切回来，恢复原状。整个流程走一遍，备库的可用性基本可以放心。

6. 26ai环境下的典型报错与排错实录

最后这部分，把我最近在26ai上搭Data Guard时遇到的几个真实报错和排查过程整理出来，都是网上很难直接搜到答案的坑。

6.1 ORA-12514: 监听器无法识别连接描述符中的服务

这个报错在duplicate阶段最常见。原因是备库的监听器里没有静态SID配置，或者配置后没有reload。最典型的场景是：备库还没启动到nomount，RMAN通过动态服务名去连接辅助实例，但实例还没起来，动态注册失败，监听器当然不认识这个服务。

排查步骤：

code复制1. 确认备库已启动到nomount
2. 确认listener.ora里有SID_LIST_LISTENER配置
3. lsnrctl reload 重新加载
4. lsnrctl services 查看监听器实际注册的服务

如果lsnrctl services里能看到静态SID，问题就解决了。如果还不行，检查tnsnames.ora里SERVICE_NAME是否和listener.ora里的GLOBAL_DBNAME一致。

6.2 ORA-16191: 主库日志传输未启动

这个报错通常出现在主库切换日志后，备库无法接收归档。原因是主备库的密码文件不一致，或者REMOTE_LOGIN_PASSWORDFILE参数不对。

解决方案：把主库的orapw文件拷贝到备库，重启备库，然后重新启动MRP。在26ai上，如果使用了两节点以上集群，还需要检查密码文件是否在所有节点上同步。

6.3 备库自动恢复挂起，状态为WAITING_FOR_LOG

在26ai上如果配置了FRA，备库的归档日志空间满了，MRP会自动挂起。排查方法是查看V$RECOVERY_STATUS和告警日志：

code复制SELECT * FROM V$RECOVERY_STATUS;
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE=200G SCOPE=BOTH;

如果是日志应用缓慢导致的堆积，需要确认主库归档频率和网络带宽。通常加大备库FRA容量可以解决大部分问题，但根治方案是优化日志传输，改ASYNC为SYNC，或者增加网络带宽。

6.4 CDB/PDB架构下，PDB没有全部打开

26ai默认以CDB架构安装。如果主库是CDB，duplicate整个CDB后，备库所有PDB需要处于和主库一致的状态。有时候PDB会处于MOUNTED状态，导致业务连不上。

code复制-- 在备库执行
ALTER PLUGGABLE DATABASE ALL OPEN;

但注意，如果备库要一直保持standby角色，PDB不应该随意打开为读写模式，否则会导致日志应用失败。正确做法是让PDB跟随CDB的standby状态，通过ALTER PLUGGABLE DATABASE pdb1 OPEN READ ONLY，或者使用Data Guard Broker统一管理。

6.5 Data Guard Broker在26ai上的变化

26ai里Data Guard Broker（dgmgrl）做了不少自动化增强，包括角色切换时的自动临时表空间文件处理、更细粒度的健康检查等。搭建完成后，建议立刻注册到Broker管理：

code复制dgmgrl sys/oracle@orcl_pri
CREATE CONFIGURATION dg_config AS PRIMARY DATABASE IS orcl_pri CONNECT IDENTIFIER IS orcl_pri;
ADD DATABASE orcl_stb AS CONNECT IDENTIFIER IS orcl_stb;
ENABLE CONFIGURATION;
SHOW CONFIGURATION;

通过dgmgrl可以看到更清晰的同步状态和潜在问题，后续的switchover和failover也建议由Broker接管，减少人为操作失误。

6.6 关于26ai的AI自动调优功能

最后提一句，26ai的自治数据库相关特性在Data Guard环境里也能用，比如自动内存调优会自动适配备库的角色切换。但AI调优改变参数后，主备两边的参数可能产生漂移，建议用参数基线对比功能定期检查主备参数一致性，避免切换后性能异常。

code复制SELECT NAME, VALUE FROM V$SGA_TARGET_ADVICE;

这条查询可以看到内存自动调优的建议值，作为参考即可，不必过度依赖。真正重要的还是把Data Guard基础链路维护好，日志传输和应用不出问题，AI功能才有发挥空间。

我在实际使用中的体会是：Data Guard搭建这件事，90%的精力都在准备阶段，参数、监听、目录、权限这些搞定了，duplicate本身其实很快。而在26ai上，新版本对duplicate的自动化程度已经很高，很多老版本的兼容性坑也都填平了，只要按上面这套流程走，大概率一次成功。最后再分享一个小技巧：搭建完成后，把主备库的完整参数文件都导出一份保存好，切换或故障恢复时对照着看，很多莫名其妙的延迟问题其实都是参数漂移造成的。