Oracle 19c ADG搭建实战：从零到主备同步与角色切换-代码聚汇网

Oracle 19c ADG搭建实战：从零到主备同步与角色切换

要上进的柯同学·2026-09-02·阅读 21 GEO检测（免费）

Oracle 19cActive Data Guard物理备库

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

直接说结论：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环境需要先关闭所有实例，单机直接如下操作
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE FORCE LOGGING;
ALTER DATABASE OPEN;

-- 验证
SELECT log_mode, force_logging FROM v$database;

-- 设置归档目录，19c默认使用FRA，需要用DB_RECOVERY_FILE_DEST
ALTER SYSTEM SET db_recovery_file_dest_size=100G SCOPE=BOTH;
ALTER SYSTEM SET db_recovery_file_dest='/u01/app/oracle/fra' SCOPE=BOTH;
-- 单实例也可以设置本地归档路径，但不建议，FRA统一管理更方便

这里有个细节：开归档需要重启数据库，生产环境如果没法立刻重启，可以等维护窗口，但ADG搭建这件事本身就必须停机一小会儿，后面RMAN duplicate也会从头复制数据文件，所以你要做好心理准备，找一个允许短暂停机的时间窗口来做整套操作。

3.2 配置Standby Redo Log（备库重做日志）

Standby redo log可能是ADG搭建里最容易被忽略、却最关键的一步。它和普通redo log的区别在于，它是专门用来接收来自主库的redo数据的日志文件。备库MRP进程应用日志时，优先读standby redo log，只有standby redo log没覆盖到的部分才去读归档日志。

不建standby redo log的话，ADG也能跑起来，但日志应用会有一段延迟，而且switchover时可能会出现日志缺失的问题。我的原则是：主库建几组online redo，备库就建比它多一组的standby redo，每组大小和主库online redo一致。

sql复制-- 先看主库在线日志组数量和大小
SELECT group#, bytes, status FROM v$log;
SELECT group#, member FROM v$logfile;

-- 假设主库有4组，每组200M，那备库要建5组standby redo，每组200M
-- 在备库操作，路径和主库online redo路径保持一致
ALTER DATABASE ADD STANDBY LOGFILE GROUP 11 ('/u01/app/oracle/oradata/orcl/stdby_redo11.log') SIZE 200M;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 12 ('/u01/app/oracle/oradata/orcl/stdby_redo12.log') SIZE 200M;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 13 ('/u01/app/oracle/oradata/orcl/stdby_redo13.log') SIZE 200M;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 14 ('/u01/app/oracle/oradata/orcl/stdby_redo14.log') SIZE 200M;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 15 ('/u01/app/oracle/oradata/orcl/stdby_redo15.log') SIZE 200M;

注意这个操作不是在主库做，是在备库做。很多人搞反了，备份库上执行ADD STANDBY LOGFILE报错"database not mounted"，因为备库还没创建出来。正确的时间点是在备库实例创建好、但还没打开的时候做，或者直接用RMAN DUPLICATE ... FOR STANDBY时让RMAN自动创建。我习惯在RMAN duplicate之前先把备库实例用STARTUP NOMOUNT起起来，然后手工建standby log，这样整个过程可控性更强。

3.3 主库初始化参数调整

ADG要求主库设置几个关键参数，下面是19c单实例环境的最小集：

sql复制ALTER SYSTEM SET db_unique_name='orcl_p' SCOPE=SPFILE;
ALTER SYSTEM SET log_archive_config='dg_config=(orcl_p,orcl_s)' SCOPE=BOTH;
ALTER SYSTEM SET log_archive_dest_1='location=use_db_recovery_file_dest valid_for=(all_logfiles,all_roles) db_unique_name=orcl_p' SCOPE=BOTH;
ALTER SYSTEM SET log_archive_dest_2='service=orcl_s async valid_for=(online_logfiles,primary_role) db_unique_name=orcl_s' SCOPE=BOTH;
ALTER SYSTEM SET log_archive_dest_state_2=enable SCOPE=BOTH;
ALTER SYSTEM SET standby_file_management='AUTO' SCOPE=BOTH;
ALTER SYSTEM SET fal_server='orcl_s' SCOPE=BOTH;
ALTER SYSTEM SET fal_client='orcl_p' SCOPE=BOTH;
ALTER SYSTEM SET db_file_name_convert='/u01/app/oracle/oradata/orcl','/u01/app/oracle/oradata/orcl' SCOPE=SPFILE;
ALTER SYSTEM SET log_file_name_convert='/u01/app/oracle/oradata/orcl','/u01/app/oracle/oradata/orcl' SCOPE=SPFILE;

