Oracle – 第26页 – Ludatou's data life

Oracle Truncate table原理剖析二：从truncate结果看待恢复

总结一下前面，首先是段头块，它指向了L2块，L2块指向了L1块，而L1块则指向了我们真实的物理数据块。那么做了truncate操作，它到底做了什么鬼？这里需要测试一下，查看如下测试引入：

SQL> select OBJECT_NAME,OBJECT_ID,DATA_OBJECT_ID from dba_objects where OBJECT_NAME='A';

OBJECT_NAME                     OBJECT_ID DATA_OBJECT_ID
------------------------------ ---------- --------------
A                                   75722          75722

我们先来看一下对象，当我们创建对象的之后，OBJECT_ID和data_object_id都会是一样的，但是当我们发生truncate之后，我们的object_id不会变，而data_object_id则会变掉。

SQL> truncate table a;
Table truncated.

SQL> select OBJECT_NAME,OBJECT_ID,DATA_OBJECT_ID from dba_objects where OBJECT_NAME='A';

OBJECT_NAME                     OBJECT_ID DATA_OBJECT_ID
------------------------------ ---------- --------------
A                                   75722          75727

这里可以看到Truncate表之后，data_object_id从75722变成了75727。分别看一下段头块，L2位图块，L1位图块，数据块，这个ID是否有变化。分别从检查块130,129,224,225

BBED> set block 130
        BLOCK#          130

BBED> dump /v offset 272 count 20
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 130     Offsets:  272 to  291  Dba:0x00000000
-------------------------------------------------------
 cf270100 00000010 80004001 08000000 l ......@.....
 00000000                            l .....

BBED> set block 129
BLOCK#          129

BBED> dump /v offset 104 count 20
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 129     Offsets:  104 to  123  Dba:0x00000000
-------------------------------------------------------
 cf270100 01000000 00000000 80004001 l ..........@.
 05000100                            l ....

BBED> set block 128
        BLOCK#          128

BBED>  dump /v offset 192 count 10
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 128     Offsets:  192 to  201  Dba:0x00000000
-------------------------------------------------------
 cf270100 e6151400 0000              l ..

BBED> set block 144
        BLOCK#          144

BBED> dump /v offset 192 count 10
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 144     Offsets:  192 to  201  Dba:0x00000000
-------------------------------------------------------
 ca270100 de300f00 0000              l ..

BBED> set block 160
        BLOCK#          160

BBED> dump /v offset 192 count 10
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 160     Offsets:  192 to  201  Dba:0x00000000
-------------------------------------------------------
 ca270100 de300f00 0000              l ..

BBED> set block 176
        BLOCK#          176

BBED> dump /v offset 192 count 10
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 176     Offsets:  192 to  201  Dba:0x00000000
-------------------------------------------------------
 ca270100 de300f00 0000              l ..

BBED> set block 192
        BLOCK#          192

BBED> dump /v offset 192 count 10
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 192     Offsets:  192 to  201  Dba:0x00000000
-------------------------------------------------------
 ca270100 de300f00 0000              l ..

 <16 bytes per line>

BBED> set block 208
        BLOCK#          208

BBED> dump /v offset 192 count 10
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 208     Offsets:  192 to  201  Dba:0x00000000
-------------------------------------------------------
 ca270100 de300f00 0000              l ..

 <16 bytes per line>

BBED> set block 224
        BLOCK#          224

BBED> dump /v offset 192 count 10
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 224     Offsets:  192 to  201  Dba:0x00000000
-------------------------------------------------------
 ca270100 de300f00 0000              l ..

BBED> set block 225
BLOCK#          225

BBED> dump /v offset 24 count 10
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 225     Offsets:   24 to   33  Dba:0x00000000
-------------------------------------------------------
 ca270100 90121400 0000              l ......

通过对各个块的dump，发现段头和L2位图块的data_obj_id已经发生了改变，从ca270100变成了cf270100，而只有第一个L1发生了变化，数据块则没有发生改变。其实到了这里,MDATA如何快速恢复truncate数据的原理非常清楚了.

那么如果从手工修复的角度来看的话，要处理的东西就比较多了，这方面可以参考第三节的内容。
也可以参考hellodba的《移花接木————利用Oracle表扫描机制恢复被Truncate的数据》

Data access tuning Data model MDATA Oracle 数据技术 | Guang Cai Li | 2015-08-26

Oracle Truncate table原理剖析一：ASSM的三级位图实践解析

