[20210423]dump sga映像的对应块.txt

--//昨天的测试。链接 http://blog.itpub.net/267265/viewspace-2769217/，转储的sga映像自然没有数据文件的文件头。
--//尝试加一个文件头看看是否能正常读取，另外再次提醒使用dd要小心。

1.环境：
SYS@book> @ 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.问题提出:
SYS@book> alter system dump datafile '/u01/tmp/book/60c00000' block 51844;
alter system dump datafile '/u01/tmp/book/60c00000' block 51844
*
ERROR at line 1:
ORA-01565: error in identifying file '/u01/tmp/book/60c00000'
ORA-27048: skgfifi: file header information is invalid
Additional information: 9
--//无法识别文件头，不能做正常转储。

3.顺便增加1个文件头看看：
$ cd /u01/tmp/book
$ cp 60c00000 60c00000.ORG
$ dd if=/mnt/ramdisk/book/users01.dbf of=/u01/tmp/book/60c00000 bs=8192 count=1 conv=notrunc
1+0 records in
1+0 records out
8192 bytes (8.2 kB) copied, 6.3288e-05 seconds, 129 MB/s
--//注意一定要加conv=notrunc,不然输出文件会截断!!

SYS@book> alter system dump datafile '/u01/tmp/book/60c00000' block 51844;
alter system dump datafile '/u01/tmp/book/60c00000' block 51844
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [krhcvt_filhdr_v10_01], [], [], [], [], [], [], [], [], [], [], []
--//文件头也没有。

$ dd if=/mnt/ramdisk/book/users01.dbf of=/u01/tmp/book/60c00000 bs=8192 count=2 conv=notrunc
2+0 records in
2+0 records out
16384 bytes (16 kB) copied, 8.1974e-05 seconds, 200 MB/s

SYS@book> alter system dump datafile '/u01/tmp/book/60c00000' block 51844;
System altered.

--//OK,现在可以了。查看转储，太长截取其中一部分:
Block header dump:  0x004000d1
 Object id on Block? Y
 seg/obj: 0xa  csc: 0x03.175941c3  itc: 2  flg: O  typ: 1 - DATA
     fsl: 0  fnx: 0x0 ver: 0x01

 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0005.009.00000078  0x00c01cfe.0015.28  C---    0  scn 0x0000.0001cd26
0x02   0x000a.002.00004a8f  0x00c00a75.0e4f.01  --U-    1  fsc 0x0000.175941c5
bdba: 0x004000d1
data_block_dump,data header at 0x7fe5f2d6125c
===============
tsiz: 0x1fa0
hsiz: 0x6c
pbl: 0x7fe5f2d6125c
     76543210
flag=--------
ntab=2
nrow=43
frre=-1
fsbo=0x6c
fseo=0xc50
avsp=0x1590
tosp=0x1590
0xe:pti[0]  nrow=21 offs=0
0x12:pti[1] nrow=22 offs=21
0x16:pri[0] offs=0x1f8a
0x18:pri[1] offs=0x1f45
0x1a:pri[2] offs=0x1e95
0x1c:pri[3] offs=0x1e3c
0x1e:pri[4] offs=0x1de2
0x20:pri[5] offs=0x1d87
0x22:pri[6] offs=0x1d31
0x24:pri[7] offs=0x1c7e
0x26:pri[8] offs=0x1c18
....

tab 1, row 6, @0xc50
tl: 171 fb: -CH-FL-- lb: 0x0  cc: 22 cki: 5
col  0: [ 6]  53 59 53 54 45 4d
col  1: [ 2]  c1 02
col  2: [16]  32 44 35 39 34 45 38 36 46 39 33 42 31 37 41 31
col  3: [ 1]  80
col  4: [ 2]  c1 04
col  5: [ 7]  78 71 08 18 0c 26 29
col  6: [ 7]  78 75 02 03 11 28 3c
col  7: [ 7]  78 74 08 18 0c 2e 2b
col  8: [ 7]  78 71 08 18 0d 08 05
col  9: [ 1]  80
col 10: *NULL*
col 11: [ 2]  c1 02
col 12: *NULL*
col 13: *NULL*
col 14: [ 1]  80
col 15: [ 1]  80
col 16: [22]
 44 45 46 41 55 4c 54 5f 43 4f 4e 53 55 4d 45 52 5f 47 52 4f 55 50
