adg查询阻塞不是adg自身问题，而是备库本地状态或主备同步异常所致；ora-00604/ora-08102是逻辑坏块引发的语义错误，adg不校验逻辑一致性，仅同步物理块镜像。
Active Data Guard 的查询阻塞恢复，本质不是“修复”问题，而是识别并解除导致只读查询被挂起或超时的底层原因——ADG 本身不提供自动解阻塞机制，它只是把主库的重做流实时应用到备库，而阻塞必然来自备库本地状态或主备同步链路异常。
ORA-00604 / ORA-08102 在备库查询时出现，是不是 ADG 阻塞？
不是。这类错误是逻辑坏块触发的语义校验失败（如索引结构错乱、ITL 条目损坏），和 ADG 同步无关。ADG 只同步物理块镜像，不会校验逻辑一致性。一旦主库已有逻辑坏块，备库应用后同样出错，SELECT 就会卡在坏块访问点上，表现为长时间无响应或直接报错。此时查 alert.log 不会出现 replaced from physical standby，说明 ADG 根本没介入。
- 先用
RMAN VALIDATE CHECK LOGICAL DATABASE确认是否为逻辑坏块 - 若确认，优先重建对应索引：
DROP INDEX idx_name; CREATE INDEX idx_name ON ... - 表级逻辑损坏需结合
DBMS_REPAIR.CHECK_OBJECT定位坏行，再决定导出/重建或跳过
备库查询长时间等待 event “log file sync” 或 “db file sequential read”
这通常不是 ADG 功能问题，而是备库 I/O 或日志应用瓶颈。ADG 要求备库持续应用重做，如果磁盘慢、归档路径满、或 standby_file_management 设置为 MANUAL 导致文件未自动创建，都会让重做应用滞后，进而使查询看到不一致或未提交的数据状态，引发隐式等待。
- 检查
V$DATAGUARD_STATS中apply_lag和transport_lag是否持续增长 - 确认
archive_lag_target是否设得过大（如 > 900），导致归档不及时 - 查
V$ARCHIVE_DEST_STATUS看目标状态是否为VALID，ERROR列是否有值 - 避免在备库执行
ALTER SYSTEM CHECKPOINT—— 这会强制写 checkpoint，加剧 I/O 压力
查询被 enq: SS – contention 或 enq: RO – fast object reuse 阻塞
这是备库内部资源争用，常见于频繁 DDL（如分区交换、在线重定义）后未清理临时段，或大量并发只读查询争抢共享池中的游标/对象句柄。ADG 备库虽只读，但 DDL 仍可执行（需显式开启 ALTER DATABASE OPEN READ WRITE，但这已脱离标准 ADG 模式），更常见的是主库 DDL 传播后，在备库应用阶段引发锁等待。
- 查
V$SESSION_WAIT确认阻塞会话的EVENT和P1TEXT/P2TEXT参数含义 - 检查
V$OBJECT_USAGE和DBA_SEGMENTS中是否存在大量TEMPORARY或UNUSABLE状态对象 - 禁用不必要的统计信息自动收集：
EXEC DBMS_STATS.LOCK_TABLE_STATS对关键表加锁 - 避免在业务高峰执行大表
MOVE或REBUILD，这些操作会在备库重放时放大锁争用
真正难处理的，是那种没有明显错误码、查询既不报错也不返回，却卡在 SQL*Net message from client 或 resmgr: become active 上的情况——这往往指向资源管理器（RESOURCE_MANAGER_PLAN）在备库启用了限制策略，或主库传来的重做中包含未提交的大事务，备库应用线程被 hang 住。这种场景下，光看 SQL 执行计划没用，必须从 V$MANAGED_STANDBY 和 V$TRANSACTION 入手追根溯源。