逐个解释一下：

log_archive_config：把主备的db_unique_name都列进去，告诉Oracle这俩是一个Data Guard配置里的成员。
log_archive_dest_1：本地归档，valid_for=(all_logfiles,all_roles)表示不管主库还是备库角色，都往本地FRA写归档。这个设置很重要，否则switchover之后备库转主库，归档就断了。
log_archive_dest_2：远程传输目标，service=orcl_s对应tnsnames里配的备库服务名，async是异步传输方式。生产要求高的话可以用sync，但单机异步足够，性能影响小。
fal_server和fal_client：备库拉取缺失归档时用。fal_server配的是对端库（备库视角下就是主库），fal_client配的是本库。
db_file_name_convert和log_file_name_convert：数据文件和日志文件的路径转换映射。这里我两库路径一样，所以左右都是同一个路径，但这俩参数还是显式写上更稳妥。
standby_file_management=AUTO：备库会自动管理数据文件的增删，主库加一个数据文件，备库会自动加上。这是ADG日常运维的基石。

改完这些参数，别忘了：

sql复制-- 如果db_unique_name改动了，需要重启
SHUTDOWN IMMEDIATE;
STARTUP;

db_unique_name是存在spfile里的，改了必须重启才能生效。重启后用show parameter db_unique_name确认。

3.4 配置Oracle Net和密码文件

主备库之间要通信，靠的就是Oracle Net。我在两台机器的$ORACLE_HOME/network/admin/tnsnames.ora里都加了对方和己方的条目：

code复制ORCL_P =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = primary)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl_p)
    )
  )

ORCL_S =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = standby)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl_s)
    )
  )

这里有个细节：Oracle Net里用的SERVICE_NAME是db_unique_name，不是db_name。19c里通过DB_UNIQUE_NAME注册动态服务名，所以tnsnames里的SERVICE_NAME要写orcl_p和orcl_s，写orcl也能连，但DG传输是严格按db_unique_name匹配的。

密码文件这块，ADG的日志传输需要用sys用户的密码去远端验证连接，两边密码必须一致。最简单的做法是直接把主库的密码文件拷贝到备库：

bash复制# 在主库执行
scp $ORACLE_HOME/dbs/orapworcl oracle@standby:$ORACLE_HOME/dbs/orapworcl

19c默认密码版本是12C以上，包含了SHA512版本，只要两边密码文件一致就没问题。如果你不想拷贝，也可以在备库上手工orapwd创建密码文件并设成和主库一样的密码，效果一样。我推荐拷贝，省得记密码。

4. 备库端初始化：在复制数据之前，先把"空壳"立起来

备库在RMAN duplicate之前，需要先有一个能起来的空实例，这样RMAN才能往里面灌数据。这一步的核心是：准备参数文件、创建密码文件、启动到nomount状态。

4.1 从主库提取参数文件并改造

先在主库生成pfile，然后改造成备库的启动参数：

bash复制# 主库
sqlplus / as sysdba
CREATE PFILE='/tmp/initorcl_s.ora' FROM SPFILE;

把这份pfile传到备库，然后做以下修改：

db_unique_name改成orcl_s
db_file_name_convert和log_file_name_convert的路径映射确认无误
添加备库所需的control_files路径
去掉主库特有的路径配置（如果有）

下面是我实际用的备库pfile核心部分：

code复制*.audit_file_dest='/u01/app/oracle/admin/orcl/adump'
*.compatible='19.0.0'
*.control_files='/u01/app/oracle/oradata/orcl/control01.ctl','/u01/app/oracle/oradata/orcl/control02.ctl'
*.db_name='orcl'
*.db_unique_name='orcl_s'
*.db_file_name_convert='/u01/app/oracle/oradata/orcl','/u01/app/oracle/oradata/orcl'
*.log_file_name_convert='/u01/app/oracle/oradata/orcl','/u01/app/oracle/oradata/orcl'
*.db_recovery_file_dest_size=100G
*.db_recovery_file_dest='/u01/app/oracle/fra'
*.fal_client='orcl_s'
*.fal_server='orcl_p'
*.log_archive_config='dg_config=(orcl_p,orcl_s)'
*.log_archive_dest_1='location=use_db_recovery_file_dest valid_for=(all_logfiles,all_roles) db_unique_name=orcl_s'
*.log_archive_dest_2='service=orcl_p async valid_for=(online_logfiles,primary_role) db_unique_name=orcl_p'
*.log_archive_dest_state_2=enable
*.standby_file_management='AUTO'
*.memory_target=2048M

