关于数据文件中数据存储的一点浅见！

表空间（tablespace），算是Oracle数据库一个至关重要的概念了，而表空间又是有一至多个数据文件（datafile）文件组成。

从表空间开始，其内部从大到小，又分为段（segment）、区（extent）、块（block）。

块作为数据库最小存储单位，那么它是怎么在数据文件中存储的呢？我一直就很疑惑，
今天通过dump文件，终于对Block在ASSM表空间的存储有了一点比较清晰的认识了。

下面是本次试验的结果

1、        首先看看数据库的版本：

SQL> SELECT * FROM V$VERSION;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
PL/SQL Release 10.2.0.1.0 - Production
CORE    10.2.0.1.0      Production
TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 – Production

2、        创建一个ASSM表空间：

SQL>CREATE TABLESPACE TEST DATAFILE ‘D:\TEST01.DBF’ SIZE 50M EXTENT MANAGEMENT LOCAL
2  SEGMENT SPACE MANAGEMENT AUTO UNIFORM. SIZE 1M;

表空间已创建。

查看一下刚才创建的表空间:

SQL>SELECT TABLESPACE_NAME,BLOCK_SIZE,EXTENT_MANAGEMENT,ALLOCATION_TYPE,SEGMENT_SPACE_MANAGEMENT
  2  FROM USER_TABLESPACES WHERE TABLESPACE_NAME='TEST';

TABLESPACE_NAME                BLOCK_SIZE EXTENT_MAN ALLOCATIO SEGMEN
------------------------------ ---------- ---------- --------- ------
TEST                                 8192 LOCAL      UNIFORM   AUTO

3、        创建测试表

SQL> CREATE TABLE TEST (ID NUMBER) TABLESPACE TEST;

表已创建。

SQL> ANALYZE TABLE TEST COMPUTE STATISTICS;

表已分析。

SQL> SET LINESIZE 100
SQL> SELECT TABLE_NAME,TABLESPACE_NAME,BLOCKS,EMPTY_BLOCKS FROM USER_TABLES
  2  WHERE TABLE_NAME='TEST';

TABLE_NAME                     TABLESPACE_NAME                    BLOCKS EMPTY_BLOCKS
------------------------------ ------------------------------ ---------- ------------
TEST                           TEST                                    0          128

注意：由于test表时刚刚创建的表，所以block为0， 但是并不表示test这个segment没有使用数据块，只是用来存储数据的块数为0，由于表空间设置了uniform统一extent大小为1M，故此，test表有128个empty_block
128 * 8k = 1M。

接下来就可以进行详细的分析步骤了：

SQL> SET SERVEROUTPUT ON;
SQL> exec show_space('TEST','SYS');
Total Blocks--------------------------------------128
Total Bytes---------------------------------------1048576
Unused Blocks-------------------------------------124
Unused Bytes--------------------------------------1015808
Last Used FileId----------------------------------7
Last Used BlockId---------------------------------9
Last Used Block-----------------------------------4

PL/SQL 过程已成功完成。

从以上结果，我们可以看出，Last Used BlockId = 9，也就是表明，建表过程中，数据文件中的block是从第9个开始分配的，那么，前面从block 1 一直到 block 8都是系统预留给数据文件的，用来保存数据文件头和空间使用情况等信息的。

先分析数据文件前8个block的内容，其中block1是数据文件的文件头，block2~block8是存放ASSM位图信息的，用来管理整个数据文件的空间使用情况：

对于block1，不能使用像一般数据块一样的dump，
例如：
SQL> conn /as sysdba
已连接。
SQL> alter system dump datafile 7 block 1;

系统已更改。

表面上是dump出来了，但是查看dump文件时，发现：

Start dump data blocks tsn: 6 file#: 7 minblk 1 maxblk 1
Block 1 (file header) not dumped: use dump file header command
End dump data blocks tsn: 6 file#: 7 minblk 2 maxblk 1

