Data model

Oracle Truncate table原理剖析三：偷天换日也要找到你

如果说hellodba发明的truncate的手段恢复为移花接木，那么以下的手段可以称之为偷天换日，在此感谢伟翔同学的信息提供以及建议。

对于Truncate恢复，总结以下步骤：

1.遍历所有数据文件的数据块，寻找offset 1是23的(16进制)，23代表段头块，同时还要和相应的Data Object Id相同的，这个需要检索offset 272的位置。（直接sqlplus就可以实现了）
2.找到了段头块，我们就可以通过offset 5192寻找到我们的L2块。
3.找到了L2块，我们就可以通过offset 116找到所有的L1块。找到了L1块，我们就等于找到了数据块。
4.至此，我们就可以开始反向的构造段头块。
5.修改段头块、L2块和第一个L1块的Data Object Id.，同时在修改数据字典。
6.修改段头块的高水位信息。当然这里的高水位块的辨别，一定会是在最后一个Extents上，你可以设置到最后一个Extnets的最后一个块，这个信息的准备性其实无所谓，全表扫描的时候它一定会扫描这个块下面所有的块。
7.修改段头上的Extents信息。

而在这些之前对segment header 结构的熟悉是必须的。

测试truncate恢复过程如下：

首先恢复段头，L1,L2等object_data_id为原object_data_id

BBED> set block 130
        BLOCK#          130

BBED> modify /x ca offset 272
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 130              Offsets:  272 to  291           Dba:0x00000000
------------------------------------------------------------------------
 ca270100 00000010 80004001 08000000 00000000

BBED> set block 129
        BLOCK#          129

BBED> modify /x ca offset 104
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 129              Offsets:  104 to  123           Dba:0x00000000
------------------------------------------------------------------------
 ca270100 01000000 00000000 80004001 05000100

BBED> set block 128
        BLOCK#          128

BBED> modify /x ca offset 192
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 128              Offsets:  192 to  211           Dba:0x00000000
------------------------------------------------------------------------
 ca270100 e6151400 00000000 80004001 08000000

BBED> sum apply
Check value for File 0, Block 128:
current = 0x35a9, required = 0x35a9

还需要修改数据字典，否则会报错。

SQL> select * from a1.a;
select * from a1.a
                 *
ERROR at line 1:
ORA-08103: object no longer exists

SQL> update OBJ$ set DATAOBJ#= 75722 where OBJ#= 75722;
1 row updated.

SQL> commit;
Commit complete.

SQL> update TAB$ set DATAOBJ#=75722 where OBJ#=75722;
1 row updated.

SQL> commit;
Commit complete.

SQL> update  SEG$ set HWMINCR=75722 where FILE#=5 and BLOCK#=130; -- 这里的130为段头
1 row updated.

SQL> commit;
Commit complete.

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.

SQL> startup
ORACLE instance started.

Total System Global Area  839282688 bytes
Fixed Size                  2233000 bytes
Variable Size             511708504 bytes
Database Buffers          322961408 bytes
Redo Buffers                2379776 bytes
Database mounted.
Database opened.

SQL> select * from a1.a;
no rows selected

2.段头高水位信息恢复

修改了这些东西后，我们会发现数据还是没有。我们还需要修改一些信息。一个很重要的信息就是段头上的高水位信息。在Truncate之前，段头上会记载。前面2节内容在解析L1块的时候说明过：
可以看到223后面直接就是225，直接此处跳空，这是因为我们的224是L1位图块，后面紧跟着我们刚刚说的225,226,227,228,229,230,231,232,233。但是问题是，这里看不到后面的234到239？这是因为234到239还是空闲没有格式化过的块，但是它已经被L1锁定了。
所以我们现在的高水位的块是234，一般做全表扫描的查询就会查高水位以下(234)的块。我们来看下我们现在的高水位。

BBED> dump /v offset 48 count 16
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 130     Offsets:   48 to   63  Dba:0x00000000
-------------------------------------------------------
 00000000 03000000 08000000 83004001 l ..............@.

BBED> dump /v offset 92 count 16
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 130     Offsets:   92 to  107  Dba:0x00000000
-------------------------------------------------------
 00000000 03000000 08000000 83004001 l ..............@.

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

    FILENO    BLOCKNO
---------- ----------
         5        131

