1. 项目概述为什么在今天还要认真对待ORACLE12C ADG部署如果你正在维护一套运行在生产环境中的Oracle数据库尤其是承载着核心业务交易、财务结算或客户主数据的系统那么“宕机一分钟损失多少钱”这个问题你大概率已经算过不止一次。而ADG——Active Data Guard不是什么新潮概念它是Oracle从11g开始就稳定交付、在12c中完成关键能力加固的企业级高可用与灾备基石。它解决的从来不是“能不能用”的问题而是“出事时能不能秒级切换”“报表查询会不会拖垮主库”“备份窗口能不能压缩到零”这些真实压在DBA肩上的具体压力。我接触过不少团队初期把ADG当成“高级备份”来用只配了物理备库但没开实时应用Real-Time Apply结果主库一出故障手动切换耗时15分钟起步也见过另一些团队在12c环境下盲目套用11g的部署脚本忽略了12c引入的多租户CDB/PDB架构对ADG角色切换、日志传输路径、密码文件同步带来的结构性影响导致备库启动后始终卡在MOUNT状态日志里反复报ORA-16789、ORA-16664这类看似晦涩、实则指向明确的错误。这些都不是配置疏漏而是对12c ADG底层机制理解不到位的必然结果。这篇内容就是为那些真正要把它部署进生产环境、而不是仅在测试机上跑通命令的人写的。它不讲“什么是ADG”这种教科书定义而是聚焦在12c这个特定版本下从零开始搭建一套可落地、可监控、可切换的ADG环境所必须跨越的全部技术关卡包括如何设计符合12c多租户特性的DG Broker配置、为什么standby redo log的组数和大小必须按主库redo log的3倍冗余计算、如何用一条SQL语句精准判断备库是否真正处于“实时应用”而非“归档应用”状态、以及最关键的——当switchover执行到一半卡住时你该先看哪三张动态性能视图。所有内容都来自某金融行业核心账务系统的ADG上线实录步骤可复制参数有依据坑点有标注。2. 整体架构设计与方案选型逻辑2.1 为什么是12c ADG而不是RAC或GoldenGate在动手之前必须厘清一个根本性问题我们为什么要选择ADG这直接决定了后续所有配置的取舍。很多团队在立项时会把RACReal Application Clusters、GoldenGateOGG和ADG并列比较但三者解决的问题域其实完全不同。RAC是解决“单点性能瓶颈”的方案。它让多个实例同时读写同一套存储目标是横向扩展OLTP吞吐量。但它本身不提供异地容灾能力节点全部挂掉数据就没了。而且RAC的部署复杂度、硬件依赖共享存储、许可成本都远高于ADG。GoldenGate是解决“异构平台、逻辑级复制”的方案。它可以实现Oracle到MySQL、Oracle到Kafka、甚至跨版本的表级增量同步。但它的延迟通常在秒级到分钟级无法做到ADG的亚秒级同步更重要的是OGG需要额外进程、额外许可、额外的运维监控体系对于只需要“主库挂了备库立刻顶上”这种刚性需求来说属于过度设计。ADG的核心价值恰恰在于“物理一致性”与“零数据丢失”。它基于Oracle Redo流的字节级复制备库的数据块与主库完全一致只是应用时间略有延迟通常1秒。这意味着切换后应用无需任何适配连接字符串改个IP就能继续工作备库可以开启只读模式分担主库的报表、BI查询压力这是RAC和OGG都难以低成本实现的它天然支持快照备库Snapshot Standby允许你在备库上做补丁测试、升级验证再一键切回物理备库整个过程不影响主库。所以当你看到项目标题是“ORACLE12C ADG安装部署”背后的真实需求通常是“我们需要一套能扛住机房级故障、切换RTO2分钟、且日常能分担查询负载的灾备方案”。这个前提一旦确认ADG就是最直接、最经济、最可靠的选项。而选择12c是因为它相比11g在ADG领域有三个不可忽视的增强一是引入了Far Sync Instance远程同步实例可将主库与备库间的网络延迟影响降到最低二是DG Broker对多租户的支持更成熟DGMGRL命令能直接管理CDB和PDB级别的保护模式三是ALTER DATABASE RECOVER MANAGED STANDBY DATABASE命令新增了USING CURRENT LOGFILE子句让实时应用的启用和停止更可控。2.2 网络与存储架构不能妥协的底层基础ADG不是软件装上去就完事的它的稳定性70%取决于网络和存储的底层设计。我在某省级政务云项目中就吃过亏主备库部署在同一台物理服务器的两个虚拟机上网络走的是虚拟交换机结果一次宿主机内核升级虚拟网卡驱动短暂失联ADG的LGWR进程检测到网络中断自动降级为ARCH模式等网络恢复主库已积压了20GB归档日志备库追了40分钟才赶上。这不是ADG的bug是架构设计的硬伤。因此12c ADG的部署必须满足以下三条铁律网络隔离与带宽保障主库与备库之间必须有独立的、低延迟RTT 10ms、高带宽建议≥1Gbps的专用网络链路。绝对禁止与业务流量、管理流量混用。如果主备库跨地域如同城双活必须评估网络抖动。此时Far Sync Instance就不再是可选项而是必选项——它作为一个轻量级的“中继站”只负责接收主库的redo并转发给备库自身不应用日志极大降低了主库因网络问题而阻塞的风险。存储一致性要求主库和备库的存储必须保证I/O特性一致。例如主库使用ASMAutomatic Storage Management管理磁盘组备库也必须使用ASM且磁盘组名称、AUAllocation Unit大小、条带化策略必须完全相同。我曾见过一个案例主库ASM磁盘组AU大小为4MB备库误配为1MB导致备库在应用redo时尝试向一个不存在的AU地址写入数据报ORA-15081错误整个恢复进程挂起。这个错误不会在alert.log里直接提示AU不匹配而是在trace文件里深埋排查耗时超过6小时。操作系统与Oracle Home规划主备库的操作系统版本小版本号如Red Hat 7.6 vs 7.9应尽量一致内核参数特别是net.core.somaxconn,fs.aio-max-nr必须严格对齐。Oracle Home路径建议完全一致如/u01/app/oracle/product/12.1.0/dbhome_1这能避免DG Broker在生成drc文件时因路径差异导致的权限或解析错误。更重要的是ORACLE_SID在主备库上可以不同事实上推荐不同便于区分但DB_UNIQUE_NAME必须全局唯一且在tnsnames.ora中正确定义——这是DG Broker识别主备关系的唯一标识符一旦配错DGMGRL里看到的永远是“Configuration Status: DISABLED”。2.3 12c多租户CDB/PDB下的ADG特殊考量12c引入的多租户架构是ADG部署中最大的认知分水岭。很多DBA习惯性地认为“只要主库CDB启用了ADG下面的所有PDB就自动受保护”这是一个危险的误解。实际上ADG在12c中是以CDB为单位进行配置和管理的PDB的状态完全继承自其所在的CDB。这意味着主库CDB切换为备库角色后其内部所有PDB自动变为只读状态无法单独对某个PDB执行open操作备库CDB切换为主库后所有PDB默认处于MOUNT状态必须手动ALTER PLUGGABLE DATABASE pdb_name OPEN;才能对外提供服务DG Broker的SHOW CONFIGURATION命令显示的是CDB级别的状态不会列出每个PDB的详细信息。要检查PDB状态必须登录到CDB实例执行SELECT CON_ID, NAME, OPEN_MODE FROM V$PDBS;。因此在12c ADG部署中必须额外增加两个关键步骤在主库上为每个需要保护的PDB创建对应的SERVICE并注册到监听器。这样当CDB完成角色切换后应用可以通过服务名而非SID无缝连接到新的主库PDB避免因tnsnames.ora未及时更新导致的连接失败。编写标准化的switchover脚本其中必须包含PDB的open/close逻辑。一个典型的switchover后置操作序列是-- 在新的主库原备库上执行 ALTER PLUGGABLE DATABASE ALL CLOSE IMMEDIATE; ALTER PLUGGABLE DATABASE ALL OPEN; -- 或者针对单个PDB ALTER PLUGGABLE DATABASE pdb_app OPEN;忽略这两点会导致切换完成后应用连不上数据库或者连上了但PDB是MOUNT状态报ORA-01109错误。这不是ADG没生效而是12c多租户模型下的必然行为必须被纳入运维流程。3. 核心细节解析与实操要点3.1 密码文件那个被90%人忽略的“信任凭证”在Oracle中密码文件orapwSID的作用远不止于SYS用户登录。在ADG环境中它是主库与备库之间建立“信任通道”的唯一凭证。主库的LGWR进程在发送redo时会携带一个由密码文件加密的认证令牌备库的RFSRemote File Server进程收到后必须用本地密码文件解密成功才能接受该redo流。如果密码文件不一致RFS进程会拒绝接收alert.log里会出现类似RFS[2]: Failed to archive log的报错而V$ARCHIVE_DEST_STATUS视图中对应备库的目的地状态会显示为ERROR。那么如何确保主备库密码文件100%一致答案是绝不能在备库上手工创建或修改密码文件。正确的做法只有一个从主库完整拷贝过去。具体操作步骤如下在主库上确认密码文件位置SELECT * FROM V$PWFILE_USERS; -- 查看当前密码文件路径通常为 $ORACLE_HOME/dbs/orapwSID SHOW PARAMETER remote_login_passwordfile; -- 确保值为 EXCLUSIVE停止主库监听器可选但强烈建议防止拷贝过程中有新连接触发密码文件写入lsnrctl stop使用scp或rsync将主库的orapwSID文件完整拷贝到备库的$ORACLE_HOME/dbs/目录下并确保属主和权限完全一致# 在主库执行 scp $ORACLE_HOME/dbs/orapw$ORACLE_SID oraclestandby_host:$ORACLE_HOME/dbs/ # 在备库执行修复权限 chown oracle:oinstall $ORACLE_HOME/dbs/orapw$ORACLE_SID chmod 640 $ORACLE_HOME/dbs/orapw$ORACLE_SID启动备库到NOMOUNT状态验证密码文件有效性SQL STARTUP NOMOUNT; SQL SELECT * FROM V$PWFILE_USERS; -- 应能看到 SYS, SYSTEM 等用户且 SYS 的 SYSDBA 权限为 TRUE这里有一个极易踩的坑很多人在备库上执行orapwd命令重新生成密码文件以为只要用户名密码一样就行。这是完全错误的。orapwd生成的密码文件其内部的加密密钥Key与主库的完全不同即使用户名密码一字不差RFS进程也无法解密主库发来的令牌。我亲眼见过一个团队因为orapwd重生成了密码文件导致ADG同步中断长达36小时期间主库产生的所有redo都无法传到备库最终只能从备份恢复RPORecovery Point Objective彻底失效。3.2 Standby Redo LogSRLADG实时应用的“缓冲区”Standby Redo LogSRL是ADG区别于传统物理备库Physical Standby的核心组件。没有SRL备库只能以“归档应用”Archived Log Apply模式工作即等主库把redo写满、归档成arch_xxx.arc文件后再通过网络传输过来再应用。这种方式的延迟取决于主库redo log的切换频率可能高达几分钟。而SRL的存在让备库可以像主库一样直接接收LGWR进程推送的“在线”redo流并实时写入自己的SRL文件然后由MRPManaged Recovery Process进程立即读取并应用。这就实现了真正的“实时应用”Real-Time Apply延迟控制在秒级。那么SRL该怎么配一个流传甚广的错误公式是“SRL组数 主库redo log组数 1”。这在12c中是严重过时的。12c官方文档明确指出SRL的组数应至少等于主库redo log组数的2倍且每组大小不得小于主库最大redo log文件的大小。为什么是2倍因为12c的LGWR进程在高并发场景下可能同时向多个SRL组写入。如果SRL组数不足RFS进程在写满一个SRL组后需要等待MRP进程将其应用完毕、释放空间才能写入下一个组。这会造成RFS写入阻塞进而反压到主库的LGWR导致主库事务提交变慢甚至出现log file sync等待事件飙升。计算示例主库有3组redo log每组大小为200MB。那么备库至少需要配置6组SRL每组大小≥200MB。实际生产中我通常会配置8组每组250MB留出25%的冗余空间。创建SRL的SQL命令如下在备库MOUNT状态下执行-- 先查看当前SRL状态 SELECT GROUP#, THREAD#, SEQUENCE#, ARCHIVED, STATUS FROM V$STANDBY_LOG; -- 添加8组SRL假设DB_UNIQUE_NAME为cdb_stby ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 /u01/oradata/cdb_stby/srl01.log SIZE 250M, /u01/oradata/cdb_stby/srl02.log SIZE 250M, /u01/oradata/cdb_stby/srl03.log SIZE 250M, /u01/oradata/cdb_stby/srl04.log SIZE 250M, /u01/oradata/cdb_stby/srl05.log SIZE 250M, /u01/oradata/cdb_stby/srl06.log SIZE 250M, /u01/oradata/cdb_stby/srl07.log SIZE 250M, /u01/oradata/cdb_stby/srl08.log SIZE 250M;提示SRL文件的路径必须与主库的DB_CREATE_FILE_DEST或DB_RECOVERY_FILE_DEST参数指定的路径风格一致。如果主库使用OMFOracle Managed Files备库也必须开启OMFDB_CREATE_FILE_DEST非空否则SRL创建会失败报ORA-01276错误。3.3 初始化参数那些决定ADG生死的“开关”ADG的运行高度依赖一组精心配置的初始化参数。它们就像汽车的油门、刹车和方向盘任何一个设置不当都会导致ADG无法启动、同步中断或切换失败。以下是12c ADG中最关键的8个参数及其配置逻辑参数名主库推荐值备库推荐值作用与原理说明DB_UNIQUE_NAMEcdb_primarycdb_stby强制唯一。DG Broker通过此值识别主备关系。必须在tnsnames.ora中为对方定义同名的服务别名。LOG_ARCHIVE_CONFIGDG_CONFIG(cdb_primary,cdb_stby)DG_CONFIG(cdb_primary,cdb_stby)告诉Oracle这个Data Guard配置中包含哪些DB_UNIQUE_NAME。主备库必须完全一致否则ALTER SYSTEM SET LOG_ARCHIVE_DEST_2会报ORA-16606。LOG_ARCHIVE_DEST_1LOCATIONUSE_DB_RECOVERY_FILE_DEST VALID_FOR(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAMEcdb_primaryLOCATIONUSE_DB_RECOVERY_FILE_DEST VALID_FOR(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAMEcdb_stby定义本地归档路径。VALID_FOR子句确保无论角色如何变化本地归档都有效。LOG_ARCHIVE_DEST_2SERVICEcdb_stby ASYNC NOAFFIRM VALID_FOR(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAMEcdb_stbySERVICEcdb_primary LGWR SYNC AFFIRM VALID_FOR(ONLINE_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAMEcdb_primary核心传输参数。主库用ASYNC异步降低对业务影响备库用SYNC AFFIRM同步确认确保主库commit前redo已安全写入备库SRL。LGWR比ARCH更高效。FAL_SERVERcdb_stbycdb_primaryFailover Archive Log Server。当备库发现缺失归档日志时主动向此服务请求拉取。主备库必须互指。DB_FILE_NAME_CONVERT/u01/oradata/cdb_stby/, /u01/oradata/cdb_primary//u01/oradata/cdb_primary/, /u01/oradata/cdb_stby/数据文件路径转换规则。当主库执行CREATE TABLESPACE时备库能自动将数据文件创建在正确路径。路径末尾的/不能省略LOG_FILE_NAME_CONVERT/u01/oradata/cdb_stby/, /u01/oradata/cdb_primary//u01/oradata/cdb_primary/, /u01/oradata/cdb_stby/重做日志文件路径转换规则。原理同上确保备库能正确创建SRL。STANDBY_FILE_MANAGEMENTAUTOAUTO必须为AUTO。当主库添加/删除数据文件时备库自动同步无需人工干预。设为MANUAL是重大风险。配置这些参数时有一个黄金法则所有涉及路径转换的参数DB_FILE_NAME_CONVERT,LOG_FILE_NAME_CONVERT其值必须是字符串精确匹配且区分大小写。我曾在一个Linux系统上因为主库路径是/u01/oradata/CDB_PRIMARY/大写而备库参数里写成了/u01/oradata/cdb_primary/小写导致主库创建的新表空间数据文件在备库上被创建到了根目录/下瞬间占满磁盘alert.log里全是ORA-01119错误。3.4 DG Broker配置告别手敲SQL的自动化管理在11g时代DBA们习惯于用ALTER DATABASE ...系列SQL命令来管理ADG。这种方式在12c中依然可行但效率低下且易出错。DG BrokerData Guard Broker是Oracle提供的图形化命令行一体化管理工具它通过一个中央配置文件drc文件来维护整个Data Guard配置的状态所有操作ENABLE,DISABLE,SWITCHOVER,FAILOVER都通过DGMGRL命令行客户端执行大大降低了人为失误的概率。启用DG Broker的步骤如下在主备库上启用Broker相关参数-- 主库和备库均需执行 ALTER SYSTEM SET dg_broker_startTRUE SCOPEBOTH; ALTER SYSTEM SET dg_broker_config_file1/u01/app/oracle/product/12.1.0/dbhome_1/dbs/dr1cdb_primary.dat SCOPESPFILE; ALTER SYSTEM SET dg_broker_config_file2/u01/app/oracle/product/12.1.0/dbhome_1/dbs/dr2cdb_primary.dat SCOPESPFILE; -- 注意config_file1和file2路径必须不同且所在文件系统必须有足够空间建议≥100MB SHUTDOWN IMMEDIATE; STARTUP;使用DGMGRL创建配置# 连接到主库 dgmgrl / DGMGRL CONNECT / DGMGRL CREATE CONFIGURATION my_dg_config AS PRIMARY DATABASE IS cdb_primary CONNECT IDENTIFIER IS cdb_primary; DGMGRL ADD DATABASE cdb_stby AS CONNECT IDENTIFIER IS cdb_stby MAINTAINED AS PHYSICAL; DGMGRL ENABLE CONFIGURATION;验证配置状态DGMGRL SHOW CONFIGURATION; -- 正常输出应为 -- Configuration - my_dg_config -- Protection Mode: MaxPerformance -- Members: -- cdb_primary - Primary database -- cdb_stby - Physical standby database -- Fast-Start Failover: DISABLED -- Configuration Status: SUCCESS注意CONNECT IDENTIFIER必须是在tnsnames.ora中为对方数据库定义的服务名且该服务名必须能被tnsping通。如果tnsping cdb_stby失败DGMGRL的ADD DATABASE命令一定会报ORA-12154: TNS:could not resolve the connect identifier specified。DG Broker的最大优势在于它能自动处理复杂的依赖关系。例如当你执行SWITCHOVER TO cdb_stby时Broker会自动检查主库是否有未提交的事务检查备库SRL是否已应用到最新自动关闭主库的监听器自动重启主库为备库角色自动重启备库为主库角色自动更新双方的tnsnames.ora如果配置了StaticConnectIdentifier。这一切都比手写一长串ALTER DATABASE命令可靠得多。这也是为什么在12c生产环境中我坚决反对禁用DG Broker坚持用它作为ADG的唯一管理入口。4. 实操过程与核心环节实现4.1 从零开始主备库环境准备与预检清单在敲下第一个CREATE CONFIGURATION命令之前必须完成一份详尽的预检清单Pre-checklist。这份清单不是形式主义而是规避90%部署失败的防火墙。我把它分为“主库侧”、“备库侧”和“网络侧”三个维度每一项都必须打钩确认。主库侧预检共12项SELECT * FROM V$DATABASE;确认DB_NAME和DB_UNIQUE_NAME如cdb_primary。SELECT LOG_MODE, FORCE_LOGGING FROM V$DATABASE;确保LOG_MODEARCHIVELOG且FORCE_LOGGINGYES。若为NO执行ALTER DATABASE FORCE LOGGING;。SELECT * FROM V$ARCHIVE_DEST_STATUS WHERE STATUS!INACTIVE;检查DEST_ID1本地归档状态为VALID。SELECT * FROM V$PWFILE_USERS WHERE USERNAMESYS AND SYSDBATRUE;确认密码文件有效。SELECT GROUP#, BYTES/1024/1024 MB, STATUS FROM V$LOG;记录主库redo log组数和大小用于SRL计算。SHOW PARAMETER db_create_file_dest;记录OMF路径用于DB_FILE_NAME_CONVERT。SELECT NAME, VALUE FROM V$PARAMETER WHERE NAME IN (log_archive_config, log_archive_dest_1, log_archive_dest_2);确认当前归档参数为后续对比做准备。SELECT * FROM V$DATAGUARD_CONFIG;确认当前无其他DG配置残留。SELECT * FROM V$VERSION;记录Oracle版本如12.1.0.2.0确保主备库版本完全一致。SELECT * FROM V$OPTION WHERE PARAMETERData Guard;确认Data Guard选项已安装返回TRUE。SELECT * FROM V$INSTANCE;确认实例状态为OPEN。ls -l $ORACLE_HOME/dbs/orapw$ORACLE_SID;确认密码文件存在且权限为-rw-r-----。备库侧预检共10项SELECT * FROM V$DATABASE;确认DB_NAME与主库相同如cdb但DB_UNIQUE_NAME不同如cdb_stby。SELECT STATUS FROM V$INSTANCE;确认实例状态为MOUNTED如果是冷备库或NOMOUNT如果是刚建好的空库。SELECT * FROM V$PWFILE_USERS;确认密码文件已从主库拷贝且SYS用户SYSDBA权限为TRUE。SELECT GROUP#, THREAD#, SEQUENCE#, STATUS FROM V$STANDBY_LOG;确认SRL已按前述规则创建完毕8组250MB。SELECT * FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID1;确认本地归档路径LOCATION有效且有足够空间。SHOW PARAMETER db_unique_name;确认值为cdb_stby。SHOW PARAMETER log_archive_config;确认值为DG_CONFIG(cdb_primary,cdb_stby)。SHOW PARAMETER fal_server;确认值为cdb_primary。SELECT * FROM V$RECOVERY_FILE_DEST;确认DB_RECOVERY_FILE_DEST空间充足建议≥50GB。ls -l /u01/oradata/cdb_stby/;确认数据文件目录结构与主库一致即使为空。网络侧预检共5项ping -c 4 standby_host和ping -c 4 primary_host双向互通。telnet standby_host 1521和telnet primary_host 1521端口开放。tnsping cdb_stby从主库执行tnsping cdb_primary从备库执行均返回OK。nslookup standby_host和nslookup primary_hostDNS解析正确或/etc/hosts已正确映射。cat $ORACLE_HOME/network/admin/tnsnames.ora确认主备库的tnsnames.ora中对方的服务名定义完整且HOST、PORT、SERVICE_NAME准确无误。这份清单我通常会打印出来逐项打钩。曾经有一个项目就是因为第4项“备库SRL未创建”导致ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;命令执行后V$MANAGED_STANDBY视图中PROCESSRFS的状态一直是IDLE而PROCESSMRP0根本不存在整整排查了3小时才发现根源。4.2 关键命令执行从启动到实时应用的全流程完成预检后就可以进入核心的ADG启动流程。这个流程不是一蹴而就的而是分阶段、有状态反馈的精密操作。我将它拆解为四个阶段每个阶段都有明确的成功标志和失败应对。阶段一启动备库至MOUNT状态并开启MRP进程-- 在备库上执行 SQL STARTUP MOUNT; -- 验证SELECT STATUS FROM V$INSTANCE; 应返回 MOUNTED SQL ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; -- 验证SELECT PROCESS, STATUS, THREAD#, SEQUENCE# FROM V$MANAGED_STANDBY; -- 正常应看到 PROCESSMRP0STATUSAPPLYING_LOGSEQUENCE#持续递增注意USING CURRENT LOGFILE是12c新增的关键子句它告诉MRP进程不要等归档日志直接从SRL中读取最新的redo流。没有它MRP默认只应用归档日志无法实现“实时”。阶段二验证实时应用状态仅仅看到MRP0在运行并不代表实时应用已生效。必须通过以下两条SQL交叉验证-- 1. 检查MRP进程是否真的在应用SRL而非归档 SELECT PROCESS, CLIENT_PROCESS, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY WHERE PROCESSMRP0 AND CLIENT_PROCESSLGWR; -- 2. 检查备库当前应用的SCN是否紧跟主库 SELECT (SELECT CURRENT_SCN FROM V$DATABASE) AS PRIMARY_SCN, (SELECT APPLIED_SCN FROM V$DATABASE) AS STANDBY_APPLIED_SCN, (SELECT CURRENT_SCN FROM V$DATABASE) - (SELECT APPLIED_SCN FROM V$DATABASE) AS SCN_GAP FROM DUAL; -- 理想状态SCN_GAP 10000即差距小于1万个SCN约等于1秒如果SCN_GAP持续大于10万说明SRL写入或MRP应用存在瓶颈需要检查V$ARCHIVE_DEST_STATUS中STATUS是否为VALID以及V$DATAGUARD_STATS中VALUE是否为0表示无延迟。阶段三启用DG Broker并加入配置# 在主库上启动DGMGRL dgmgrl / DGMGRL CONNECT / DGMGRL CREATE CONFIGURATION my_dg AS PRIMARY DATABASE IS cdb_primary CONNECT IDENTIFIER IS cdb_primary; DGMGRL ADD DATABASE cdb_stby AS CONNECT IDENTIFIER IS cdb_stby MAINTAINED AS PHYSICAL; DGMGRL ENABLE CONFIGURATION; -- 验证DGMGRL SHOW CONFIGURATION; 输出 Configuration Status: SUCCESS提示如果ENABLE CONFIGURATION失败最常见的原因是tnsnames.ora中cdb_stby服务的SERVICE_NAME写成了cdb_primary或者HOST地址写错了。此时DGMGRL的错误信息非常模糊必须回到网络预检环节用tnsping逐一验证。阶段四执行首次Switchover演练这是对整个ADG配置的终极检验。务必在业务低峰期进行并提前通知所有相关方。DGMGRL SWITCHOVER TO cdb_stby; -- 此命令会自动执行所有切换逻辑 -- 成功后DGMGRL会提示 Operation requires shutdown of instance cdb_primary on database cdb_primary -- 此时主库实例会自动关闭备库会自动重启为OPEN状态 -- 切换完成后立即在新主库原备库上执行 SQL SELECT DATABASE_ROLE, OPEN_MODE FROM V$DATABASE; -- 应返回 DATABASE_ROLEPRIMARY, OPEN_MODEREAD WRITE -- 在新备库原主库上执行 SQL SELECT DATABASE_ROLE, OPEN_MODE FROM V$DATABASE; -- 应返回 DATABASE_ROLEPHYSICAL STANDBY, OPEN_MODEMOUNTED注意SWITCHOVER是可逆的FAILOVER是不可逆的。演练必须用SWITCHOVER严禁在非紧急情况下使用FAILOVER。4.3 监控与日常运维让ADG真正“活”起来部署完成只是万里长征第一步。ADG的价值体现在它7x24小时稳定运行的每一天。因此必须建立一套轻量、高效、自动化的监控体系。我推荐以下三个层次的监控组合第一层DG Broker内置健康检查5分钟级# 创建一个简单的巡检脚本 check_dg.sh #!/bin/bash dgmgrl / EOF CONNECT / SHOW CONFIGURATION; SHOW DATABASE VERBOSITY cdb_primary; SHOW DATABASE VERBOSITY cdb_stby; EXIT EOF将此脚本加入crontab每5分钟执行一次并将输出重定向到日志文件。关键关注点Configuration Status必须为SUCCESScdb_primary的Role为PRIMARYIntended State为TRANSPORT-ONcdb_stby的Role为PHYSICAL STANDBYIntended State为APPLY-ON