assm三级位图可以说是dba的基础技能知识了，这里用测试的方法验证下三级位图的原理。

1.建立实验环境所需要的表

SQL> create tablespace a1 datafile '/oracle/app/oracle/oradata/ora11/a1.dbf' size 20m;
Tablespace created.
SQL> create user a1 identified by a1 default tablespace a1;
User created.
SQL> grant dba to a1;
Grant succeeded.
SQL> connect a1/a1
Connected.
SQL> create table a as select * from dba_tables;
Table created.

实验环境建立完成之后，就需要摸清楚我们的这个段A的位图及数据块分布情况，我们不直接从视图里面查，这里我们考虑需要通过bbed的方式从数据块中获取位图及数据块分布情况。

2.段头块/L3位图块指向了哪些L2位图块

段由哪些区间构成？这个信息我们需要从段头块中获取出来。当你创建一个段后，即使你没有往里面插入任何数据，系统也是会预先分配一些区给你的。所以段头块是那个块，我们可以通过dba_segments查询出来。就算truncate了这个段，我们仍然能够从dba_segments中查询到段头的信息。

SQL> select HEADER_FILE,HEADER_BLOCK from dba_segments where SEGMENT_NAME='A' and owner='A1';
HEADER_FILE HEADER_BLOCK
----------- ------------
          5          130

找到了段头块，就可以用bbed挖掘下信息。

BBED> set filename '/oracle/app/oracle/oradata/ora11/a1.dbf'
        FILENAME        /oracle/app/oracle/oradata/ora11/a1.dbf
BBED> set block 130
        BLOCK#          130
BBED> dump /v offset 0 count 20
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 130     Offsets:    0 to   19  Dba:0x00000000
-------------------------------------------------------
 23a20000 82004001 d8321400 00000104 l #.@.....
 848d0000                            l ....

这里我们可以看到段头块的第一个offset是23。那么我们的段头块指向的L2位图块在offset 5192的位置。这里请记住段头块的标示是23。

BBED> dump /v offset 5192 count 100
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 130     Offsets: 5192 to 5291  Dba:0x00000000
-------------------------------------------------------
 81004001 00000000 00000000 00000000 l ..@.............
 00000000 00000000 00000000 00000000 l ................
 00000000 00000000 00000000 00000000 l ................
 00000000 00000000 00000000 00000000 l ................
 00000000 00000000 00000000 00000000 l ................
 00000000 00000000 00000000 00000000 l ................
 00000000                            l ....

从这里我们既可以找到我们的L2位图块，81004001，这里只有1个L2块，因为后面都是00000000(空)，因为涉及到操作系统字节序的问题，这里需要转换换成01400081。转换后我们可以使用下列查询找到文件号和块号。

SQL> select dbms_utility.data_block_address_file(to_number('01400081','xxxxxxxx')) as fileno,dbms_utility.data_block_address_block(to_number('01400081','xxxxxxxx')) as blockno from dual;

    FILENO    BLOCKNO
---------- ----------
         5        129

3.L2位图块指向了哪些L1位图块
接下来我们可以继续读我们的L2位图块来寻找我们的L1位图块。可以看到L2的第一个offset是21。请记住L2位图块的标示是21。

BBED> set block 129
        BLOCK#          129

BBED> dump /v offset 0 count 20
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 129     Offsets:    0 to   19  Dba:0x00000000
-------------------------------------------------------
 21a20000 81004001 d4321400 00000604 l !.@.....
 48a10000                            l H

L2指向L1数据块的位置从offset 116开始。到哪儿结束需要看后面有没有00000000(空)

BBED> dump /v offset 116 count 100
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 129     Offsets:  116 to  215  Dba:0x00000000
-------------------------------------------------------
 80004001 01000100 90004001 01000100 l ..@.......@.....
 a0004001 01000100 b0004001 01000100 l ........
 c0004001 01000100 d0004001 01000100 l ........
 e0004001 05000100 00000000 00000000 l ............
 00000000 00000000 00000000 00000000 l ................
 00000000 00000000 00000000 00000000 l ................
 00000000                            l ....

