一、最高优先级：备用库compatible参数设置错误（19c最易踩坑）
原因
虽然数据库安装的是19c，但备用库的初始化参数compatible被错误设为11.2.0.4（比如复制了旧11g的参数文件、手动改错），导致实例以11g兼容模式运行，读取19c原生备份片时就会报“版本不兼容”。
验证方法（备用库执行）
sqlplus/assysdba-- 查看compatible参数（必须是19.x.x.x）showparameter compatible;-- 也可以查v$database确认selectname,valuefromv$parameterwherename='compatible';如果输出是11.2.0.4/12.1.0.2等非19c值，就是这个问题。
解决步骤
-- 1. 关闭备用库实例shutdownimmediate;-- 2. 修改spfile（如果用pfile，直接编辑initDGSTBY.ora）altersystemsetcompatible='19.0.0.0'scope=spfile;-- 3. 重新启动到nomount（19c兼容模式）startup nomount;-- 验证：再次查看参数，必须是19.0.0.0showparameter compatible;二、主备库19c补丁版本不一致（小版本不兼容）
原因
Oracle 19c的不同补丁集（比如19.3 vs 19.18 vs 19.21）会导致RMAN备份片的元数据格式差异，即使都是19c，高补丁版本主库的备份片，低补丁版本备库也会报“版本不兼容”。
验证方法
1. 主库查完整版本
sqlplus/assysdba-- 查详细版本（含补丁）selectbanner_fullfromv$version;-- 示例输出：Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production-- Version 19.18.0.0.02. 备用库查完整版本
sqlplus/assysdbaselectbanner_fullfromv$version;对比两者的补丁版本（比如主库19.18，备库19.3），差异≥3个补丁级就可能触发该错误。
解决步骤
- 优先将备库补丁升级到与主库完全一致（推荐，符合DG最佳实践）；
- 临时方案：改用“备份集+恢复”模式（避开active模式的实时备份片传输），步骤参考之前给你的“主库备份→备库恢复”流程（去掉11g相关限制即可）。
三、备用库ORACLE_HOME被“污染”（混用11g二进制）
原因
备库机器上同时装了11g和19c，即使ORACLE_HOME设为19c，但若LD_LIBRARY_PATH/PATH混入11g路径，会导致RMAN/OCI调用11g的库文件，从而报版本不兼容。
验证方法（备用库执行）
# 1. 查LD_LIBRARY_PATH（不能包含11g的lib目录）echo$LD_LIBRARY_PATH# 2. 查RMAN二进制的真实版本（必须是19c）$ORACLE_HOME/bin/rman --version# 3. 查Oracle二进制文件的版本file$ORACLE_HOME/bin/oracle- 如果
LD_LIBRARY_PATH有/u01/app/oracle/product/11.2.0/dbhome_1/lib； - 如果
rman --version输出是11.2.0.4； - 就是这个问题。
解决步骤
# 1. 清空旧环境变量，重新配置纯19c环境unsetLD_LIBRARY_PATHunsetORACLE_HOMEunsetPATH# 2. 重新设置19c环境（替换为你的真实路径）exportORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1exportLD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATHexportPATH=$ORACLE_HOME/bin:$PATHexportORACLE_SID=DGSTBY# 3. 验证：再次查RMAN版本rman --version# 正确输出：RMAN for Linux: Version 19.0.0.0.0 - Production四、主库备份时显式限制了“兼容性”（反向兼容坑）
原因
主库之前执行RMAN备份时，用了COMPATIBLE WITH '11.2.0.4'参数，强制备份片兼容11g，导致19c备库读取时反而报“19c备份片不兼容11g”（逻辑反了，但Oracle会触发该错误）。
验证方法（主库执行）
rman target /# 列出最近的备份，查看兼容属性list backup summary;# 或查备份元数据selectbs.recid, bs.completion_time, bs.compatibility fromv$backup_setbs where bs.backup_type='F'and rownum<=5;如果compatibility列显示11.2.0.4，就是这个问题。
解决步骤
# 主库重新执行无兼容限制的全库备份rman target / run{allocate channel ch1typedisk;# 去掉COMPATIBLE WITH参数，纯19c备份backup full databaseformat'/u01/backup/DGPRIM_19c_full_%U.bkp'include current controlfile;release channel ch1;}然后重新用这个纯19c备份片执行active duplicate（或备库恢复）。
五、TNS连接的服务名指向错误实例（19c多实例环境）
原因
备库机器有多个19c实例，你的TNS服务名DGSTBY指向了另一个19c实例（比如测试库），而那个实例的compatible参数是11g兼容模式，导致RMAN连错库报版本错。
验证方法
# 1. 测试TNS指向的实例SIDtnsping DGSTBY# 2. 用TNS连接后查实例信息sqlplus sys/密码@DGSTBY as sysdbaselectinstance_name, host_name fromv$instance;selectvalue fromv$parameterwherename='compatible';确认实例名是DGSTBY，且compatible是19c。
解决步骤
修正tnsnames.ora，确保DGSTBY的SERVICE_NAME/SID指向正确的19c备库实例：
DGSTBY = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 备库IP)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SID = DGSTBY) # 明确指定SID，避免连错实例 (SERVICE_NAME = DGSTBY) ) )总结
- 19c环境下的
ORA-19690，90%是备用库compatible参数设成了低版本，优先检查这个参数； - 其次是主备19c补丁版本不一致，或备库环境变量混入11g路径；
- 排除以上后，再验证TNS指向、主库备份的兼容限制，均可快速定位问题。
你可以先按顺序查：compatible参数 → RMAN二进制版本 → 主备补丁版本，这三个点能解决99%的19c同版本下的ORA-19690错误。
