Oracle ASSM三級位圖塊結構

前幾天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文章:

By eygle on 2007-07-04 12:50 |

Comments (21) |

Internal | 1487 |

21 Comments

dump一下segment header block看一下

增加了一個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>

我也是win平臺win2kserver

非常不錯。。。

原來認為雙向鏈表如果太長的話，查找鏈表中間的數據不是太方便，可能是oracle認為L3不會太多，所以這樣做了。

不過你的產生L3的思路不錯，當初，我沒有認為產生L3有這么大難度，就直接在8k的block上增加數據，結果是增加到了800多G，還是沒有出現L3。后來，因為測試的任務緊，就沒有再繼續了。

感謝你的測試。

圖上缺了一條線，segment header還應該指向最后一個L3 BMB,形成一個環，中間其他三級位圖塊之間是單向的。

to justin ;

我的這個測試機是比較差勁的了。

不知道這種情況下一個L1的數據塊可以管轄多少個數據塊,這樣可以估算下數據量達到多少可以撐暴這個L3的所有塊,以前讀過liews把索引建立成二叉樹,然后弄到32級撐暴的文章,感覺和這邊有點異曲同工,呵呵!!!!!

為此我創建了一個2k block_size的表空間，設置uniform size區間大小為10K，這樣可以盡量所見空間耗用：

雖然有錯字，不過你的這個設定的確是成功的關鍵，不然又不知道需要n個G了果然有實力，學寫學習！

導出的塊中有pdba,記錄的是父塊的地址，所以中間幾級都是雙向的

to hxy;

在哪里？請幫忙指出一下，或者給個例子。

謝謝！

這里為什么要定義一個extent的大小為10K,

難道是用于估計插入多少行會出現三級塊嗎？

to xiaolong;

這個問題問的好。

我為了使區間盡量多，自然要使區間盡量小，而不同block_size最小區間是多大？你可以測試一下。

經過測試(版本為 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？

又一個問題，如果你不使用Uniform Size，你的Extent很快會擴展到很大，那你可能永遠也看不到3級位圖塊。

你可以檢查一下你的創建語句，并可以順便研究一下Uniform Size和Auto Allocate的區別。

謝謝eygle。 你點的2點， 我概念都有點模糊。

當extent auto Allocate時，不管block_size的大小， 0-15區段為64K. 15 - 18 為1M。

補充一小點：

這里的L1與Data Block的關系有點象share pool中bucket與chunk之間的關系。

從該segment的第1個區到第101區都是1個L1對應3個區，從第102個區開始是1個L1對12個區，增加幅度so大！后面的沒試，電腦太破 ~

可見想弄出個L2來都挺崩潰的

大師，請教個問題，幫忙解答(L1 BMB怎么知道下面block塊地址的)：http://www.itpub.net/thread-1052467-1-1.html

這個測試表的數據大小大概是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下面測試的，大師，這是不是正確的。

謝謝！

總結

以上是生活随笔為你收集整理的assm的结构_Oracle ASSM三级位图块结构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。