坏块修复

坏块分为物理坏块和逻辑坏块,前者是硬件问题产生,后者是oracle内部数据有问题,本次试验针对后者。


需要归档模式,步骤

复制代码
1create tablespace test 1m (table t1, insert)2 RMAN>backup tablespace test3 模拟坏块4 DBV5 ANALYZE TABLE6 RMAN BACKUP7EXP8 DBMS_REPAIR9 BLOCKRECOVER
复制代码

1,sys用户下创建表空间

SYS@jsce>create tablespace tbs1 datafile 'e:\tbs1.dbf' size 1m; --大小1M,容易填满(现在突然有疑惑:为什么要填满,才能制造坏块?)

在tbs1中创建表tb1,数据来源是scott.emp

SYS@jsce>create table tb1 tablespace tbs1 as select * from scott.emp;

双倍递增插入表tb1,来源也是其自己

SYS@jsce>insert into tb1 select * from tb1; --这里是select出来的东西插入到表,没有关键字values

已创建15行。

SYS@jsce>insert into tb1 select * from tb1;

已创建30行。

SYS@jsce>insert into tb1 select * from tb1;

已创建60行。




在插满之后,不要忘记commit,否则oracle不能shutdown,最后确认一下插入的数据量“15360”

》给表增加索引,后面查询有坏块之后,坏块带来损失的数据ORPHAN_TABLE;

SYS@jsce>create index i1 on tb1(ename);

索引已创建。

SYS@jsce>alter system checkpoint; --这一步是将插入的数据作检查点写入数据文件,下一步就要通过ultraedit修改数据文件,制造坏块。

系统已更改。

备注:如果表字段没有设置not null必输项,并且表字段很多,那么可以指定字段来插入一部分,比如emp表

insert into emp(empno,ename,sal) values(22,'sumsen',8900);

2,rman备份表空间tbs1,得到优良备份(下面还原使用)

RMAN> backup tablespace tbs1 tag=ok;--增加tag

3,shutdown之后,通过ultraedit修改数据文件 --修改的时候不要开头部,那里是数据文件名称,有可能导致oracle启动失败

修改,保存之后,数据文件目录会多出一个TBS1.DBF.bak,说明修改过了,不知道为何

启动oracle再次查询报错,坏块产生 --这里的select 是遇到第一个坏块就报错,因此如果有多个坏块,也是报出一个错误信息,需要用下面的REPAIR_TABLE查询所有的坏块。

4,用dbv检测

这里仅仅给出坏块数,没有给出坏块号和文件号

5,使用 ANALYZE TABLE

SYS@jsce>analyze table tb1 validate structure;

6,rman的备份和exp导出有坏块的表空间

exp导出sys下的

E:\Documents and Settings\xs>exp userid='sys/sys as sysdba' file=e:\exptbs1.dmp tablespaces=tbs1

导出表空间没有问题

导出表有坏块报错

rman提示超过坏块限制

通过设置坏块最大数来继续备份

RMAN> run{set maxcorrupt for datafile 3 to 10;backup tablespace tbs1 tag=bad;} 要写在一块,让rman知道是一个事务

因为最大坏块设置为了10,tbs1有两个坏块,可以通过备份

7,包DBMS_REPAIR

exec DBMS_REPAIR.ADMIN_TABLES('REPAIR_TABLE',1,1,'USERS');--表数据

exec DBMS_REPAIR.ADMIN_TABLES('ORPHAN_TABLE',2,1,'USERS');--索引数据

检查坏块:dbms_repair.check_object , 这里的schema_name是用户,比如我在sys下建立的表空间,这里就是sys,

object_name是表不是表空间(查询的时候报错也是通过select * from tb1)

declare
cc number;
begin
dbms_repair.check_object(schema_name => 'SYS',object_name => 'TB1',corrupt_count => cc);
dbms_output.put_line(a => to_char(cc)); --这里a=>不明不白,可以去掉
end;


看到这里用dbms_repair.check,检查的结果corrupt_count=2,有2个块损坏,和dbv的结果一致。
check完之后,在我们刚在创建的REPAIR_TABLE中查看块损坏详细信息:

复制代码
SELECTobject_name,       relative_file_id,       block_id,       marked_corrupt,       corrupt_description,       repair_description,       CHECK_TIMESTAMP  from repair_table;
复制代码

得到4个结果,不过就两个块(33,69),只是时间不一样,不解?

我们注意看MARKED_CORRUPT的值,这里经过check_object后,已经标识为TRUE了。(

》使用包的skip_corrupt_blocks过程来跳过坏块

exec dbms_repair.skip_corrupt_blocks(schema_name => 'SYS',object_name => 'TB1',flags => 1);

损失了15360-15020=340 条数据

》处理index上的无效键值;dump_orphan_keys

declare
cc number;
begin
dbms_repair.dump_orphan_keys(schema_name => 'SYS',object_name => 'I1',object_type => 2,
repair_table_name => 'REPAIR_TABLE',orphan_table_name => 'ORPHAN_TABLE',key_count => CC);
end;

之后查询数据,我们根据这个结果来考虑是否需要rebuild index(?)

和上面的损失数目一样

9  BLOCKRECOVER 恢复坏块--前提是坏块事先有备份

RMAN> blockrecover from tag=ok datafile 3 block 33,69;--必须要指定坏块号

之后查询tb1,恢复

这时候dbv检测也为0


18:10 更新,使用oracle内部事件

再次破坏了数据文件,可是查询时候仍然不报错,想到是前面执行了让oracle跳过坏块的过程

exec dbms_repair.skip_corrupt_blocks(schema_name => 'SYS',object_name => 'TB1',flags => 1);

直接将flag=>2

SELECT tablespace_name, segment_type, owner, segment_name
FROM dba_extents
WHERE file_id = 3
and 35 between block_id AND block_id + blocks - 1 --这里 35 between不懂

ALTER SYSTEM SET EVENTS='10231 trace name context forever,level 10' ;

之后

SQL> ALTER SYSTEM SET EVENTS='10231 trace name context off' ;

系统已更改。

删除表空间

SYS@jsce>drop tablespace tbs1 including contents and datafiles; --表空间物理文件也被删除

之后导入

演示省略。


你可能感兴趣的:(oracle,关键字,insert,create,修复)