Incident details in: /u01/app/oracle/diag/rdbms/crjnew/crjnew/incident/incdir_444262/crjnew_mrp0_21854_i444262.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Recovery Slave PR1E previously exited with exception 600
Tue May 27 19:30:07 2014
MRP0: Background Media Recovery terminated with error 448
Errors in file /u01/app/oracle/diag/rdbms/crjnew/crjnew/trace/crjnew_pr00_21856.trc:
ORA-00448: normal completion of background process
Recovery interrupted!
Recovered data files to a consistent state at change 12331596967112
MRP0: Background Media Recovery process shutdown (crjnew)
Tue May 27 19:30:11 2014
Sweep [inc][444672]: completed
Sweep [inc][444262]: completed
Sweep [inc2][444672]: completed
Sweep [inc2][444262]: completed
Tue May 27 19:32:08 2014
Primary database is in MAXIMUM PERFORMANCE mode
你会看到，当你手工发起recover managed standby database disconnect from session后，会出现上述的错误。我们也可以清楚
的看到，之所以MRP经常无法正常启动，是因为有文件存在坏块。对于数据文件坏块，通过dbv检查你会发现是这么一种情况：
[oracle@gscrj01 ~]$ dbv file=/u01/app/oracle/oradata/CRJNEW/datafile/o1_mf_sysaux_859l29lq_.dbf blocksize=8192
DBVERIFY: Release 11.2.0.3.0 - Production on Tue May 27 18:02:42 2014
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
DBVERIFY - Verification starting : FILE = /u01/app/oracle/oradata/CRJNEW/datafile/o1_mf_sysaux_859l29lq_.dbf
Page 121298 is influx - most likely media corrupt
Corrupt block relative dba: 0x0081d9d2 (file 2, block 121298)
Fractured block found during dbv:
Data in bad block:
type: 6 format: 2 rdba: 0x0081d9d2
last change scn: 0x0b37.2c742a38 seq: 0x3 flg: 0x04
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x441f0601
check value in block header: 0xf89f
computed block checksum: 0x2281
DBVERIFY - Verification complete
Total Pages Examined : 655360
Total Pages Processed (Data) : 77609
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 66328
Total Pages Failing (Index): 0
Total Pages Processed (Lob) : 9344
Total Pages Failing (Lob) : 0
Total Pages Processed (Other): 108285
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 393793
Total Pages Marked Corrupt : 1
Total Pages Influx : 1
Total Pages Encrypted : 0
Highest block SCN : 745850569 (2871.745850569)
[oracle@gscrj01 ~]$ dbv file=/u01/app/oracle/oradata/CRJNEW/datafile/crj_data07.dbf blocksize=8192
DBVERIFY: Release 11.2.0.3.0 - Production on Tue May 27 18:12:41 2014
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
DBVERIFY - Verification starting : FILE = /u01/app/oracle/oradata/CRJNEW/datafile/crj_data07.dbf
DBVERIFY - Verification complete
Total Pages Examined : 3932160
Total Pages Processed (Data) : 47043
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 22456
Total Pages Failing (Index): 0
Total Pages Processed (Other): 3862660
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 1
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
Total Pages Encrypted : 0
Highest block SCN : 745794635 (2871.745794635)
我这里检查了2个报错的文件，发现sysaux的文件有一个坏块，然而另外一个数据dbv检查并没有提示坏块，但是为什么会报错呢？
这里的错误基本上都是类似ORA-10567: Redo is inconsistent with data block 的问题，这可能不是block本身的问题，可能是
日志写的内容和块的内容不一致了。
开始我看只有3个文件有报错，那我就想，能否直接从主库scp 这3个文件到备库，然后直接recover就行了呗？ 大概是这样一个操作：
--备库
alter database datafile n offline dro