[20171122]恢复数据文件块头5.txt

[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现在恢复正常了.

时间： 2024-09-17 03:40:58

[20171122]恢复数据文件块头5.txt的相关文章

[20171114]恢复数据文件块头2.txt

[20171114]恢复数据文件块头2.txt --//曾经写过一篇[20161111]数据库文件头的修复.txt,但是利用大小相似的数据文件头覆盖来恢复,那是属于特种恢复. --//参考链接:http://blog.itpub.net/267265/viewspace-2128309/ --//不在正常操作范围,完全是不得已而为之.基本写那篇在一年之前,这次做一个带引号"常规恢复"看看. --//后记:纯属无聊,千万不要把这当作常规的恢复. 1.环境: SCOTT@book>

[20171115]恢复数据文件块头3补充.txt

[20171115]恢复数据文件块头3补充.txt --// 昨天做了恢复数据文件块头,通过备份文件直接取出文件块头,覆盖原来的数据块,然后修复. --//补充几点: --1.文件头损坏,无法使用rman的块恢复功能. --2.文件头损坏,dbv检查发现都是坏块.我感觉主要文件块头损坏,dbv无法定位其它剩下的块. 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING                    VERSION        BANNER --------

[20161031]rman备份与数据文件变化3.txt

[20161031]rman备份与数据文件变化3.txt --想象一下,如果备份文件时间很长,而这个时候数据文件大小发生了变化,oracle的备份如何解决这个问题呢? --前面我已经做了增大数据文件,参考链接:http://blog.itpub.net/267265/viewspace-2127386/ --这次测试减少数据文件大小看看. 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING                    VERSION        BAN

[20161031]rman备份与数据文件变化2.txt

[20161031]rman备份与数据文件变化2.txt --想象一下,如果备份文件时间很长,而这个时候数据文件大小发生了变化,oracle的备份如何解决这个问题呢? 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING                    VERSION        BANNER ------------------------------ -------------- -------------------------------------

[20161107]关于数据文件位图区.txt

[20161107]关于数据文件位图区.txt --上个星期写一篇 [20161104]File Space Bitmap Block损坏能修复吗?.txt 链接:http://blog.itpub.net/267265/viewspace-2127826/       http://www.itpub.net/thread-2071023-1-1.html --里面提到 --正常数据文件第1块OS.第2块是文件头,第3块开始-128块是位图区. --我文件很小,估计在1块里面: --8192*

[20161102]rman备份与数据文件变化5.txt

[20161102]rman备份与数据文件变化5.txt --想象一下,如果备份文件时间很长,而这个时候数据文件大小发生了变化,oracle的备份如何解决这个问题呢? --前面我已经做了增大数据文件,参考链接:http://blog.itpub.net/267265/viewspace-2127386/ --这次测试减少数据文件大小看看.相关链接: http://blog.itpub.net/267265/viewspace-2127424/ http://blog.itpub.net/2672

[20161031]rman备份与数据文件OS块.txt

[20161031]rman备份与数据文件OS块.txt --每个数据文件都有一个OS块,位于数据文件的第1块(也是0块).通过bbed无法访问: BBED> set dba 7,0 BBED-00205: illegal or out of range DBA (File 7, Block 0) BBED> set dba 7,1         DBA             0x01c00001 (29360129 7,1) BBED> dump File: /mnt/ramdis

[20151125]数据文件的unrecover.txt

[20151125]数据文件的unrecover.txt --前一阵子我给别人演示truncate的不完全恢复,结果非常难堪的遇到无法恢复的情况. --问题是我建立的数据库按照这个链接建立的. http://blog.itpub.net/267265/viewspace-1845062/ --而这样建立的数据库表空间example的属性NOLOGGING. CREATE TABLESPACE EXAMPLE DATAFILE   '/mnt/ramdisk/book/example01.dbf'

[20151028]理解数据文件offline+drop.txt

[20151028]理解数据文件offline+drop.txt --前几天做删除数据文件的恢复测试,自己在理解offline drop的方式存在错误,做一个记录: The ALTER DATABASE DATAFILE <datafile name> OFFLINE DROP command, is not meant to allow you to remove a datafile. What the command really means is that you are offlin