从dump出来的地方我们来看，前面是一个地址，后面跟着是01000100，比较规律，大概7组之后就变成00000000(空)了。跟上面一样因为字节序的问题，这里我们需要将80004001转换成01400080。然后我们通过下列查询得到了区块的位置。而后面的01000100，前面的01则这个L1下面的块全部填满，无空数据块，后面的01则代表这个块是instance 1产生的。而最后的一个05000100，05则代表着这个L1下面还有空块，可以插入。而后面的01我们说过代表着是instance。如果这个系统是个rac的系统，节点2也插入了数据，那么这里就会显示05000200。

SQL> select dbms_utility.data_block_address_file(to_number('01400080','xxxxxxxx')) as fileno,dbms_utility.data_block_address_block(to_number('01400080','xxxxxxxx')) as blockno from dual
     union
     select dbms_utility.data_block_address_file(to_number('01400090','xxxxxxxx')) as fileno,dbms_utility.data_block_address_block(to_number('01400090','xxxxxxxx')) as blockno from dual
     union
     select dbms_utility.data_block_address_file(to_number('014000a0','xxxxxxxx')) as fileno,dbms_utility.data_block_address_block(to_number('014000a0','xxxxxxxx')) as blockno from dual
     union
     select dbms_utility.data_block_address_file(to_number('014000b0','xxxxxxxx')) as fileno,dbms_utility.data_block_address_block(to_number('014000b0','xxxxxxxx')) as blockno from dual
     union
     select dbms_utility.data_block_address_file(to_number('014000c0','xxxxxxxx')) as fileno,dbms_utility.data_block_address_block(to_number('014000c0','xxxxxxxx')) as blockno from dual
     union
     select dbms_utility.data_block_address_file(to_number('014000d0','xxxxxxxx')) as fileno,dbms_utility.data_block_address_block(to_number('014000d0','xxxxxxxx')) as blockno from dual
     union
     select dbms_utility.data_block_address_file(to_number('014000e0','xxxxxxxx')) as fileno,dbms_utility.data_block_address_block(to_number('014000e0','xxxxxxxx')) as blockno from dual;
    FILENO    BLOCKNO
---------- ----------
         5        128
         5        144
         5        160
         5        176
         5        192
         5        208
         5        224

7 rows selected.

通过上述查询，我们找到了7个L1块的信息。
4.L1位图块指向了哪些数据块
前面我们查到了我们的L2块上指向的L1块，并且清楚的知道哪个L1下面是满的，哪个L1下面还有空闲块。我们就从拿最后一个有空闲块的L1位图块进行分析。

BBED> set block 224
        BLOCK#          224

BBED> dump /v offset 0 count 10
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 224     Offsets:    0 to    9  Dba:0x00000000
-------------------------------------------------------
 20a20000 e0004001 d432              l  .@.
<16 bytes per line>

可以看到L1的第一个offset是20。请记住L1位图块的标示是20。
L1指向数据块的位置从offset 204开始。到哪儿结束需要看后面有没有00000000(空)

BBED> dump /v offset 204 count 80
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 224     Offsets:  204 to  283  Dba:0x00000000
-------------------------------------------------------
 e0004001 08000000 00000000 e8004001 l ........08000000 08000000 00000000 00000000 l ................
 00000000 00000000 00000000 00000000 l ................
 00000000 00000000 00000000 00000000 l ................
 00000000 00000000 00000000 00000000 l ................

大家可以看到这里的值是e0004001,08000000,00000000，下一组值是e8004001,08000000,08000000，然后面就是00000000(空)。
这两个的意思是告诉我们L1指向数据块的起始位置，比如e0004001，就是文件5，块224，也就是它自己本身。08000000就代表着这个块后面的连续7个块都是的。而e8004001,08000000,08000000，就是文件5，块232，08000000就代表着这个块后面的连续7个块也是的。而最后一个08000000则代表着offset，这里我们可以不用去管它。所以这里我们就能够知道我们的L1块下面具体的数据块有：
224(它本身),225,226,227,228,229,230,231,232,233,234,235,236,237,238,239。来用下列语句查证一下。

SQL> select distinct dbms_rowid.rowid_block_number(rowid) from a order by 1
................ ................ ................ ................ ................
                                 220
                                 221
                                 222
                                 223
                                 225
                                 226
                                 227
                                 228
                                 229
                                 230
                                 231
                                 232
                                 233

可以看到223后面直接就是225，直接此处跳空，这是因为我们的224是L1位图块，后面紧跟着我们刚刚说的225,226,227,228,229,230,231,232,233。但是问题是，这里看不到后面的234到239？这是因为234到239还是空闲没有格式化过的块，但是它已经被L1锁定了。那么我们的L1能不能看到这些情况呢？我们可以观察offset 396。

