客户有个11g的active dataguard库，mrp进程停了，看alertlog，可以看到有关ora-7445[kdxlin]的报错：
cat alert*.log
....
Exception [type:SIGSEOV,Address not mapped to object] [ADDR:0xC] |PC：0x96504C7,kdxlin()+4153][flags: 0x0,count:1]
Errors in le /aabb/app/oracle/rdbms/diag/rdbms/rmydbsid/mydbsid/trace/partsm_pr18_21343.trc (incident=70353):
ORA-07445: exception encountered: core dump (kdxlin()+4153) [SIGSEGV] [ADDR:0xC] |PC:0x96504C7][Address not mapped to object][]
Incident details in: /aabb/app/oracle/rdbms/diag/rdbms/rmydbsid/mydbsid/incident/incdir_70353/mydbsid_pr18_21343_i70353.trc
Use ADRCI or Support Workbench to package the incident.
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0xC][PC:0x96504C7,kdxlin()+4153][flags:0XO,count:1]
Incidenl 70353 created, dump file/aabb/app/oracle/rdbms/diag/rdbms/rmydbsid/mydbsid/incident/incdir_70353/mydbsid_pr18_21343_i70353.trc
ORA-07445: exception encountered: core dump (kdxlin()+4153) [SIGSEGV] [ADDR:0xC] |PC:0x96504C7][Address not mapped to object][]
...
cat /aabb/app/oracle/rdbms/diag/rdbms/rmydbsid/mydbsid/incident/incdir_70353/mydbsid_pr18_21343_i70353.trc
...
Error 607 in redo applicalion callback
Dump of change vector
Typ:2 CLS:1 APN:5 DBA0x2598d645 OBJ:3S3792 SCN:0x0960.99d2655e SEQ:1 OP:10.2 ENC:0 RBL:0
index redo(kdxlin):insert leaf row
KTB Redo
op:0x01 ver:0x01
compat bit:4(post-11) padding:1
op:F xid:0x0001.01a.010d8f34 uba:0x00dc8e3.6bf5.20
REDO: SINGLE/NONKEY/--
itl:3, sno:255, row size 23
insert key:(14):05 c4 02 4e 31 4f 07 78 74 0b 09 11 27 29
nonkey (length: 5):
fb: --H-FL-- lb:0x0 cc:1
(2).01 80
Block after image is corrupt:
buffer tsn: 5 rdba:0x2598d645(1024/630773317)
scn:0x960.99d10d33 seq:0x01 flg:0x04 tail:0x0d330601
frmt:0x02 chkval:0xa1ae type:0x06=trans data
Hex dump of currupt header 3=CHKVAL
...
从trace中，我们可以看到这个dataguard上有坏块，坏块是在（file#5, block# 630773319）中。
先说一下对于坏块的处理：
1. 主库：
■ 如果是在索引块上，重建索引
■ 如果是在数据块上，且存在备份，用备份做blockrecover
■ 如果是在空块上，建一个表，填充这个块，填充时就会自动格式化对应的坏块。可以参考我以前写过的这里。
■ 如果是11gADG，物理坏块将触发ABMR(Automatic Block Recover)，oracle将通过ABMR自动修复坏块。
■ 如果是逻辑坏块，且配置了DB_LOST_WRITE_PROTECT+DB_BLOCK_CHEKING，将自动修复。(参考Doc ID 1302539.1)
■ 如果ABMR和lost write protection没有触发，将dataguard的文件rman备份，再restore到主库，再recover。
2.备库：
■ 首先考虑ABMR和DB_LOST_WRITE_PROTECT，是否自动修复
■ 利用备份，做blockrecover
■ 将主库的文件rman备份，再restore到主库，再recover。
由于是逻辑坏块，ABMR没有被触发。那么我们常规的做法是上面的第2和第3，可是，问题来了。
尝试第3条，将主库的文件拷贝到备库，发现这个发生坏块的库是在上海，根据两地三中心的架构，这个是个远程dataguard。拷贝文件和传输文件需要比较多的时间。那么究竟需要多少时间？我发现这个坏块（file#5, block# 630773319）是在一个bigfile tablespace上，而这个tablespace的datafile，已经到达了7T的大小!orz 给跪了……
尝试第2条，发现主库和local dataguard都在深圳，这个库在上海，而备份软件是在深圳的dataguard上备份的。远程的机器上没有agent，网络也没有通。再次跪。
好了，传统的方法都不行，开始思考非常规的方法，和同事进行头脑风暴了：
1. 既然是备库索引上的坏块，那么我主库重建索引，备库也就重建索引了。
>>可是现在mrp停在前面的一步，在没有过去这个点之前，是一直卡在这里，不会apply后续的日子，也就不会重复主库上的重建索引的操作。
2.既然已经找到对应的坏块，但是有不能进行blockrecover，那么将好块dd出来，再dd到坏块中。
>>由于使用是asm，要做这种操作的话，需要将数据文件先cp到文件系统，再在文件系统上做dd，在将块传输到上海。可惜7T的asm文件无法cp出来。
3.将这个坏块dd成物理坏块，利用ABMR恢复。
>>做dd也是有同2的问题，7T的asm文件无法cp出来。
4. 用bbed来修改，也涉及到cp 7T的asm文件。
这个时候，客户提出了一种解决方案，用增量备份，然后在做recover datafile 5 noredo;
这种方案之前都没有试过，我心里也没底，所以我在我自己的测试机器上测试了这种方案，发现还是无法修复坏块。但是客户坚持想尝试一下，没想到，成功了！
没想到增量备份+recover datafile noredo，这种追dataguard缺少归档日志的方式，也可以修复坏块！（增量备份的大小只有几个G，传输很方便。）
把这个好消息告诉了同事，同事指出，这个方法其实存在偶然性，因为这种方式，要求在mrp停掉的那个scn之后，坏块对应的主库上的块，已经被修改过了。这样才能包含在主库增量备份中。
一语惊醒梦中人，我在测试机上测试失败的原因，正是我在主库上没有修改对应的记录，即备库坏块对应在主库上的块，没有被修改过。所以也就不会包含在增量备份中了。
所以，多了这种方法之后，我们又可以头脑风暴，如果后续还发生这种情况，怎么样使得主库没有修改的块，发生变动……如update对应的块，如rebuild index online……
另外，再说一下：珍惜生命，远离bigfile tablespace。