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

简介: [20171115]恢复数据文件块头4补充.txt --// 昨天做了恢复数据文件块头,通过备份文件直接取出文件块头,覆盖原来的数据块,然后修复. --//补充几点: --1.

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

--// 昨天做了恢复数据文件块头,通过备份文件直接取出文件块头,覆盖原来的数据块,然后修复.
--//补充几点:
--1.文件头损坏,无法使用rman的块恢复功能.
--2.文件头损坏,dbv检查发现都是坏块.我感觉主要文件块头损坏,dbv无法定位其它剩下的块.

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 database filesperset=1 format '/home/oracle/backup/20171114_%U';
--//注:这是我个人主张的备份方式设置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. 昨天测试发现文件头是最后备份的.

RMAN> list backupset 206;
List of Backup Sets
===================
BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
206     Full    5.69M      DISK        00:00:00     2017-11-14 15:09:38
        BP Key: 207   Status: AVAILABLE  Compressed: NO  Tag: TAG20171114T150933
        Piece Name: /home/oracle/backup/20171114_fcsji7ti_1_1
  List of Datafiles in backup set 206
  File LV Type Ckp SCN    Ckp Time            Name
  ---- -- ---- ---------- ------------------- ----
  6       Full 13278016603 2017-11-14 15:09:38 /mnt/ramdisk/book/tea01.dbf

--//确定备份片文件是/home/oracle/backup/20171114_fcsji7ti_1_1.
--//我的数据库名=BOOK.

$  strings -t d /home/oracle/backup/20171114_fcsji7ti_1_1  | grep BOOK
   8223 OBOOK
5955615 OBOOK

--//8223/8192=1.0037841796875
--//5955615/8192=727.0037841796875

--//可以确定包含BOOK在备份文件集的第1块,第727块.

BBED> set filename '/home/oracle/backup/20171114_fcsji7ti_1_1'
        FILENAME        /home/oracle/backup/20171114_fcsji7ti_1_1

BBED> set block 1
        BLOCK#          1

BBED> map /v
File: /home/oracle/backup/20171114_fcsji7ti_1_1 (100)
Block: 1                                     Dba:0x19000001
------------------------------------------------------------
BBED-00400: invalid blocktype (19)

BBED> map
File: /home/oracle/backup/20171114_fcsji7ti_1_1 (100)
Block: 727                                   Dba:0x190002d7
------------------------------------------------------------
Data File Header

struct kcvfh, 860 bytes                    @0

ub4 tailchk                                @8188

--//可以确定文件头备份在727块中.从这里还可以看出文件头实际上最后写入备份文件集中的.

$ ls -l /home/oracle/backup/20171114_fcsji7ti_1_1
-rw-r----- 1 oracle oinstall 5971968 2017-11-14 15:09:38 /home/oracle/backup/20171114_fcsji7ti_1_1

--// 备份文件占 5971968/8192=729块(从0开始记数,最大728).基本上倒数第2块就是文件头的备份.(注:对于filesperset=1的备份集)

3.换一句话讲如果restore恢复,是否是最后写入文件头(对于备份集合,估计copy的方式不是这样).

--//还是做测试验证我这个判断是否正确.
SYS@book> startup mount ;
ORACLE instance started.
Total System Global Area  634732544 bytes
Fixed Size                  2255792 bytes
Variable Size             197133392 bytes
Database Buffers          427819008 bytes
Redo Buffers                7524352 bytes
Database mounted.

--//选择恢复数据文件2,主要tea01.dbf太小了.估计测不出来.
$ mv sysaux01.dbf sysaux01.dbf_x

--//建立脚本如下:
$ cat dump_head.sh
#! /bin/bash
for i in $(seq 1000)
do
#   echo $i
    xxd -c16 -g 2 -s 8192 -l 16 /mnt/ramdisk/book/sysaux01.dbf >> /tmp/sysaux_head.txt 2>/dev/null
    sleep 0.1
done

--//首先启动dump_tea_head.sh脚本,session 1:
$ .  dump_tea_head.sh &