BBED> dump /v offset 396 count 50
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 224     Offsets:  396 to  445  Dba:0x00000000
-------------------------------------------------------
 11111111 11000000 00000000 00000000 l ................
 00000000 00000000 00000000 00000000 l ................
 00000000 00000000 00000000 00000000 l ................
 0000                                l ..

这里可以看到的是11111111,11000000。那么这个代表什么意思呢？如果这个块是full的话，就是1，是unformatted的话就是0，正好和我们前面看到的吻合。

node参考：
Buddy Yuan《truncate》

MDATA Oracle Oracle恢复数据技术 | Guang Cai Li | 2015-08-20

现版本Mdata恢复工具在恢复oracle数据时候使用的考虑以及使用技巧

1.delete恢复的时候会把历史的delete操作未被重用的数据块部分的数据恢复出来，所以做delete恢复的时候需要考虑到这点，当然需要恢复的数据可以通过刷选出来

2.truncate恢复时候是可以选择是或者否恢复出delete的数据的，这点可以同通过contain的方式实现

3.lob inindex损坏的时候，lob的数据恢复就成了比较大的难题

4.坏块部分目前mdata没有做处理碰到坏块就异常退出程序，比如像dul在09年时候也未处理，当然现在的支持是比较好的。后续的mdata 4.0版本会对坏块做略过处理，并增加坏块评估统计的功能，mdata 4.0研发重点会在坏块的处理上

5.虽然目前我们已经有scan的功能，也可以直接通过block（1.4版本） scan的方式恢复出对应的数据，但是在asm中，这部分内容需要做优化和调整，现有的mdata3.6可以通过在asm file 1保存完好的情况下直接读asm disk恢复出datafile，功能类似amdu，（同时从asm直接恢复出表的功能我们也已经开发完毕，4.0中发布），如果file 1有损坏则在针对asm的disk做datafile的直接恢复时候做特殊处理，所以当前版本的scan建议就只用在非asm格式下的恢复。如果asm file 1还保存完好，那么也可以通过mdata3.6版本恢复出对应的数据文件.直接scan出datafile的功能是用在asm file 1损害的情况下，为了尽最大程度恢复数据的情况下使用。mdata后续的版本更新中会持续改善这类的支持。

6.恢复数据的scan tablespace小技巧
可以并行scan 扫描增加扫描速度；
可以对大的单表数据在unload的数据方式上选择dmp，这样的话在导入时候可以增加效率；
没事可以到ddl目录下逛逛，没准有发现。

当然了这个工具持续更新了一年，后续我和hc也会持续的更新，有任何问题也可以联系我和hc，在修复工具的使用问题上，非常欢迎大家联系我们。

MDATA Oracle Oracle恢复数据技术 | Guang Cai Li | 2015-08-18

由繁化简:快速解析asm disk header结构

在asm instance crash,特定的一些场景下无法启动asm，为了恢复数据或者其他需要则需要直接从disk中读取数据，此时asm disk的number则为必需获取的信息，特别是在一些不规范的disk命名环境，因此需要用kfed读取磁盘头依次获取信息。

在disk中

kfdhdb.dsknum 代表磁盘号
kfdhdb.grptyp 代表磁盘类型
kfdhdb.dskname 代表磁盘名字
kfdhdb.grpname 代表磁盘所在asm diskgroup 名字
kfdhdb.blksize 代表磁盘的块单元大小
kfdhdb.dsksize 代表磁盘的全部大小

因此识别asm disk所属的asm diskgroup number以及asm disk number只需要在用kfed read asm disk时候加上dsknum以及grpname来区分即可
例如

 kfed read /dev/oracleasm/disks/VOL01   | grep dsknum

或者写成批量处理的脚本，效率会更高。
通过此种方式找到0号磁盘的情况下，通过识别2号au的的file 1，就可以找到想恢复的文件了。

案例：