注意看这里的高水位是83004001，转换成文件号和块号，刚好是文件5块131。而前面的00000000，03000000，则代表着是扩展0，block 3，代表着高水位的位置。刚好是第一个extent的第三个块。128是L1，129是L2，130是段头块。而131则是第一个可以使用的数据块。所以这里记录了extent 0，block为3则代表了文件5的131号块。而08000000则代表了extent的大小，我们每个extents是由8个块组成的。
那在truncate之前，我们的高水位的块是文件5块234，我们从块128开始，每8个块是一个extent，234是第14个extent的第三个块。后面的6个块是没有插入数据的空块。这个在前面我dump 最后一个L1块得知。回顾一下，这里下面的块状态显示11111111 11000000。

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 ..

所以我们这个地方要把高水位从00000000 03000000 08000000 83004001修改成0d000000 02000000 08000000 ea004001。0d000000代表13，表明是第十四个扩展，02000000代表02，表明是第三个块开始，而08000000还是一样代表着这个扩展是8个块的大小，而ea004001则代表着文件5块234。

BBED> modify /x 0d offset 48
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 130              Offsets:   48 to   63           Dba:0x00000000
------------------------------------------------------------------------
 0d000000 03000000 08000000 83004001

BBED> modify /x 02 offset 52
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 130              Offsets:   52 to   67           Dba:0x00000000
------------------------------------------------------------------------
 02000000 08000000 83004001 00000000

BBED> modify /x ea offset 60
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 130              Offsets:   60 to   75           Dba:0x00000000
------------------------------------------------------------------------
 ea004001 00000000 00000000 00000000

BBED> dump /v offset 48 count 16
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 130     Offsets:   48 to   63  Dba:0x00000000
-------------------------------------------------------
 0d000000 02000000 08000000 ea004001 l ............
BBED> modify /x 0d offset 92
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 130              Offsets:   92 to  107           Dba:0x00000000
------------------------------------------------------------------------
 0d000000 03000000 08000000 83004001

BBED> modify /x 02 offset 96
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 130              Offsets:   96 to  111           Dba:0x00000000
------------------------------------------------------------------------
 02000000 08000000 83004001 00000000

BBED>  modify /x ea offset 104
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 130              Offsets:  104 to  119           Dba:0x00000000
------------------------------------------------------------------------
 ea004001 00000000 00000000 00000000

BBED> dump /v offset 92 count 16
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 130     Offsets:   92 to  107  Dba:0x00000000
-------------------------------------------------------
 0d000000 02000000 08000000 ea004001 l ............
BBED> sum apply
Check value for File 0, Block 130:
current = 0x8c54, required = 0x8c54

修改完成之后，刷新buffer cache，然后重新查询。

SQL> alter system flush buffer_cache;
System altered.
SQL> select count(1) from a1.a;
  COUNT(1)
----------
       142

3.Extents信息恢复
可以看到数据量不对，这是因为我们Truncate之后，在段头上只剩下了一个Extent的信息。而我们的Extents是有14个的，这需要我们在修改如下几个地方。Offset 264代表着我们Extents的数量，，这里修改成0e代表了14个extents。

BBED> modify /x 0e offset 264
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 130              Offsets:  264 to  363           Dba:0x00000000
------------------------------------------------------------------------
 0e000000 00000000 ca270100 00000010 80004001 08000000 88004001 08000000
 90004001 08000000 98004001 08000000 a0004001 08000000 a8004001 08000000
 b0004001 08000000 b8004001 08000000 c0004001 08000000 c8004001 08000000
 d0004001

修改完Extents的数量之后，还需要添加对应的Extents Map的信息。因为我们的Extents Map信息也被删除了。从我们的offset 280开始。

BBED> dump /v offset 280 count 100
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 130     Offsets:  280 to  379  Dba:0x00000000
-------------------------------------------------------
 80004001 08000000 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 ....

80004001 08000000这个Extents是我们第一个Extents。代表了文件5的块128。我们可以依次类推下列的信息出来。而08000000则代表有8个数据块构成一个Extents。