注意备库的log_archive_dest_2和主库是镜像关系：主库往备库传，备库往主库传。虽然目前备库还没转主库，但参数先配好，以后switchover就不用再改这行了。

4.2 创建备库目录结构

备库需要有一套完整的目录来放数据文件、控制文件、归档日志、告警日志等。我的做法是把主库的目录结构完整复制一份：

bash复制# 备库执行，以oracle用户
mkdir -p /u01/app/oracle/oradata/orcl
mkdir -p /u01/app/oracle/fra
mkdir -p /u01/app/oracle/admin/orcl/adump
mkdir -p /u01/app/oracle/admin/orcl/dpdump
mkdir -p /u01/app/oracle/admin/orcl/pfile

adump目录如果不存在，数据库启动时audit_file_dest会报错，这是新手最容易踩的坑，ORA-09925就是它。

4.3 启动备库到Nomount

把改造后的pfile放到备库的$ORACLE_HOME/dbs下，以spfile方式启动：

bash复制# 备库
export ORACLE_SID=orcl
sqlplus / as sysdba

-- 用pfile启动，让实例先起来
STARTUP NOMOUNT PFILE='/u01/app/oracle/oradata/orcl/initorcl_s.ora';

-- 如果启动正常，创建spfile并重启到nomount
CREATE SPFILE FROM PFILE='/u01/app/oracle/oradata/orcl/initorcl_s.ora';
SHUTDOWN ABORT;
STARTUP NOMOUNT;

这里用SHUTDOWN ABORT看起来有点粗暴，但现在库还是空壳，没有数据文件，所以ABORT也无所谓。目的就是让实例从pfile正常读参数，生成spfile，再以spfile的方式保持nomount状态。

启动到nomount的意义是：实例已经运行，$ORACLE_HOME/dbs下有密码文件，监听能注册上服务，RMAN duplicate就能通过Oracle Net连进来灌数据。如果这步失败，比如报ORA-01565（找不到spfile）、ORA-27037（文件不存在），先检查目录和参数文件路径，基本都是路径问题。

5. RMAN Duplicate：把主库的"血肉"完整搬到备库

备库实例在nomount状态等着，主库的RMAN开始执行DUPLICATE DATABASE FOR STANDBY。这一步会把主库的数据文件、控制文件、归档日志、spfile全部复制到备库，然后自动创建备库的控制文件。

5.1 主库RMAN连接备库

RMAN通过网络连接主备两端，语法如下：

bash复制rman target sys/密码@orcl_p auxiliary sys/密码@orcl_s

这里要求你在主库的机器上执行，target连主库，auxiliary连备库。两个连接都要求用户名密码正确。Oracle的RMAN会先检查两端实例是否都活着、参数是否匹配、密码是否一致，任何一个不对都会在连接阶段报错，所以这一步是提前暴露问题的最好时机。

常见的连接阶段报错：ORA-01017: invalid username/password，原因基本是密码文件不一致；ORA-12514: TNS listener does not know service，原因基本是tnsnames里的SERVICE_NAME写错或者监听没注册上；ORA-12541: TNS no listener，原因基本是防火墙或监听没起。这三个错误占了ADG搭建报错的大头。

5.2 执行Duplicate命令

连上之后，执行如下命令：

bash复制RUN {
  ALLOCATE CHANNEL c1 DEVICE TYPE disk;
  ALLOCATE AUXILIARY CHANNEL c2 DEVICE TYPE disk;
  DUPLICATE TARGET DATABASE FOR STANDBY
    FROM ACTIVE DATABASE
    DOREVERY DATABASE;
}

FROM ACTIVE DATABASE是19c最推荐的复制方式，它直接从运行中的主库复制数据文件，不需要先做全量备份。DOREVERY DATABASE表示在复制结束后，直接把备库置于恢复模式（managed recovery），这样MRP进程立刻开始应用日志，主备同步马上建立。

如果主备路径不一致，需要在Duplicate命令里加DB_FILE_NAME_CONVERT和LOG_FILE_NAME_CONVERT子句，但我前面已经用初始化参数设置了，这里就不用重复指定。

这个步骤的时间取决于主库数据量。我做过几十GB的库，大概十几分钟；如果是几TB的库，需要预留足够的时间窗口。复制过程中，RMAN会显示进度，不用干等，可以开另一个终端观察备库的告警日志：

bash复制tail -f /u01/app/oracle/diag/rdbms/orcl_s/orcl/trace/alert_orcl.log

看到Completed: DUPLICATE TARGET DATABASE FOR STANDBY就说明复制成功。

