ora-19566 表示 rman 主动拒绝备份含坏块的数据，需先查 v$database_block_corruption 确认坏块位置及类型（corrupt/fractured/logical），再据类型分路径修复：物理坏块须先处理存储硬件，逻辑索引可重建，逻辑表优先 alter table move；误用 maxcorrupt 或跳过选项将掩盖风险。
ORA-19566 不是备份失败，是 RMAN 主动拒绝把坏块写进备份集——它在喊“这数据不能信”，不是在说“我不会备份”。
查 v$database_block_corruption 是唯一可信起点
这个视图记录的是 Oracle 已确认的坏块位置，不是猜测、不是日志推断。空结果不等于安全，但非空就代表必须立刻处理。
- 登录 SQL*Plus，执行
SELECT * FROM v$database_block_corruption;，拿到FILE#、BLOCK#、CORRUPTION_TYPE -
CORRUPTION_TYPE常见值：CORRUPT（物理扇区失效）、FRACTURED（块头尾校验不一致）、LOGICAL（索引键乱序、LOB 指针断裂） - 如果返回多行，尤其
BLOCK#连续，说明不是单点故障，而是段级损坏，修复优先级高于孤立坏块 - 若视图为空但仍有 ORA-19566，补跑
RMAN> VALIDATE CHECK LOGICAL DATABASE;或用dbv扫单个文件
用 dba_extents 定位坏块属于哪个对象
只知道文件和块号，就像知道车祸发生在“某条路第 123 米”，但不知道撞的是谁的车——修之前必须知道坏块属于哪张表、哪个索引或 LOB 段。
- 执行
SELECT owner, segment_name, segment_type FROM dba_extents WHERE file_id = &F AND &B BETWEEN block_id AND block_id + blocks - 1;（&F和&B替换为上一步查到的值） - 若查不到结果，坏块可能落在空闲空间、回滚段或数据字典中，需结合
alert.log中的Corrupt Block Found行比对OBJN/OBJD - 对疑似对象运行
ANALYZE TABLE xxx VALIDATE STRUCTURE CASCADE;可触发更细粒度校验，但会锁表，OLTP 环境慎用 - LOB 段容易被漏检：普通
BACKUP DATABASE不校验 LOB 内容，必须显式加CHECK LOGICAL
按 corruption_type 分路径修复，别混用方案
物理坏块和逻辑坏块的修复成本、风险、依赖条件完全不同。拿重建索引当万能药，等于给心脏手术用创可贴。
-
CORRUPT或FRACTURED：本质是存储层问题。RAID 降级、磁盘扇区失效、ASM 磁盘亮红灯——必须先换硬件或重建阵列，再用RECOVER DATAFILE或BLOCKRECOVER；DBMS_REPAIR只能跳过，不能修复 -
LOGICAL且是索引：最安全快捷。DROP INDEX idx_name;+CREATE INDEX，无需停业务 -
LOGICAL且是表：优先尝试ALTER TABLE xxx MOVE;（会重建段并跳过坏块），但注意索引失效、LOB 存储属性重置；不可行时再考虑EVENT 10231+CREATE TABLE AS SELECT
set maxcorrupt 是临时创可贴，不是修复开关
它只在一个 run { } 块内生效，且必须绑定具体数据文件。设了不代表安全，只代表你愿意让坏块原封不动进备份集。
- 正确写法：
run { set maxcorrupt for datafile 4 to 10; backup datafile 4; } - 错误写法：
set maxcorrupt to 10（语法不合法）、set maxcorrupt for datafile 4 to 100却执行backup database（不生效） - 若坏块分布在多个文件（如
FILE#显示 3、7、12 都有），得为每个文件单独设一次 -
SKIP OFFLINE和SKIP INACCESSIBLE是文件级跳过，对已打开文件内的坏块完全无效
真正容易被忽略的点是：坏块类型决定修复路径，而类型判断依赖 v$database_block_corruption.CORRUPTION_TYPE 的准确解读——LOGICAL 不等于“可以随便重建”，CORRUPT 也不等于“必须整个文件恢复”。修之前没看清这一行，后面所有操作都在赌运气。