必须使用文件头的dump语句，我这里使用的是：

SQL> ALTER SYSTEM SET EVENTS 'IMMEDIATE TRACE NAME FILE_HDRS LEVEL 10';

系统已更改。

SQL> @GET_TRACEFILE

跟踪文件
--------------------------------------------------------------------------
f:\oracle\product\10.2.0\admin\hongye\udump\hongye_ora_6132.trc

下面是得到的文件头信息，我这里只截取了datafile 7，也就是刚才创建的表空间的相关信息：

DATA FILE #7:
  (name #39) D:\TEST01.DBF
creation size=6400 block size=8192 status=0xe head=39 tail=39 dup=1         

--此处显示该数据文件的一些基本信息，6400即Block数量，6400 * 8k = 50M，刚好是数据文件的size，block size是db_block_size，位置是存储在D:\TEST01.DBF。

tablespace 6, index=9 krfil=7 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:2 scn: 0x0000.0017d6ed 08/22/2010 15:20:57
Stop scn: 0xffff.ffffffff 08/22/2010 15:20:57
Creation Checkpointed at scn:  0x0000.0017d6ec 08/22/2010 15:20:57
thread:1 rba 0x3f.6598.10)
enabled  threads:  01000000 00000000 00000000 00000000 00000000 00000000
. . . . . .       --（此处略掉一些重复的信息）
  00000000 00000000 00000000 00000000 00000000 00000000
Hot Backup end marker scn: 0x0000.00000000
aux_file is NOT DEFINED
V10 STYLE. FILE HEADER:
        Compatibility Vsn = 169869568=0xa200100
        Db ID=2405770514=0x8f652512, Db Name='HONGYE'
        Activation ID=0=0x0
        Control Seq=2186=0x88a, File size=6400=0x1900
        File Number=7, Blksiz=8192, File Type=3 DATA
Tablespace #6 - TEST  rel_fn:7
Creation   at   scn: 0x0000.0017d6ec 08/22/2010 15:20:57
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
reset logs count:0x2b34fcd2 scn: 0x0000.00000001 reset logs terminal rcv data:0x0 scn: 0x0000.00000000
prev reset logs count:0x0 scn: 0x0000.00000000 prev reset logs terminal rcv data:0x0 scn: 0x0000.00000000
recovered at 01/01/1988 00:00:00
status:0x4 root dba:0x00000000 chkpt cnt: 2 ctl cnt:1
begin-hot-backup file size: 0
Checkpointed at scn:  0x0000.0017d6ed 08/22/2010 15:20:57
thread:1 rba 0x3f.6598.10)
enabled  threads:  01000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
   . . . . . .     --（此处略掉一些重复的信息）
  00000000 00000000 00000000 00000000 00000000 00000000
External cache id: 0x0 0x0 0x0 0x0
Absolute fuzzy scn: 0x0000.00000000
Recovery fuzzy scn: 0x0000.00000000 01/01/1988 00:00:00
Terminal Recovery Stamp  01/01/1988 00:00:00
Platform. Information:         Creation Platform. ID: 7
Current Platform. ID: 7        Last Platform. ID: 7

Block2就是File Space Header Block了，从这里开始，就记录了与数据文件里使用空间相关的信息 了。

下面是Block2的trace文件：

Dump file f:\oracle\product\10.2.0\admin\hongye\udump\hongye_ora_2272.trc
Sun Aug 22 16:12:15 2010
ORACLE V10.2.0.1.0 - Production vsnsta=0
vsnsql=14 vsnxtr=3
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
Windows NT Version V6.1
CPU                 : 2 - type 586, 2 Physical Cores
Process Affinity    : 0x00000000
Memory (Avail/Total): Ph:1178M/2047M, Ph+PgF:2408M/4095M, VA:1476M/2047M
Instance name: hongye

Redo thread mounted by this instance: 1

Oracle process number: 18

Windows thread id: 2272, image: ORACLE.EXE (SHAD)


