ADG 查询阻塞通常并不是 ADG 自身故障，而多半由备库本地状态异常或主备同步链路问题引起；ORA-00604 / ORA-08102 则属于逻辑坏块导致的语义错误，ADG 仅负责同步物理块镜像，并不会检查数据的逻辑一致性。
Active Data Guard 的查询阻塞恢复，核心并不在于“修复 ADG”，而在于准确识别并消除导致只读查询挂起、卡顿或超时的根本原因——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”
这种情况通常也不是 Oracle 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 通过重做传播到备库后，在应用阶段引发对象级锁等待或资源争用，而不是单纯的 ADG 查询故障。
- 通过
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），或者主库传输过来的重做中包含尚未提交的大事务，导致备库应用线程被拖慢甚至挂起。在这种场景下，仅凭 SQL 执行计划往往无法定位问题，必须进一步结合 V$MANAGED_STANDBY 与 V$TRANSACTION 进行更深入的排查与分析。
