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 --------- ...
随机推荐
- CXF_Spring_Rest
一.接口类 <PRE class=java name="code">@Path("/rest_HelloWorld") public interfa ...
- gulp源码解析（三）—— 任务管理
上篇文章我们分别对 gulp 的 .src 和 .dest 两个主要接口做了分析,今天打算把剩下的面纱一起揭开 —— 解析 gulp.task 的源码,了解在 gulp4.0 中是如何管理.处理任务的 ...
- 计算机程序的思维逻辑 (66) - 理解synchronized
上节我们提到了多线程共享内存的两个问题,一个是竞态条件,另一个是内存可见性,我们提到,解决这两个问题的一个方案是使用synchronized关键字,本节就来讨论这个关键字. 用法 synchroniz ...
- 学习ui-router
ui-router的学习 在单页面应用中要把各个分散的视图给组织起来是通过路由机制来实现的.Angular原始的路由机制靠ngRoute提供,通过hash和history来实现的,可以检测浏览器是否支 ...
- DataAdapter&&DataSet 帮助理解小程序
// 2105/07/08 // DataAdapter&&DataSet using System; using System.Collections.Generic; using ...
- cloudbase-init 自动扩盘的副作用 - 每天5分钟玩转 OpenStack（154）
这是 OpenStack 实施经验分享系列的第 4 篇. cloudbase-init 的一项功能是自动扩展 windows 的 C 盘.比如 windows 镜像是 20G,在部署 instance ...
- .Net程序员学用Oracle系列(18)：PLSQL Developer 攻略
1.功能说明及使用技巧 1.1.对象浏览器 1.2.SQL 窗口 1.3.测试窗口 1.4.命令窗口 1.5.图表窗口 1.6.报告窗口 1.7.右键菜单 1.8.快速登录技巧 1.9.其它 2.总结 ...
- 开发过程中常用到的git命令
将git上项目下载到本地 1.将项目下载到本地 git clone (git项目地址) 2.进入项目文件夹中(cd 某文件夹) 切换到要使用的分支 git checkout develop 3.抓取远 ...
- 【openstack N版】——创建云主机
一.启动实例 1.1 已准备服务介绍 MySql:为各个服务提供数据存储. RabbitMQ:为各个服务之间通信提供交通枢纽. keystone:为各个服务之间通信提供认证和服务注册. Glance: ...
- 深入浅出Redis-Spring整合Redis
概述: 在之前的博客中,有提到过Redis 在服务端的一些相关知识,今天主要讲一下Java 整合Redis的相关内容. 下面是Jedis 的相关依赖: <dependency> <g ...