详解Oracle本地管理表空间

嘉淑4049

1 名词解释与约定　　表空间（Tablespace）：为数据库提供使用空间的逻辑结构，其对应物理结构是数据文件，一个表空间可以包含多个数据文件。
　　本地管理表空间（Locally Managed Tablespace简称LMT）：8i以后出现的一种新的表空间的管理模式，通过本地位图来管理表空间的空间使用。
　　字典管理表空间（Dictionary-Managed Tablespace简称DMT）：8i以前包括以后都还可以使用的一种表空间管理模式，通过数据字典管理表空间的空间使用。
　　段（Segment）：数据库一种逻辑结构，如表段，索引段，回滚段等，段存在于表空间中，并对应一定的存储空间。
　　区间，可以简称区（Extent）：段的存储可以分成一个或多个区间，每个区间占用一定数量的数据块（block），在本地管理的表空间中，表空间的Extent就对应段的Extent。
　　块（Block）：数据库最小的存储单位，在本文中Block的大小约定为8192字节。
　　位（Bit）：本地管理表空间的空间管理单位，一个位可能等于一个区间，也可能多个位组成一个区间。
　　2 本地管理表空间
　　2.1 语法
　　在Oracle8I的版本中，Oracle推出了一种全新的表空间管理方式：本地化管理的表空间。所谓本地化管理，就是指Oracle不再利用数据字典表来记录Oracle表空间里面的区的使用状况，而是在每个表空间的数据文件的头部加入了一个位图区，在其中记录每个区的使用状况。每当一个区被使用，或者被释放以供重新使用时，Oracle都会更新数据文件头部的这个记录，反映这个变化。
　　本地化管理的表空间的创建过程：
　　语法：CREATE TABLESPACE 表空间名字 DATAFILE '数据文件详细信息' [EXTENT MANAGEMENT { LOCAL {AUTOALLOCATE | UNIFORM [SIZE INTETER [K|M] ] } } ]
　　关键字EXTENT MANAGEMENT LOCAL 指定这是一个本地化管理的表空间。对于系统表空间，只能在创建数据库的时候指定EXTENT MANGEMENT LOCAL，因为它是数据库创建时建立的第一个表空间。
　　在8i中，字典管理还是默认的管理方式，当选择了LOCAL关键字，即表明这是一个本地管理的表空间。当然还可以继续选择更细的管理方式：是AUTOALLOCATE 还是 UNIFORM.。若为AUTOALLOCATE，则表明让Oracle来决定区块的使用办法；若选择了UNIFORM，则还可以详细指定每个区块的大小，若不加指定，则为每个区使用1M大小。
　　2.2 本地管理优点
　　1. 本地化管理的表空间避免了递归的空间管理操作。而这种情况在数据字典管理的表空间是经常出现的，当表空间里的区的使用状况发生改变时，数据字典的表的信息发生改变，从而同时也使用了在系统表空间里的回滚段。
　　2. 本地化管理的表空间避免了在数据字典相应表里面写入空闲空间、已使用空间的信息，从而减少了数据字典表的竞争，提高了空间管理的并发性
　　3. 区的本地化管理自动跟踪表空间里的空闲块，减少了手工合并自由空间的需要。
　　4. 表空间里的区的大小可以选择由Oracle系统来决定，或者由数据库管理员指定一个统一的大小，避免了字典表空间一直头疼的碎片问题。
　　5. 从由数据字典来管理空闲块改为由数据文件的头部记录来管理空闲块，这样避免产生回滚信息，不再使用系统表空间里的回滚段。因为由数据字典来管理的话，它会把相关信息记在数据字典的表里，从而产生回滚信息。
　　由于这种表空间的以上特性，所以它支持在一个表空间里边进行更多的并发操作，并减少了对数据字典的依赖。
　　3 本地管理表空间管理机制
　　表空间是一种为段（表，索引等）提供空间的逻辑结构，所以，当在表空间中增加，删除段的时候，数据库就必须跟踪这些空间的使用。
　　如下例所示，假定一个新创建的表空间包含了五个表
　　表一……表二……表三……表四……表五……未用空间
　　当我们删除表四的时候，就有如下结果
　　表一……表二……表三……空闲空间段……表五……未用空间
　　很明显，ORACLE需要有一个机制来管理表空间中各数据文件的这些分配的或未分配的空间，为了跟踪这些可以使用的空间（包括未分配使用的和可以重复使用的），对于每一个空间，我们必须知道：
　　1、这个可用空间位于什么数据文件
　　2、这个空间的尺寸是多大
　　3、如果它在用了，是哪一个段占用的这个空间
　　直到8i之前，所有的表空间都是采用字典管理模式，为了确保能保存以上的信息，ORACLE用了两个数据字典表:UET$（已使用的区间）或FET$（空闲空间）：
　　SQL> desc UET$
　　Name Type Nullable Default Comments
　　--------- ------ -------- ------- --------
　　SEGFILE# NUMBER
　　SEGBLOCK# NUMBER
　　EXT# NUMBER
　　TS# NUMBER
　　FILE# NUMBER
　　BLOCK# NUMBER
　　LENGTH NUMBER
　　
　　SQL> desc FET$
　　Name Type Nullable Default Comments
　　------ ------ -------- ------- --------
　　TS# NUMBER
　　FILE# NUMBER
　　BLOCK# NUMBER
　　LENGTH NUMBER
　　查询该表可以看到，每个使用空间或空闲空间（不一定是一个extent，可以是多个extent）都在该表中对应了一行。它的工作方式是当一个段被删除的时候，ORACLE就移动UET$中相应的行到FET$，这个过程的发生是连续的，而且可能发生等待。当并发性很高的时候，数据字典的争用就来了。另外有一个问题就是，当表的空间很不连续或表空间有大量的碎片引起这两个表的增大，那么也就会引起数据库性能上的下降。
　　本地管理表空间正是为了解决这一问题来的，在表空间的空间管理上，ORACLE将存储信息保存在表空间的头部的位图中，而不是保存在数据字典中。通过这样的方式，在分配回收空间的时候，表空间就可以独立的完成操作也不用与其它对象关系。
　　下面就让我们进入到本地管理表空间的内部，看看ORACLE是怎么实现这一工作的。
　　4 用Uniform方式的本地管理表空间
　　4.1 当uniform size值太小时
　　SQL> create tablespace demo32 datafile '/oradata/ltest/demo32.dbf' size 10m extent management local uniform size 32k;
　　ORA-03249: Uniform size for auto segment space managed tablespace should have at least 5 blocks
　　注意: 我实验环境block为8k, 所以uniform size至少为40k.
　　4.2 当storage参数中的initial为空时
　　SQL> create tablespace demo64 datafile '/oradata/ltest/demo64.dbf' size 10m extent management local uniform size 64k;
　　Tablespace created
　　SQL> select a.initial_extent / 1024 "INIT_EXTENT(K)",
　　 2 a.next_extent / 1024 "NEXT_EXTENT(K)"
　　 3 from user_tablespaces a
　　 4 where a.tablespace_name = 'DEMO64';
　　INIT_EXTENT(K) NEXT_EXTENT(K)
　　-------------- --------------
　　 6464
　　SQL> create table demotab64(x number) tablespace demo64;
　　Table created
　　SQL> select a.table_name,
　　 2a.initial_extent / 1024 "INIT_EXTENT(K)",
　　 3a.next_extent / 1024 "NEXT_EXTENT(K)"
　　 4 from user_tables a
　　 5 where a.table_name = 'DEMOTAB64';
　　TABLE_NAMEINIT_EXTENT(K) NEXT_EXTENT(K)
　　-------------------------- -------------- --------------
　　DEMOTAB646464
　　注意: 建表时没有存储参数initial时, 初始化区与下一个区的大小都是64k, 与uniform size的大小一样的.
　　SQL> select a.bytes / 1024 "INIT_EXTENT(K)" from user_extents a where a.segment_name = 'DEMOTAB64' and a.extent_id = 0;
　　INIT_EXTENT(K)
　　--------------
　　 64
　　SQL> select count(*) from user_extents where segment_name = 'DEMOTAB64';
　　 COUNT(*)
　　----------
　　1
　　注意: 在该段中, 产生一个区.
　　4.3 当initial < uniform size时
　　SQL> create table demotab64_1(x number) tablespace demo64 storage (initial 1K next 5k);
　　Table created
　　SQL> select a.table_name,
　　 2a.initial_extent / 1024 "INIT_EXTENT(K)",
　　 3a.next_extent / 1024 "NEXT_EXTENT(K)"
　　 4 from user_tables a
　　 5 where a.table_name = 'DEMOTAB64_1';
　　TABLE_NAMEINIT_EXTENT(K) NEXT_EXTENT(K)
　　--------------------------- -------------- --------------
　　DEMOTAB64_11664
　　注意: 此时INIT_EXTENT为16, 不是initial参数的1.
　　SQL> select a.bytes / 1024 "INIT_EXTENT(K)" from user_extents a where a.segment_name = 'DEMOTAB64_1' and a.extent_id = 0;
　　INIT_EXTENT(K)
　　--------------
　　 64
　　SQL> select count(*) from user_extents where segment_name = 'DEMOTAB64_1';
　　COUNT(*)
　　----------
　　1
　　4.4 当initial > uniform size时
　　SQL> create table demotab64_200(x number) tablespace demo64 storage (initial 200K next 20k);
　　Table created
　　SQL> select a.table_name,
　　 2a.initial_extent / 1024 "INIT_EXTENT(K)",
　　 3a.next_extent / 1024 "NEXT_EXTENT(K)"
　　 4 from user_tables a
　　 5 where a.table_name = 'DEMOTAB64_200';
　　TABLE_NAMEINIT_EXTENT(K) NEXT_EXTENT(K)
　　-------------------------- -------------- --------------
　　DEMOTAB64_20020064
　　注意: initial > uniform size时, 初始化区的大小initial的大小.
　　SQL> select a.bytes / 1024 "INIT_EXTENT(K)" from user_extents a where a.segment_name = 'DEMOTAB64_200' and a.extent_id = 0;
　　INIT_EXTENT(K)
　　--------------
　　 64
　　SQL> select count(*) from user_extents where segment_name = 'DEMOTAB64_200';
　　 COUNT(*)
　　----------
　　4
　　注意: 此时分配的区已经不是1个了, 是4个. 在这种情况下initial就有起做作用. 分配区的数量为: 取整(initial/uniform size) + 1
　　
　　结论: 在uniform size时, initial不管为多少时, 这个段的每一个区大小都为uniform size的大小.
　　5 用autoallocate方式的本地管理表空间
　　5.1 当storage参数中的initial为空时
　　SQL> create tablespace demoa datafile '/oradata/ltest/demoa.dbf' size 10m extent management local autoallocate;
　　Tablespace created
　　SQL> select a.initial_extent / 1024 "INIT_EXTENT(K)",
　　 2a.next_extent / 1024 "NEXT_EXTENT(K)"
　　 3from user_tablespaces a
　　 4where a.tablespace_name = 'DEMOA';
　　INIT_EXTENT(K) NEXT_EXTENT(K)
　　-------------- --------------
　　64
　　SQL> create table demoatab(x number) tablespace demoa;
　　Table created
　　SQL> select a.table_name,
　　 2a.initial_extent / 1024 "INIT_EXTENT(K)",
　　 3a.next_extent / 1024 "NEXT_EXTENT(K)"
　　 4from user_tables a
　　 5where a.table_name = 'DEMOATAB';
　　TABLE_NAMEINIT_EXTENT(K) NEXT_EXTENT(K)
　　------------------------- -------------- --------------
　　DEMOATAB64
　　SQL> select count(*) from user_extents where segment_name = 'DEMOATAB';
　　 COUNT(*)
　　----------
　　 1
　　此后不断增加数据，可以发现：
　　SQL> select a.segment_name, a.bytes, a.blocks from user_extents a where a.segment_name = 'DEMOATAB';
　　SEGMENT_NA BYTES BLOCKS
　　---------- ---------- ----------
　　DEMOATAB　 65536 8
　　DEMOATAB　 65536 8
　　DEMOATAB　 65536 8
　　DEMOATAB　 65536 8
　　DEMOATAB　 65536 8
　　DEMOATAB　 65536 8
　　DEMOATAB　 65536 8
　　DEMOATAB　 65536 8
　　DEMOATAB　 65536 8
　　DEMOATAB　 65536 8
　　DEMOATAB　 65536 8
　　DEMOATAB　 65536 8
　　DEMOATAB　 65536 8
　　DEMOATAB　 65536 8
　　DEMOATAB　 65536 8
　　DEMOATAB　 65536 8
　　DEMOATAB　 1048576 128
　　DEMOATAB　 1048576 128
　　DEMOATAB　 1048576 128
　　DEMOATAB　 1048576 128
　　DEMOATAB　 1048576 128
　　DEMOATAB　 1048576 128
　　DEMOATAB　 1048576 128
　　23 rows selected
　　当自动分配时，发现开始第一个区分配8个块(64K), 到17区开始, 每个区分配128个块(大小1M). 我做过实验当initial足够大时, 第一个区的大小不一定都是64K, 可以是1M, 8M, 64M 甚至是256M.
　　5.2 当initial < uniform size时
　　SQL> create table demoatab_1(x number) tablespace demoa storage (initial 1K next 5k);
　　Table created
　　SQL> select a.table_name,
　　 2a.initial_extent / 1024 "INIT_EXTENT(K)",
　　 3a.next_extent / 1024 "NEXT_EXTENT(K)"
　　 4 from user_tables a
　　 5where a.table_name = 'DEMOATAB_1';
　　TABLE_NAMEINIT_EXTENT(K) NEXT_EXTENT(K)
　　-------------------------- -------------- --------------
　　DEMOATAB_116
　　SQL> select a.bytes / 1024 "INIT_EXTENT(K)" from user_extents a where a.segment_name = 'DEMOATAB_1' and a.extent_id = 0;
　　INIT_EXTENT(K)
　　--------------
　　64
　　SQL> select count(*) from user_extents where segment_name = 'DEMOATAB_1';
　　 COUNT(*)
　　----------
　　 1
　　5.3 当initial > uniform size时
　　SQL> create table demoatab_200(x number) tablespace demoa storage (initial 200K next 5k);
　　Table created
　　SQL> select a.table_name,
　　 2a.initial_extent / 1024 "INIT_EXTENT(K)",
　　 3a.next_extent / 1024 "NEXT_EXTENT(K)"
　　 4 from user_tables a
　　 5where a.table_name = 'DEMOATAB_200';
　　TABLE_NAMEINIT_EXTENT(K) NEXT_EXTENT(K)
　　--------------------------- -------------- --------------
　　DEMOATAB_200200
　　SQL> select a.bytes / 1024 "INIT_EXTENT(K)" from user_extents a where a.segment_name = 'DEMOATAB_1' and a.extent_id = 0;
　　INIT_EXTENT(K)
　　--------------
　　64
　　SQL> select count(*) from user_extents where segment_name = 'DEMOATAB_200';
　　 COUNT(*)
　　----------
　　 4
　　结论: 1. ORACLE通过强制性的手段使本地管理表空间中的所有Extent是同样大小的, 尽管可能自定义了不同的存储参数. 2. 在自动分配的本地管理的表空间中, 区间尺寸可能由以下尺寸组成64K, 1M, 8M, 64M 甚至是256M. 但是不管多大, 都有一个通用尺寸64k, 所以64K就是该表空间的位大小.
　　6 检查uet$与fet$是否有数据
　　SQL> select file#, name from v$datafile;
　　 FILE# NAME----------------------------------------
　　 1 /oradata/LTEST/datafile/o1_mf_system_79q5214w_.dbf
　　 2 /oradata/LTEST/datafile/o1_mf_undotbs1_79q521ct_.dbf
　　 3 /oradata/LTEST/datafile/o1_mf_sysaux_79q52169_.dbf
　　 4 /oradata/LTEST/datafile/o1_mf_users_79q521do_.dbf
　　 5 /oradata/LTEST/datafile/o1_mf_example_79q55jt4_.dbf
　　 6 /oradata/LTEST/datafile/o1_mf_bigtbs_7ct5vw4x_.dbf
　　 12 /oradata/ltest/demo64.dbf
　　 13 /oradata/ltest/demo1024.dbf
　　 14 /oradata/ltest/demoa.dbf
　　9 rows selected
　　可以检查uet$与fet$
　　SQL> select count(*) from uet$ where file# = 12;
　　 COUNT(*)
　　----------
　　 0
　　SQL> select count(*) from fet$ where file# = 12;
　　 COUNT(*)
　　----------
　　 0
　　采用本地管理的表空间, 这两张视图中没有数据. 下面就通过Dump块的信息, 来进一步分析本地管理表空间的特点.
　　7 Dump数据文件中位图信息(第3个块到第8个块)
　　7.1 dump第三个块
　　数据文件的前两个块是文件头, 所以dump第3个块. 从第3个块到第8个块是该数据文件的数据文件的位图区. 如果db_block_size为8192, 那么占用的空间为64K. http://blog.csdn.net/huang_xw/article/details/6966245文也用另一种不是很严谨的方法验证了占用64K大小的问题.
　　SQL> alter system dump datafile 12 block 3;
　　System altered
　　Dump出来的信息如下:
　　Start dump data blocks tsn: 13 file#: 12 minblk 3 maxblk 3
　　buffer tsn: 13 rdba: 0x03000003 (12/3)
　　scn: 0x0000.0011ee0d seq: 0x01 flg: 0x04 tail: 0xee0d1e01
　　frmt: 0x02 chkval: 0x430e type: 0x1e=KTFB Bitmapped File Space Bitmap
　　Hex dump of block: st=0, typ_found=1
　　Dump of memory from 0x00000000064EFC00 to 0x00000000064F1C00
　　0064EFC00 0000A21E 03000003 0011EE0D 04010000 [................]
　　0064EFC10 0000430E 0000000C 00000009 00000000 [.C..............]
　　0064EFC20 00000001 0000F7F7 00000000 00000000 [................]
　　0064EFC30 00000000 00000000 00000FF1 00000000 [................]
　　0064EFC40 00000000 00000000 00000000 00000000 [................]
　　 Repeat 506 times
　　0064F1BF0 00000000 00000000 00000000 EE0D1E01 [................]
　　File Space Bitmap Block:
　　BitMap Control: 这句话说明该块还是位图区(3-8块都这样子, 可dump每个块出来验证)
　　RelFno: 12, BeginBlock: 9, Flag: 0, First: 1, Free: 63479
　　F10F000000000000 0000000000000000 0000000000000000 0000000000000000 (共248行)
　　0000000000000000 0000000000000000 0000000000000000 0000000000000000
　　……
　　0000000000000000 0000000000000000 0000000000000000 0000000000000000
　　End dump data blocks tsn: 13 file#: 12 minblk 3 maxblk 3
　　
　　共248行, 每行32个字节, 每个字节8位, 共有位数: 248 * 32 * 8 = 63488
　　前面两节的内容是: F10F => 1111 0001 0000 1111 => 9个位为1, 与下面通过user_extents算出来的一样. 还有空闲区共有: 63488 - 9 = 63479 (注意: 位大小为1的个数与extent个数相等, 只是一个巧合. 因为位图管理中位大小为1对应的是8个block的使用情况, 当一个区的分配大小不为8个block时, 比如128个block时, 两者就不会相等了.)
　　
　　可看表空间DEMO64中已经用了几个区.
　　SQL> select count(*) from user_extents a where a.tablespace_name = 'DEMO64';
　　 COUNT(*)
　　----------
　　 9
　　7.2 先扩展后, 再dump第三个块
　　SQL> alter table demotab64 allocate extent;
　　Table altered
　　SQL> alter system dump datafile 12 block 3;
　　System altered
　　
　　Dump出来的信息如下:
　　Start dump data blocks tsn: 13 file#: 12 minblk 3 maxblk 3
　　buffer tsn: 13 rdba: 0x03000003 (12/3)
　　scn: 0x0000.0011fc4f seq: 0x01 flg: 0x00 tail: 0xfc4f1e01
　　frmt: 0x02 chkval: 0x0000 type: 0x1e=KTFB Bitmapped File Space Bitmap
　　Hex dump of block: st=0, typ_found=1
　　Dump of memory from 0x00000000064EFC00 to 0x00000000064F1C00
　　0064EFC00 0000A21E 03000003 0011FC4F 00010000 [........O.......]
　　0064EFC10 00000000 0000000C 00000009 00000000 [................]
　　0064EFC20 00000002 0000F7F6 00000000 00000000 [................]
　　0064EFC30 00000000 00000000 00000FF3 00000000 [................]
　　0064EFC40 00000000 00000000 00000000 00000000 [................]
　　 Repeat 506 times
　　0064F1BF0 00000000 00000000 00000000 FC4F1E01 [..............O.]
　　File Space Bitmap Block:
　　BitMap Control:
　　RelFno: 12, BeginBlock: 9, Flag: 0, First: 2, Free: 63478
　　F30F000000000000 0000000000000000 0000000000000000 0000000000000000
　　0000000000000000 0000000000000000 0000000000000000 0000000000000000
　　……
　　0000000000000000 0000000000000000 0000000000000000 0000000000000000
　　End dump data blocks tsn: 13 file#: 12 minblk 3 maxblk 3
　　
　　前面两节的内容是: F30F => 1111 0011 0000 1111 => 10个位为1.
　　说明通过语句”alter table demotab64 allocate extent”, 又增加了一个区的分配.
　　8 Dump数据文件中数据信息(比如第9个块)
　　查看dba_extents视图, 也可以发现表DEMOTAB64从第9个块开始分配第一个区.
　　SQL> select a.segment_name, a.file_id, a.block_id, a.extent_id from dba_extents a where a.segment_name = 'DEMOTAB64';
　　SEGMENT_NAME FILE_ID BLOCK_IDEXTENT_ID
　　-------------- ---------- ---------- ----------
　　DEMOTAB641290
　　DEMOTAB6412171
　　
　　Dump第9个块, 这个块相当表头的信息.
　　SQL> alter system dump datafile 12 block 9;
　　System altered
　　Dump出来的信息如下:
　　Start dump data blocks tsn: 13 file#: 12 minblk 9 maxblk 9
　　buffer tsn: 13 rdba: 0x03000009 (12/9)
　　scn: 0x0000.0011fc4f seq: 0x02 flg: 0x04 tail: 0xfc4f2002
　　frmt: 0x02 chkval: 0x5aaf type: 0x20=FIRST LEVEL BITMAP BLOCK
　　Hex dump of block: st=0, typ_found=1
　　Dump of memory from 0x00000000064EFC00 to 0x00000000064F1C00
　　0064EFC00 0000A220 03000009 0011FC4F 04020000 [ .......O.......]
　　0064EFC10 00005AAF 00000000 00000000 00000000 [.Z..............]
　　0064EFC20 00000000 00000000 00000000 00000000 [................]
　　 Repeat 1 times
　　0064EFC40 00000000 00000000 00000000 00000004 [................]
　　0064EFC50 FFFFFFFF 0000000D 00000003 00000010 [................]
　　0064EFC60 00010002 00000000 00000000 00000000 [................]
　　0064EFC70 00000000 00000003 00000000 00000000 [................]
　　0064EFC80 00000000 00220008 000001C4 00000003 [......".........]
　　0064EFC90 0300000A 00000000 00000000 00000003 [................]
　　0064EFCA0 00000008 0300000C 00000000 00000000 [................]
　　0064EFCB0 00000000 00000000 00000000 00000001 [................]
　　0064EFCC0 0000CE6D 00000000 00000000 03000009 [m...............]
　　0064EFCD0 00000008 00000000 03000011 00000008 [................]
　　0064EFCE0 00000008 00000000 00000000 00000000 [................]
　　0064EFCF0 00000000 00000000 00000000 00000000 [................]
　　 Repeat 8 times
　　0064EFD80 00000000 00000000 00000000 00001011 [................]
　　0064EFD90 00000000 00000000 00000000 00000000 [................]
　　 Repeat 485 times
　　0064F1BF0 00000000 00000000 00000000 FC4F2002 [............. O.]
　　Dump of First Level Bitmap Block
　　--------------------------------
　　 nbits : 4 nranges: 2 parent dba: 0x0300000a poffset: 0
　　 unformatted: 13 total: 16 first useful block: 3
　　 owning instance : 1
　　 instance ownership changed at
　　 Last successful Search
　　 Freeness Status: nf1 0 nf2 0 nf3 0 nf4 0
　　
　　 Extent Map Block Offset: 4294967295
　　 First free datablock : 3
　　 Bitmap block lock opcode 3
　　 Locker xid: : 0x0008.022.000001c4
　　 Inc #: 0 Objd: 52845
　　 HWM Flag: HWM Set
　　 Highwater:: 0x0300000c ext#: 0 blk#: 3 ext size: 8
　　 #blocks in seg. hdr's freelists: 0
　　 #blocks below: 0
　　 mapblk 0x00000000 offset: 0
　　 --------------------------------------------------------
　　 DBA Ranges :
　　 --------------------------------------------------------
　　 0x03000009 Length: 8 Offset: 0
　　 0x03000011 Length: 8 Offset: 8
　　
　　 0:Metadata 1:Metadata 2:Metadata 3:unformatted
　　 4:unformatted 5:unformatted 6:unformatted 7:unformatted
　　 8:unformatted 9:unformatted 10:unformatted 11:unformatted
　　 12:unformatted 13:unformatted 14:unformatted 15:unformatted
　　 --------------------------------------------------------
　　End dump data blocks tsn: 13 file#: 12 minblk 9 maxblk 9