[20171122]恢复数据文件块头5.txt
--//前几天做了恢复数据文件块头,通过备份文件直接取出文件块头,覆盖原来的数据块,然后修复.
--//今天测试使用image copy来恢复.也是直接使用直接取出文件块头覆盖原来的数据块.
1.环境:
SCOTT@book> @ &r/ver1
PORT_STRING VERSION BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx 11.2.0.4.0 Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
2.建立测试环境:
CREATE TABLESPACE TEA DATAFILE
'/mnt/ramdisk/book/tea01.dbf' SIZE 40M AUTOEXTEND ON NEXT 16M MAXSIZE UNLIMITED
LOGGING
ONLINE
EXTENT MANAGEMENT LOCAL AUTOALLOCATE
BLOCKSIZE 8K
SEGMENT SPACE MANAGEMENT AUTO
FLASHBACK ON;
create table t1 tablespace tea as select rownum id ,lpad('A',32,'A') name from dual connect by level<=1e5;
--//建立rman备份:
backup as copy database format '/home/oracle/backup/%b';
--//注:这是我个人主张的备份方式设置filesperset=1,可惜我们团队一直不建议使用.这样备份文件显得太多了.实际上这样做与我后面的恢复有关.
create table t2 tablespace tea as select rownum id ,lpad('B',32,'B') name from dual connect by level<=1e5;
--//建立大小5M的表。注:说明一点,我是先做数据库备份,再建立t2表.
--//破坏数据文件头,注:数据文件头在数据文件的第2块.第1块OS头.
update t2 set name=lpad('C',32,'C') where id <=5;
alter system checkpoint;
alter system checkpoint;
alter system checkpoint;
rollback ;
update t2 set name=lpad('D',32,'D') where id between 5 and 9;
commit ;
alter database datafile 6 offline ;
$ dd if=/dev/zero of=/mnt/ramdisk/book/tea01.dbf count=1 bs=8192 conv=notrunc seek=1
1+0 records in
1+0 records out
8192 bytes (8.2 kB) copied, 3.8338e-05 seconds, 214 MB/s
2. 使用image copy恢复:
--//image copy 就简单了,因为一一对应.第一块就是文件头.
RMAN> list datafilecopy 30;
List of Datafile Copies
=======================
Key File S Completion Time Ckp SCN Ckp Time
------- ---- - ------------------- ---------- -------------------
30 6 A 2017-11-22 11:28:12 13279859806 2017-11-22 11:28:12
Name: /home/oracle/backup/tea01.dbf
Tag: TAG20171122T112746
--//通过dd ,还是bbed都是很相对简单.仅仅测试使用bbed.
--//dd if=/home/oracle/backup/tea01.dbf skip=1 of=/mnt/ramdisk/book/tea01.dbf seek=1 count=1 bs=8192 conv=notrunc
3.dbv 与rman检查:
RMAN> validate datafile 6;
Starting validate at 2017-11-22 11:37:15
using channel ORA_DISK_1
using channel ORA_DISK_2
using channel ORA_DISK_3
RMAN-06169: could not read file header for datafile 6 error reason 7
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of validate command at 11/22/2017 11:37:15
RMAN-06056: could not access datafile 6
$ dbv file=/mnt/ramdisk/book/tea01.dbf
DBVERIFY: Release 11.2.0.4.0 - Production on Wed Nov 22 11:39:20 2017
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
DBVERIFY - Verification starting : FILE = /mnt/ramdisk/book/tea01.dbf
Page 1 is marked corrupt
Corrupt block relative dba: 0x00000001 (file 0, block 1)
Completely zero block found during dbv:
Page 2 is marked corrupt
Corrupt block relative dba: 0x00000002 (file 0, block 2)
Bad header found during dbv:
Data in bad block:
type: 29 format: 2 rdba: 0x01800002
last change scn: 0x0003.178a94ee seq: 0x2 flg: 0x04
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x94ee1d02
check value in block header: 0xb859
computed block checksum: 0x0
Page 3 is marked corrupt
Corrupt block relative dba: 0x00000003 (file 0, block 3)
Bad header found during dbv:
Data in bad block:
type: 30 format: 2 rdba: 0x01800003
last change scn: 0x0003.178a94ee seq: 0x1 flg: 0x04
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x94ee1e01
check value in block header: 0x5952
computed block checksum: 0x0
--//一旦文件头损坏,检查根本不能通过.
RMAN> recover datafile 6 block 1;
Starting recover at 2017-11-22 11:49:34
using channel ORA_DISK_1
using channel ORA_DISK_2
using channel ORA_DISK_3
starting media recovery
media recovery complete, elapsed time: 00:00:00
Finished recover at 2017-11-22 11:49:34
RMAN> blockrecover datafile 6 block 1;
Starting recover at 2017-11-22 11:51:31
using channel ORA_DISK_1
using channel ORA_DISK_2
using channel ORA_DISK_3
starting media recovery
media recovery complete, elapsed time: 00:00:00
Finished recover at 2017-11-22 11:51:31
--//看上去ok实际上什么也没做.也就是文件头损坏,这样不行:
BBED> dump /v offset 0 filename '/mnt/ramdisk/book/tea01.dbf' block 1
File: /mnt/ramdisk/book/tea01.dbf (6)
Block: 1 Offsets: 0 to 63 Dba:0x01800001
-----------------------------------------------------------------------------------------------------------
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 l ................................
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 l ................................
<32 bytes per line>
--//依旧还是0000.
4.恢复:
BBED> map filename '/home/oracle/backup/tea01.dbf' block 1
File: /home/oracle/backup/tea01.dbf (206)
Block: 1 Dba:0x33800001
------------------------------------------------------------
Data File Header
struct kcvfh, 860 bytes @0
ub4 tailchk @8188
--//OK image copy block 1确实文件头.
BBED> help copy
COPY [ DBA | FILE | FILENAME | BLOCK ] TO [ DBA | FILE | FILENAME | BLOCK ]
BBED> copy filename '/home/oracle/backup/tea01.dbf' block 1 to filename '/mnt/ramdisk/book/tea01.dbf' block 1
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
File: /mnt/ramdisk/book/tea01.dbf (6)
Block: 1 Offsets: 0 to 63 Dba:0x01800001
------------------------------------------------------------------------------------------------------------------------------------------------
0ba20000 01008001 00000000 00000104 dfb50000 00000000 0004200b 6e21b74f 424f4f4b 00000000 bdb00000 00140000 00200000 06000300 00000000 00000000
<64 bytes per line>
--//唯独要记住一点操作前要看看offset是否是0,不要可能可能从某个中间位置开始copy.
BBED> show offset
OFFSET 0
BBED> dump /v offset 0 filename '/mnt/ramdisk/book/tea01.dbf' block 1
File: /mnt/ramdisk/book/tea01.dbf (6)
Block: 1 Offsets: 0 to 63 Dba:0x01800001
-----------------------------------------------------------------------------------------------------------
0ba20000 01008001 00000000 00000104 dfb50000 00000000 0004200b 6e21b74f l .......................... .n!.O
424f4f4b 00000000 bdb00000 00140000 00200000 06000300 00000000 00000000 l BOOK............. ..............
<32 bytes per line>
--//ok已经写入.
SCOTT@book> alter database datafile 6 online ;
alter database datafile 6 online
*
ERROR at line 1:
ORA-01113: file 6 needs media recovery
ORA-01110: data file 6: '/mnt/ramdisk/book/tea01.dbf'
RMAN> recover datafile 6;
Starting recover at 2017-11-22 11:45:16
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=94 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=106 device type=DISK
allocated channel: ORA_DISK_3
channel ORA_DISK_3: SID=119 device type=DISK
starting media recovery
media recovery complete, elapsed time: 00:00:00
Finished recover at 2017-11-22 11:45:17
SCOTT@book> alter database datafile 6 online ;
Database altered.
SCOTT@book> column name format a40
SCOTT@book> select * from t2 where id between 1 and 9;
ID NAME
---------- ----------------------------------------
1 BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
2 BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
3 BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
4 BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
5 DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
6 DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
7 DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
8 DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
9 DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
9 rows selected.
--//OK现在恢复正常了.
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/267265/viewspace-2147607/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/267265/viewspace-2147607/
扫一扫
81
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