*** 2010-08-22 16:12:16.001
*** SERVICE NAME SYS$USERS) 2010-08-22 16:12:15.734
*** SESSION ID 26.496) 2010-08-22 16:12:15.734
Start dump data blocks tsn: 6 file#: 7 minblk 2 maxblk 2
buffer tsn: 6 rdba: 0x01c00002 (7/2)
scn: 0x0000.0017d80f seq: 0x02 flg: 0x04 tail: 0xd80f1d02
frmt: 0x02 chkval: 0xbb79 type: 0x1d=KTFB Bitmapped File Space Header
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x08C32200 to 0x08C34200
8C32200 0000A21D 01C00002 0017D80F 04020000  [................]
. . . . . .    --（省略重复信息）
8C341F0 00000000 00000000 00000000 D80F1D02  [................]
File Space Header Block:
Header Control:
RelFno: 7, Unit: 128, Size: 6400, Flag: 1
AutoExtend: NO, Increment: 0, MaxSize: 0           --这里是表空间的一些相关属性。
Initial Area: 7, Tail: 6280, First: 1, Free: 48
Deallocation scn: 0.0
Header Opcode:
Save: No Pending Op
End dump data blocks tsn: 6 file#: 7 minblk 2 maxblk 2

对于block3~block8这6个block，
这可以使用alter system dump datafile 7 block n;来dump出来，其实这6个block的内容是很相似的，现以block3为例：

Start dump data blocks tsn: 6 file#: 7 minblk 3 maxblk 3
buffer tsn: 6 rdba: 0x01c00003 (7/3)
scn: 0x0000.0017d80f seq: 0x01 flg: 0x04 tail: 0xd80f1e01
frmt: 0x02 chkval: 0x4e3b type: 0x1e=KTFB Bitmapped File Space Bitmap
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x08C32200 to 0x08C34200
8C32200 0000A21E 01C00003 0017D80F 04010000  [................]
. . . . . .    --（省略重复信息）
8C341F0 00000000 00000000 00000000 D80F1E01  [................]
File Space Bitmap Block:
BitMap Control:
RelFno: 7, BeginBlock: 9, Flag: 0, First: 1, Free: 63487
0100000000000000 0000000000000000 0000000000000000 0000000000000000
. . . . . .                   --（此处略去相同的内容）
0000000000000000 0000000000000000 0000000000000000 0000000000000000
End dump data blocks tsn: 6 file#: 7 minblk 3 maxblk 3

此处显示01，转化成二进制就是0000 0001，交换位序，转化成实际的顺序为 1000 0000，
即第一个block，从文件中可用发现beginBlock=9，即第九号Block，即为test表extent所占用的第一个位置。

至此，数据文件的保留块就全部分析完毕了，总共8块，8 * 8k = 64k （这是由于我的db_block_size = 8k的原因，其实在db_block_size = 32k的时候，是要保留129k的系统空间的）。

下面分析表中的数据在数据文件中的存储：


SQL> select * from test;

未选定行

现在表中是没有数据的，刚才上面也已经查过了，使用的block=0（其实是真是数据使用的block=0）；

从系统块信息中，我们推测出了，test表的使用空间从9号blocks开始，

SQL> COL SEGMENT_NAME FOR A10
SQL> SELECT SEGMENT_NAME,HEADER_FILE,HEADER_BLOCK FROM DBA_SEGMENTS
  2  WHERE SEGMENT_NAME='TEST';

SEGMENT_NA HEADER_FILE HEADER_BLOCK
---------- ----------- ------------
TEST                 7           12

通过查询dba_segments视图，却发现header_block从12开始的，

这就说名block9、block10、block11存储的不是表中的实际数据，下面通过dump文件说明这三个块的作用


SQL> ALTER SYSTEM DUMP DATAFILE 7 BLOCK 9;

系统已更改。

SQL> @GET_TRACEFILE

