1.主库
1.1 查看是否有从库
1）查看所有归档目的地配置，重点关注远程备库相关信息
col DEST_NAME for a40; col DESTINATION for a40; set lines 300; SELECT DEST_ID, -- 目的地ID（如1、2、...） DEST_NAME, -- 目的地名称（如LOG_ARCHIVE_DEST_2） DESTINATION, -- 归档目的地（备库的TNS连接字符串） STATUS, -- 状态（VALID表示有效配置） TYPE, -- 类型（PHYSICAL=物理备库，LOGICAL=逻辑备库，LOCAL=本地） DELAY_MINS, -- 延迟应用日志的分钟数（0表示实时同步） TARGET FROM V$ARCHIVE_DEST WHERE DEST_ID > 0; DEST_ID DEST_NAME DESTINATION STATUS TYPE DELAY_MINS TARGET ---------- ---------------------------------------- ---------------------------------------- --------- ------- ---------- ------- 1 LOG_ARCHIVE_DEST_1 /data/oradata/arch VALID PUBLIC 0 PRIMARY 2 LOG_ARCHIVE_DEST_2 rkhydg VALID PUBLIC 0 STANDBY 3 LOG_ARCHIVE_DEST_3 INACTIVE PUBLIC 0 PRIMARY 4 LOG_ARCHIVE_DEST_4 INACTIVE PUBLIC 0 PRIMARY 5 LOG_ARCHIVE_DEST_5 INACTIVE PUBLIC 0 PRIMARY
2）查看是否存在Standby日志
SELECT GROUP#, THREAD#, BYTES/1024/1024 "SIZE(MB)", STATUS FROM V$STANDBY_LOG; GROUP# THREAD# SIZE(MB) STATUS ---------- ---------- ---------- ---------- 6 0 500 UNASSIGNED 7 0 500 UNASSIGNED 8 0 500 UNASSIGNED 9 0 500 UNASSIGNED 10 0 500 UNASSIGNED 11 0 500 UNASSIGNED
3）查看Data Guard配置中的数据库
-- V$DATAGUARD_CONFIG 视图记录了 Data Guard 配置中的所有数据库（主库 + 备库）：
如果非RAC的话，查询出多条数据，则为ADG
SELECT DB_UNIQUE_NAME FROM V$DATAGUARD_CONFIG; DB_UNIQUE_NAME ------------------------------ rkhy rkhydg
1.2 查看主从应用模式
1）查看主库是否存在从库、且是否支持切换
archive log list;
col name for a50; set lines 300; -- SWITCHOVER_STATUS：SESSIONS ACTIVE（从库则为：NOT ALLOWED） select SWITCHOVER_STATUS,NAME,PROTECTION_MODE,OPEN_MODE,LOG_MODE,DATABASE_ROLE,DB_UNIQUE_NAME from v$database; SWITCHOVER_STATUS NAME PROTECTION_MODE OPEN_MODE LOG_MODE DATABASE_ROLE DB_UNIQUE_NAME -------------------- -------------------------------------------------- -------------------- -------------------- ------------ ---------------- ------------------------------ SESSIONS ACTIVE RKHY MAXIMUM PERFORMANCE READ WRITE ARCHIVELOG PRIMARY rkhy
2）查看从库应用模式
select process,status,thread#,sequence# from v$managed_standby;
SQL> select process,status,thread#,sequence# from v$managed_standby; PROCESS STATUS THREAD# SEQUENCE# --------- ------------ ---------- ---------- ARCH CLOSING 1 2406076 ARCH CLOSING 1 2406074 ARCH OPENING 1 2405819 ARCH CLOSING 1 2406075 LNS WRITING 1 2406077
1.3 查看主从延时
1）确定从库应用状态
archive log list;
SELECT DEST_ID, STATUS, APPLIED_SCN,ERROR FROM V$ARCHIVE_DEST WHERE TARGET='STANDBY';
该查询可获取主库到从库的归档日志传输状态及已应用的系统更改号（SCN）等信息。STATUS为VALID表示传输通道正常，APPLIED_SCN显示了从库已应用到的 SCN 值。但仅通过APPLIED_SCN无法直接得出从库的延时，需结合主库的当前 SCN 及相关时间信息才能估算延时，且计算相对复杂，还需考虑 SCN 的生成速度等因素。
2）如果是Archive应用模式（v$archived_log：name 字段是归档日志聚堆路径）
---- 查询在 Archive 应用模式下，还未应用的归档日志 -- 正序 col name for a50; set lines 300; select t.name,t.thread#,t.sequence#,to_char(t.first_time,'yyyy-mm-dd hh24:mi:ss'),to_char(t.next_time,'yyyy-mm-dd hh24:mi:ss'), APPLIED,t.stamp from v$archived_log t where APPLIED = 'NO' order by t.stamp ; -- 倒序 col name for a50; set lines 300; select t.name,t.thread#,t.sequence#,to_char(t.first_time,'yyyy-mm-dd hh24:mi:ss'),to_char(t.next_time,'yyyy-mm-dd hh24:mi:ss'), APPLIED,t.stamp from v$archived_log t where APPLIED = 'NO' order by t.stamp desc; ---- 查询在 Archive 应用模式下，已经应用的归档日志(最新应用的归档日志) select * from ( select t.name,t.thread#,t.sequence#,to_char(t.first_time,'yyyy-mm-dd hh24:mi:ss'),to_char(t.next_time,'yyyy-mm-dd hh24:mi:ss'), APPLIED,t.stamp from v$archived_log t where APPLIED = 'YES' order by t.stamp desc ) where rownum<=1;
3）如果是Redo 应用模式（v$archived_log：name 字段是 unique name 名称）
-- name 字段是 unique name 名称 select t.name,t.thread#,t.sequence#,to_char(t.first_time,'yyyy-mm-dd hh24:mi:ss'),to_char(t.next_time,'yyyy-mm-dd hh24:mi:ss'), APPLIED,t.stamp from v$archived_log t where t.name = 'caiwudg' and APPLIED = 'NO' order by t.stamp ;
2. 备库
2.1 查看备库主从复制相关进程情况
1）v$managed_standby -- 检查 mrp0 进程是否开启
select process,status,sequence# from v$managed_standby;
PROCESS STATUS SEQUENCE# --------- ------------ ---------- ARCH CLOSING 2406027 ARCH CLOSING 2406025 ARCH CLOSING 2400962 ARCH CLOSING 2406026 MRP0 APPLYING_LOG 2405932 RFS IDLE 0 RFS IDLE 0 RFS IDLE 0 RFS WRITING 2406028
主从应用模式说明（redo log应用还是 archlog 应用）
存在 PROCESS='MRP0' 且 STATUS='APPLYING_LOG'：说明备库的恢复进程正在主动应用 redo 日志（非空闲状态）。 RFS 进程的 STATUS 为 RECEIVING 或 IDLE：表示 RFS 进程正在接收主库的 redo 数据（RECEIVING），或刚接收完（IDLE），且这些数据正被 MRP0 实时应用。 MRP0 和 RFS 关联的 THREAD# 和 SEQUENCE# 一致：说明 RFS 接收的 redo（同一序列号）正在被 MRP0 应用，即 “边传边用”。
字段说明
PROCESS：从库上的守护进程类型
ARCH：归档进程（负责将主库传输的日志归档到从库）
MRP0：介质恢复进程（负责将归档日志应用到从库，实现数据同步）
RFS：远程文件服务器进程（负责接收主库传输的日志）
STATUS：进程当前状态
SEQUENCE#：日志序列号（标识主库生成的归档日志 / 在线日志编号，序号递增）
当前状态解读
ARCH 进程（4 行） 状态均为 CLOSING，表示这些进程正在完成对序列号为 2406027、2406025、2400962、2406026 的归档日志的归档操作（即将日志文件关闭并标记为完成）。 说明从库已成功接收这些日志并完成归档，是正常状态。 MRP0 进程（1 行） 状态为 APPLYING_LOG，表示正在应用序列号为 2405932 的归档日志。 这是从库同步的核心进程，该状态说明从库正在积极应用日志以追平主库数据。 RFS 进程（4 行） 3 个 RFS 状态为 IDLE（序号 0）：表示这些进程当前空闲，等待接收主库新的日志。 1 个 RFS 状态为 WRITING（序号 2406028）：表示正在接收并写入主库传输的最新日志（序列号 2406028）。 说明主库到从库的日志传输正常，RFS 进程能及时接收新日志。
关键结论
日志传输正常：RFS 进程有一个正在写入最新日志（2406028），说明主库日志能成功传输到从库。 日志应用中：MRP0 进程正在应用日志（2405932），但当前应用的序列号（2405932）远小于最新接收的日志序列号（2406028），说明存在 应用延迟（与之前查询的 apply lag 结果一致）。 整体来看，从库的日志传输和应用流程未中断，但应用速度落后于传输速度，需关注 MRP0 进程是否存在性能瓶颈（如资源不足、大事务阻塞等）。
2.2 查看主从复制延时与预计追平时间
1）v$dataguard_stats -- 检查 ADG 同步情况
set linesize 300;
select NAME,VALUE,TIME_COMPUTED,DATUM_TIME from v$dataguard_stats;
NAME VALUE TIME_COMPUTED DATUM_TIME -------------------------------------------------- ---------------------------------------------------------------- ------------------------------ ------------------------------ transport lag +00 00:00:00 08/04/2025 09:44:25 08/04/2025 09:44:24 apply lag +00 00:34:32 08/04/2025 09:44:25 08/04/2025 09:44:24 apply finish time +00 00:05:51.117 08/04/2025 09:44:25 estimated startup time 9 08/04/2025 09:44:25
关键指标解读
transport lag（传输延迟） 值为 +00 00:00:00，表示主库生成的日志传输到从库没有延迟，日志同步传输正常。 apply lag（应用延迟） 值为 +00 00:34:32，表示从库已接收日志，但尚未应用到数据库中，延迟时长为 34 秒 32 毫秒。 这是核心延迟指标，说明从库数据落后于主库约 34 秒，存在明显延时。 apply finish time（预计追平时间） 值为 +00 00:05:51.117，表示按照当前从库的日志应用速度，还需要约 5 分 51 秒 才能追平主库的最新数据。 estimated startup time（预计启动时间） 值为 9（单位：秒），表示如果从库重启，预计 9 秒可完成启动，与延迟无关。
2.3 查看从库延时应用归档的大小
1）v$archived_log
select ceil((sysdate-next_time)*24*60) "M" from v$archived_log where applied='YES' AND SEQUENCE#=(SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE applied='YES');
结果含义
查询返回 M=34，表示：
从库最后一个成功应用的归档日志，其结束时间（next_time）距离当前时间 已过去 34 分钟。
这间接反映了从库的 数据延迟时间：由于从库在这 34 分钟内未应用新的归档日志，导致数据落后于主库约 34 分钟（与之前 v$dataguard_stats 中 apply lag 显示的 34 秒可能存在统计口径差异，需结合具体场景分析）。
2.4 查看从库是否开启ADG与实时应用
1）查看从库是否开启ADG
select open_mode,protection_mode,database_role,switchover_status from v$database;
OPEN_MODE PROTECTION_MODE DATABASE_ROLE SWITCHOVER_STATUS -------------------- -------------------- ---------------- -------------------- READ ONLY WITH APPLY MAXIMUM PERFORMANCE PHYSICAL STANDBY NOT ALLOWED
如果 open_mode 为 READ ONLY 且 database_role 为 PHYSICAL STANDBY，同时 protection_mode 显示了相应的保护模式（如 MAXIMUM PERFORMANCE 等），则有可能开启了 ADG。因为 ADG 需要将备库以只读模式打开
select process,status from v$managed_standby where process like 'MRP%';
PROCESS STATUS --------- ------------ MRP0 APPLYING_LOG
如果 MRP 进程（介质恢复进程）的状态为 APPLYING_LOG 且数据库处于只读模式，说明正在进行实时应用日志，这是 ADG 开启的一个重要标志，表明备库在应用日志的同时还能提供只读查询功能。
2）查看是否开启实时应用
最直接的判断依据是：
v$database.open_mode 为 READ ONLY WITH APPLY（ADG 实时应用）
select open_mode from v$database;
SQL> select open_mode from v$database; OPEN_MODE -------------------- READ ONLY WITH APPLY
v$managed_standby 中 MRP 进程状态为 APPLYING_LOG；
SQL> select process,status,sequence# from v$managed_standby; PROCESS STATUS SEQUENCE# --------- ------------ ---------- ARCH CLOSING 2406045 ARCH CLOSING 2406043 ARCH CLOSING 2400962 ARCH CLOSING 2406044 MRP0 APPLYING_LOG 2405993 RFS IDLE 0 RFS IDLE 0 RFS IDLE 0 RFS IDLE 2406046
v$archive_dest_status.recovery_mode 为 REAL_TIME_APPLY。
SQL> select recovery_mode from v$archive_dest_status; RECOVERY_MODE ----------------------- MANAGED REAL TIME APPLY IDLE IDLE IDLE IDLE IDLE
满足以上任一条件（尤其是后两者），即可确认从库开启了日志文件的实时应用。
3）开启实时应用
alter database recover managed standby database using current logfile disconnect;
3. 查看引发主从延时的操作
3.1 核心思路
从库延时的本质是 “主库生成的日志未及时传输到从库” 或 “从库未及时应用已接收的日志”。引发延时的操作可能是：
主库上的大事务（如批量 DML、DDL）导致日志量突增；
主库日志传输受阻（如网络延迟、归档进程异常）；
从库应用进程（MRP）效率低（如资源不足、锁冲突）。
因此，需要分别在主库和从库定位问题环节。
3.2 在主库查看的关键信息（日志生成与传输）
主库的操作直接影响日志的产生和传输，需重点排查是否存在 “日志输出过多” 或 “传输瓶颈”：
1. 查看近期大事务或高负载操作
执行以下语句，查看主库近期耗时较长的 SQL 或事务：
sql
-- 查看当前活跃的长事务（可能正在生成大量日志）
select s.sid, s.serial#, s.username, t.used_ublk, t.start_time, q.sql_text from v$transaction t join v$session s on t.addr = s.taddr left join v$sql q on s.sql_id = q.sql_id order by t.start_time;
-- 查看历史执行的大事务（通过归档日志量反推）
select sql_id, sum(executions) execs, sum(buffer_gets) buf_gets, sum(redo_size) redo_size from v$sql where parsing_schema_name not in ('SYS', 'SYSTEM') order by redo_size desc;
说明：redo_size 越大，生成的日志越多，可能导致从库处理延迟。
在 Oracle 11.2.0.4 版本中，v$sql 视图不存在 redo_size 这个字段，这是导致报错 ORA-00904: "REDO_SIZE": invalid identifier 的直接原因。 redo_size 字段用于统计 SQL 语句执行过程中生成的重做日志大小，该字段是在 Oracle 12c 及更高版本 中才新增到 v$sql 视图中的。而 11g 版本的 v$sql 视图没有这个字段，因此无法直接通过该视图查询 SQL 生成的重做日志量。 替代方案（11g 兼容查询） 如果需要在 11g 中分析 SQL 生成的日志量或对系统的影响，可使用以下替代字段进行间接评估： sql -- 查看消耗资源较高的 SQL（通过逻辑读、物理读、执行次数等） select sql_id, sum(executions) execs, sum(buffer_gets) buf_gets, -- 逻辑读（间接反映 SQL 复杂度） sum(disk_reads) disk_reads, -- 物理读 sum(rows_processed) rows_processed -- 处理的行数（间接反映 DML 规模） from v$sql where parsing_schema_name not in ('SYS', 'SYSTEM') group by sql_id order by buf_gets desc; -- 按逻辑读降序，优先排查资源消耗高的 SQL 说明 在 11g 中，无法直接通过视图获取 SQL 生成的重做日志量，需通过上述间接指标（如逻辑读、处理行数）推测 SQL 对系统的影响（通常这些指标与重做日志量正相关）。 若需精确统计重做日志，可结合 v$transaction 视图的 used_ublk（回滚段块数）或启用审计日志跟踪 DML 操作。
2. 检查主库日志传输状态
查看归档进程（ARCH）是否正常传输日志到从库：
-- 主库查看归档目标状态（确认日志是否成功传输到从库）
select dest_id, status, error, archived_seq#
from v$archive_dest_status
where dest_id > 0; -- dest_id对应从库的归档目标
SQL> select dest_id, status, error, archived_seq# 2 from v$archive_dest_status 3 where dest_id > 0; DEST_ID STATUS ERROR ARCHIVED_SEQ# ---------- --------- ----------------------------------------------------------------- ------------- 1 VALID 2406115 2 VALID 2406115 3 INACTIVE 2406115 4 INACTIVE 2406115 5 INACTIVE 2406115 6 INACTIVE 2406115 7 INACTIVE 2406115 8 INACTIVE 2406115 9 INACTIVE 2406115 10 INACTIVE 2406115 11 INACTIVE 2406115 DEST_ID STATUS ERROR ARCHIVED_SEQ# ---------- --------- ----------------------------------------------------------------- ------------- 12 INACTIVE 2406115 13 INACTIVE 2406115 14 INACTIVE 2406115 15 INACTIVE 2406115 16 INACTIVE 2406115 17 INACTIVE 2406115 18 INACTIVE 2406115 19 INACTIVE 2406115 20 INACTIVE 2406115 21 INACTIVE 2406115 22 INACTIVE 2406115 DEST_ID STATUS ERROR ARCHIVED_SEQ# ---------- --------- ----------------------------------------------------------------- ------------- 23 INACTIVE 2406115 24 INACTIVE 2406115 25 INACTIVE 2406115 26 INACTIVE 2406115 27 INACTIVE 2406115 28 INACTIVE 2406115 29 INACTIVE 2406115 30 INACTIVE 2406115 31 INACTIVE 2406115 31 rows selected.
若 status 为 ERROR，需查看 error 字段（如网络错误、磁盘满），这会直接导致传输延时。
若 redo_sequence# 远大于从库已接收的序列号（需结合从库查询），说明传输存在积压。
3.3 在从库查看的关键信息（日志接收与应用）
从库的日志接收（RFS 进程）和应用（MRP 进程）是延时的另一关键环节，需排查是否存在 “接收慢” 或 “应用慢”：1. 确认从库日志接收与应用的延迟差
执行以下语句，对比从库已接收的日志和已应用的日志序列号： -- 从库：已接收的最新日志序列号（RFS进程负责接收） select max(sequence#) as received_seq from v$archived_log; -- 从库：已应用的最新日志序列号（MRP进程负责应用） select max(sequence#) as applied_seq from v$archived_log where applied = 'YES'; 若 received_seq 远大于 applied_seq：说明从库接收日志正常，但应用缓慢（问题在 MRP 进程）。 若 received_seq 很小（远小于主库当前序列号）：说明日志传输延迟（问题在主库传输或网络）。
2. 查看从库应用进程（MRP）的瓶颈
检查 MRP 进程是否因资源不足或锁等待导致应用慢：
-- 从库：查看MRP进程状态及等待事件
select process, status, sequence#
from v$managed_standby
where process like 'MRP%';
-- 从库：查看应用日志时的等待事件（如IO等待、锁等待）
select event, total_waits, time_waited
from v$system_event
where event like '%recovery%' or event like '%log%';
若 MRP 状态为 WAITING_FOR_REDO（等待日志）：可能是传输延迟；若等待事件中出现以下情况，需重点关注：
MRP wait on archivelog arrival（MRP 等待归档日志到达）：总等待次数（total_waits）或等待时间（time_waited）较大，说明从库频繁等待主库传输日志，传输效率低于应用速度。 parallel recovery slave next change（并行恢复从进程等待下一个变更）：若等待时间过长，可能是并行恢复配置不合理或从库 CPU / 内存资源不足，导致应用效率低。 log file sequential read（日志文件顺序读取）：等待次数多且时间长，可能是从库日志文件 IO 性能不足，影响日志读取效率。 parallel recovery control message reply（并行恢复控制消息响应）：等待时间过长可能反映并行恢复进程间通信效率低，或主从库日志同步机制存在瓶颈。
若存在大量 db file parallel write 或 log file sync 等待：说明从库 IO 性能不足，导致应用慢。
3. 定位具体延迟的日志及对应操作
若从库应用延迟（applied_seq 落后），可通过日志序列号关联主库操作：
在从库找到未应用的日志序列号（如 X）；
在主库查询该序列号日志对应的操作时间和 SQL：
-- 主库：查询序列号X的日志生成时间
select first_time as next_time, sequence#
from v$log_history
where sequence# = '2406108';
-- 结合主库审计日志或AWR报告，定位该时间段内的大操作
3.4 总结：主库还是从库查看？
主库：主要排查 “引发大量日志的操作”（如大事务）和 “日志传输是否正常”；从库：主要排查 “日志接收是否完整” 和 “日志应用是否受阻”（如 MRP 进程状态、资源瓶颈）。
最佳实践：先在从库确认延迟环节（传输延迟还是应用延迟），再针对性到主库或从库深入查询具体操作。例如：
若传输延迟：去主库查归档进程错误或网络问题；
若应用延迟：去从库查 MRP 等待事件，或通过日志序列号反推主库对应时间的操作。
4.查看主从是否有GAP
SQL> SELECT * FROM V$ARCHIVE_GAP; no rows selected SQL>
posted on
浙公网安备 33010602011771号