分类: Oracle
2009-07-22 19:05:12
完整的恢复策略是恢复坏块最有效的方法。备份恢复策略至少应该包括定期的物理备份和日志归档。其中,归档日志还可以作为判别坏块产生原因的工具。
1、当出现坏块时,使用物理备份进行文件还原,在此文件基础上使用归档日志恢复至故障时间点。以Recovery Manager为例:
1)先offline受影响的数据文件,执行以下的语句:
ALTER DATABASE DATAFILE 'name_file' OFFLINE;
2)保留有坏块的数据文件,然后拷贝备份的数据文件。如果恢复的数据文件要求路径
不同,执行以下的语句:
ALTER DATABASE RENAME FILE 'old_name' TO 'new_name';
3)恢复数据文件,执行以下语句:
RECOVER DATAFILE 'name_of_file';
4) Online恢复后的数据文件,执行以下的语句:
ALTER DATABASE DATAFILE 'name_of_file' ONLINE;
2、在特定情况下(9i以上版本可用),还可以使用块级恢复,以加快恢复进程:
RMAN> blockrecover datafile n block nnnn;
3、通过ROWID RANGE SCAN保存数据
1)先取得坏块中ROW ID的最小值,执行以下的语句:
SELECT dbms_rowid.rowid_create(1,
DUAL;
2)取得坏块中的ROW ID的最大值,执行以下的语句:
SELECT dbms_rowid.rowid_create(1,
DUAL;
3)建议一个临时表存储那些没有坏块的数据,执行以下的语句:
CREATE TABLE salvage_table AS SELECT * FROM corrupt_tab Where 1=2;
4)保存那些不存在坏块的数据到临时表中,执行以下的语句:
INSERT INTO salvage_table SELECT /*+ ROWID(A) */ * FROM
INSERT INTO salvage_table SELECT /*+ ROWID(A) */ * FROM
5)根据临时表中的数据重建表,重建表上的索引,限制。
4、使用10231诊断事件,在做全表扫描的时候跳过坏块
可以在session级别设定:
ALTER SESSION SET EVENTS '10231 TRACE NAME CONTEXT FOREVER,
LEVEL 10';
也可以在数据库级别上设定,在初始化参数中加入:event="10231 trace name
context forever, level 10",然后重启数据库。
然后从存在坏块的表中取出不存在坏块的数据,执行以下的语句:
CREATE TABLE salvage_emp AS SELECT * FROM corrupt_table;
最后rename生成的corrupt_table为原来表的名字,并重建表上的索引和限制。
5、使用dbms_repair包进行恢复
使用dbms_repair标记有坏块的表,在做全表扫描的时候跳过坏块,执行以下的
语句:
Execute
DBMS_REPAIR.SKIP_CORRUPT_BLOCKS('
然后使用exp工具或者createtable as select的方法取出没有坏块数据,然后
重建表,表上的索引和限制。
6、UNDO表空间坏块
1) dump undoheader(如果数据库不能open用event 1015升成trace文件,本案例的情况)找到活动事务(状态为10)和对应的undo dba地址和使用的回滚段:
SQL>alter system dump undo header "_SYSSMU22$";
SQL>alter system dump undo header "_SYSSMU27$";
或者:
ALTER SYSTEM SET event="10015 trace name context forever, level 10"
SCOPE=SPFILE;
index state cflags wrap# uel scn dba
parent-xid nub
stmt_num
------------------------------------------------------------------------------------------------
0x11 10 0x90 0x5a1a0 0x0007 0x000b.4a936c82 0x0140d7bf
0x0000.000.00000000 0x00000001 0x00000000 0x0000
……
Recovering rollback segment _SYSSMU27$
Recovering rollback segment _SYSSMU22$
SQL> select dbms_utility.data_block_address_file(21026751) "file",
2 dbms_utility.data_block_address_block(21026751) "block"
3 from dual;
file block
---------- ----------
5 55231
2) dump回滚段内容得到相关活动事物对应的对象以便以后进行处理(也可以数据库启动后查询系统表来判断 select owner,segment_name from dba_segments where segment_name='PENDING_TRANS$';):
SQL> alter system dump datafile 5 block55231;
********************************************************************************
UNDO BLK:
xid: 0x0016.010.0005a635 seq: 0x3696 cnt: 0x42 irb: 0x42 icl: 0x0 flg: 0x0000
*-----------------------------
* Rec #0x42 slt: 0x10 objn: 17674(0x0000450a) objd: 17674 tblspc: 12(0x0000000c)
* Layer: 10 (Index) opc: 22 rci 0x41
Undo type: Regular undo Last buffer split: No
Temp Object: No
Tablespace Undo: No
rdba: 0x00000000
*-----------------------------
3) 设置隐含参数跳过相应回滚段:
_offline_rollback_segments= _SYSSMU22$, _SYSSMU27$
4)启动数据库,删除offline的回滚段并处理活动事物对应的对象:
drop rollback segemnt "_SYSSMU22$";
drop rollback segemnt "_SYSSMU27$";
处理活动事务相关的对象(rebuild index,exchange partition,drop
table)等。
在没有完整备份恢复策略的情况下,可以使用应急手段进行恢复,但过程较为
复杂且风险较大。
完整备份恢复策略需要合理规划和相应的资源投入。
数据库坏块问题原因复杂,破坏性大。但完整的备份恢复策略,经常性的检查,有效的故障识别以及对应的恢复手段,可以帮助用户最大限度的应对数据库坏块问题所带来的风险。
http://space.itpub.net/464838/