跟踪文件
-------------------------------------------------------------------
f:\oracle\product\10.2.0\admin\hongye\udump\hongye_ora_2272.trc

下面是trace文件内容：

Start dump data blocks tsn: 6 file#: 7 minblk 9 maxblk 9
buffer tsn: 6 rdba: 0x01c00009 (7/9)
scn: 0x0000.0017d812 seq: 0x01 flg: 0x04 tail: 0xd8122001
frmt: 0x02 chkval: 0x5acc type: 0x20=FIRST LEVEL BITMAP BLOCK
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x08C32200 to 0x08C34200
8C32200 0000A220 01C00009 0017D812 04010000  [ ...............]
  . . . . . .            --（此处省略重复的内容）
8C341F0 00000000 00000000 00000000 D8122001  [............. ..]
Dump of First Level Bitmap Block        --说明 Block9是 L1的位图块
--------------------------------
   nbits : 4 nranges: 1         parent dba:  0x01c0000b   poffset: 0     
   unformatted: 60      total: 64        first useful block: 4   
   
--Block9管理64个Block，其中60个未使用，4个已经使用了，已使用的4个块包括：L1块9和10，L2块11和extent的头块12。

   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 : 4      
   Bitmap block lock opcode 0
   Locker xid:     :  0x0000.000.00000000
   Inc #: 0 Objd: 52561
  HWM Flag: HWM Set
       Highwater::  0x01c0000d  ext#: 0      blk#: 4      ext size: 128   
  #blocks in seg. hdr's freelists: 0     
  #blocks below: 0     
  mapblk  0x00000000  offset: 0     
  --------------------------------------------------------
  DBA Ranges :
  --------------------------------------------------------
   0x01c00009  Length: 64     Offset: 0      
  
-- 此处是 Block 9 管理的Block的详细使用情况，前4个是元数据块，不存实际数据，
-- unformatted表示为格式化块。另外根据使用情况，可分为0~25 free、25~50 free、50~75free和full等。

   0:Metadata   1:Metadata   2:Metadata   3:Metadata
   4:unformatted   5:unformatted   6:unformatted   7:unformatted
   8:unformatted   9:unformatted   10:unformatted   11:unformatted
   12:unformatted   13:unformatted   14:unformatted   15:unformatted
   16:unformatted   17:unformatted   18:unformatted   19:unformatted
   20:unformatted   21:unformatted   22:unformatted   23:unformatted
   24:unformatted   25:unformatted   26:unformatted   27:unformatted
   28:unformatted   29:unformatted   30:unformatted   31:unformatted
   32:unformatted   33:unformatted   34:unformatted   35:unformatted
   36:unformatted   37:unformatted   38:unformatted   39:unformatted
   40:unformatted   41:unformatted   42:unformatted   43:unformatted
   44:unformatted   45:unformatted   46:unformatted   47:unformatted
   48:unformatted   49:unformatted   50:unformatted   51:unformatted
   52:unformatted   53:unformatted   54:unformatted   55:unformatted
   56:unformatted   57:unformatted   58:unformatted   59:unformatted
   60:unformatted   61:unformatted   62:unformatted   63:unformatted
  --------------------------------------------------------
End dump data blocks tsn: 6 file#: 7 minblk 9 maxblk 9

从上面的文件中，我们发现，block9实际上是Level 1的位图块，记录test表中每个块的使用情况。
经过测试，block10和block9内容很相似，也是Level 1 的位图块。

再看block11

SQL> ALTER SYSTEM DUMP DATAFILE 7 BLOCK 11;

系统已更改。

SQL> @GET_TRACEFILE

跟踪文件
------------------------------------------------------------------
f:\oracle\product\10.2.0\admin\hongye\udump\hongye_ora_2272.trc

trace文件的内容截取如下：