modify /x 8800 offset 288  modify /x 4001 offset 290  modify /x 08 offset 292
modify /x 9000 offset 296  modify /x 4001 offset 298  modify /x 08 offset 300
modify /x 9800 offset 304  modify /x 4001 offset 306  modify /x 08 offset 308
modify /x a000 offset 312  modify /x 4001 offset 314  modify /x 08 offset 316
modify /x a800 offset 320  modify /x 4001 offset 322  modify /x 08 offset 324
modify /x b000 offset 328  modify /x 4001 offset 330  modify /x 08 offset 332
modify /x b800 offset 336  modify /x 4001 offset 338  modify /x 08 offset 340
modify /x c000 offset 344  modify /x 4001 offset 346  modify /x 08 offset 348
modify /x c800 offset 352  modify /x 4001 offset 354  modify /x 08 offset 356
modify /x d000 offset 360  modify /x 4001 offset 362  modify /x 08 offset 364
modify /x d800 offset 368  modify /x 4001 offset 370  modify /x 08 offset 372
modify /x e000 offset 376  modify /x 4001 offset 378  modify /x 08 offset 380
modify /x e800 offset 384  modify /x 4001 offset 386  modify /x 08 offset 388

BBED> dump /v offset 280 count 128
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 130     Offsets:  280 to  407  Dba:0x00000000
-------------------------------------------------------
 80004001 08000000 88004001 08000000 l ..@.......@.....
 90004001 08000000 98004001 08000000 l ..@.......@.....
 a0004001 08000000 a8004001 08000000 l ........
 b0004001 08000000 b8004001 08000000 l ........
 c0004001 08000000 c8004001 08000000 l ........
 d0004001 08000000 d8004001 08000000 l ........
 e0004001 08000000 e8004001 08000000 l ........
 00000000 00000000 00000000 00000000 l ................

 <16 bytes per line>

当然这些Extents Map修改完成之后，我们还需要在添加Auxillary Map。从Offset 2736开始。

BBED> dump /v offset 2736 count 200
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 130     Offsets: 2736 to 2935  Dba:0x00000000
-------------------------------------------------------
80004001 83004001 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 00000000 00000000 00000000 l ................
 00000000 00000000 00000000 00000000 l ................
 00000000 00000000 00000000 00000000 l ................
 00000000 00000000 00000000 00000000 l ...............

这里的80004001 83004001，代表这Extents中，L1块的地址和Data Block的地址，可以看到在Extents 1上面，它的L1块是128，而数据块是从131开始的。因为我们的129是L2，130是段头。所以下面我们构造其他的数据的时候，我们也要遵循这个规律。我们的Extents 2，它的L1还是128块，但是它的数据块却是从136开始的。而Extents 3，它的L1就是第二个L1块，也就是144，而它的数据块的开始则是从145开始的。依次类推下去。结果如下：

modify /x 8000 offset 2744  modify /x 4001 offset 2746
modify /x 8800 offset 2748  modify /x 4001 offset 2750
modify /x 9000 offset 2752  modify /x 9000 offset 2754
modify /x 9100 offset 2756  modify /x 4001 offset 2758
modify /x 9000 offset 2760  modify /x 4001 offset 2762
modify /x 9800 offset 2764  modify /x 4001 offset 2766
modify /x a000 offset 2768  modify /x 4001 offset 2770
modify /x a100 offset 2772  modify /x 4001 offset 2774
modify /x a000 offset 2776  modify /x 4001 offset 2778
modify /x a800 offset 2780  modify /x 4001 offset 2782
modify /x b000 offset 2784  modify /x 4001 offset 2786
modify /x b100 offset 2788  modify /x 4001 offset 2790
modify /x b000 offset 2792  modify /x 4001 offset 2794
modify /x b800 offset 2796  modify /x 4001 offset 2798
modify /x c000 offset 2800  modify /x 4001 offset 2802
modify /x c100 offset 2804  modify /x 4001 offset 2806
modify /x c000 offset 2808  modify /x 4001 offset 2810
modify /x c800 offset 2812  modify /x 4001 offset 2814
modify /x d000 offset 2816  modify /x 4001 offset 2818
modify /x d100 offset 2820  modify /x 4001 offset 2822
modify /x d000 offset 2824  modify /x 4001 offset 2826
modify /x d800 offset 2828  modify /x 4001 offset 2830
modify /x e000 offset 2832  modify /x 4001 offset 2834
modify /x e100 offset 2836  modify /x 4001 offset 2838
modify /x e000 offset 2840  modify /x 4001 offset 2842
modify /x e800 offset 2844  modify /x 4001 offset 2846

BBED> dump /v offset 2736 count 128
 File: /oracle/app/oracle/oradata/ora11/a1.dbf (0)
 Block: 130     Offsets: 2736 to 2863  Dba:0x00000000
