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

[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数据块，当然这仅仅是我的猜测，也许完全不正确。