要上进的柯同学直接说结论：Oracle 19c的ADG（Active Data Guard）搭建，如果你手里只有一套现成的单机环境，从零开始做完全库的物理备库，按我下面的顺序一步步走，大概两个小时能跑通主备同步。整个过程不涉及RAC，不涉及DG Broker的复杂配置，就是最基础、最常用、生产环境里最普遍的那套玩法——主库开归档、开强制日志、配standby log，备库用RMAN duplicate搞定数据文件，然后开实时应用，最后验证同步和角色切换。
这篇文章适合正在学Data Guard的DBA，也适合被安排搭一套容灾、但网上教程东一榔头西一棒子、照着敲还报错的人。我会把每个操作背后的原因讲清楚，而不是只丢命令，因为ADG这玩意儿报错百分之八十出在准备工作不严谨，真正RMAN duplicate那步反而是最不容易出问题的。
1. 动手前的底层认知：ADG到底在复制什么东西
很多人第一次搭ADG，容易把注意力全放在命令上，结果遇到ORA-错误就懵。我建议你先在大脑里建立一张图：ADG的物理备库，本质上是主库数据文件的一份块级别副本，再加上主库产生的所有归档日志，持续往备库这边搬、往备库里应用。主库每产生一个日志切换，备库就多应用一批变更，两边数据文件的内容最终保持一致。
这里有个关键认知：备库不是通过什么同步协议实时拉数据的，而是主库主动把日志送过来。Oracle Data Guard的日志传输（Redo Transport）负责把主库的online redo log和归档日志传到备库，备库的MRP进程（Managed Recovery Process）负责把这些日志apply到备库的数据文件上。Active Data Guard和普通Physical Standby的唯一区别就是，ADG允许备库在实时应用日志的同时，以只读方式打开，对外提供查询、报表、备份等读负载。这一点在生产环境里非常香，容灾库不再是一台闲着吃灰的冷备机，而是能把读流量分流过去。
版本选择上，19c是目前最主流的长线支持版本，它和12c、18c在ADG搭建流程上几乎一样，但有几个细节变化要注意：
- 19c默认使用
ora-19c的密码版本，主备库之间连接时，密码文件里的密码版本必须一致，否则日志传输会报ORA-01017，这是个高频坑。 - 19c的
DB_UNIQUE_NAME概念依旧是核心，主备库的DB_NAME要相同，DB_UNIQUE_NAME必须不同，这个从11g开始就是铁律。 - 19c对磁盘路径没有强制要求OFA规范，但强烈建议主备库目录结构保持一致，后面你就知道这个决定能省多少事。
ADG的搭建思路可以概括成两条线：一条是日志的传输链路，另一条是备库的恢复链路。传输链路要打通，靠的是主备库之间的Oracle Net连接（一个tnsnames条目、一个监听、一个密码文件），恢复链路要走通，靠的是备库的控制文件、数据文件、归档日志和应用进程。这两条线在搭建过程中是并行准备的，最后在RMAN duplicate这一步汇合。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 环境规划与边界条件：哪些坑必须在开工前填平
我见过太多人上来就敲命令，结果卡在莫名其妙的地方，最后发现是环境规划没做好。ADG搭建对环境的敏感度非常高，下面这几项是开工前必须确认的。
2.1 主机与版本规划
我的实验环境是两套单实例，操作系统都是Linux 7.6，数据库版本都是19.3，打了最新的RU补丁。主备库版本一致是最省心的状态，Oracle允许备库版本高于主库，但不允许低于主库。实操中我的建议很简单：主备库装同一个版本的软件，补丁也打到同一个级别，不然以后做switchover，备库转主库那一下很容易翻车。
主机信息我习惯列一张表贴在旁边：
| 角色 | 主机名 | IP | DB_NAME | DB_UNIQUE_NAME | DB_VERSION |
|---|---|---|---|---|---|
| 主库 | primary | 192.168.56.101 | orcl | orcl_p | 19.3.0.0 |
| 备库 | standby | 192.168.56.102 | orcl | orcl_s | 19.3.0.0 |
注意DB_NAME两边一样，都是orcl，DB_UNIQUE_NAME必须不一样，一个是orcl_p，一个是orcl_s。数据文件路径我在两台机器上都用/u01/app/oracle/oradata/orcl，保持一致，后面用RMAN duplicate的时候可以省掉路径转换的麻烦。如果两边路径不一致，也可以用DB_FILE_NAME_CONVERT和LOG_FILE_NAME_CONVERT参数做映射，但能统一路径就别给自己找事。
2.2 网络与防火墙边界
主备库之间的网络必须稳定，带宽不能太小。日志传输是持续性的，高峰期主库日志切换频繁，如果网络拥塞，备库的日志缺口会越拉越大。搭建前用ping测延迟，正常内网环境1ms以内最好，超过5ms就要考虑是不是跨机房了，跨机房的话必须评估日志量再决定要不要搭。
防火墙这块我单独说。Linux 7默认firewalld是开启的，你telnet不通、监听连不上，先查防火墙而不是先怀疑监听配置。我惯用的做法是：
bash复制# 在两台机器上都执行，放行Oracle监听端口
firewall-cmd --permanent --add-port=1521/tcp
firewall-cmd --reload
# 验证端口通不通
telnet 192.168.56.101 1521
另外还要确认/etc/hosts里两条主机的解析都配好了，Oracle Net对主机名解析非常敏感，你写主机名连不通但写IP能通，多半就是hosts配置的问题。配好之后用tnsping验证，这是我最先做的连通性测试。
2.3 磁盘空间与归档格式
主备库的磁盘空间要预留充足。备库这边除了要放一套完整的数据文件，还要放从主库传过来的归档日志。19c的归档日志如果没配置自动清理策略，会一直堆积，尤其ADG备库上，DB_RECOVERY_FILE_DEST如果用了FRA，空间满了之后MRP进程会直接挂掉，主备同步中断。实操中我建议：
- 数据文件所在文件系统至少留30%余量。
- 归档空间独立规划，不要和数据文件挤在一起，我一般给FRA分配不少于100GB。
- 主库也检查
DB_RECOVERY_FILE_DEST_SIZE，确保归档能写进去。
主库的日志模式必须提前检查：
sql复制-- 确认归档模式和强制日志状态
SELECT log_mode, force_logging, supplemental_log_data_pk, supplemental_log_data_all FROM v$database;
ADG不要求强制补充日志（supplemental log），但强烈建议打开FORCE LOGGING，这样能避免某些NOLOGGING操作（比如direct load）在备库产生不可用的数据块。运维规范里，开了ADG的主库必须FORCE LOGGING，这是硬规矩。
3. 主库端改造：把主库变成一台"愿意往外发日志"的机器
主库是ADG的源头，源头不改造，后面全白搭。这一节我按顺序操作，每一步都说明目的。
3.1 开启归档模式与强制日志
如果你的库还没开归档，先做这一步。开了归档之后，主库每次日志切换都会把redo log的内容复制成归档日志文件，这是备库获取数据变更的载体。
sql复制-- 用sysdba登录
sqlplus / as sysdba
-- 若是RAC环境需要先关