-------------------------------------------------------
 80004001 83004001 80004001 88004001 l ..@...@...@...@.
 90009000 91004001 90004001 98004001 l ......@...@...@.
 a0004001 a1004001 a0004001 a8004001 l
 b0004001 b1004001 b0004001 b8004001 l
 c0004001 c1004001 c0004001 c8004001 l
 d0004001 d1004001 d0004001 d8004001 l
 e0004001 e1004001 e0004001 e8004001 l
 00000000 00000000 00000000 00000000 l ................

修改完成这些后，我们就能够查到我们全部的数据了。

SQL> alter system flush buffer_cache;
System altered.

SQL> select count(1) from a1.a;
  COUNT(1)
----------
      2775

此时切勿执行一些其他的操作，应该尽快的使用CTAS的方式将这个表进行备份或者是导出。因为段头块L2和L1的信息还一些是没有修改的。

SQL> create table a2.a as select * from a1.a;
Table created.

SQL> drop table a1.a;
Table dropped

至此，Truncate恢复完成。仔细的研究才会发现，其实最重要的是摸清楚整个段的构造情况，只要你对整个段的构造情况，了若指掌，基本上恢复是很简单的。

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

show_space脚本：快速检测表的存储信息

Tom在很多年前写了一个脚本工具showspace用来分析空间使用情况，此工具使用起来很方便可以快速了解表的存储信息。具体如下：
create or replace procedure show_space ( p_segname_1 in varchar2, p_owner_1 in varchar2 default user, p_type_1 in varchar2 default 'TABLE', p_space in varchar2 default 'AUTO', p_analyzed in varchar2 default 'Y' ) as p_segname varchar2(100); p_type varchar2(10); p_owner varchar2(30);


l_unformatted_blocks number;

l_unformatted_bytes number;

l_fs1_blocks number;

l_fs1_bytes number;

l_fs2_blocks number;

l_fs2_bytes number;

l_fs3_blocks number;

l_fs3_bytes number;

l_fs4_blocks number;

l_fs4_bytes number;

l_full_blocks number;

l_full_bytes number;
l_free_blks number;

l_total_blocks number;

l_total_bytes number;

l_unused_blocks number;

l_unused_bytes number;

l_LastUsedExtFileId number;

l_LastUsedExtBlockId number;

l_LAST_USED_BLOCK number;
procedure p( p_label in varchar2, p_num in number )

is

begin

dbms_output.put_line( rpad(p_label,40,'.') ||

p_num );

end;

begin

p_segname := upper(p_segname_1); -- rainy changed

p_owner := upper(p_owner_1);

p_type := p_type_1;
if (p_type_1 = 'i' or p_type_1 = 'I') then --rainy changed

p_type := 'INDEX';

end if;
if (p_type_1 = 't' or p_type_1 = 'T') then --rainy changed

p_type := 'TABLE';

end if;
if (p_type_1 = 'c' or p_type_1 = 'C') then --rainy changed

p_type := 'CLUSTER';

end if;
dbms_space.unused_space

( segment_owner => p_owner,

segment_name => p_segname,

segment_type => p_type,

total_blocks => l_total_blocks,

total_bytes => l_total_bytes,

unused_blocks => l_unused_blocks,

unused_bytes => l_unused_bytes,

LAST_USED_EXTENT_FILE_ID => l_LastUsedExtFileId,

LAST_USED_EXTENT_BLOCK_ID => l_LastUsedExtBlockId,

LAST_USED_BLOCK => l_LAST_USED_BLOCK );
if p_space = 'MANUAL' or (p_space <> 'auto' and p_space <> 'AUTO') then

dbms_space.free_blocks

( segment_owner => p_owner,

segment_name => p_segname,

segment_type => p_type,

freelist_group_id => 0,

free_blks => l_free_blks );
p( 'Free Blocks', l_free_blks );

end if;
p( 'Total Blocks', l_total_blocks );

p( 'Total Bytes', l_total_bytes );

p( 'Unused Blocks', l_unused_blocks );

p( 'Unused Bytes', l_unused_bytes );

p( 'Last Used Ext FileId', l_LastUsedExtFileId );

p( 'Last Used Ext BlockId', l_LastUsedExtBlockId );

p( 'Last Used Block', l_LAST_USED_BLOCK );
/*IF the segment is analyzed */

if p_analyzed = 'Y' then

