eygle.com   eygle.com
eygle.com  
 

« 《循序渐进Oracle》内容简介 | Blog首页 | DBA Scripts:转换RDBA的文件和数据块地址 »

Oracle ASSM三级位图块结构

作者:eygle |【转载时请以超链接形式标明文章和作者信息及本声明
链接:

前几天Piner发布了一个悬赏:寻找ASSM三级位图块的文章,同时给出了对于ASSM结构的猜想。

Piner猜想的结构和我想像的不同,我认为ASSM的结构应该如下图所示:

也就是说我认为BMB的结构应该是均衡的,同时段头的PAGETABLE SEGMENT HEADER同时充当了第0个3级位图块的角色。

在PAGETABLE SEGMENT HEADER中实际上我们可以很容易的看到这样的输出:

--------------------------------------------------------
Segment Type: 1 nl2: 103 blksz: 2048 fbsz: 0
L2 Array start offset: 0x00000434
First Level 3 BMB: 0x00000000
L2 Hint for inserts: 0x0355cfad
Last Level 1 BMB: 0x03560c9c
Last Level II BMB: 0x0355cfad
Last Level III BMB: 0x00000000
Map Header:: next 0x034000bf #extents: 51 obj#: 33141 flag: 0x20000000
Extent Map
-----------------------------------------------------------------

也就是说,这里记录了First Level 3 BMB和Last Level III BMB的地址,那么这就足够了,这里的双向指针完全可以进行Level 3级位图块的导航,而这第0个三级位图块也即段头,并无需记录所有3级位图块的地址。

由于产生另外一个3级位图块并不容易,所以Piner才提出悬赏,他构造了一个873G的大表,仍然没有产生另外的3级位图块:

SQL> select bytes/1024/1024/1024 "SIZE(G)" from user_segments where segment_name='TEST';

SIZE(G)
----------
873.25

为了寻找3级位图块,我着手做了以下实验,实验要能够:
1.实现更快快速的区间分配与扩展
2.使第0个3级位图块也即segment header尽量小,以便进一步扩展

为此我创建了一个2k block_size的表空间,设置uniform size区间大小为10K,这样可以尽量所见空间耗用:

SQL> create tablespace eygle
2 datafile 'd:\EYGLE01.DBF' size 1024M reuse blocksize 2048
3 extent management local uniform size 10k
4 segment space management auto;

表空间已创建。

SQL> set timing on
SQL> alter tablespace eygle add datafile 'f:\eygle02.dbf' size 8191M reuse;

表空间已更改。

已用时间: 00: 44: 42.08

注意,增加了一个8G的数据文件,足足用了我44分钟,这是一个Windows平台,异常缓慢。

然后创建一个数据表,设置高pctfree值,使得每个Block只存储一行数据,然后插入1千万记录:

SQL> create table EYGLE
2 (
3 ID NUMBER(8),
4 UNAME CHAR(1000)
5 )
6 tablespace eygle
7 pctfree 50
8 initrans 1
9 maxtrans 255
10 ;

表已创建。

已用时间: 00: 00: 00.00
SQL> begin
2 for i in 1 .. 100 loop
3 for i in 1 .. 100000 loop
4 insert into eygle values(i,'eygle');
5 end loop;
6 commit;
7 end loop;
8 end;
9 /

完成这些操作之后,这个表用了大约9G空间:

SQL> select bytes/1024/1024/1024 sizegb from dba_segments
2 where segment_name='EYGLE';

SIZEGB
----------
8.9988327

此时第一个3级位图块出现了,这是多么珍贵的一个3级位图块啊:

Start dump data blocks tsn: 12 file#: 13 minblk 4032222 maxblk 4032222
buffer tsn: 12 rdba: 0x037d86de (13/4032222)
scn: 0x0000.00bdc864 seq: 0x01 flg: 0x04 tail: 0xc8642201
frmt: 0x02 chkval: 0xf597 type: 0x22=THIRD LEVEL BITMAP BLOCK
Dump of Third Level Bitmap Block
number: 9 , next : 0x00000000
L2 Ranges :
--------------------------------------------------------
0x037d86dd
0x037dd22d 0x037e1d7d 0x037e68cd 0x037eb41d
0x037eff6d 0x037f4abd 0x037f960d 0x037fe15d

--------------------------------------------------------
End dump data blocks tsn: 12 file#: 13 minblk 4032222 maxblk 4032222

这个位图上上存在一个向下的指针:next : 0x00000000 ,当然现在还没有数值,我们可以再产生下一个3级位图块来观察。

那么实际上到这里已经足够了,我的图示已经得到了足够的说明。

-The End-


历史上的今天...
      >> 2006-07-04文章:
             在北京 感觉地震
      >> 2005-07-04文章:
             徐克的新作《七剑》
------
这篇 【Oracle ASSM三级位图块结构】来自 eygle.com | CSDN网摘| del.icio.us|Google订阅 | 鲜果订阅 | 抓虾订阅

By eygle on 2007-07-04 12:50 | Comments (21) | Posted to Internal | Edit |

