Heim  >  Artikel  >  Datenbank  >  ORACLE空间管理实验4:块管理之ASSM三级位图结构

ORACLE空间管理实验4:块管理之ASSM三级位图结构

WBOY
WBOYOriginal
2016-06-07 15:50:441624Durchsuche

L1、L2、L3块的作用:--方便查找数据块。 L3中有指向L2的指针,L2有指向L1的指针,L1中有多个数据块的指针和状态。 1、每个L3中,有多个L2的地址(第一个L3是段头)。 2、每个L2中,有多个L1的地址。 3、每个L1中,有多个数据块地址。 ORACLE最多支持三级位


L1、L2、L3块的作用:--方便查找数据块。

L3中有指向L2的指针,L2有指向L1的指针,L1中有多个数据块的指针和状态。
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:  ---这段是BUFFER CACHE的BLOCK HEADER信息,参考:http://blog.csdn.net/haibusuanyun/article/details/17525523
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
Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn