oracle坏块修复处理#ocp试验#

cf2000

　　坏块分为物理坏块和逻辑坏块，前者是硬件问题产生，后者是oracle内部数据有问题，本次试验针对后者。
　　
需要归档模式，步骤



1 create tablespace test 1m (table t1, insert)
2 RMAN>backup tablespace test
3 模拟坏块
4 DBV
5 ANALYZE TABLE
6 RMAN BACKUP
7 EXP
8 DBMS_REPAIR
9 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中查看块损坏详细信息：




SELECT object_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; --表空间物理文件也被删除
　　之后导入
　　演示省略。