相关文章 随机文章
  • Oracle KSL Latch 管理层 与 Latch管理
  • Oracle10gR2中的Mutex竞争的案例
  • CURSOR_SPACE_FOR_TIME 参数废弃
  • 关于Mutex的笔记
  • DBA警世录:bootstrap$的禁忌
  • 2007 年终总结-Eygle.Com的发展历程
    从网易Q1财报 看网易的高瞻远瞩
    华友的IPO历程-之二
    进京两周年记-Eygle在北京的生活之九
    元旦献礼-《深入解析Oracle》第一、四章下载
    搜索本站:

    留言 (21)

    第一次见L3

    Posted by: codepeon at July 4, 2007 12:32 PM

    这还是一颗平衡的B+/-树啊

    Posted by: anysql at July 4, 2007 2:11 PM

    dump一下segment header block看一下

    Posted by: kamus at July 5, 2007 12:54 AM

    增加了一个8G的数据文件用了44分钟?晕!我才用了3分多
    SQL> set timing on
    SQL> alter tablespace justin add datafile 'E:\oracle\product\10.2.0\oradata\orcl
    \justin2.dbf' size 8192M;

    表空间已更改。

    已用时间: 00: 03: 28.15
    SQL>

    Posted by: justin at July 5, 2007 3:22 AM

    我也是win平台win2kserver

    Posted by: justin at July 5, 2007 3:26 AM

    非常不错。。。
    原来认为双向链表如果太长的话,查找链表中间的数据不是太方便,可能是oracle认为L3不会太多,所以这样做了。

    不过你的产生L3的思路不错,当初,我没有认为产生L3有这么大难度,就直接在8k的block上增加数据,结果是增加到了800多G,还是没有出现L3。后来,因为测试的任务紧,就没有再继续了。

    感谢你的测试。

    Posted by: piner at July 5, 2007 9:19 AM

    你的图还是单向链表结构,应当是双向的吧。

    Posted by: piner at July 5, 2007 9:31 AM

    图上缺了一条线,segment header还应该指向最后一个L3 BMB,形成一个环,中间其他三级位图块之间是单向的。

    Posted by: eygle at July 5, 2007 9:42 AM

    to justin ;
    我的这个测试机是比较差劲的了。

    Posted by: eygle at July 5, 2007 5:16 PM

    不知道这种情况下一个L1的数据块可以管辖多少个数据块,这样可以估算下数据量达到多少可以撑暴这个L3的所有块,以前读过liews把索引建立成二叉树,然后弄到32级撑暴的文章,感觉和这边有点异曲同工,呵呵!!!!!

    Posted by: 八神苍月 at July 7, 2007 2:09 PM

    为此我创建了一个2k block_size的表空间,设置uniform size区间大小为10K,这样可以尽量所见空间耗用:

    虽然有错字,不过你的这个设定的确是成功的关键,不然又不知道需要n个G了果然有实力,学写学习!

    Posted by: mustapha at July 7, 2007 8:31 PM

    导出的块中有pdba,记录的是父块的地址,所以中间几级都是双向的

    Posted by: hxy at September 5, 2007 10:10 AM

    to hxy;
    在哪里?请帮忙指出一下,或者给个例子。

    谢谢!

    Posted by: eygle at September 5, 2007 10:26 AM

    这里为什么要定义一个extent的大小为10K,
    难道是用于估计插入多少行会出现三级块吗?

    Posted by: xiaolong78x at September 11, 2007 10:26 AM

    to xiaolong;
    这个问题问的好。

    我为了使区间尽量多,自然要使区间尽量小,而不同block_size最小区间是多大?你可以测试一下。

    Posted by: eygle at September 11, 2007 10:31 AM

    经过测试(版本为 9201 for win)
    block_size=2k extent_size(min) = 4k
    block_size=4k extent_size(min) = 8k
    block_size=8k extent_size(min) = 16k

    如果是是区间区间尽量多, 你的extent_size 为什么不等于4K?

    Posted by: xiaolong78x at September 11, 2007 11:49 AM

    又一个问题,如果你不使用Uniform Size,你的Extent很快会扩展到很大,那你可能永远也看不到3级位图块。

    你可以检查一下你的创建语句,并可以顺便研究一下Uniform Size和Auto Allocate的区别。

    Posted by: eygle at September 11, 2007 11:59 AM

    谢谢eygle。 你点的2点, 我概念都有点模糊。
    当extent auto Allocate时,不管block_size的大小, 0-15区段为64K. 15 - 18 为1M。

    Posted by: xiaolong78x at September 11, 2007 5:10 PM

    补充一小点:
    这里的L1与Data Block的关系有点象share pool中bucket与chunk之间的关系。
    从该segment的第1个区到第101区都是1个L1对应3个区,从第102个区开始是1个L1对12个区,增加幅度so大!后面的没试,电脑太破 ~
    可见想弄出个L2来都挺崩溃的

    Posted by: johnson at March 30, 2008 1:40 AM

    大师,请教个问题,帮忙解答(L1 BMB怎么知道下面block块地址的):http://www.itpub.net/thread-1052467-1-1.html

    Posted by: g_hk at September 8, 2008 5:01 PM

    这个测试表的数据大小大概是20g

    100*100000*2k (one row is one block) = 20, 000, 000k= about 20g.

    但是从数据文件看只有10g,所以我运行insert的时候总是提示不能扩展段.
    'd:\EYGLE01.DBF' size 1024M
    'f:\eygle02.dbf' size 8191M

    后来我又加了俩个5g的数据文件,才成功insert所有的数据

    Bytes: 20982353920
    Blocks: 10245290

    我在11.6下面测试的,大师,这是不是正确的。

    谢谢!

    Posted by: lsllcm at September 5, 2009 7:54 PM

    发表留言:



    Remember Me?
    (输入验证码后方可评论,谢谢支持)



    CopyRight © 2004~2010 eygle.com, All rights reserved.