5.3 Duplicate完成之后的两件必做事

复制完成后，备库处于MOUNTED状态，MRP进程应该已经在应用日志。但还需要做两件事：

第一，把备库改为Active Data Guard模式（打开只读）：

sql复制-- 备库
sqlplus / as sysdba
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
-- 等待几秒，让MRP跑起来
ALTER DATABASE OPEN;

注意顺序：要先启动MRP，再OPEN备库。如果先OPEN，备库会直接报ORA-01154: database busy，因为MRP还没启动，实例不认为自己是物理备库。

ALTER DATABASE OPEN执行完，备库进入只读打开状态，但是此刻MRP还没跑起来，因为打开会中断恢复。别急，再执行：

sql复制ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

这时候ADG模式正式生效：备库只读打开 + MRP实时应用日志。

第二，检查同步状态：

sql复制-- 主库查归档传输
SELECT dest_id, status, error FROM v$archive_dest WHERE dest_id=2;
SELECT thread#, sequence#, applied FROM v$archived_log ORDER BY sequence# DESC FETCH FIRST 5 ROWS ONLY;

-- 备库查日志应用
SELECT process, status, thread#, sequence# FROM v$managed_standby;
SELECT name, value, unit, time_computed FROM v$dataguard_stats WHERE name='apply lag';

v$managed_standby里应该能看到MRP0进程，状态是APPLYING_LOG。v$dataguard_stats里apply lag应该是0秒或者几秒以内，说明实时应用正常。

6. 验证与排错：ADG建完不算完，能切换才算真的稳

搭建完成只是第一步，ADG的终极价值是主备切换。我在生产环境里见过太多"搭建时好好的，一切换就挂"的案例。原因基本都一样：只验证了日志同步，没验证切换流程，甚至没验证备库能不能成为主库。这一节我把验证和排错的关键点都过一遍。

6.1 Switchover演练：主备角色平滑互换

switchover是无损切换，主库变备库、备库变主库，数据不丢。这是容灾演练和计划内维护的标配操作。19c的switchover流程非常成熟，按下面几步走不会出问题：

sql复制-- 1. 在主库验证是否可以切换
SELECT switchover_status FROM v$database;
-- 显示 TO STANDBY 或 SESSIONS ACTIVE，都表示可以切换

-- 2. 主库转为备库角色
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;

-- 3. 在旧备库（新主库）上执行切换
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
ALTER DATABASE OPEN;

-- 4. 启动旧主库（新备库）的MRP
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
ALTER DATABASE OPEN;

执行完switchover，我会做三个检查：

新主库的v$database.switchover_status显示TO STANDBY或NOT ALLOWED（说明已经是主库）。
新备库的v$managed_standby里MRP状态正常。
v$dataguard_stats的apply lag归零。

switchover演练我建议在搭建当晚就做一遍。原因很简单：这是唯一能确认你的ADG配置真的能转主库的机会。我见过有人搭完ADG后一年的没做过切换，真到需要切换时，发现备库的log_archive_dest_2参数少了valid_for子句，切过去之后新备库不会归档，故障链路直接断掉。现在多花十分钟演练，以后少熬一个通宵。

6.2 Failover场景：备库强制转主库

failover是故障切换，主库挂了或者不可用，备库强制转主库，可能有数据丢失风险（取决于保护模式）。我建议在演练时也顺便验证一下，但要在测试环境做，生产环境不要随意failover。

主库彻底挂掉时操作：

sql复制-- 备库
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;
ALTER DATABASE OPEN;

从备库激活为主库之后，原主库如果后续恢复了，不能直接加回ADG配置，需要重新flashback或重建。所以failover是"最后的手段"，日常演练用switchover，failover只是验证流程可操作即可，不必真的在原备库上激活，可以在测试环境clone一套再演练。

6.3 常见问题排查清单

我把搭建和验证过程中最容易碰到的问题整理成表，按概率排序：

现象	排查方向	最常见原因
RMAN连接备库报ORA-01017	密码文件两边是否一致	密码文件用的是不同密码或不同密码版本
主库`v$archive_dest`的status=ERROR	查看error列	tnsnames服务名错误、监听未注册、防火墙
备库MRP0进程不存在	查看alert日志	未执行`RECOVER MANAGED STANDBY`或控制文件非standby类型
`apply lag`持续增长	检查网络、归档空间、备库磁盘	备库FRA空间满了
switchover时报`ORA-01031`	确认两端`sys`密码一致、权限正常	密码文件不一致在切换时也会报权限错
备库打开报`ORA-10458`	查看alert日志	物理备库必须先启用MRP再OPEN

