Oracle数据块损坏的恢复实例
测试环境：11.2.0.4
1.构建数据块损坏的测试环境
1.1 创建测试表
--Create Table t_test
conn jingyu/jingyu
drop table t_test purge;
create table t_test (id number, name char(2000));
--Insert data
insert 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 Index
create 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, id
from t_test
order by 1,2;
--这里对象占用块数的查询前后不匹配,与书中不符,但不影响实验,结果如下:
SQL> select blocks from user_tables where table_name = 'T_TEST';
BLOCKS
----------
5
SQL> 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 10
10 rows selected.
1.3 使用bbed工具模拟破坏6号数据文件的3893数据块
关于bbed的编译和使用可参考
1.3.1 准备bbed配置文件：
编辑/tmp/bbed.par参数配置文件
--编辑/tmp/bbed.par参数配置文件
blocksize=8192
listfile=/tmp/listfile.txt
mode=edit
--编辑/tmp/listfile.txt文件
SQL> select file#||' '||name||' '||bytes from v$datafile ;
FILE#||''||NAME||''||BYTES
--------------------------------------------------------------------------------
1 +DATA1/jyzhao/datafile/system.256.919998779 786432000
2 +DATA1/jyzhao/datafile/sysaux.257.919998781 891289600
3 +DATA1/jyzhao/datafile/undotbs1.258.919998783 125829120
4 +DATA1/jyzhao/datafile/users.259.919998789 13107200
5 +DATA1/jyzhao/datafile/undotbs2.264.919999419 78643200
6 +DATA1/jyzhao/datafile/dbs_d_jingyu.268.927427887 104857600
7 +DATA1/jyzhao/datafile/dbs_i_jingyu.270.927427891 31457280
8 +DATA1/jyzhao/datafile/soe.278.939295201 104857600
9 +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.txt
6 /opt/app/oracle/datafile/dbs_d_jingyu01.dbf 104857600
SQL> alter system checkpoint;
测试调用bbed正常：
--调用bbed
cd /tmp
bbed parfile=bbed.par
1.3.2 破坏数据文件6的3893数据块
[oracle@jyrac1 tmp]$ bbed parfile=bbed.par
Password:
BBED: Release 2.0.0.0.0 - Limited Production on Wed Mar 22 15:28:00 2017
Copyright (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> f
BBED-00212: search string not found
BBED> 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,3893
Warning: 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> exit
1.3.3 使用dbv检查文件
[oracle@jyrac1 tmp]$ dbv file=/opt/app/oracle/datafile/dbs_d_jingyu01.dbf
DBVERIFY: Release 11.2.0.4.0 - Production on Wed Mar 22 15:31:50 2017
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
DBVERIFY - Verification starting : FILE = /opt/app/oracle/datafile/dbs_d_jingyu01.dbf
Page 3893 is marked corrupt
Corrupt 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: 0xd398
DBVERIFY - Verification complete
Total Pages Examined : 12800
Total Pages Processed (Data) : 2512
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 989
Total Pages Failing (Index): 0
Total Pages Processed (Other): 9025
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 273
Total Pages Marked Corrupt : 1
Total Pages Influx : 0
Total Pages Encrypted : 0
Highest 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-17
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=148 instance=jyzhao1 device type=DISK
channel ORA_DISK_1: restoring block(s)
channel ORA_DISK_1: specifying block(s) to restore from backup set
restoring blocks of datafile 00006
channel ORA_DISK_1: reading from backup piece +FRA1/jyzhao/backupset/2017_03_22/nnndf0_tag20170322t123922_0.463.939299963
channel ORA_DISK_1: piece handle=+FRA1/jyzhao/backupset/2017_03_22/nnndf0_tag20170322t123922_0.463.939299963 tag=TAG20170322T123922
channel ORA_DISK_1: restored block(s) from backup piece 1
channel ORA_DISK_1: block restore complete, elapsed time: 00:00:01
starting media recovery
media recovery complete, elapsed time: 00:00:04
Finished 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 4
UNDOTBS1 3 3
SYSAUX 2 2
SYSTEM 1 1
UNDOTBS2 5 5
DBS_D_JINGYU 6 6
DBS_I_JINGYU 7 7
SOE 8 1024
DBS_D_JINGYU 9 9
9 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 1
TEMP 201 1
3.2 创建 REPAIR_TABLE 和 ORPHAN_KEY_TABLE
REPAIR_TABLE用来记录错误检查结果，ORPHAN_KEY_TABLE用来记录表坏块中记录在索引中对应键值。
--通过如下存储过程创建 REPAIR_TABLE 和 ORPHAN_KEY_TABLE
--Repair Table
declare
begin
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 Table
declare
begin
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_TABLE
BEGIN
DBMS_REPAIR.ADMIN_TABLES (
TABLE_NAME => 'REPAIR_TABLE',
TABLE_TYPE => dbms_repair.repair_table,
ACTION => dbms_repair.drop_action);
END;
/
--DROP ORPHAN_KEY_TABLE
BEGIN
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 on
declare
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 on
SQL> 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: 1
PL/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 TRUE
mark 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 TRUE
SQL> 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 on
declare
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 on
SQL> 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: 3
PL/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)
----------
7
3.6 重建freelist
如果不想使用CTAS方式重建表而仍是在原表上修复，则需要重建对象的Freelist，防止这个数据块以后被加到freelist中。使用下面的方法：
declare
begin
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 segment
ORA-06512: at "SYS.DBMS_REPAIR", line 401
ORA-06512: at line 3
3.7 重建索引
目前索引和数据块仍然存在不一致，必须要重建索引：
--以id=4为例，索引和数据块依然存在不一致：
SQL> select * from jingyu.t_test where id = 4;
no rows selected
SQL> 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.dbf
DBVERIFY: Release 11.2.0.4.0 - Production on Wed Mar 22 17:29:42 2017
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
DBVERIFY - Verification starting : FILE = /opt/app/oracle/datafile/dbs_d_jingyu01.dbf
Page 3893 is marked corrupt
Corrupt 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: 0xd398
DBVERIFY - Verification complete
Total Pages Examined : 12800
Total Pages Processed (Data) : 2512
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 989
Total Pages Failing (Index): 0
Total Pages Processed (Other): 9025
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 273
Total Pages Marked Corrupt : 1
Total Pages Influx : 0
Total Pages Encrypted : 0
Highest block SCN : 3907507 (0.3907507)
善后工作（与数据块恢复无关）：
养成一个习惯，做任何实验，如果对实验环境改动较大，建议实验完毕后，尽量恢复到正常状态，避免今后测试其他案例时现修复环境。
我这里就是把实验环境恢复(6号文件恢复为原来的ASM存储上):
RMAN> list copy of datafile 6;
using target database control file instead of recovery catalog
List 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: TAG20170322T142256
16 6 A 22-MAR-17 3817798 22-MAR-17
Name: /opt/app/oracle/datafile/dbs_d_Jingyu01.dbf
14 6 A 22-MAR-17 3817798 22-MAR-17
Name: +FRA1/jyzhao/datafile/dbs_d_jingyu.368.939306031
Tag: TAG20170322T142027
RMAN> 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-17
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=143 instance=jyzhao1 device type=DISK
starting media recovery
media recovery complete, elapsed time: 00:00:01
Finished recover at 22-MAR-17
RMAN> alter database open;
database opened
至此，已完成数据块恢复实例的整个实验。
此外，针对坏块问题，还有一种方式是设置10231 event，具体可参考：
Reference
- http://blog.itpub.net/4227/viewspace-68509/
- 张晓明. 大话Oracle RAC[M]. 人民邮电出版社, 2011.
Oracle数据块损坏的恢复实例的更多相关文章
- Oracle 数据块损坏与恢复具体解释
1.什么是块损坏: 所谓损坏的数据块,是指块没有採用可识别的 Oracle 格式,或者其内容在内部不一致. 通常情况下,损坏是由硬件故障或操作系统问题引起的.Oracle 数据库将损坏的块标识为&qu ...
- java.sql.SQLException: ORA-01578: ORACLE 数据块损坏问题解决办法
错误信息: java.sql.SQLException: ORA-01578: ORACLE 数据块损坏 (文件号 17, 块号 315703) ORA-01110: 数据文件 17: 'D:\ORA ...
- Oracle数据块损坏篇之10231内部事件
实验:某个分区数据块损坏,不完全恢复此分区表数据 背景:数据库没有有效备份,某个分区中有数据块损坏. 要求:最大限度恢复此分区数据. 环境:RHEL 6.4 + Oracle 11.2.0.4 1. ...
- ORA-01578: ORACLE 数据块损坏 (文件号 10, 块号 57896)ORA-01110: 数据文件 10: '/data/oradata/prod35.dbf'
https://community.oracle.com/thread/3540795 概述 ------------- 数据库坏块(corruption) 的类型可以按照坏块所属对象的不同,分为用户 ...
- ORA-01578: ORACLE 数据块损坏 (文件号 13, 块号 2415081) ORA-01110: 数据文件XXXXXX
1.使用DBV检查数据文件,在cmd执行:dbv file='E:\APP\ADMINISTRATOR\ORADATA\ORCL\USERS01.DBF' blocksize=8192:然后等待检测结 ...
- [转]Oracle数据块体系的详细介绍
数据块概述Oracle对数据库数据文件(datafile)中的存储空间进行管理的单位是数据块(data block).数据块是数据库中最小的(逻辑)数据单位.与数据块对应的,所有数据在操作系统级的最小 ...
- oracle数据块核心剖析
详见: http://blog.yemou.net/article/query/info/tytfjhfascvhzxcytp57 数据块(Oracle Data Blocks),本文简称为" ...
- 数据块损坏(block corruption)
分为物理损坏和逻辑损坏-物理损坏一般指数据块头部不可以访问.数据块校验值不合法,数据块格式不再是oracle承认的格式-逻辑损坏一般是在物理性结构完整的情况下,数据的内容在含义上不正确,比如保存了不允 ...
- Oracle 数据块
以emp表为例 SYS@ prod>select * from scott.emp; EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO --------- ...
随机推荐
- 学习计划——巩固基础+进阶练习
时间:2016/3/23---24 内容:如何用CSS进行网页布局 课程复习 目标:完成一个demo+完成一篇学习心得博客 时间:2016/3/25---26 内容:网页布局基础 课程复习 目标: ...
- c#中读取数据库bit布尔字段数据转换Int和bool时的错误
数据库里bit这个布尔类型的字段,非常实用,但是在c#里读取时,许多人喜欢犯一些错误,导致运行报错. 实际中,有效的正确读取方法只有以下两种: int xxx= Convet.ToInt16(read ...
- （@WhiteTaken）设计模式学习——单例模式
单例模式,个人理解就是,使用了这个模式,可以保证一个类只生成唯一的实例对象.就是在整个程序中,这个类只存在一个实例对象. GoF对单例模式的定义:保证一个类,只有一个实例存在,同时提供能对该实例加以访 ...
- 使用T4模板生成POCO类
为什么叫T4?因为简写为4个T. T4(Text Template Transformation Toolkit)是微软官方在VisualStudio 2008中开始使用的代码生成引擎.在 Visua ...
- contenteditable实现可编辑的HTML标签
最近工作中遇到了一个小问题,让我学到了新的标签属性--contenteditable. 我需要实现的是手机端界面,特别简单的一个页面,如下图: 在我脑海里第一时间想到的应该就是一个form表单然后里面 ...
- SpringMVC简版教程、部分功能
注:本文只用注解来实现 前言 SpringMVC各种流程图流程图(其他的各种流程图) jsp.xml.action彼此之间的关系,都如何使用 spring-mvc.xml如何配置,放在哪里? acti ...
- ABP入门系列（11）——编写单元测试
ABP入门系列目录--学习Abp框架之实操演练 源码路径:Github-LearningMpaAbp 1. 前言 In computer programming, unit testing is a ...
- node将excel内容转json
小颖分享的这个方法,前提是你已经安装了node,如果大家不知道自己是否安装过node可以打开cmd,然后执行:node -v,如果安装过,你会看到你安装的node版本号,如果没有安装请先安装node. ...
- InnoDB和Foreign KEY Constraints
InnoDB表中中Foreign Key定义 1. InnoDB允许a foreign key引用一个索引列或者索引组列. 2. InnoDB现在并不支持用户定义的分区表有foreign keys,这 ...
- 简单C程序，迷宫
#include<stdio.h> #include <stdlib.h> int visit(int, int); ][] = { {, , , , , , , , ,}, ...