ora-00600在dg备库上90%以上是本地坏块所致，需通过rman validate、dbv及dd验证定位并确认主库无误后，方可谨慎覆盖文件并验证i/o稳定性。
先确认是不是备库本地坏块，别急着覆盖主库文件
ora-00600在dg备库上出现，90%以上不是主库传过来的“脏数据”，而是备库自己读文件时校验失败。最典型的是[kcbz_check_objd_typ_3]、[4000]、[4193]这几类——它们都指向备库本地数据文件某块的物理或逻辑损坏，比如asm diskgroup不一致、存储i/o错误、磁盘坏道，甚至只是备库所在主机内存故障导致buffer写歪。
-
V$DATABASE_BLOCK_CORRUPTION视图为空 ≠ 没坏块，它只记录RMAN主动扫描发现的块 - 对疑似数据文件运行
RMAN> VALIDATE DATAFILE <file> CHECK LOGICAL</file>，注意加CHECK LOGICAL，否则只做物理校验 - 用
dbv file=<datafile_path> blocksize=<block_size></block_size></datafile_path>离线校验，重点关注输出里Corrupt block relative dba行 - 必须在主库也跑一遍
VALIDATE DATAFILE <file></file>，如果主库通过而备库报错，基本锁定为备库本地问题
遇到[2619]这类归档日志损坏错误，优先清理归档而非恢复
ORA-00600 [2619]明确指向归档日志损坏，常见于备库磁盘满后人为删了归档，但MRP进程仍试图读取已不完整的归档文件（如1_84747_958258329.dbf）。此时强行RECOVER DATABASE只会反复失败。
- 直接走RMAN归档清理三步法：
DELETE NOPROMPT ARCHIVELOG UNTIL TIME 'SYSDATE-2' -
CROSSCHECK ARCHIVELOG ALL：将损坏归档标记为EXPIRED -
DELETE NOPROMPT EXPIRED ARCHIVELOG ALL：真正删掉元数据残留 - 做完这三步，DG GAP机制通常会自动从主库重传缺失归档，MRP进程几秒内就能继续推进
覆盖文件前必须保留原文件快照，且验证底层I/O是否稳定
只有在确认主库VALIDATE通过、且备库dbv定位到具体坏块位置后，才考虑用主库文件覆盖。但覆盖不是终点，而是风险起点。
- 用
cp /u01/oradata/stdby/users01.dbf /u01/oradata/stdby/users01.dbf.bak_$(date +%s)备份原文件 - 覆盖后不要立刻执行
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE - 先用
dd if=users01.dbf of=/dev/null bs=8192 skip=<block_num> count=1</block_num>测试该块能否稳定读取 - 若
dd报I/O错误，说明是备库存储层问题（非文件内容问题），得查ASM disk、OS磁盘健康度
Apply挂起后如何安全重启而不丢日志
ORA-00600导致MRP进程中断后，V$MANAGED_STANDBY中PROCESS状态会卡在APPLYING_LOG或WAIT_FOR_GAP，直接重启Apply可能跳过未处理的日志段。
- 先查
SELECT * FROM V$ARCHIVED_LOG WHERE APPLIED='NO' AND DEST_ID=2 ORDER BY FIRST_TIME，确认未应用日志范围 - 执行
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL干净终止当前Apply - 再用
STARTUP MOUNT+ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT重新启动 - 观察
V$MANAGED_STANDBY中PROCESS状态是否回到APPLYING_LOG，并检查SEQ#是否连续推进
真实场景里最容易被忽略的，是覆盖文件后不做dd验证就直接启Apply——你以为修好了坏块，其实只是把I/O层的问题暂时掩过去了。