Start dump data blocks tsn: 6 file#: 7 minblk 11 maxblk 11
buffer tsn: 6 rdba: 0x01c0000b (7/11)
scn: 0x0000.0017d811 seq: 0x01 flg: 0x04 tail: 0xd8112101
frmt: 0x02 chkval: 0x4a62 type: 0x21=SECOND LEVEL BITMAP BLOCK
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x08C32200 to 0x08C34200
8C32200 0000A221 01C0000B 0017D811 04010000  [!...............]
  . . . . . .            --（此处省略重复的内容）
8C341F0 00000000 00000000 00000000 D8112101  [.............!..]
Dump of Second Level Bitmap Block
    number: 2       nfree: 2       ffree: 0      pdba:     0x01c0000c
   Inc #: 0 Objd: 52561
  opcode:0
xid:
  L1 Ranges :
  --------------------------------------------------------
   0x01c00009  Free: 5 Inst: 1       --此处指向Block9
   0x01c0000a  Free: 5 Inst: 1       --此处指向Block10
  
  --------------------------------------------------------
End dump data blocks tsn: 6 file#: 7 minblk 11 maxblk 11

从上面我发现，block11其实是Level 2 的位图块，指向了两个Level 1的位图块。

至此，和test表相关的位图块也已经分析完毕了。

从block 12开始，存储的就是实际的表中的数据了，下面看下Block12在没有数据情况下的trace文件：

SQL> ALTER SYSTEM DUMP DATAFILE 7 BLOCK 12;

系统已更改。

SQL> @GET_TRACEFILE

跟踪文件
--------------------------------------------------------------------
f:\oracle\product\10.2.0\admin\hongye\udump\hongye_ora_2272.trc

相应的trace文件内容为：

