|
测试环境：11.2.0.4 - 1.构建数据块损坏的测试环境
- 2.有备份：常规恢复坏块
- 3.无备份：跳过坏块
1.构建数据块损坏的测试环境1.1 创建测试表 --Create Table t_testconn jingyu/jingyudrop table t_test purge;create table t_test (id number, name char(2000));--Insert datainsert into t_test values(1, 'alfred 1');insert into t_test values(2, 'alfred 2');insert into t_test values(3, 'alfred 3');insert into t_test values(4, 'alfred 4');insert into t_test values(5, 'alfred 5');insert into t_test values(6, 'alfred 6');insert into t_test values(7, 'alfred 7');insert into t_test values(8, 'alfred 8');insert into t_test values(9, 'alfred 9');insert into t_test values(10, 'alfred 10');commit;--Create Indexcreate index idx_t_test_1 on t_test(id);--Statistics--analyze table t_test compute statistics;EXEC DBMS_STATS.gather_table_stats('JINGYU', 'T_TEST', cascade => TRUE);1.2 查询表中每一行对应的文件号和块号 --查询t_test表中每一行对应的文件和块号select blocks from user_tables where table_name = 'T_TEST';select dbms_rowid.rowid_relative_fno(rowid) R_FNO,dbms_rowid.rowid_block_number(rowid) b_no, idfrom t_testorder by 1,2;--这里对象占用块数的查询前后不匹配,与书中不符,但不影响实验,结果如下: SQL> select blocks from user_tables where table_name = 'T_TEST'; BLOCKS---------- 5SQL> select dbms_rowid.rowid_relative_fno(rowid) R_FNO, 2 dbms_rowid.rowid_block_number(rowid) b_no, id 3 from t_test 4 order by 1,2; R_FNO B_NO ID---------- ---------- ---------- 6 3892 1 6 3892 2 6 3892 3 6 3893 4 6 3893 5 6 3893 6 6 3894 7 6 3894 8 6 3894 9 6 3895 1010 rows selected.1.3 使用bbed工具模拟破坏6号数据文件的3893数据块 关于bbed的编译和使用可参考 1.3.1 准备bbed配置文件：
编辑/tmp/bbed.par参数配置文件 --编辑/tmp/bbed.par参数配置文件blocksize=8192listfile=/tmp/listfile.txtmode=edit--编辑/tmp/listfile.txt文件 SQL> select file#||' '||name||' '||bytes from v$datafile ;FILE#||''||NAME||''||BYTES--------------------------------------------------------------------------------1 +DATA1/jyzhao/datafile/system.256.919998779 7864320002 +DATA1/jyzhao/datafile/sysaux.257.919998781 8912896003 +DATA1/jyzhao/datafile/undotbs1.258.919998783 1258291204 +DATA1/jyzhao/datafile/users.259.919998789 131072005 +DATA1/jyzhao/datafile/undotbs2.264.919999419 786432006 +DATA1/jyzhao/datafile/dbs_d_jingyu.268.927427887 1048576007 +DATA1/jyzhao/datafile/dbs_i_jingyu.270.927427891 314572808 +DATA1/jyzhao/datafile/soe.278.939295201 1048576009 +DATA1/jyzhao/datafile/dbs_d_jingyu.277.939295229 104857600由于bbed不能直接操作ASM里面的数据文件，所以需把对应的数据文件转储出来： RMAN> backup as copy datafile 6 format '/opt/app/Oracle/datafile/dbs_d_jingyu01.dbf';--mount RMAN> switch datafile 6 to copy;RMAN> recover datafile 6;RMAN> alter database open;--编辑/tmp/listfile.txt,添加6号文件信息vi /tmp/listfile.txt6 /opt/app/oracle/datafile/dbs_d_jingyu01.dbf 104857600SQL> alter system checkpoint;测试调用bbed正常： --调用bbedcd /tmpbbed parfile=bbed.par1.3.2 破坏数据文件6的3893数据块 [oracle@jyrac1 tmp]$ bbed parfile=bbed.parPassword: BBED: Release 2.0.0.0.0 - Limited Production on Wed Mar 22 15:28:00 2017Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.************* !!! For Oracle Internal Use only !!! ***************BBED> set dba 6,3893 DBA 0x01800f35 (25169717 6,3893)BBED> find /c alfred File: /opt/app/oracle/datafile/dbs_d_jingyu01.dbf (6) Block: 3893 Offsets: 2170 to 2681 Dba:0x01800f35------------------------------------------------------------------------ 616c6672 65642036 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 <32 bytes per line>BBED> f File: /opt/app/oracle/datafile/dbs_d_jingyu01.dbf (6) Block: 3893 Offsets: 4179 to 4690 Dba:0x01800f35------------------------------------------------------------------------ 616c6672 65642035 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 <32 bytes per line>BBED> f File: /opt/app/oracle/datafile/dbs_d_jingyu01.dbf (6) Block: 3893 Offsets: 6188 to 6699 Dba:0x01800f35------------------------------------------------------------------------ 616c6672 65642034 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 <32 bytes per line>BBED> fBBED-00212: search string not foundBBED> dump /v dba 6,3893 offset 2170 count 64 File: /opt/app/oracle/datafile/dbs_d_jingyu01.dbf (6) Block: 3893 Offsets: 2170 to 2233 Dba:0x01800f35------------------------------------------------------- 616c6672 65642036 20202020 20202020 l alfred 6 20202020 20202020 20202020 20202020 l 20202020 20202020 20202020 20202020 l 20202020 20202020 20202020 20202020 l <16 bytes per line>BBED> dump /v dba 6,3893 offset 4179 count 64 File: /opt/app/oracle/datafile/dbs_d_jingyu01.dbf (6) Block: 3893 Offsets: 4179 to 4242 Dba:0x01800f35------------------------------------------------------- 616c6672 65642035 20202020 20202020 l alfred 5 20202020 20202020 20202020 20202020 l 20202020 20202020 20202020 20202020 l 20202020 20202020 20202020 20202020 l <16 bytes per line>BBED> dump /v dba 6,3893 offset 6188 count 64 File: /opt/app/oracle/datafile/dbs_d_jingyu01.dbf (6) Block: 3893 Offsets: 6188 to 6251 Dba:0x01800f35------------------------------------------------------- 616c6672 65642034 20202020 20202020 l alfred 4 20202020 20202020 20202020 20202020 l 20202020 20202020 20202020 20202020 l 20202020 20202020 20202020 20202020 l <16 bytes per line>BBED> modify 901010 dba 6,3893Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y File: /opt/app/oracle/datafile/dbs_d_jingyu01.dbf (6) Block: 3893 Offsets: 6188 to 6251 Dba:0x01800f35------------------------------------------------------------------------ 0dbf9272 65642034 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020 <32 bytes per line>BBED> exit1.3.3 使用dbv检查文件 [oracle@jyrac1 tmp]$ dbv file=/opt/app/oracle/datafile/dbs_d_jingyu01.dbfDBVERIFY: Release 11.2.0.4.0 - Production on Wed Mar 22 15:31:50 2017Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.DBVERIFY - Verification starting : FILE = /opt/app/oracle/datafile/dbs_d_jingyu01.dbfPage 3893 is marked corruptCorrupt block relative dba: 0x01800f35 (file 6, block 3893)Bad check value found during dbv: Data in bad block: type: 6 format: 2 rdba: 0x01800f35 last change scn: 0x0000.003b68be seq: 0x1 flg: 0x06 spare1: 0x0 spare2: 0x0 spare3: 0x0 consistency value in tail: 0x68be0601 check value in block header: 0x6485 computed block checksum: 0xd398DBVERIFY - Verification completeTotal Pages Examined : 12800Total Pages Processed (Data) : 2512Total Pages Failing (Data) : 0Total Pages Processed (Index): 989Total Pages Failing (Index): 0Total Pages Processed (Other): 9025Total Pages Processed (Seg) : 0Total Pages Failing (Seg) : 0Total Pages Empty : 273Total Pages Marked Corrupt : 1Total Pages Influx : 0Total Pages Encrypted : 0Highest block SCN : 3893454 (0.3893454)[oracle@jyrac1 tmp]$ 2.有备份：常规恢复数据库有有效的RMAN备份，那么很简单，直接恢复损害数据块即可。
RMAN> blockrecover datafile 6 block 3893; 常规恢复输出类似下面这样： RMAN> blockrecover datafile 6 block 3893;Starting recover at 22-MAR-17using target database control file instead of recovery catalogallocated channel: ORA_DISK_1channel ORA_DISK_1: SID=148 instance=jyzhao1 device type=DISKchannel ORA_DISK_1: restoring block(s)channel ORA_DISK_1: specifying block(s) to restore from backup setrestoring blocks of datafile 00006channel ORA_DISK_1: reading from backup piece +FRA1/jyzhao/backupset/2017_03_22/nnndf0_tag20170322t123922_0.463.939299963channel ORA_DISK_1: piece handle=+FRA1/jyzhao/backupset/2017_03_22/nnndf0_tag20170322t123922_0.463.939299963 tag=TAG20170322T123922channel ORA_DISK_1: restored block(s) from backup piece 1channel ORA_DISK_1: block restore complete, elapsed time: 00:00:01starting media recoverymedia recovery complete, elapsed time: 00:00:04Finished recover at 22-MAR-17恢复完成后可以正常访问。 3.无备份：跳过坏块3.1 查看AFN和RFN 绝对数据文件号：AFN是数据文件在整个系统范围内的编号。
相对数据文件号：RFN是数据文件在表空间范围内的编号。
两个文件可能有相同的RFN，但是不会有相同的AFN。
获取普通文件的AFN和RFN:
select tablespace_name, file_id "AFN", relative_fno "RFN" from dba_data_files; SQL> select tablespace_name, file_id "AFN", relative_fno "RFN" from dba_data_files;TABLESPACE_NAME AFN RFN------------------------------ ---------- ----------USERS 4 4UNDOTBS1 3 3SYSAUX 2 2SYSTEM 1 1UNDOTBS2 5 5DBS_D_JINGYU 6 6DBS_I_JINGYU 7 7SOE 8 1024DBS_D_JINGYU 9 99 rows selected.注意：实验发现，大文件表空间的RFN固定为1024。 获取临时文件的AFN和RFN：
select tablespace_name, file_id + value "AFN", relative_fno "RFN" from dba_temp_files, v$parameter where name = 'db_files'; SQL> select tablespace_name, file_id + value "AFN", relative_fno "RFN" from dba_temp_files, v$parameter where name = 'db_files';TABLESPACE_NAME AFN RFN------------------------------ ---------- ----------TEMP_JINGYU 202 1TEMP 201 13.2 创建 REPAIR_TABLE 和 ORPHAN_KEY_TABLE
REPAIR_TABLE用来记录错误检查结果，ORPHAN_KEY_TABLE用来记录表坏块中记录在索引中对应键值。 --通过如下存储过程创建 REPAIR_TABLE 和 ORPHAN_KEY_TABLE--Repair Tabledeclarebegin dbms_repair.admin_tables( table_name => 'REPAIR_TABLE', table_type => dbms_repair.repair_table, action => dbms_repair.create_action, tablespace => 'USERS' );end;/select owner, object_name, object_type from dba_objects where object_name like '%REPAIR_TABLE';--Orphan Key Tabledeclarebegin dbms_repair.admin_tables( table_name => 'ORPHAN_KEY_TABLE', table_type => dbms_repair.orphan_table, action => dbms_repair.create_action, tablespace => 'USERS' );end;/select owner, object_name, object_type from dba_objects where object_name like '%ORPHAN_KEY_TABLE';--不再需要时，可以通过下面的存储过程删除 REPAIR_TABLE 和 ORPHAN_KEY_TABLE 这两个表：--DROP REPAIR_TABLEBEGIN DBMS_REPAIR.ADMIN_TABLES ( TABLE_NAME => 'REPAIR_TABLE', TABLE_TYPE => dbms_repair.repair_table, ACTION => dbms_repair.drop_action);END;/--DROP ORPHAN_KEY_TABLEBEGIN DBMS_REPAIR.ADMIN_TABLES ( TABLE_NAME => 'ORPHAN_KEY_TABLE', TABLE_TYPE => dbms_repair.orphan_table, ACTION => dbms_repair.drop_action);END;/3.3 使用CHECK_OBJECT过程检测坏块 set serveroutput ondeclare rpr_count int;begin rpr_count := 0; dbms_repair.check_object( schema_name => 'JINGYU', object_name => 'T_TEST', repair_table_name => 'REPAIR_TABLE', corrupt_count => rpr_count ); dbms_output.put_line('repair count: ' || to_char(rpr_count));end;/select object_name, block_id, corrupt_type, marked_corrupt, corrupt_description, repair_description from repair_table;执行结果： SQL> set serveroutput onSQL> declare 2 rpr_count int; 3 begin 4 rpr_count := 0; 5 dbms_repair.check_object( 6 schema_name => 'JINGYU', 7 object_name => 'T_TEST', 8 repair_table_name => 'REPAIR_TABLE', 9 corrupt_count => rpr_count 10 ); 11 dbms_output.put_line('repair count: ' || to_char(rpr_count)); 12 end; 13 /repair count: 1PL/SQL procedure successfully completed.SQL> select object_name, block_id, corrupt_type, marked_corrupt, corrupt_description, repair_description from repair_table;OBJECT_NAME BLOCK_ID CORRUPT_TYPE MARKED_COR------------------------------ ---------- ------------ ----------CORRUPT_DESCRIPTION--------------------------------------------------------------------------------REPAIR_DESCRIPTION--------------------------------------------------------------------------------T_TEST 3893 6148 TRUEmark block software corrupt如果marked_corrupt不是true，则需要使用fix_corrupt_blocks过程修复： declare fix_count int;begin fix_count := 0; dbms_repair.fix_corrupt_blocks( schema_name => 'JINGYU', object_name => 'T_TEST', object_type => dbms_repair.table_object, repair_table_name => 'REPAIR_TABLE', fix_count => fix_count ); dbms_output.put_line('fix count: ' || to_char(fix_count));end;/这里实验此步骤执行不执行都可以。 3.4 使用DUMP_ORPHAN_KEYS过程来保存坏块中的索引键值 select object_name, block_id, marked_corrupt from repair_table; select index_name from dba_indexes where table_name in (select distinct object_name from repair_table); SQL> select object_name, block_id, marked_corrupt from repair_table;OBJECT_NAME BLOCK_ID MARKED_COR------------------------------ ---------- ----------T_TEST 3893 TRUESQL> select index_name from dba_indexes where table_name in (select distinct object_name from repair_table);INDEX_NAME------------------------------IDX_T_TEST_1这时还存在着一个潜在的问题。
就是表有坏块，但索引没有损坏，通过表扫描会出现错误，但是通过索引扫描仍然可以返回结果，这会造成数据的不一致性。
比如，这里我知道id = 4的记录： SQL> select * from jingyu.t_test where id = 4;select * from jingyu.t_test where id = 4 *ERROR at line 1:ORA-01578: ORACLE data block corrupted (file # 6, block # 3893)ORA-01110: data file 6: '/opt/app/oracle/datafile/dbs_d_jingyu01.dbf'SQL> select id from jingyu.t_test where id = 4; ID---------- 4使用DUMP_ORPHAN_KEYS过程来保存坏块中的索引键值： set serveroutput ondeclare key_count int;begin key_count := 0; dbms_repair.dump_orphan_keys( schema_name => 'JINGYU', object_name => 'IDX_T_TEST_1', object_type => dbms_repair.index_object, repair_table_name => 'REPAIR_TABLE', orphan_table_name => 'ORPHAN_KEY_TABLE', key_count => key_count ); dbms_output.put_line('orphan key count: ' || to_char(key_count));end;/执行结果如下： SQL> set serveroutput onSQL> declare 2 key_count int; 3 begin 4 key_count := 0; 5 dbms_repair.dump_orphan_keys( 6 schema_name => 'JINGYU', 7 object_name => 'IDX_T_TEST_1', 8 object_type => dbms_repair.index_object, 9 repair_table_name => 'REPAIR_TABLE', 10 orphan_table_name => 'ORPHAN_KEY_TABLE', 11 key_count => key_count 12 ); 13 dbms_output.put_line('orphan key count: ' || to_char(key_count)); 14 end; 15 /orphan key count: 3PL/SQL procedure successfully completed.这样当之后执行完SKIP_CORRUPT_BLOCKS操作后，就可以重新建立索引了（对每个索引都要执行DUMP_ORPHAN_KEYS过程）。 3.5 使用skip_corrupt_blocks过程来跳过坏块
执行skip_corrupt_blocks过程，使后续DML操作跳过坏块： begin dbms_repair.skip_corrupt_blocks ( schema_name => 'JINGYU', object_name => 'T_TEST', object_type => dbms_repair.table_object, flags => dbms_repair.skip_flag );end;/执行结果： SQL> select count(1) from jingyu.t_test;select count(1) from jingyu.t_test *ERROR at line 1:ORA-01578: ORACLE data block corrupted (file # 6, block # 3893)ORA-01110: data file 6: '/opt/app/oracle/datafile/dbs_d_Jingyu01.dbf'SQL> begin 2 dbms_repair.skip_corrupt_blocks ( 3 schema_name => 'JINGYU', 4 object_name => 'T_TEST', 5 object_type => dbms_repair.table_object, 6 flags => dbms_repair.skip_flag 7 ); 8 end; 9 /PL/SQL procedure successfully completed.SQL> select count(1) from jingyu.t_test; COUNT(1)---------- 73.6 重建freelist
如果不想使用CTAS方式重建表而仍是在原表上修复，则需要重建对象的Freelist，防止这个数据块以后被加到freelist中。使用下面的方法： declarebegin dbms_repair.rebuild_freelists ( schema_name => 'JINGYU', object_name => 'T_TEST', object_type => dbms_repair.table_object );end;/这里实际已知坏块不在freelist中，所以不需要执行，执行会报错如下错误： SQL> declare 2 begin 3 dbms_repair.rebuild_freelists ( 4 schema_name => 'JINGYU', 5 object_name => 'T_TEST', 6 object_type => dbms_repair.table_object 7 ); 8 end; 9 /declare*ERROR at line 1:ORA-10614: Operation not allowed on this segmentORA-06512: at "SYS.DBMS_REPAIR", line 401ORA-06512: at line 33.7 重建索引
目前索引和数据块仍然存在不一致，必须要重建索引： --以id=4为例，索引和数据块依然存在不一致：SQL> select * from jingyu.t_test where id = 4;no rows selectedSQL> select id from jingyu.t_test where id = 4; ID---------- 4--重建索引，不能采用rebuild，只能drop后再create。因为rebuild数据源来自索引：--测试rebuild发现的确还存在不一致：SQL> alter index jingyu.idx_t_test_1 rebuild;Index altered.SQL> select id from jingyu.t_test where id = 4; ID---------- 4--先drop再create index，确认一致：SQL> drop index jingyu.idx_t_test_1;Index dropped.SQL> create index jingyu.idx_t_test_1 on jingyu.t_test(id);Index created.SQL> select id from jingyu.t_test where id = 4;no rows selected当然，如果此时使用dbv检查数据文件，依然是有坏块的，上面所有操作只是跳过坏块，并没有解决。 [oracle@jyrac1 ~]$ dbv file=/opt/app/oracle/datafile/dbs_d_jingyu01.dbfDBVERIFY: Release 11.2.0.4.0 - Production on Wed Mar 22 17:29:42 2017Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.DBVERIFY - Verification starting : FILE = /opt/app/oracle/datafile/dbs_d_jingyu01.dbfPage 3893 is marked corruptCorrupt block relative dba: 0x01800f35 (file 6, block 3893)Bad check value found during dbv: Data in bad block: type: 6 format: 2 rdba: 0x01800f35 last change scn: 0x0000.003b68be seq: 0x1 flg: 0x06 spare1: 0x0 spare2: 0x0 spare3: 0x0 consistency value in tail: 0x68be0601 check value in block header: 0x6485 computed block checksum: 0xd398DBVERIFY - Verification completeTotal Pages Examined : 12800Total Pages Processed (Data) : 2512Total Pages Failing (Data) : 0Total Pages Processed (Index): 989Total Pages Failing (Index): 0Total Pages Processed (Other): 9025Total Pages Processed (Seg) : 0Total Pages Failing (Seg) : 0Total Pages Empty : 273Total Pages Marked Corrupt : 1Total Pages Influx : 0Total Pages Encrypted : 0Highest block SCN : 3907507 (0.3907507)善后工作（与数据块恢复无关）：
养成一个习惯，做任何实验，如果对实验环境改动较大，建议实验完毕后，尽量恢复到正常状态，避免今后测试其他案例时现修复环境。
我这里就是把实验环境恢复(6号文件恢复为原来的ASM存储上): RMAN> list copy of datafile 6;using target database control file instead of recovery catalogList of Datafile Copies=======================Key File S Completion Time Ckp SCN Ckp Time ------- ---- - --------------- ---------- ---------------18 6 A 22-MAR-17 3895505 22-MAR-17 Name: +DATA1/jyzhao/datafile/dbs_d_jingyu.268.939306177 Tag: TAG20170322T14225616 6 A 22-MAR-17 3817798 22-MAR-17 Name: /opt/app/oracle/datafile/dbs_d_Jingyu01.dbf14 6 A 22-MAR-17 3817798 22-MAR-17 Name: +FRA1/jyzhao/datafile/dbs_d_jingyu.368.939306031 Tag: TAG20170322T142027RMAN> switch datafile 6 to copy;datafile 6 switched to datafile copy "+DATA1/jyzhao/datafile/dbs_d_jingyu.268.939306177"RMAN> recover datafile 6;Starting recover at 22-MAR-17allocated channel: ORA_DISK_1channel ORA_DISK_1: SID=143 instance=jyzhao1 device type=DISKstarting media recoverymedia recovery complete, elapsed time: 00:00:01Finished recover at 22-MAR-17RMAN> alter database open;database opened至此，已完成数据块恢复实例的整个实验。 此外，针对坏块问题，还有一种方式是设置10231 event，具体可参考：
|
免费注册
发表于 2017-05-05 17:18