--//启动恢复,session 2:
RMAN> restore datafile 2;
Starting restore at 2017-11-15 11:38:52
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=300 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=1 device type=DISK
allocated channel: ORA_DISK_3
channel ORA_DISK_3: SID=14 device type=DISK

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00002 to /mnt/ramdisk/book/sysaux01.dbf
channel ORA_DISK_1: reading from backup piece /home/oracle/backup/20171114_f8sji7te_1_1
channel ORA_DISK_1: piece handle=/home/oracle/backup/20171114_f8sji7te_1_1 tag=TAG20171114T150933
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
Finished restore at 2017-11-15 11:38:54
--//1秒完成恢复. 数据文件2的备份集是/home/oracle/backup/20171114_f8sji7te_1_1

$ fg
. dump_head.sh
^C

$ head -10 /tmp/sysaux_head.txt
0002000: 00a2 0000 0100 8000 0000 0000 0000 0105  ................
0002000: 00a2 0000 0100 8000 0000 0000 0000 0105  ................
0002000: 00a2 0000 0100 8000 0000 0000 0000 0105  ................
0002000: 00a2 0000 0100 8000 0000 0000 0000 0105  ................
0002000: 00a2 0000 0100 8000 0000 0000 0000 0105  ................
0002000: 00a2 0000 0100 8000 0000 0000 0000 0105  ................
0002000: 00a2 0000 0100 8000 0000 0000 0000 0105  ................
0002000: 00a2 0000 0100 8000 0000 0000 0000 0105  ................
         ~~~~                               ~~~~
0002000: 0ba2 0000 0100 8000 0000 0000 0000 0104  ................
0002000: 0ba2 0000 0100 8000 0000 0000 0000 0104  ................
....

--//注意看下划线部分.

--//完成后通过bbed观察
BBED> p dba 2,1 kcvfh.kcvfhbfh
struct kcvfhbfh, 20 bytes                   @0
   ub1 type_kcbh                            @0        0x0b
   ub1 frmt_kcbh                            @1        0xa2
   ub1 spare1_kcbh                          @2        0x00
   ub1 spare2_kcbh                          @3        0x00
   ub4 rdba_kcbh                            @4        0x00800001
   ub4 bas_kcbh                             @8        0x00000000
   ub2 wrp_kcbh                             @12       0x0000
   ub1 seq_kcbh                             @14       0x01
   ub1 flg_kcbh                             @15       0x04 (KCBHFCKV)
   ub2 chkval_kcbh                          @16       0xbac4
   ub2 spare3_kcbh                          @18       0x0000

--//检查备份集的备份的文件头:

BBED> dump /v FILENAME '/home/oracle/backup/20171114_f9sji7te_1_1' block 82951 count 16 offset 0
File: /home/oracle/backup/20171114_f9sji7te_1_1 (202)
Block: 82951                             Offsets:    0 to   15                            Dba:0x32814407
-----------------------------------------------------------------------------------------------------------
0ba20000 87004000 00000000 00000104                                     l ......@.........
<32 bytes per line>

BBED> dump /v dba 2,1 count 16 offset 0
File: /mnt/ramdisk/book/sysaux01.dbf (2)
Block: 1                                 Offsets:    0 to   15                            Dba:0x00800001
-----------------------------------------------------------------------------------------------------------
0ba20000 01008000 00000000 00000104                                     l ................
<32 bytes per line>
 
--//很明显我的判断还是正确的,我觉得前面应该是"构造"出来的,写错文件头的开头部分kcvfhbfh.type_kcbh=00.最后在写入
--//正确的文件头.

--//我的第一感觉oracle这样设计有它一定道理.因为没有正确写入文件头,dbv检查报坏块.这个数据文件是"无用".
--//另外一个原因就是假设restore时发生中断,而这个时候文件头已经前期正常写入,很可能可以online该数据文件.

--//当然这些都是我个人的猜测,也许不对...^_^.

--// 修改为00看看.

BBED> assign  dba 2,1 kcvfh.kcvfhbfh.type_kcbh=0x00
BBED-00217: unable to assign: (0) is out of range (1, 74)

BBED> set dba 2,1
        DBA             0x00800001 (8388609 2,1)

BBED> help assign
ASSIGN[/x|d|u|o] <target spec>=<source spec>
<target spec> : [ DBA | FILE | FILENAME | BLOCK | OFFSET | symbol | *symbol ]
<source spec> : [ value | <target spec options> ]

BBED> assign   kcvfh.kcvfhbfh.type_kcbh=0x00
BBED-00217: unable to assign: (0) is out of range (1, 74)