[oracle@oradb bin]$ kfed read /dev/oracleasm/disks/VOL01
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                            1 ; 0x002: KFBTYP_DISKHEAD
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                       0 ; 0x004: T=0 NUMB=0x0
kfbh.block.obj:              2147483648 ; 0x008: TYPE=0x8 NUMB=0x0
kfbh.check:                  3091711072 ; 0x00c: 0xb847c460
kfbh.fcn.base:                        0 ; 0x010: 0x00000000
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfdhdb.driver.provstr:    ORCLDISKVOL01 ; 0x000: length=13
kfdhdb.driver.reserved[0]:    810307414 ; 0x008: 0x304c4f56
kfdhdb.driver.reserved[1]:           49 ; 0x00c: 0x00000031
kfdhdb.driver.reserved[2]:            0 ; 0x010: 0x00000000
kfdhdb.driver.reserved[3]:            0 ; 0x014: 0x00000000
kfdhdb.driver.reserved[4]:            0 ; 0x018: 0x00000000
kfdhdb.driver.reserved[5]:            0 ; 0x01c: 0x00000000
kfdhdb.compat:                168820736 ; 0x020: 0x0a100000
kfdhdb.dsknum:                        0 ; 0x024: 0x0000                  //这里是磁盘号。
kfdhdb.grptyp:                        3 ; 0x026: KFDGTP_HIGH             //这里是磁盘类型。
kfdhdb.hdrsts:                        3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname:                   VOL01 ; 0x028: length=5                //磁盘名称。
kfdhdb.grpname:                    DATA ; 0x048: length=4                //磁盘所属的磁盘组。
kfdhdb.fgname:                    VOL01 ; 0x068: length=5
kfdhdb.capname:                         ; 0x088: length=0
kfdhdb.crestmp.hi:             32942006 ; 0x0a8: HOUR=0x16 DAYS=0x1d MNTH=0x9 YEAR=0x7da
kfdhdb.crestmp.lo:            449689600 ; 0x0ac: USEC=0x0 MSEC=0x36e SECS=0x2c MINS=0x6
kfdhdb.mntstmp.hi:             32942646 ; 0x0b0: HOUR=0x16 DAYS=0x11 MNTH=0xa YEAR=0x7da
kfdhdb.mntstmp.lo:           1573951488 ; 0x0b4: USEC=0x0 MSEC=0x26 SECS=0x1d MINS=0x17
kfdhdb.secsize:                     512 ; 0x0b8: 0x0200
kfdhdb.blksize:                    4096 ; 0x0ba: 0x1000                    //这里指每个block的大小。
kfdhdb.ausize:                  1048576 ; 0x0bc: 0x00100000
kfdhdb.mfact:                    113792 ; 0x0c0: 0x0001bc80
kfdhdb.dsksize:                   10236 ; 0x0c4: 0x000027fc             //这里是磁盘的大小。
kfdhdb.pmcnt:                         2 ; 0x0c8: 0x00000002
kfdhdb.fstlocn:                       1 ; 0x0cc: 0x00000001
kfdhdb.altlocn:                       2 ; 0x0d0: 0x00000002
kfdhdb.f1b1locn:                      2 ; 0x0d4: 0x00000002
kfdhdb.redomirrors[0]:                0 ; 0x0d8: 0x0000
kfdhdb.redomirrors[1]:                0 ; 0x0da: 0x0000
kfdhdb.redomirrors[2]:                0 ; 0x0dc: 0x0000
kfdhdb.redomirrors[3]:                0 ; 0x0de: 0x0000
kfdhdb.dbcompat:              168820736 ; 0x0e0: 0x0a100000
kfdhdb.grpstmp.hi:             32942006 ; 0x0e4: HOUR=0x16 DAYS=0x1d MNTH=0x9 YEAR=0x7da
kfdhdb.grpstmp.lo:            448217088 ; 0x0e8: USEC=0x0 MSEC=0x1d0 SECS=0x2b MINS=0x6
kfdhdb.ub4spare[0]:                   0 ; 0x0ec: 0x00000000
kfdhdb.ub4spare[1]:                   0 ; 0x0f0: 0x00000000
kfdhdb.ub4spare[2]:                   0 ; 0x0f4: 0x00000000
kfdhdb.ub4spare[3]:                   0 ; 0x0f8: 0x00000000
kfdhdb.ub4spare[4]:                   0 ; 0x0fc: 0x00000000
kfdhdb.ub4spare[5]:                   0 ; 0x100: 0x00000000
kfdhdb.ub4spare[6]:                   0 ; 0x104: 0x00000000
kfdhdb.ub4spare[7]:                   0 ; 0x108: 0x00000000
kfdhdb.ub4spare[8]:                   0 ; 0x10c: 0x00000000
kfdhdb.ub4spare[9]:                   0 ; 0x110: 0x00000000
kfdhdb.ub4spare[10]:                  0 ; 0x114: 0x00000000
kfdhdb.ub4spare[11]:                  0 ; 0x118: 0x00000000
kfdhdb.ub4spare[12]:                  0 ; 0x11c: 0x00000000
kfdhdb.ub4spare[13]:                  0 ; 0x120: 0x00000000
kfdhdb.ub4spare[14]:                  0 ; 0x124: 0x00000000
kfdhdb.ub4spare[15]:                  0 ; 0x128: 0x00000000
kfdhdb.ub4spare[16]:                  0 ; 0x12c: 0x00000000
kfdhdb.ub4spare[17]:                  0 ; 0x130: 0x00000000
kfdhdb.ub4spare[18]:                  0 ; 0x134: 0x00000000
kfdhdb.ub4spare[19]:                  0 ; 0x138: 0x00000000
kfdhdb.ub4spare[20]:                  0 ; 0x13c: 0x00000000
kfdhdb.ub4spare[21]:                  0 ; 0x140: 0x00000000
kfdhdb.ub4spare[22]:                  0 ; 0x144: 0x00000000
kfdhdb.ub4spare[23]:                  0 ; 0x148: 0x00000000
kfdhdb.ub4spare[24]:                  0 ; 0x14c: 0x00000000
kfdhdb.ub4spare[25]:                  0 ; 0x150: 0x00000000
kfdhdb.ub4spare[26]:                  0 ; 0x154: 0x00000000
kfdhdb.ub4spare[27]:                  0 ; 0x158: 0x00000000
kfdhdb.ub4spare[28]:                  0 ; 0x15c: 0x00000000
kfdhdb.ub4spare[29]:                  0 ; 0x160: 0x00000000
kfdhdb.ub4spare[30]:                  0 ; 0x164: 0x00000000
kfdhdb.ub4spare[31]:                  0 ; 0x168: 0x00000000
kfdhdb.ub4spare[32]:                  0 ; 0x16c: 0x00000000
kfdhdb.ub4spare[33]:                  0 ; 0x170: 0x00000000
kfdhdb.ub4spare[34]:                  0 ; 0x174: 0x00000000
kfdhdb.ub4spare[35]:                  0 ; 0x178: 0x00000000
kfdhdb.ub4spare[36]:                  0 ; 0x17c: 0x00000000
kfdhdb.ub4spare[37]:                  0 ; 0x180: 0x00000000
kfdhdb.ub4spare[38]:                  0 ; 0x184: 0x00000000
kfdhdb.ub4spare[39]:                  0 ; 0x188: 0x00000000
kfdhdb.ub4spare[40]:                  0 ; 0x18c: 0x00000000
kfdhdb.ub4spare[41]:                  0 ; 0x190: 0x00000000
kfdhdb.ub4spare[42]:                  0 ; 0x194: 0x00000000
kfdhdb.ub4spare[43]:                  0 ; 0x198: 0x00000000
kfdhdb.ub4spare[44]:                  0 ; 0x19c: 0x00000000
......