dbms_space.space_usage(segment_owner => p_owner ,

segment_name => p_segname ,

segment_type => p_type ,

unformatted_blocks => l_unformatted_blocks ,

unformatted_bytes => l_unformatted_bytes,

fs1_blocks => l_fs1_blocks,

fs1_bytes => l_fs1_bytes ,

fs2_blocks => l_fs2_blocks,

fs2_bytes => l_fs2_bytes,

fs3_blocks => l_fs3_blocks ,

fs3_bytes => l_fs3_bytes,

fs4_blocks => l_fs4_blocks,

fs4_bytes => l_fs4_bytes,

full_blocks => l_full_blocks,

full_bytes => l_full_bytes);

dbms_output.put_line(rpad(' ',50,'*'));

dbms_output.put_line('The segment is analyzed');

p( '0% -- 25% free space blocks', l_fs1_blocks);

p( '0% -- 25% free space bytes', l_fs1_bytes);

p( '25% -- 50% free space blocks', l_fs2_blocks);

p( '25% -- 50% free space bytes', l_fs2_bytes);

p( '50% -- 75% free space blocks', l_fs3_blocks);

p( '50% -- 75% free space bytes', l_fs3_bytes);

p( '75% -- 100% free space blocks', l_fs4_blocks);

p( '75% -- 100% free space bytes', l_fs4_bytes);

p( 'Unused Blocks', l_unformatted_blocks );

p( 'Unused Bytes', l_unformatted_bytes );

p( 'Total Blocks', l_full_blocks);

p( 'Total bytes', l_full_bytes);
end if;

end; /

使用方法参考：
https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:5350053031470

Data access tuning Data model Oracle performance tuning 数据技术 | Guang Cai Li | 2014-03-16 | show_space

ASSM三级位图结构

L1、L2、L3块的作用：–方便查找数据块。

L1中有指向L3的指针，L2有指向L3的指针，L3中有多个数据块的指针和状态。
1、每个L3中，有多个L2的地址（第一个L3是段头）。
2、每个L2中，有多个L1的地址。
3、每个L1中，有多个数据块地址。
Oracle最多支持三级位图。
一级位图用于管理具体数据块的使用。
二级位图块记录了一级位图块的地址。
三级位图块记录了二级位图块的地址。Segment Heade可以管理极大数据量的对象的空间，很难出现另一个三级位图块。

1.如何查找段头–第一个L3块

BYS@ bys3>create tablespace test2 datafile ‘/u01/oradata/bys3/test22.dbf’ size 10m;
Tablespace created.
BYS@ bys3>create table test2(aa varchar2(10)) tablespace test2;
Table created.
BYS@ bys3>insert into test2 values(789);
1 row created.
BYS@ bys3>commit;
Commit complete.
BYS@ bys3>select dbms_rowid.ROWID_BLOCK_NUMBER(rowid),dbms_rowid.ROWID_RELATIVE_FNO(rowid) ,aa from test2;
DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID) AA
———————————— ———————————— ———-
131 7 789
BYS@ bys3>select header_block,header_file fromdba_segments where segment_name=’TEST2′ and owner=’BYS’;
HEADER_BLOCK HEADER_FILE ——-从这语句找到段头
———— ———–
130 7
BYS@ bys3>select object_id,data_object_id from dba_objects where object_name=’TEST2′ and owner=’BYS’;
OBJECT_ID DATA_OBJECT_ID
———- ————–
23199 23199
BYS@ bys3>alter table test2 allocate extent (size 960k);
Table altered.
BYS@ bys3>alter system dump datafile 7 block 130;
System altered.
BYS@ bys3>select value from v$diag_info where name like ‘De%’;
VALUE
—————————————————————————————————-
/u01/diag/rdbms/bys3/bys3/trace/bys3_ora_4215.trc
################

段头–第一个L3块的解读：