--//无法这样修改
BBED> assign  dba 2,1 kcvfh.kcvfhbfh.type_kcbh=0x0b
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
ub1 type_kcbh                               @0        0x0b
--//说明assign语法没有问题.

BBED> modify /x 00 dba 2,1
File: /mnt/ramdisk/book/sysaux01.dbf (2)
Block: 1                                                    Offsets:    0 to   15                                               Dba:0x00800001
------------------------------------------------------------------------------------------------------------------------------------------------
00a20000 01008000 00000000 00000104
<64 bytes per line>

BBED> sum apply dba 2,1;
Check value for File 2, Block 1:
current = 0xbacf, required = 0xbacf

$ dbv file=/mnt/ramdisk/book/sysaux01.dbf

DBVERIFY: Release 11.2.0.4.0 - Production on Wed Nov 15 15:12:39 2017

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

DBVERIFY - Verification starting : FILE = /mnt/ramdisk/book/sysaux01.dbf
Page 1 is influx - most likely media corrupt
Corrupt block relative dba: 0x00800001 (file 2, block 1)
Fractured block found during dbv:
Data in bad block:
type: 0 format: 2 rdba: 0x00800001
last change scn: 0x0000.00000000 seq: 0x1 flg: 0x04
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x00000b01
check value in block header: 0xbacf
computed block checksum: 0x0

--//收尾
RMAN> recover datafile 2,6;

Starting recover at 2017-11-15 15:15:10
using channel ORA_DISK_1
using channel ORA_DISK_2
using channel ORA_DISK_3

starting media recovery

archived log for thread 1 with sequence 917 is already on disk as file /u01/app/oracle/archivelog/book/1_917_896605872.dbf
archived log for thread 1 with sequence 918 is already on disk as file /u01/app/oracle/archivelog/book/1_918_896605872.dbf
archived log for thread 1 with sequence 919 is already on disk as file /u01/app/oracle/archivelog/book/1_919_896605872.dbf
archived log for thread 1 with sequence 920 is already on disk as file /u01/app/oracle/archivelog/book/1_920_896605872.dbf
archived log for thread 1 with sequence 921 is already on disk as file /u01/app/oracle/archivelog/book/1_921_896605872.dbf
archived log file name=/u01/app/oracle/archivelog/book/1_917_896605872.dbf thread=1 sequence=917
archived log file name=/u01/app/oracle/archivelog/book/1_918_896605872.dbf thread=1 sequence=918
archived log file name=/u01/app/oracle/archivelog/book/1_919_896605872.dbf thread=1 sequence=919
media recovery complete, elapsed time: 00:00:01
Finished recover at 2017-11-15 15:15:11

RMAN> sql 'alter database open ';
sql statement: alter database open

--//补充修改kcvfh.kcvfh.kcvfhbfh=0x5的情况:
SYS@book> shutdown immediate ;
Database closed.
Database dismounted.
ORACLE instance shut down.


BBED> set dba 2,1
        DBA             0x00800001 (8388609 2,1)

BBED> assign kcvfh.kcvfhbfh.flg_kcbh=0x05
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
ub1 flg_kcbh                                @15       0x05 (KCBHFNEW, KCBHFCKV)

BBED> assign kcvfh.kcvfhbfh
BBED-00216: unable to assign: type mismatch between (kcvfhbfh, flg_kcbh)

BBED> p kcvfh.kcvfhbfh
struct kcvfhbfh, 20 bytes                   @0
   ub1 type_kcbh                            @0        0x0b
   ub1 frmt_kcbh                            @1        0xa2
   ub1 spare1_kcbh                          @2        0x00
   ub1 spare2_kcbh                          @3        0x00
   ub4 rdba_kcbh                            @4        0x00800001
   ub4 bas_kcbh                             @8        0x00000000
   ub2 wrp_kcbh                             @12       0x0000
   ub1 seq_kcbh                             @14       0x01
   ub1 flg_kcbh                             @15       0x05 (KCBHFNEW, KCBHFCKV)
                                                            ~~~~~~~~
   ub2 chkval_kcbh                          @16       0xcd44
   ub2 spare3_kcbh                          @18       0x0000

BBED> assign kcvfh.kcvfhbfh.flg_kcbh=0x04
ub1 flg_kcbh                                @15       0x04 (KCBHFCKV)