col 17: *NULL*
col 18: [ 1]  80
col 19: *NULL*
col 20: *NULL*
col 21: [62]
 53 3a 31 45 39 42 43 34 30 38 42 37 44 39 36 44 34 39 35 45 30 30 39 38 46
 31 45 37 30 46 41 45 42 37 30 36 35 42 43 32 30 33 42 30 33 30 34 39 44 34
 38 37 37 32 38 34 34 33 46 42 34 31
..
end_of_block_dump

--//53 59 53 54 45 4d = SYSTEM
--//32 44 35 39 34 45 38 36 46 39 33 42 31 37 41 31 = 2D594E86F93B17A1
--//53 3a 31 45 39 42 43 34 30 38 42 37 44 39 36 44 34 39 35 45 30 30 39 38 46 = S:1E9BC408B7D96D495E0098F
--//31 45 37 30 46 41 45 42 37 30 36 35 42 43 32 30 33 42 30 33 30 34 39 44 34 = 1E70FAEB7065BC203B03049D4
--//38 37 37 32 38 34 34 33 46 42 34 31                                        = 87728443FB41
--//与前面的测试能对上。

--//再次尝试使用bbed观察，这次bbed能识别文件头的OS，文件头块，基本不会出现问题。这次输入block=51844没有再出现问题。

BBED> set dba 100,51844
        DBA             0x1900ca84 (419482244 100,51844)

BBED> x /rcncnnttttncnnnnnccnnncct *kdbr[27]
rowdata[0]                                  @3244
----------
flag@3244: 0x6c (KDRHFL, KDRHFF, KDRHFH, KDRHFC)
lock@3245: 0x00
cols@3246:   22
ckix@3247:    5

col    0[6] @3248: SYSTEM
col    1[2] @3255: 1
col   2[16] @3258: 2D594E86F93B17A1
col    3[1] @3275: 0
col    4[2] @3277: 3
col    5[7] @3280: 2013-08-24 11:37:40
col    6[7] @3288: 2017-02-03 16:39:59
col    7[7] @3296: 2016-08-24 11:45:42
col    8[7] @3304: 2013-08-24 12:07:04
col    9[1] @3312: 0
col   10[0] @3314: *NULL*
col   11[2] @3315: 1
col   12[0] @3318: *NULL*
col   13[0] @3319: *NULL*
col   14[1] @3320: 0
col   15[1] @3322: 0
col  16[22] @3324: DEFAULT_CONSUMER_GROUP
col   17[0] @3347: *NULL*
col   18[1] @3348: 0
col   19[0] @3350: *NULL*
col   20[0] @3351: *NULL*
col  21[62] @3352: S:1E9BC408B7D96D495E0098F1E70FAEB7065BC203B03049D487728443FB41

3.扩展知识点：
--//实际上转储数据块，仅仅数据库启动到nomount就可以。
SYS@book> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.

SYS@book> startup nomount
ORACLE instance started.
Total System Global Area  643084288 bytes
Fixed Size                  2255872 bytes
Variable Size             205521920 bytes
Database Buffers          427819008 bytes
Redo Buffers                7487488 bytes

SYS@book> alter system dump datafile '/u01/tmp/book/60c00000' block 51843;
System altered.

SYS@book> alter system dump datafile '/u01/tmp/book/60c00000' block 51844;
System altered.

--//所以我怀疑odu ，gdul之类的恢复工具，有可能就是利用这个特性dump数据块，当然这仅仅是我的猜测，也许完全不正确。