Oracle DG/ADG巡检指南：从日志传输到应用延迟的完整检查清单

Oracle DG/ADG巡检指南：从日志传输到应用延迟的完整检查清单

发布时间：2026/10/14 3:07:55
Oracle DG/ADG巡检指南：从日志传输到应用延迟的完整检查清单 前段时间帮一家客户的Oracle DG环境做例行巡检发现一个挺吓人的现场备库的MRP进程已经卡在几天前的日志序列上但打开视图中显示的apply lag竟然还是0。你是不是也觉得lag是0那就等于没毛病实际上主库这几天新归档的redo日志压根没传过来备库只是在“空转”。这种问题光靠看一眼状态根本发现不了必须把传输、接收、应用三段链路分开逐项核对。这就是我写这篇内容的原因。Oracle DGData Guard和ADGActive Data Guard的日常巡检和单实例库巡检完全是两码事。单实例你只要盯空间、告警、性能就行DG/ADG是一套主备数据保护体系核心不是某台库自身的健康而是主备之间的数据流是否连续、保护级别是否达标、关键时刻能不能切得过去。这篇文章就是我这些年做DG/ADG巡检时沉淀下来的一套操作清单结合具体SQL、命令和真实踩坑现场希望能帮你少走几步弯路。1. 为什么DG/ADG不能按单实例那套巡检逻辑来很多DBA习惯性地把DG/ADG理解成“主库把日志送到备库备库往自己库里应用”然后就按单实例的思路巡检看空间够不够、看有没有报错完事。但DG是一条端到端的数据链路任何一个环节断了备库表面上还能open实际上已经失去了容灾意义。我通常把这条链路拆成四段主库redo生成、网络传输、备库接收归档、备库redo应用。四个环节里前三个属于“同步”范畴最后一个属于“应用”范畴。ADG之所以和DG不同是因为它在备库应用redo的同时保持只读打开可以承载报表、只读查询这类负载所以ADG巡检还要额外关心备库的性能和临时表空间。也正因为ADG是“活的”它的巡检比普通DG要复杂一截。还有一个容易被忽略的点RMAN备份和DG不是同一个用途。RMAN解决的是误删除、误更新之后的“时间点恢复”DG解决的是主库物理故障之后的“接管”。尤其是ADG很多业务已经把只读流量的很大比例放到备库上备库一旦追不上主库或断链不只是容灾风险连日常查询都会出问题。所以巡检DG/ADG本质上是巡检一条数据流水线而不是巡检两台孤立的数据库。我对DG/ADG巡检的维度总结起来就六块巡检维度关注内容常见风险点角色与配置主备角色、保护模式、Broker状态保护级别悄悄降级日志传输归档传输状态、网络连通性、空间备库归档空间写满导致传输中断日志应用RFS接收、MRP进程、应用延迟MRP进程假死、日志断流数据一致性归档缺口GAP、序列连续性归档GAP无人发现ADG服务只读打开状态、临时表空间、性能临时表空间被误删、查询把备库打垮切换能力FSFO配置、Switchover状态、演练记录Observer挂了、切换条件不满足下面每一章我就按这套维度展开讲可落地的检查方法。2. 巡检开跑前三个状态三分钟摸清主备家底2.1 数据库角色和保护模式第一件事不是看性能而是确认自己和备库分别处于什么角色、什么保护模式。最基础的一条SQLSELECT name, database_role, protection_mode, protection_level, open_mode FROM v$database;看四个字段就够了database_role主库是PRIMARY备库是PHYSICAL STANDBY如果是ADG则备库也是PHYSICAL STANDBY只是多了只读打开。protection_mode这是配置里写的期望保护模式常见三种——MAXIMUM PROTECTION、MAXIMUM AVAILABILITY、MAXIMUM PERFORMANCE。protection_level这是当前实际运行中的保护级别。正常情况下它应该和protection_mode保持一致如果某个环境配置的是MAXIMUM AVAILABILITY但level变成了RESYNCHRONIZATION说明主备之间的redo同步出现延迟保护级别已经临时降级了。这种状态必须记录原因不能放着不管。open_mode主库是READ WRITEADG备库应该是READ ONLY WITH APPLY普通物理备库则是READ ONLY。这里能看到ADG实时应用到底有没有生效。日常运营中绝大多数生产环境是MAXIMUM PERFORMANCE少部分核心库用MAXIMUM AVAILABILITY。保护模式没有绝对好坏全看业务对RPO的要求。性能模式下主库写redo不需要等备库确认性能最好但主库故障时理论上可能丢少量日志最大保护模式下主库提交要等备库写完才返回性能牺牲很大还要求备库绝对不能断所以实际落地反而最少。巡检时只需要确认当前模式和你环境的设计一致即可。2.2 DG Broker 配置状态我强烈建议环境统一使用DG Broker来维护而不是手工改参数。原因很简单Broker会统一管理LOG_ARCHIVE_DEST_n、FAL_SERVER等一堆参数还会自动校验配置一致性。如果你一边用Broker一边手工去ALTER SYSTEM改归档目标参数两边可能会互相覆盖这种冲突我见过不止一次。查Broker状态只需要两条命令dgmgrl sys/oracle主库TNS show configuration dgmgrl sys/oracle主库TNS show database 备库DB_UNIQUE_NAME第一条会输出整个DG配置的概要比如Configuration - dgconfig Protection Mode: MaxPerformance Databases: orcl - Primary database orclstd - Standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS看到Configuration Status是SUCCESS说明Broker层面的链路完整性没问题。如果变成WARNING后面往往会跟着原因提示比如备库日志传输模式不是预期值、某个库没有被正常管理之类。第二条show database能看到更细的状态重点看最后的Database Status是否SUCCESS。这里补充一个经验show configuration输出的SUCCESS不代表一切正常它只说明Broker能管理到这些库真正要确认的是每一台库内部的运行状态。所以两条命令都要跑。2.3 配置基线参数抽查巡检不可能每次把参数全翻一遍我一般是抽查表和DG链路直接相关的几个参数。下面这几个参数出问题的概率很高需要确认它们的值和预期一致参数作用巡检关注点log_archive_dest_n定义备库传输目标和属性确认多个dest没有冲突SYNC/ASYNC设置符合保护级别log_archive_format归档文件名格式主备两端最好一致否则手动补归档时容易找不到文件fal_server备库自动请求缺失归档时访问的主库备库端该项必须配置正确否则GAP无法自动补齐standby_file_management是否自动管理备库数据文件应为AUTO否则主库加数据文件后备库不会自动建db_file_name_convert/log_file_name_convert主备文件路径转换规则路径不一致时确认转换参数存在否则文件创建会失败看一眼show parameter输出很快但能省掉后续很多灾难。特别是standby_file_management有些环境建好后没人动默认值也可能是MANUAL一旦主库在线加了个数据文件备库会直接报ORA-01274之类的错误MRP进程挂掉然后你才会发现通信断了。3. 主备链路体检从redo传输到日志应用逐段量化3.1 传输链路V$ARCHIVE_DEST_STATUS 与 TNS 连通性链路体检从传输段开始。在主库查SELECT dest_id, dest_name, status, error, gap_status FROM v$archive_dest_status WHERE dest_id BETWEEN 2 AND 5;这里只看归档传输的目标状态。status列举几个常见值VALID目标正常正在接收或等待日志。ERROR传输出了问题这时候必须立刻去看error列它会直接给出ORA错误码。INACTIVE/DEFERRED目标被手动禁用或处于停用状态要确认是故意的还是意外。gap_status列表示备库是否有归档缺口正常是NO GAP。如果出现GAP字样说明备库确实缺日志了要往下走GAP处理流程。我遇到过好几次备库归档空间写满的情况表现就是主库这边dest状态变成ERRORerror列显示ORA-00257。其实问题出在备库的db_recovery_file_dest或归档目录满了但主库的传输进程照样在尝试发送只是备库拒绝接收。这种时候光看主库状态还不够要SSH到备库去清空间。传输链路还应该顺手验证网络连接tnsping 备库TNS别名看返回的延迟和成功率。如果延迟特别高或者出现ORA-12541、ORA-12170那基本就是监听、防火墙或者网络线路的问题。别小看这一步很多看似“备库hang住”的问题其实是连接已经断了。3.2 应用链路V$MANAGED_STANDBY、MRP 与 DataGuard Stats传输段的终点是备库接下来看应用段。在备库执行SELECT process, status, thread#, sequence#, block#, delay_mins FROM v$managed_standby;这个视图能看到备库后端的几个关键进程RFS远程文件服务器负责接收主库传来的redo正常状态是ATTACHED说明主备连接还健在。MRP0介质恢复进程也就是真正把redo应用到备库数据文件的进程。它可能出现的状态有APPLYING_LOG、WAIT_FOR_LOG、WAIT_FOR_REDO。短时间停在WAIT_FOR_LOG是正常的但如果长时间卡在同一序列号不动就得怀疑断流或假死了。注意别把delay_mins当成实时延迟。这个字段是LOG_ARCHIVE_DEST_n里的DELAY属性表示人工配置的延迟应用时间跟实时的apply lag不是一回事。另一个更直观的指标来自V$DATAGUARD_STATSSELECT name, value, unit FROM v$dataguard_stats WHERE name IN (transport lag, apply lag, apply finish time);三个值的含义transport lag主库最新redo到备库接收到位的时间差衡量的是传输段。正常配置下应该在秒级甚至0。apply lag备库接收到的redo到完成应用的时间差衡量的是应用段。ADG实时应用场景下通常也在几秒内。apply finish time按当前应用速度备库追平主库还需要多少时间。切换前这个值最好趋近于0。这里有个非常关键的排查思路看到lag高先分清是哪一段高。transport lag高问题在传输段查网络、备库空间、磁盘apply lag高问题在应用段查MRP进程状态、备库IO、是否有会话冲突。很多人一看到lag高就重配Broker其实方向错了。3.3 归档缺口从 GAP 发现到追平恢复DG环境最怕的就是GAP也就是备库缺少了某一段归档日志。小GAP通常能通过备库的FAL机制自动补齐但如果是主库端日志已经不存在了或者FAL服务器配错了GAP就会一直挂在那里。发现GAP有两个路径。第一个路径是前面提过的v$archive_dest_status里gap_status字段第二个更直接备库执行SELECT * FROM v$archive_gap;如果查出来有记录说明备库正缺日志。接下来把主备两边的日志序列做个对比量一量缺口有多大-- 主库当前归档的最大序列号 SELECT thread#, MAX(sequence#) FROM v$archived_log GROUP BY thread#; -- 备库已应用到的最大序列号 SELECT thread#, MAX(sequence#) FROM v$archived_log WHERE applied YES GROUP BY thread#;两边一减缺多少一目了然。手动补GAP的完整流程我是这么做的在备库确认缺哪个thread、哪个sequencev$archive_gap会告诉你需要哪个序列号。到主库去查对应归档文件的位置和名字SELECT name FROM v$archived_log WHERE thread# 1 AND sequence# 缺失的序列号;用scp或挂载共享存储把归档文件拷贝到备库的归档目录也可以用dbms_file_transfer。在备库手动注册这个归档文件ALTER DATABASE REGISTER LOGFILE /备库归档路径/归档文件名;恢复MRP的应用ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;如果环境配置了fal_server并且主库的归档文件还在备库一般会自动补GAP这一步是兜底手段。但fal_server有个前提备库要能通过TNS解析到主库且主库有足够的归档保留策略。很多环境的归档保留时间太短GAP一发生主库都已经清了那批归档就只能靠备份恢复或者flashback database来解决了。经验之谈GAP处理速度一定要快。时间拖得越长主库归档保留压力和单体故障风险就越大。补完GAP后建议再查一次v$archive_gap确认空然后看apply lag继续追平。4. ADG不是“备着就行”实时查询场景下的巡检重点4.1 确认只读打开并持续应用ADG和普通DG最大的区别就是备库可以READ ONLY WITH APPLY在应用redo的同时允许只读查询。这是它的卖点也意味着你要额外确认这个状态真的活着。备库执行SELECT name, open_mode, database_role FROM v$database;如果open_mode不是READ ONLY WITH APPLY而是READ ONLY说明实时应用其实没开启你可能只是把备库以普通只读方式打开了MRP并没有在应用redo。这种情况下备库的apply lag会不断累积。出现这种情况时通常是因为MRP没启动或者备库被以read only方式启动时没有加上recover managed standby database的联动。另外要确认MRP0进程确实在动。光看进程存在不代表它在干活我习惯连续隔几分钟查两次序列号确认它确实在推进SELECT process, sequence#, status FROM v$managed_standby WHERE process MRP0;两次结果序列号如果一直没变那就是卡住了。别被进程状态迷惑注意看时间戳和序列号的前进。4.2 临时表空间、性能与会话冲突检查ADG备库承载了查询负载之后性能检查就再也不能忽略。我最常遇到的问题是备库临时表空间被人动过。临时表空间在DG环境里特别容易被忽略因为主库的临时表空间不会被自动复制到备库备库的临时表空间通常是建库时单独创建的。主库加一个临时表空间备库不会跟着加反过来如果有人误操作把备库临时表空间删了或删了tempfile那后果立竿见影——所有落到备库的只读查询会直接报错。日常巡检可以顺手查备库的临时文件情况SELECT tablespace_name, SUM(bytes)/1024/1024 AS size_mb FROM dba_temp_files GROUP BY tablespace_name;确认备库至少有一个可用的临时表空间且容量匹配查询负载。前段时间一个客户环境就是A同学在备库清空间时直接删了tempfile结果第二天的报表任务全部报ORA-25153。恢复倒是不难重建一个临时表空间再设为默认即可但如果当时没人发现影响面会更大。性能层面ADG备库的apply lag如果持续偏高可以看看是不是只读查询和MRP在抢IO。尤其是大范围全表扫描、大排序这类查询会把备库的IO吃满MRP应用redo反而排不上队。查看备库的Top等待事件SELECT event, COUNT(*), SUM(time_waited)/100 AS time_waited_s FROM v$session_wait, v$session WHERE v$session.sid v$session_wait.sid GROUP BY event ORDER BY time_waited_s DESC FETCH FIRST 10 ROWS ONLY;如果看到大量buffer busy waits、db file sequential read并且apply lag在涨就要考虑是不是该把大查询迁走或者在备库上做资源隔离用Database Resource Manager把报表service的IO优先级调低。这个问题在ADG环境里属于典型矛盾备库既要跑查询又在做恢复两边都吃IO不做隔离早晚出事。5. 数据保护底线保护级别、FSFO 和切换准备状态5.1 保护模式与 Fast-Start Failover 状态核对前面提过保护模式这里要特别强调保护级别的核对。protection_mode是配置protection_level是现状。二者不一致说明当前数据保护能力已经低于设计目标。最典型的场景是配置了MAXIMUM AVAILABILITY但主库临时IO抖动导致redo同步延迟protection_level会临时降为RESYNCHRONIZATION等追平后又恢复。别小看这个过程如果降级发生在你夜里睡觉时等早上起来发现已经过了好几个小时而这几个小时内主库如果挂了你可能会丢数据。Fast-Start FailoverFSFO是DG的高可用自动切换方案。很多环境虽然启用了FSFO但Observer进程没有被好好守护。Observer是独立于数据库之外的一个监控进程它负责在备库侧判断主库是否宕机然后触发自动切换。如果Observer自己挂了FSFO就废了而主库状态看起来还是“一切正常”。通过Broker检查FSFOdgmgrl sys/oracle主库TNS show fast_start_failover重点看三件事是否ENABLED目标的备库名是否正确Observer状态是不是RUNNING。Observer如果跑在某个服务器上还没配守护一定要给它加个systemd或类似服务防止它随登录会话退出。FSFO阈值配置也值得看一眼。FastStartFailoverThreshold表示主库失去心跳多久后触发自动切换一般设置在15到30秒。设太短容易被网络抖动误触发设太长又失去了自动切换的意义。这个值没有绝对标准得按你实际的网络稳定性和业务容忍度来调。5.2 切换演练中的观察要点日常巡检看的是状态但状态正常不代表能顺利切换。我强烈建议每个季度做一次切换演练哪怕是Switchover这种非破坏性切换。演练前巡检时就要留意一些前置条件主库switchover_status是否为TO STANDBY或TO PRIMARY如果显示NOT ALLOWED说明当前不具备切换条件。备库的apply finish time是否已经接近0这代表切换前备库是否追平。数据文件路径转换规则是否正确防止切换后新主库起不来。演练时我会特别观察三个东西。一是角色切换后的归档连续性旧主库转为备库后能否快速加入新主库GAP是否为0。二是应用的连接重定向方案是否靠谱很多环境切换后才发现应用还连着旧库的TNS。三是ADG场景下切换完成后新的备库有没有恢复成READ ONLY WITH APPLY因为默认情况下切完可能就是普通物理备库ADG功能不会自动回来。演练记录和巡检记录一样要留档。出了大事需要翻的时候这些记录就是判断环境的“体检档案”。6. 巡检中遇到的几个典型问题现场6.1 备库归档空间写满导致的隐形GAP有一次巡检某环境的ADG备库发现主库侧v$archive_dest_status里dest变成了ERROR报错ORA-00257意思是备库的快速恢复区满了。但奇怪的是备库那边apply lag显示为0。数据看下来既正常又不正常。原因其实不复杂备库此刻的redo应用队列是空的已接收的日志都应用完了所以apply lag是0但主库的新日志根本传不过去transport lag一直在涨。如果只看apply lag这就是个“假健康”状态。发现后我清理了备库归档空间传输自动恢复GAP慢慢追平但这个过程里主库每多跑一分钟风险就多一分。从那之后我的巡检列表里永远把v$archive_dest_status的status和error放在比v$dataguard_stats更高的优先级。6.2 保护级别悄悄降级没人发现某客户环境配置的是MAXIMUM AVAILABILITY某天主库发生过一次短时间的IO抖动redo传输延迟了几分钟。Broker和视图都没有报大错唯独protection_level从MAXIMUM AVAILABILITY变成了RESYNCHRONIZATION。因为没人拉着level字段做监控这个降级完全不可见。等IO恢复、redo追平之后level又恢复原样整个过程像没发生过一样。但这件事绝不能当没发生。在MAXIMUM AVAILABILITY模式下保护级别的任何降级都意味着短时间内的数据风险。后来我在所有锂环境的巡检SQL里都会同时拉protection_mode和protection_level并且要求两者不一致时必须写原因。这是很多DBA漏掉的一个点。6.3 ADG备库被误当成普通库清理掉临时表空间还有一次是某公司的ADG备库承载了一个报表查询。有一个新来的同事看到备库临时表空间占用很高以为是垃圾直接把tempfile删了。结果当天业务侧的报表应用统一报错ORA-25153: Temporary Tablespace is empty。说来也不是特别复杂的故障在备库重建临时表空间并设为默认临时表空间就恢复了CREATE TEMPORARY TABLESPACE temp2 TEMPFILE /u01/app/oracle/oradata/orclstd/temp02.dbf SIZE 4G AUTOEXTEND ON NEXT 512M; ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp2;但这个事的启示很大ADG备库在团队里往往被误当成“普通只读库”操作者不知道它对DG链路意味着什么。巡检时把临时表空间大小、路径、默认状态都记进基线后面任何人乱动的时候你至少知道原本应该是怎样的。7. 把巡检变成每天顺手执行的习惯7.1 一套可以落地的巡检脚本思路手动巡检做得再好也难以天天坚持所以一定要脚本化。我的习惯是写一个shell脚本用sqlplus定期连主库和备库把关键状态一次性拉出来输出成带日期的文本文件作为基线再比对判断是否告警。一个最简版本的巡检脚本框架长这样#!/bin/bash export ORACLE_HOME/u01/app/oracle/product/19.3.0/dbhome_1 export PATH$ORACLE_HOME/bin:$PATH PRIMARYsys/oracle主库TNS as sysdba STANDBYsys/oracle备库TNS as sysdba echo 主库角色与保护模式 sqlplus -s /nolog EOF conn $PRIMARY SET PAGESIZE 100 LINESIZE 200 SELECT database_role, protection_mode, protection_level, open_mode FROM v\$database; SELECT dest_id, status, error, gap_status FROM v\$archive_dest_status WHERE dest_id BETWEEN 2 AND 4; SELECT thread#, MAX(sequence#) FROM v\$archived_log GROUP BY thread#; EOF echo 备库应用状态 sqlplus -s /nolog EOF conn $STANDBY SET PAGESIZE 100 LINESIZE 200 SELECT name, open_mode, database_role FROM v\$database; SELECT process, status, thread#, sequence# FROM v\$managed_standby WHERE process IN (MRP0,RFS); SELECT name, value, unit FROM v\$dataguard_stats WHERE name IN (transport lag,apply lag,apply finish time); SELECT tablespace_name, SUM(bytes)/1024/1024 AS size_mb FROM dba_temp_files GROUP BY tablespace_name; EOF注意脚本里sqlplus的v$要写成v\$不然shell会把变量展开掉这个细节坑过很多人。脚本每天固定时间跑输出保存到一个巡检目录里文件名带日期。再往上一层可以加阈值判断比如apply lag超过5分钟就发邮件超过30分钟就触发告警。每个环境的阈值不一样得按业务容忍度来定。7.2 巡检记录归档与趋势判断纯靠“今天看一眼没事”是发现不了趋势的。我会把每次巡检的输出按日期归档每周或每月翻一次历史记录重点看几个趋势指标每日归档日志量如果逐步上升说明业务在增长要提前规划归档空间和备份策略。transport lag和apply lag的峰值及其出现频率频繁超标说明网络或备库IO存在慢性问题。备库归档目录剩余空间的变化曲线提前扩容而不是等爆了再处理。保护级别的降级次数如果经常降级说明主库的IO稳定性或者网络质量需要专项治理。有了基线异常才显得扎眼。比如平时apply lag常年不超过2秒的库某天突然变成30秒多半是IO或资源冲突这时候再去查别的问题就有方向了。我现在的习惯是每天上午固定跑一遍巡检脚本输出存档到周末再翻一遍当周的lag峰值和dest状态把所有超过阈值的项过一遍。这套流程看着不起眼但它已经在几个环境里提前帮我暴露了要出事的苗头。DG/ADG巡检这件事说到底就是把“主备链路是否持续可用”这件事变成每天看得见的数字别让它藏在角落里等出了事才被人想起。