Grid and Cluster Oracle Oracle恢复数据技术 | Guang Cai Li | 2015-08-18

asm metadata相关的v$视图与x$视图之间的关系

关于v$视图的定义我们都知道可以通过以下的方式获取:

select * from v$fixed_view_definition where view_name like '%ASM%';
select * from v$fixed_table where name like 'X$KF%';

这里我列出ASM中metadata相关主要的v$视图与x$kf视图的关联信息:

Grid and Cluster Oracle 数据技术 | Guang Cai Li | 2015-08-16

Oracle - 26. page

Oracle Truncate table原理剖析二：从truncate结果看待恢复

Oracle Truncate table原理剖析一：ASSM的三级位图实践解析

现版本Mdata恢复工具在恢复oracle数据时候使用的考虑以及使用技巧

由繁化简:快速解析asm disk header结构

asm metadata相关的v$视图与x$视图之间的关系

Oracle 恢复工具 Mdata 5.0.1 版本发布

近期文章

分类目录

扫码关注微信公众号:Oracle运维那些事获取定期发布的数据库运维的有趣事情!

近期活动

Oracle 恢复工具 Mdata 5.0.1 版本发布

近期文章

分类目录

扫码关注微信公众号:Oracle运维那些事 获取定期发布的数据库运维的有趣事情!

近期活动

扫码关注微信公众号:Oracle运维那些事获取定期发布的数据库运维的有趣事情!