BBED> p kcvfh.kcvfhbfh
struct kcvfhbfh, 20 bytes                   @0
   ub1 type_kcbh                            @0        0x0b
   ub1 frmt_kcbh                            @1        0xa2
   ub1 spare1_kcbh                          @2        0x00
   ub1 spare2_kcbh                          @3        0x00
   ub4 rdba_kcbh                            @4        0x00800001
   ub4 bas_kcbh                             @8        0x00000000
   ub2 wrp_kcbh                             @12       0x0000
   ub1 seq_kcbh                             @14       0x01
   ub1 flg_kcbh                             @15       0x04 (KCBHFCKV)
   ub2 chkval_kcbh                          @16       0xcd44
   ub2 spare3_kcbh                          @18       0x0000

--//感觉KCBHFNEW 表示新块.

目录
相关文章
|
SQL Oracle 关系型数据库
[20171225]没有备份数据文件的恢复.txt
[20171225]没有备份数据文件的恢复.txt --//别人问的问题,增加了数据文件没有备份,如何恢复,实际上很简单,因为当前控制文件有记录建立时间只要从建立数据文件开始的 --//归档日志都存在恢复是没有任何问题的.
910 0
|
监控 Oracle 关系型数据库
[20171208]强制删除归档日志文件.txt
[20171208]强制删除归档日志文件.txt --//测试环境,产生日志太多,想强制删除. RMAN> delete archivelog all ; released channel: ORA_DISK_1 allocated channel: ORA...
1435 0
|
Oracle 关系型数据库 数据库管理
[20171115]恢复数据文件块头3补充.txt
[20171115]恢复数据文件块头3补充.txt --// 昨天做了恢复数据文件块头,通过备份文件直接取出文件块头,覆盖原来的数据块,然后修复. --//补充几点: --1.
1143 0
|
Oracle 关系型数据库 数据库
[20171122]恢复数据文件块头5.txt
[20171122]恢复数据文件块头5.txt --//前几天做了恢复数据文件块头,通过备份文件直接取出文件块头,覆盖原来的数据块,然后修复. --//今天测试使用image copy来恢复.
1123 0
|
Oracle 关系型数据库 数据库管理
[20161101]rman备份与数据文件变化7.txt
[20161101]rman备份与数据文件变化7.txt --//想象一下,如果备份文件时间很长,而这个时候数据文件大小发生了变化,oracle的备份如何解决这个问题呢? --//去年已经测试了建立备份集的情况,一直想做一次image copy的测试,一直脱,主要原因自己不想做这个测试.
1189 0
|
Oracle 关系型数据库 OLAP
[20171123]rman备份与数据文件变化6.txt
[20171123]rman备份与数据文件变化6.txt --//想象一下,如果备份文件时间很长,而这个时候数据文件大小发生了变化,oracle的备份如何解决这个问题呢? --//去年已经测试了建立备份集的情况,一直想做一次image copy的测试,一直脱,主要原因自己不想做这个测试.
792 0
|
Oracle 关系型数据库 数据库
[20171114]恢复数据文件块头2.txt
[20171114]恢复数据文件块头2.txt --//曾经写过一篇[20161111]数据库文件头的修复.txt,但是利用大小相似的数据文件头覆盖来恢复,那是属于特种恢复.
1082 0
|
SQL Oracle 关系型数据库
[20170627]使用TSPITR恢复表空间.txt
[20170627]使用TSPITR恢复表空间.txt --//RMAN提供了一种实现所谓TSPITR(Tablespace Point-In-Time Recovery)的技术,通过简单的一个语句,就可以在主库不停库(很吸引人) --//的情况下,利用备份集和连续的归档日志,实现表空间级别的定点恢复。
899 0
|
Oracle 关系型数据库 测试技术
[20170623]传输表空间补充测试.txt
[20170623]传输表空间补充测试.txt --//昨天测试了使用dblink+传输表空间,链接如下:http://blog.itpub.net/267265/viewspace-2141115/ --//今天补充测试看看加参数SQLFILE生成的脚本是什么内容.
1016 0
|
SQL Oracle 关系型数据库
[20170213]删除数据没有备份可以恢复吗.txt
[20170213]删除数据没有备份可以恢复吗.txt --别人问的问题,实际上只要当时建立数据文件时归档还在是可以恢复的. --还是通过测试来说明问题: 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING        ...
780 0