Oracle Active Data Guard查询阻塞恢复如何处理？

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 根本没介入。

1. 先用 RMAN VALIDATE CHECK LOGICAL DATABASE 确认是否为逻辑坏块
2. 若确认，优先重建对应索引：DROP INDEX idx_name; CREATE INDEX idx_name ON ...
3. 表级逻辑损坏需结合 DBMS_REPAIR.CHECK_OBJECT 定位坏行，再决定导出/重建或跳过

备库查询长时间等待 event “log file sync” 或 “db file sequential read”

这通常不是 ADG 功能问题，而是备库 I/O 或日志应用瓶颈。ADG 要求备库持续应用重做，如果磁盘慢、归档路径满、或 standby_file_management 设置为 MANUAL 导致文件未自动创建，都会让重做应用滞后，进而使查询看到不一致或未提交的数据状态，引发隐式等待。

1. 检查 V$DATAGUARD_STATS 中 apply_lag 和 transport_lag 是否持续增长
2. 确认 archive_lag_target 是否设得过大（如 > 900），导致归档不及时
3. 查 V$ARCHIVE_DEST_STATUS 看目标状态是否为 VALID，ERROR 列是否有值
4. 避免在备库执行 ALTER SYSTEM CHECKPOINT —— 这会强制写 checkpoint，加剧 I/O 压力

查询被 enq: SS – contention 或 enq: RO – fast object reuse 阻塞

这是备库内部资源争用，常见于频繁 DDL（如分区交换、在线重定义）后未清理临时段，或大量并发只读查询争抢共享池中的游标/对象句柄。ADG 备库虽只读，但 DDL 仍可执行（需显式开启 ALTER DATABASE OPEN READ WRITE，但这已脱离标准 ADG 模式），更常见的是主库 DDL 传播后，在备库应用阶段引发锁等待。

1. 查 V$SESSION_WAIT 确认阻塞会话的 EVENT 和 P1TEXT/P2TEXT 参数含义
2. 检查 V$OBJECT_USAGE 和 DBA_SEGMENTS 中是否存在大量 TEMPORARY 或 UNUSABLE 状态对象
3. 禁用不必要的统计信息自动收集：EXEC DBMS_STATS.LOCK_TABLE_STATS 对关键表加锁
4. 避免在业务高峰执行大表 MOVE 或 REBUILD，这些操作会在备库重放时放大锁争用

真正难处理的，是那种没有明显错误码、查询既不报错也不返回，却卡在 SQL*Net message from client 或 resmgr: become active 上的情况——这往往指向资源管理器（RESOURCE_MANAGER_PLAN）在备库启用了限制策略，或主库传来的重做中包含未提交的大事务，备库应用线程被 hang 住。这种场景下，光看 SQL 执行计划没用，必须从 V$MANAGED_STANDBY 和 V$TRANSACTION 入手追根溯源。