这里我想重点提一下ORA-10458这个错误。很多人在RMAN duplicate之后直接ALTER DATABASE OPEN，结果报这个错，因为数据库还处于物理备库恢复模式，没有先启动MRP。解决方法是：先ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;，然后ALTER DATABASE OPEN;，再启动一次MRP。顺序对了，问题就消失了。

6.4 日常监控运维建议

ADG搭完之后，日常运维核心就一句话：盯紧归档传输和应用延迟。我习惯写一个简单的监控SQL，每天定时执行：

sql复制-- 主库查询传输和应用状态
SELECT
  d.name,
  d.database_role,
  d.protection_mode,
  d.open_mode,
  s.inst_id,
  CASE WHEN s.value > 60 THEN 'WARNING: apply lag over 60s' ELSE 'NORMAL' END AS lag_status
FROM v$database d,
     (SELECT inst_id, value FROM gv$dataguard_stats WHERE name='apply lag') s;

另外还要定期检查备库的日志缺口：

sql复制SELECT * FROM v$archive_gap;

有gap的话，需要用FAL机制自动补充，手动补救的话就是找到缺失的归档，拷到备库并注册：

sql复制ALTER DATABASE REGISTER LOGFILE '/path/to/missing_archive.log';

归档日志我建议在备库上设置自动删除策略，比如保留7天：

sql复制-- 备库配置RMAN删除策略
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;

这个策略的意思是：只有被备库应用了、且在其它备库也应用了的归档才能被RMAN删除。这样能避免备库归档无限堆积，同时不会误删还没应用的日志，是我在多个生产环境跑了几年都没出过问题的常用配置。

7. 从搭建到固化的进阶心得

最后分享几条我在多次搭建和运维ADG之后沉淀下来的体会。

第一，文档和基线要固化下来。 每搭完一套ADG，我会把主备库的参数文件、tnsnames配置、监听配置、密码文件版本、补丁版本全部导出存档，放到一个固定目录。不要依赖"脑子记住"，半年后你回来看，只有文档能告诉你当时到底怎么配的。这个习惯在我处理过的好几次"切换完回不来"的故障里救了大命。

第二，备库的备份角色要想清楚。 ADG最大的隐藏价值之一是：你可以直接在备库上做RMAN备份，而不影响主库性能。但前提是，你要在备库上配置RMAN CONFIGURE DEVICE TYPE ...以及备份集保留策略，并且要意识到备库备份对DB_UNIQUE_NAME的依赖——RMAN恢复时，如果库的角色变了，备份记录可能识别不了。生产实践里，我一般把备份作业直接挂在备库上，主库完全不跑备份。3点到4点备库抽一个小时做增量备份，主库的系统负载和IO压力能明显降一截。

第三，网络抖动的影响比你想象的大。 我之前遇到过一套ADG，搭建时一切正常，跑了俩月之后主库的v$archive_dest开始报ORA-12541，查了半天发现是主备之间的网络交换机升级，导致到备库的1521端口偶尔被拒。这类问题不体现在主库性能上，但会体现在apply lag持续增长上。所以ADG的监控一定要覆盖网络层，最简单的方式是定期tnsping备库，延迟超过阈值就告警。延迟告警比应用延迟告警提前至少半小时发现问题，性价比极高。

第四，不要跳过SQL Apply的验证。 物理备库的MRP进程在应用日志时，偶尔会因为数据文件损坏、磁盘坏道、归档文件损坏而出错。我在演练时会在备库上做一次全量逻辑校验（DBMS_TDB.CHECK_DB或RMAN的VALIDATE），确保备库的数据文件块没有物理损坏。这一步不强制，但做过的库，后续转主库的可靠性明显更有底。

第五，如果你搭的是RAC+ADG，这套流程的思路完全相通，但细节更多。 RAC主库的所有实例都要能连到备库，RAC备库的所有实例都要能接收日志，tnsnames、密码文件、参数文件都要考虑多实例的情况，RMAN duplicate时也要处理CLUSTER_DATABASE参数。但核心逻辑不变：日志传输链路 + 恢复链路。先把单机的搞明白，RAC只是复杂度增加，原理完全一样。

我自己搭ADG的次数不算少，每次搭完做switchover演练，看着主备角色平滑互换、apply lag归零的那一刻，心里才觉得踏实。数据安全这种事，平时看不见摸不着，但真到那一天，ADG能顶上，比什么都重要。希望这篇文档能帮你把ADG一次搭对，少踩几个我踩过的坑。