
Oracle 数据库的运行不可避免的会遇到各种各样的错误,就比如数据表出现坏块,此时,你这张表的数据就无法访问了,有什么好的办法可以恢复呢?
什么,你没有遇到过?😱
😏 那就祝你不久的将来遇到,哈哈开个玩笑~ 玩归玩,闹归闹,经验必须要老到!👍🏻
一、介绍今天就给大家讲讲怎么处理数据表的坏块情况!🎉
对于 Oracle 数据块物理损坏 的情形,通常可以分为两种情况:
有备份,通过 RMAN 恢复
无备份,通过 DBMS_REPAIR 修复
1、RMAN有备份的情况下,这是很理想的情形,我们可以直接通过 RMAN 块介质恢复(BLOCK MEDIA RECOVERY)功能来完成受损块的恢复。
这里我是不建议恢复整个数据库或者数据库文件来修复这些少量受损的数据块,有点浪费时间。
可参考官方文档:Block Media Recovery with RMAN
2、DBMS_REPAIR那如果没有任何备份怎么办? (PS:备份大于一切!)
我们可以使用 Oracle 自带的 DBMS_REPAIR 包来实现修复。
📢 注意: 使用 DBMS_REPAIR 包来修复,并非完全恢复,而是标记坏块,然后不对其进行访问,这部分被标记的数据也就丢失了,这是无法避免的。
可参考MOS文档:DBMS_REPAIR SCRIPT (Doc ID 556733.1)
二、实战环境准备1、环境安装可参考我的一键安装脚本:Oracle 数据库一键安装,从未如此简单
cd /Volumes/DBA/voracle/github/single_db vagrant up vagrant ssh
创建表空间:
create tablespace eason datafile '/oradata/orcl/eason.dbf' size 1g autoextend on;
创建用户:
create user eason identified by eason default tablespace eason; grant dba to eason;
创建测试表:
create table hyj as select * from dba_objects;
创建表索引:
create index i_hyj on hyj(object_id);
查看表段上的相关信息:
select segment_name , header_file , header_block, 换购网blocks from dba_segments where segment_name ='HYJ';
查出包含行记录的数据块:
select distinct dbms_rowid.rowid_block_number(rowid) from eason.hyj order by 1; DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) ------------------------------------ 1411 1412 1413 ... ... ... 2665 2666 2667 1232 rows selected.
select * from dba_extents where segment_name='HYJ';
📢 注意: 这里看到 HEADER_BLOCK 和 BLOCK_ID 不一致,其实一个 segment 的第一个区的第一个块是 FIRST LEVEL BITMAP BLOCK,第二个块是 SECOND LEVEL BITMAP BLOCK,这两个块是用来管理 free block 的,第三个块是 PAGETABLE SEGMENT HEADER,这个块才是 segment 里的 HEADER_BLOCK。
4、RMAN 备份首先,我们先做一个全备份,用来演示 RMAN 修复坏块!
run { allocate channel c1 device type disk; allocate channel c2 device type disk; crosscheck backup; crosscheck archivelog all; sql"alter system switch logfile"; delete noprompt expired backup; delete noprompt obsolete device type disk; backup database include current controlfile format '/backup/backlv_%d_%T_%t_%s_%p'; backup archivelog all DELETE INPUT; release channel c1; release channel c2; }
破坏 1468、1688、2468 数据块的内容:
dd if=/dev/zero of=/oradata/orcl/eason.dbf bs=8192 conv=notrunc seek=1468 count=1 dd if=/dev/zero of=/oradata/orcl/eason.dbf bs=8192 conv=notrunc seek=1688 count=1 dd if=/dev/zero of=/oradata/orcl/eason.dbf bs=8192 conv=notrunc seek=2468 count=1
清除 buffer cache 的内容:
alter system flush buffer_cache;
再次查询表 hyj,此时查询已经报错,发现有坏块:
select * from eason.hyj;
当然,也可以使用 bbed 进行坏块模拟!
6、坏块检查下面再介绍几种发现坏块的方式:
(1)使用 DBV 检查当前文件的坏块:
dbv file=/oradata/orcl/eason.dbf blocksize=8192;
使用 DBV检查,新闻资讯同样发现了坏块!
(2)使用 rman 检查数据库坏块:
## 检查对应的数据文件 backup check logical validate datafile 5; ## 检查当前数据库 backup validate check logical database;
结合 V$DATABASE_BLOCK_CORRUPTION 视图查看,更加方便:
select * from V$DATABASE_BLOCK_CORRUPTION;
使用 RMAN 检查后,同样发现了坏块!
(3)通过数据库的告警日志也可以发现报错:
(4)通过报错信息快速查找对应的坏表,依次填写数据文件 ID 5 和 坏块 ID 1468:
SELECT tablespace_name, segment_type, owner, segment_name FROM dba_extents WHERE file_id = &fileid and &blockid between block_id AND block_id + blocks - 1;
实验环境准备完毕,下面开始实战!
三、实战演示今天,我打算使用上述介绍的 2 种方式来演示!
1、RMAN 修复由于我们之前已经备份了,因此直接使用备份来恢复坏块:
blockrecover datafile 5 block 1468;
blockrecover datafile 5 block 1688,2468;
使用同样的方式,依次修复坏块 1688,2468,修复成功后,查询已恢复正常!
再次检查坏块情况:
backup validate check logical database; select * from V$DATABASE_BLOCK_CORRUPTION;
坏块已经都被恢复,并且数据没有丢失!
2、DBMS_REPAIR 修复首先,依然使用 dd 先模拟坏块:
dd if=/dev/zero of=/oradata/orcl/eason.dbf bs=8192 conv=notrunc seek=3333 count=1 dd if=/dev/zero of=/oradata/orcl/eason.dbf bs=8192 conv=notrunc seek=3368 count=1 dd if=/dev/zero of=/oradata/orcl/eason.dbf bs=8192 conv=notrunc seek=4000 count=1
在没有备份的前提下,我们就无法做到无损修复坏块了,需要损失对应坏块的数据。
(1)创建 repair 表,用于记录需要被修复的表:
begin dbms_repair.admin_tables ( table_name => 'REPAIR_TABLE', table_type => dbms_repair.repair_table, action => dbms_repair.create_action, tablespace => 'USERS'); end; /
(2)创建 Orphan Key 表,用于记录在表块损坏后那些孤立索引,也就是指向坏块的那些索引 :
begin dbms_repair.admin_tables ( table_name => 'ORPHAN_KEY_TABLE', table_type => dbms_repair.orphan_table, action => dbms_repair.create_action, tablespace => 'USERS'); end; /
(3)检查坏块,检测对象上受损的情形,并返回受损块数为 3:
declare num_corrupt int; begin num_corrupt := 0; DBMS_REPAIR.CHECK_OBJECT ( schema_name =>'EASON', object_name =>'HYJ', repair_table_name =>'REPAIR_TABLE', corrupt_count =>num_corrupt); dbms_output.put_line('number corrupt:'