oracle 19c的parallel recovery是自动启用的机制，不可显式配置；优化关键在于消除i/o、内存及资源瓶颈，而非调整并行度，并需用窄窗口awr（如open后5–10分钟）捕获真实恢复性能数据。
oracle 19c 中的 parallel recovery（并行恢复）本身不是可直接配置的独立功能，而是由实例恢复（instance recovery）或介质恢复（media recovery）过程中，recover 操作自动启用的并行机制。它依赖底层的并行查询框架（px）、_parallel_recovery_threads 隐含参数（默认为 cpu_count）以及 i/o 能力，**无法像 data pump 那样显式指定 parallel=4**。因此，“优化 parallel recovery”实际是：确保恢复路径不被阻塞、i/o 不成瓶颈、并行资源可用，再通过 awr 精准识别恢复慢的根因。
为什么 AWR 里看不到明显的 “Parallel Recovery” 指标
AWR 报告中没有名为 “Parallel Recovery” 的等待事件、SQL 或统计项。恢复操作（尤其是崩溃后的 instance recovery）发生在数据库 MOUNT 状态下，此时 AWR 快照无法生成；而手动执行的 RECOVER DATABASE 属于前台会话行为，其 SQL 和等待事件会出现在 AWR 的 TOP SQL 和等待事件中，但归类为普通 DML/IO 类型。
-
DBA_HIST_ACTIVE_SESS_HISTORY（ASH）可能捕获到恢复会话的采样，但仅当恢复时间足够长（>1秒）且在OPEN状态后才被记录 —— 这通常不适用于快速 instance recovery - 真正能反映恢复效率的间接指标，是 AWR 中的
log file parallel write、db file sequential read、db file scattered read等 I/O 等待事件的平均等待时间与总耗时占比 - 如果恢复过程卡在某个环节，AWR 的
Top 5 Timed Events可能显示异常高的control file sequential read（控制文件争用）或enq: CF - contention（检查点队列锁）
用 AWR 定位恢复慢的真实瓶颈
恢复性能差，90% 是 I/O 或内存配置问题，而非“并行度不够”。重点看以下三处：
- 在
Wait Events部分，关注log file parallel write的平均等待时间（ms）。若 >15ms，说明归档日志或联机日志所在存储写入延迟高，恢复时重做应用（redo apply）会被拖慢 - 查看
SQL ordered by Elapsed Time，找执行时间极长、SQL_ID为空或为系统内部 SQL（如ksrtrc相关）的行 —— 这往往对应恢复期间的块读取或回滚段清理 - 检查
Instance Efficiency Percentages中的Buffer nowait %和Redo buffer allocation retries。若前者 0 表示 log buffer 不足，频繁等待分配，拖慢 redo 写入
真正有效的“并行恢复”调优动作
所谓调优，并非调大某个“并行度开关”，而是消除恢复路径上的串行化点和资源瓶颈：
- 确保
LOG_ARCHIVE_DEST_n指向高性能、低延迟的本地或 NAS 存储，避免挂载在慢速 NFS 上；使用异步归档（ASYNC）降低主库影响 - 增大
LOG_BUFFER（尤其在 RAC 环境），减少Redo buffer allocation retries；但注意该参数不能动态修改，需重启 - 确认
_parallel_recovery_threads未被设为 0 或过小（可通过SELECT ksppinm, ksppstvl FROM x$ksppi a, x$ksppcv b WHERE a.indx = b.indx AND ksppinm LIKE '%parallel%recovery%';查看），默认值通常合理 - 检查
V$AW_AGGREGATE_OP视图中OPERATION_TYPE = 'RECOVERY'的记录（如有），看ELAPSED_TIME和ERROR_MESSAGE—— 这是极少数能直接关联恢复操作的动态视图
最常被忽略的一点：恢复性能问题往往在数据库刚 OPEN 后的前几分钟内爆发，而 AWR 默认每小时采样一次。若你怀疑恢复慢，必须在问题发生后立即手工运行 awrrpt.sql，指定一个 **5–10 分钟的窄窗口**（比如从 START_TIME 到 OPEN 后 8 分钟），否则快照里根本抓不到恢复过程的痕迹。
