在知识库中专注阅读，并随时返回相关工具与课程
本章目标：掌握本章核心知识点 前置要求：完成前序章节学习 预计时长：60 分钟
自从开始使用 RMAN Duplicate 搭建 DG 之后，发现非常好用，基本都是这样去操作，也没有遇到过什么问题。
这次有一个 20T 左右的库需要搭建 DG，放在后台去跑 Dup，结果早上看了下，报错了：
正常应该是 dup 完成后可以直接开库了。
尝试手动启动数据库报错 ORA-19838：
直接 startup mount 也是报错：
alert 日志：
12025-10-17T08:52:27.367981+08:002ORA-19838 signalled during: ALTER DATABASE MOUNT...搜索 MOS 发现一篇文档比较符合：Mounting Standby Database After RMAN Duplicate Failure Returns Error ORA-19838 (Doc ID 2452298.1)
但是数据库版本是 19.24，应该已经包括了这个 BUG 修复：
根据 MOS 提示：
To workaround the issue, restore a standby controlfile from the primary to the standby database.
参考以下几篇文档：
重建备库控制文件：
1SQL> alter session set tracefile_identifier='control_create';2SQL> alter database backup controlfile to trace resetlogs;在 diag 跟踪目录中，找到上方命令创建的跟踪文件，名称中包含 'control_create'，编辑跟踪文件，删除所有除 create controlfile 命令之外的信息，将更改保存到 SQL 文件：
1cat<<-EOF>/home/oracle/create_aux_controlfile.sql23EOF关闭备库，启动数据库实例到 nomount 状态，执行重建控制文件 SQL：
1shu immediate2startup nomount3@/home/oracle/create_aux_controlfile.sql使用以下命令检查数据文件：
1alter session set nls_date_format = 'DD-MON-RRRR HH24:MI:SS';2select status,checkpoint_change#,checkpoint_time, count(*),fuzzy from v$datafile_header3group by status,checkpoint_change#,checkpoint_time, fuzzy;打开并恢复辅助数据库：
1RMAN> {2 set until scn 36836414202;3 recover4 standby5 clone database6 delete archivelog7 ;8}至此，备库可以正常打开。
后来我又想了一下，有可能是因为 Veeam 在备份的时候，把归档日志删除了，导致 Dup 过程中无法获取到所需的归档日志，所以才恢复失败的。
看了下 Veeam 的配置策略：
并且是昨天晚上 11 点多执行成功的：
也就是说当 duplicate 需要归档日志进行恢复的时候，归档日志已经从 ASM 磁盘组中被删除，我怀疑有可能是这个原因导致的 Duplicate 失败，还需要进行实验验证。