Start dump data blocks tsn: 6 file#: 7 minblk 12 maxblk 12
buffer tsn: 6 rdba: 0x01c0000c (7/12)
scn: 0x0000.0017d812 seq: 0x01 flg: 0x04 tail: 0xd8122301
frmt: 0x02 chkval: 0x66cd type: 0x23=PAGETABLE SEGMENT HEADER
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x08C32200 to 0x08C34200
8C32200 0000A223 01C0000C 0017D812 04010000  [#...............]
  . . . . . .            --（此处省略重复的内容）
8C341F0 00000000 00000000 00000000 D8122301  [.............#..]
   Extent Control Header            -区的头块
  -----------------------------------------------------------------
  Extent Header:: spare1: 0      spare2: 0      #extents: 1      #blocks: 128   
                  last map  0x00000000  #maps: 0      offset: 2716  
       Highwater::  0x01c0000d  ext#: 0      blk#: 4      ext size: 128    --记录了高水位的相关信息
  #blocks in seg. hdr's freelists: 0     
  #blocks below: 0     
  mapblk  0x00000000  offset: 0     
                   Unlocked
  --------------------------------------------------------
  Low HighWater Mark :               --这里记录的是低高水位的信息，本例中，二者是一样的。
      Highwater::  0x01c0000d  ext#: 0      blk#: 4      ext size: 128   
  #blocks in seg. hdr's freelists: 0     
  #blocks below: 0     
  mapblk  0x00000000  offset: 0     
  Level 1 BMB for High HWM block: 0x01c00009
  Level 1 BMB for Low HWM block: 0x01c00009       --当前HWM的1级位图块
  --------------------------------------------------------
  Segment Type: 1 nl2: 1      blksz: 8192   fbsz: 0      
  L2 Array start offset:  0x00001434
  First Level 3 BMB:  0x00000000
  L2 Hint for inserts:  0x01c0000b
  Last Level 1 BMB:  0x01c0000a                    --一级位图块
  Last Level II BMB:  0x01c0000b                    --二级位图块
  Last Level III BMB:  0x00000000                   --三级位图块
     Map Header:: next  0x00000000  #extents: 1    obj#: 52561  flag: 0x10000000
  Inc # 0
  Extent Map
  -----------------------------------------------------------------
   0x01c00009  length: 128   
  
  Auxillary Map
  --------------------------------------------------------
   Extent 0     :  L1 dba:  0x01c00009 Data dba:  0x01c0000d
  --------------------------------------------------------
  
   Second Level Bitmap block DBAs
   --------------------------------------------------------
   DBA 1:   0x01c0000b
  
End dump data blocks tsn: 6 file#: 7 minblk 12 maxblk 12

我们可以看到Block12 是Extent Control Header，是整个区的控制头文件，存放着全区的的信息。

下面再测试一下，如果表中存在数据的话，这些数据是怎么存储的 ！！！

现在想test表中插入10100条记录

SQL> BEGIN
  2  FOR I IN 1..10100 LOOP
  3  INSERT INTO TEST VALUES(I);
  4  END LOOP;
  5  END;
  6  /

PL/SQL 过程已成功完成。

SQL> SELECT COUNT(*) FROM TEST;

  COUNT(*)
----------
     10100

SQL> exec show_space('TEST','SYS');
Total Blocks--------------------------------------128
Total Bytes---------------------------------------1048576
Unused Blocks-------------------------------------64
Unused Bytes--------------------------------------524288
Last Used FileId----------------------------------7
Last Used BlockId---------------------------------9
Last Used Block-----------------------------------64

PL/SQL 过程已成功完成。

再dump  block 9，可以发现extent中块的使用情况了：

下面是trace文件内容：
Start dump data blocks tsn: 6 file#: 7 minblk 9 maxblk 9
buffer tsn: 6 rdba: 0x01c00009 (7/9)
scn: 0x0000.0017e3e5 seq: 0x01 flg: 0x04 tail: 0xe3e52001
frmt: 0x02 chkval: 0x4f97 type: 0x20=FIRST LEVEL BITMAP BLOCK
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x08C32200 to 0x08C34200
8C32200 0000A220 01C00009 0017E3E5 04010000  [ ...............]
. . . . . .               --（此处省略重复的内容）
8C341F0 00000000 00000000 00000000 E3E52001  [............. ..]
Dump of First Level Bitmap Block
--------------------------------
   nbits : 4 nranges: 1         parent dba:  0x01c0000b   poffset: 0     
   unformatted: 0       total: 64        first useful block: 4      
   owning instance : 1
   instance ownership changed at 08/22/2010 17:00:02
   Last successful Search 08/22/2010 17:00:02
   Freeness Status:  nf1 0      nf2 0      nf3 0      nf4 45     

   Extent Map Block Offset: 4294967295
   First free datablock : 4      
   Bitmap block lock opcode 0
   Locker xid:     :  0x0000.000.00000000
   Inc #: 0 Objd: 52562
  HWM Flag: Not Set
      Highwater::  0x01c00049  ext#: 0      blk#: 64     ext size: 128   
  #blocks in seg. hdr's freelists: 0     
  #blocks below: 60   
  mapblk  0x00000000  offset: 0     
  --------------------------------------------------------
  DBA Ranges :
  --------------------------------------------------------
   0x01c00009  Length: 64     Offset: 0      
  
----这里我们明显可以发现，与刚才没有数据的时候，存在着很大的不同，从4~63这60个块中都有数据了，
----还可以通过dump  block10查看，可以发现Block9所管理的块都使用了，而Block10管理的块还都是unformatted状态。

   0:Metadata   1:Metadata   2:Metadata   3:Metadata
   4:75-100% free   5:75-100% free   6:75-100% free   7:FULL
   8:75-100% free   9:75-100% free   10:75-100% free   11:FULL
   12:75-100% free   13:75-100% free   14:75-100% free   15:FULL
   16:75-100% free   17:75-100% free   18:75-100% free   19:FULL
   20:75-100% free   21:75-100% free   22:FULL   23:75-100% free
   24:75-100% free   25:75-100% free   26:FULL   27:75-100% free
   28:75-100% free   29:75-100% free   30:FULL   31:75-100% free
   32:75-100% free   33:75-100% free   34:FULL   35:75-100% free
   36:75-100% free   37:75-100% free   38:FULL   39:75-100% free
   40:75-100% free   41:75-100% free   42:FULL   43:75-100% free
   44:75-100% free   45:75-100% free   46:FULL   47:75-100% free
   48:75-100% free   49:75-100% free   50:FULL   51:75-100% free
   52:75-100% free   53:75-100% free   54:FULL   55:75-100% free
   56:75-100% free   57:75-100% free   58:FULL   59:75-100% free
   60:75-100% free   61:75-100% free   62:FULL   63:75-100% free
  --------------------------------------------------------
End dump data blocks tsn: 6 file#: 7 minblk 9 maxblk 9

通过这次的dump，我们发现，数据在Block中的存储并不是顺序的，至于具体是怎么存储的，我还没弄清楚，只知道，Oracle将数据分布到了其中一个L1 块所管理的数据块。

通过dump  第16个块（当然也可以选其他的数据块了），可以看到存储的具体数据信息：

trace 文件的内容：

Start dump data blocks tsn: 6 file#: 7 minblk 16 maxblk 16
buffer tsn: 6 rdba: 0x01c00010 (7/16)
scn: 0x0000.0017e4af seq: 0x01 flg: 0x02 tail: 0xe4af0601
frmt: 0x02 chkval: 0x0000 type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x08C32200 to 0x08C34200
8C32200 0000A206 01C00010 0017E4AF 02010000  [................]
. . . . . .   --（省略相似内容）
8C341F0 48C20301 01012C3F 3E48C203 E4AF0601  [...H?,....H>....]
Block header dump:  0x01c00010
Object id on Block? Y
seg/obj: 0xcd52  csc: 0x00.17e3cf  itc: 2  flg: E  typ: 1 - DATA
     brn: 0  bdba: 0x1c00009 ver: 0x01 opc: 0
     inc: 0  exflg: 0

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0007.008.000001a5  0x008007a2.0069.34  --U-  660  fsc 0x0000.0017e4af
0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000

data_block_dump,data header at 0x8c32264
===============
tsiz: 0x1f98
hsiz: 0x53a
pbl: 0x08c32264
bdba: 0x01c00010
     76543210
flag=--------
ntab=1            --这部分是表的信息，ntab=1，一张表，nrow=660，660行数据
nrow=660
frre=-1
fsbo=0x53a
fseo=0xd93
avsp=0x32a
tosp=0x32a
0xe ti[0]        nrow=660        ffs=0
0x12 ri[0]        ffs=0x1f91
0x14 ri[1]        ffs=0x1f8a
0x16 ri[2]        ffs=0x1f83
0x18 ri[3]        ffs=0x1f7c
. . . . . .   --（省略相似内容）
block_row_dump:

tab 0, row 0, @0x1f91
tl: 7 fb: --H-FL-- lb: 0x1  cc: 1
col  0: [ 3]  c2 48 3e

--这里是具体每行的信息，row0：第一行； col 0：第一列，由于我创建的表只有1列，故这里只有col 0 。

tab 0, row 1, @0x1f8a
tl: 7 fb: --H-FL-- lb: 0x1  cc: 1
col  0: [ 3]  c2 48 3f
tab 0, row 2, @0x1f83
tl: 7 fb: --H-FL-- lb: 0x1  cc: 1
col  0: [ 3]  c2 48 40
tab 0, row 3, @0x1f7c
. . . . . .   --（省略相似内容）
end_of_block_dump
End dump data blocks tsn: 6 file#: 7 minblk 16 maxblk 16

至此，就可以了解到数据文件中，数据的大致存储方式了。

当然，以上只是我个人的浅见， 还望各路英雄豪杰能够不吝赐教和补充，

一切以弄清楚事实为目的 。 。 。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/24465008/viewspace-671583/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/24465008/viewspace-671583/