Start dump data blocks tsn: 7 file#:7 minblk 130 maxblk 130
Block dump from cache:
Dump of buffer cache at level 4 for tsn=7 rdba=29360258
BH (0x20fe6d64) file#: 7 rdba: 0x01c00082 (7/130) class: 4 ba: 0x20cb6000
set: 3 pool: 3 bsz: 8192 bsi: 0 sflg: 1 pwc: 0,0
dbwrid: 0 obj: 23199 objn: 23199 tsn: 7 afn: 7 hint: f
hash: [0x2a39d804,0x2a39d804] lru: [0x217f7ccc,0x21befb08]
lru-flags: on_auxiliary_list
ckptq: [NULL] fileq: [NULL] objq: [0x21befb20,0x22beab34] objaq: [0x2443a408,0x2
1befb28]
st: XCURRENT md: NULL fpin: ‘ktswh03: ktscts’ tch: 2
flags: block_written_once redo_since_read
LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [1]
Block dump from disk: –下面的才是物理数据文件中内容
buffer tsn: 7 rdba: 0x01c00082 (7/130)
scn: 0x0000.0082b051 seq: 0x01 flg: 0x04 tail: 0xb0512301
frmt: 0x02 chkval: 0xf0d6 type: 0x23=PAGETABLE SEGMENT HEADER –数据块类型：段头
Hex dump of block: st=0, typ_found=1
Dump of memory from 0xB6BC0600 to 0xB6BC2600
B6BC0600 0000A223 01C00082 0082B051 04010000 [#…….Q…….]–B6BC0600 0000A223，这里的23，是数据块中的块头的块类型的信息，与type: 0x23=对应。
Repeat 185 times ——-省略了大部分无关输出
B6BC25F0 00000000 00000000 00000000 B0512301 [………….#Q.]
Extent Control Header
—————————————————————–
Extent Header:: spare1: 0 spare2: 0 #extents: 18 #blocks: 384 –有18个区，384个块==16个区-8 个块，2个区-128个块，16*8+2*128=384
last map 0x00000000 #maps: 0 offset: 2716
Highwater:: 0x01c00088 ext#: 0 blk#: 8 ext size: 8
高水位的块DBA–0x01c00088 -136号块，是第二个区的第一个块。插入只会插入高水位以下的块< =，以区为单位推进--也可能是区的一半-据说算法很复杂。查询时也会找到高水位，查询高水位下的块。并发插入时候，高水位的位置会影响限制并发插入，因为只能插入高水位以下的块，如8KBLOCK时；1M区，128个块，超过128个并发会有热块，从而产生buffer busy waits.；如果是8M的区，会有1024个块，超过1024并发同样会有热块产生。 #blocks in seg. hdr's freelists: 0 #blocks below: 5 mapblk 0x00000000 offset: 0 Unlocked -------------------------------------------------------- Low HighWater Mark : --低高水位，低高水位之下的数据都已经使用了。低高水位和高水位之间，有的数据块已经使用，有的未使用-未格式化。格式化是在块头加：OJBECT号，数据字典中：dba_objects.DATA_OBJECT_ID Highwater:: 0x01c00088 ext#: 0 blk#: 8 ext size: 8 #blocks in seg. hdr's freelists: 0 #blocks below: 5 mapblk 0x00000000 offset: 0 Level 1 BMB for High HWM block: 0x01c00080 Level 1 BMB for Low HWM block: 0x01c00080 -------------------------------------------------------- Segment Type: 1 nl2: 1 blksz: 8192 fbsz: 0 L2 Array start offset: 0x00001434 First Level 3 BMB: 0x00000000 L2 Hint for inserts: 0x01c00081 ----二级位图块的DBA，换算为：0000 0001 1100 ，前10位文件号是二进制111-十进制7，16进制81--十进制129.插入时会选择这个L2下的L1的块，直到此L2下的所有L1中的块用完，才会用其它L2--在此处更改L1的DBA。 Last Level 1 BMB: 0x01c00181 Last Level II BMB: 0x01c00081 Last Level III BMB: 0x00000000 Map Header:: next 0x00000000 #extents: 18 obj#: 23199 flag: 0x10000000 Inc # 0 Extent Map --区地图，段下有几个区，区的起始地址以及包含的块数 ----------------------------------------------------------------- 0x01c00080 length: 8 0x01c00088 length: 8 0x01c00090 length: 8 0x01c00098 length: 8 0x01c000a0 length: 8 0x01c000a8 length: 8 0x01c000b0 length: 8 0x01c000b8 length: 8 0x01c000c0 length: 8 0x01c000c8 length: 8 0x01c000d0 length: 8 0x01c000d8 length: 8 0x01c000e0 length: 8 0x01c000e8 length: 8 0x01c000f0 length: 8 0x01c000f8 length: 8 0x01c00100 length: 128 0x01c00180 length: 128 Auxillary Map --辅助表，区由哪个L1管理及所管理的区-数据块的起始位置DBA--非Metadata块始地址。。辅助区地址可看出哪几个区内的块共用同一个L1，如下： -------------------------------------------------------- Extent 0 : L1 dba: 0x01c00080 Data dba: 0x01c00083 --131，第一个可用的块的地址 Extent 1 : L1 dba: 0x01c00080 Data dba: 0x01c00088 --136，可以看到这个L1和上一个L1相同，一个L1管理了两个区。 Extent 2 : L1 dba: 0x01c00090 Data dba: 0x01c00091 --145 Extent 3 : L1 dba: 0x01c00090 Data dba: 0x01c00098 Extent 4 : L1 dba: 0x01c000a0 Data dba: 0x01c000a1 Extent 5 : L1 dba: 0x01c000a0 Data dba: 0x01c000a8 Extent 6 : L1 dba: 0x01c000b0 Data dba: 0x01c000b1 Extent 7 : L1 dba: 0x01c000b0 Data dba: 0x01c000b8 Extent 8 : L1 dba: 0x01c000c0 Data dba: 0x01c000c1 Extent 9 : L1 dba: 0x01c000c0 Data dba: 0x01c000c8 Extent 10 : L1 dba: 0x01c000d0 Data dba: 0x01c000d1 Extent 11 : L1 dba: 0x01c000d0 Data dba: 0x01c000d8 Extent 12 : L1 dba: 0x01c000e0 Data dba: 0x01c000e1 Extent 13 : L1 dba: 0x01c000e0 Data dba: 0x01c000e8 Extent 14 : L1 dba: 0x01c000f0 Data dba: 0x01c000f1 Extent 15 : L1 dba: 0x01c000f0 Data dba: 0x01c000f8 Extent 16 : L1 dba: 0x01c00100 Data dba: 0x01c00102 --128个块了，L1一个管理一个区。在8KB BLOCK，8M的区时，一个L1管理可以1024个块，再大的区就未实验过了。 Extent 17 : L1 dba: 0x01c00180 Data dba: 0x01c00182 -------------------------------------------------------- Second Level Bitmap block DBAs -------------------------------------------------------- DBA 1: 0x01c00081 --二级位图块的DBA，这里只有一个L2，如果有多个L2，都会在这里显示出来的。 End dump data blocks tsn: 7 file#: 7 minblk 130 maxblk 130 #################################################3 DUMP L2块--根据段头找到L2的DBA BYS@ bys3>alter system dump datafile 7 block 129;
System altered.
BYS@ bys3>select value from v$diag_info where name like ‘De%’;
VALUE
—————————————————————————————————-
/u01/diag/rdbms/bys3/bys3/trace/bys3_ora_4982.trc
#######
Start dump data blocks tsn: 7 file#:7 minblk 129 maxblk 129
Block dump from cache:
Dump of buffer cache at level 4 for tsn=7 rdba=29360257
Block dump from disk:
buffer tsn: 7 rdba: 0x01c00081 (7/129)
scn: 0x0000.0082b04b seq: 0x03 flg: 0x04 tail: 0xb04b2103
frmt: 0x02 chkval: 0xcf4e type: 0x21=SECOND LEVEL BITMAP BLOCK –L2
Hex dump of block: st=0, typ_found=1
Dump of memory from 0xB6B43600 to 0xB6B45600
B6B43600 0000A221 01C00081 0082B04B 04030000 [!…….K…….] 0000A221中21与type: 0x21= 对应
Repeat 496 times
B6B455F0 00000000 00000000 00000000 B04B2103 [………….!K.]
Dump of Second Level Bitmap Block
number: 12 nfree: 12 ffree: 0 pdba: 0x01c00082 –父DBA，也就是L3的地址-130号块， number: 12 –L1的总数，nfree: 12–空闲的L1个数，
Inc #: 0 Objd: 23199
opcode:1
xid:
L1 Ranges :–多个L1时，按L1 DBA顺序插入/////???????插入数据时：再根据PID进行HASH，得到一个随机值，根据此值选择L2中的L1–受高水位影响的
——————————————————–
0x01c00080 Free: 5 Inst: 1 —128号块，Free: 5标记L1中可用空间状态
0x01c00090 Free: 5 Inst: 1 –144号块，Free: 0 FULL状态
0x01c000a0 Free: 5 Inst: 1
0x01c000b0 Free: 5 Inst: 1
0x01c000c0 Free: 5 Inst: 1
0x01c000d0 Free: 5 Inst: 1
0x01c000e0 Free: 5 Inst: 1
0x01c000f0 Free: 5 Inst: 1
0x01c00100 Free: 5 Inst: 1
0x01c00101 Free: 5 Inst: 1
0x01c00180 Free: 5 Inst: 1
0x01c00181 Free: 5 Inst: 1

——————————————————–
End dump data blocks tsn: 7 file#: 7 minblk 129 maxblk 129

#####################################

DUMP L3块–根据L2中的 L1 Ranges的找到第一个L1块的DBA

BYS@ bys3>alter system dump datafile 7 block 128;
System altered.
BYS@ bys3>select value from v$diag_info where name like ‘De%’;
VALUE
—————————————————————————————————-
/u01/diag/rdbms/bys3/bys3/trace/bys3_ora_5162.trc
@@@@@@@@@@@@@@@
Start dump data blocks tsn: 7 file#:7 minblk 128 maxblk 128
Block dump from cache:
Dump of buffer cache at level 4 for tsn=7 rdba=29360256
Block dump from disk:
buffer tsn: 7 rdba: 0x01c00080 (7/128)
scn: 0x0000.0082afe2 seq: 0x01 flg: 0x04 tail: 0xafe22001
frmt: 0x02 chkval: 0x9d2d type: 0x20=FIRST LEVEL BITMAP BLOCK
Hex dump of block: st=0, typ_found=1
Dump of memory from 0xB6CBD600 to 0xB6CBF600
B6CBD600 0000A220 01C00080 0082AFE2 04010000 [ ……………] 0000A220的20，表示：type: 0x20=FIRST LEVEL BITMAP BLOCK
B6CBD610 00009D2D 00000000 00000000 00000000 [-……………]
B6CBD620 00000000 00000000 00000000 00000000 […………….]
Repeat 1 times
Repeat 8 times
B6CBD780 00000000 00000000 00000000 55551511 […………..UU]
B6CBD790 00000000 00000000 00000000 00000000 […………….]
Repeat 485 times
B6CBF5F0 00000000 00000000 00000000 AFE22001 […………. ..]
Dump of First Level Bitmap Block
——————————–
nbits : 4 nranges: 2 parent dba: 0x01c00081 poffset: 0 –parent dba: 上一级DBA，L2的地址——129号块
unformatted: 8 total: 16 first useful block: 3
owning instance : 1
instance ownership changed at 01/22/2014 11:22:40
Last successful Search 01/22/2014 11:22:40
Freeness Status: nf1 0 nf2 0 nf3 0 nf4 5

Extent Map Block Offset: 4294967295
First free datablock : 3
Bitmap block lock opcode 0
Locker xid: : 0x0000.000.00000000
Dealloc scn: 3.0
Flag: 0x00000001 (-/-/-/-/-/HWM)
Inc #: 0 Objd: 23199
HWM Flag: HWM Set
Highwater:: 0x01c00088 ext#: 0 blk#: 8 ext size: 8 高水位在 0x01c00088 136号块，下一个区的第一个块
#blocks in seg. hdr’s freelists: 0
#blocks below: 5
mapblk 0x00000000 offset: 0
——————————————————–
DBA Ranges : –这个L1管理的数据块的范围
——————————————————–
0x01c00080 Length: 8 Offset: 0
0x01c00088 Length: 8 Offset: 8

0:Metadata 1:Metadata 2:Metadata 3:75-100% free —Metadata 是无数据，这里存放的是L3 L2 L1的块。
4:75-100% free 5:75-100% free 6:75-100% free 7:75-100% free
8:unformatted 9:unformatted 10:unformatted 11:unformatted
12:unformatted 13:unformatted 14:unformatted 15:unformatted 可以DUMP 12和5，对比格式化与未格式化的差别。
在L1块中关于数据块的状态有7种格式：Unformat 75-100% 50-75% 25-50% 0-25% FULL Metadata
——————————————————–
End dump data blocks tsn: 7 file#: 7 minblk 128 maxblk 128

转自互联网仅作记载。

Data access tuning Data model Oracle 数据技术 | Guang Cai Li | 2011-10-21 | assm bitmap

Oracle Truncate table原理剖析三：偷天换日也要找到你

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

show_space脚本：快速检测表的存储信息

ASSM三级位图结构

Oracle 恢复工具 Mdata 5.0.1 版本发布

近期文章

分类目录

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

近期活动

Oracle 恢复工具 Mdata 5.0.1 版本发布

近期文章

分类目录

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

近期活动

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