您的位置: 首页  >  IT文章  >  了解存储结构1

了解存储结构1

分类: IT文章 • 2023-11-22 15:43:43
理解存储结构1

存储结构

Extent:表空间中的基本单位

表空间区的管理方式

    LMT & DMT 
    LMT有两种方式控制区的大小
            autoallocate        # 自动分配
            uniform               # 由DBA指定每个区的大小

那么显然，当创建表空间时使用uniform size，每个区的大小一样，都为设定好的uniform size
而autoallocate是默认的分配方式，由oracle去管理，决定区的大小，也就是一个区有多少个块

那么我们就创建一个统一区大小表空间

create tablespace fan datafile '/u01/app/oracle/oradata/prod/fan01.dbf' size 50m uniform size 1m;

此时表空间FAN拥有一个50M的数据文件,区大小为1M(还未分配)

sys@PROD>select extent_id,file_id,tablespace_name,block_id,blocks from dba_extents where tablespace_name='FAN';


no rows selected

创建一个表FAN

scott@PROD>create table FAN(id number) tablespace FAN;

查看是否分配了区

sys@PROD>select extent_id,file_id,block_id,blocks from dba_extents where owner='&owner' and segment_name='&tablename';
Enter value for owner: SCOTT
Enter value for tablename: FAN
old   1: select extent_id,file_id,block_id,blocks from dba_extents where owner='&owner' and segment_name='&tablename'
new   1: select extent_id,file_id,block_id,blocks from dba_extents where owner='SCOTT' and segment_name='FAN'


no rows selected

为啥建了表没分配区呢？

了解存储结构1
在11g中由于新特性deferred segment creation的作用创建表时默认采用这个特性，即只在insert一行后才分配段
create table fan（id number) segment creation immediate;立即分配段
create table fan（id number) segment creation deferred;延迟分配段

可以通过show parameter来查看延迟段分配是否开启

sys@PROD>show parameter deferr

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
deferred_segment_creation            boolean     TRUE

插入一行数据

scott@PROD>insert into FAN values(1);

查看是否分配了区

sys@PROD>select extent_id,file_id,block_id,blocks from dba_extents where owner='&owner' and segment_name='&tablename';
Enter value for owner: SCOTT
Enter value for tablename: FAN
old   1: select extent_id,file_id,block_id,blocks from dba_extents where owner='&owner' and segment_name='&tablename'
new   1: select extent_id,file_id,block_id,blocks from dba_extents where owner='SCOTT' and segment_name='FAN'

 EXTENT_ID    FILE_ID   BLOCK_ID     BLOCKS
---------- ---------- ---------- ----------
         0          6        128        128

通过查询可以看到
表fan一开始只包含一个区，6号文件的128~255号块，共128个块，128*8=1024k
也就是说，fan表空间的第一个表从第128个块开始占用空间，每个区128个块

0~127号块为啥不用？

事实上，每个文件的前 128 个块，都是文件头，被 Oracle 留用了。在 Oracle 10g 中是 0 至 8 号块被 Oracle 留用。而从 Oracle 11GR2 开始，一下就留用 128 个块
这一部分文件头又分两部分，其中 0 号、 1 号块是真正的文件头， 2 ～ 127 号块是位图块。而在 Oracle10g 中， 2 ～ 8 号块则是位图块。

文件头记录了啥？

我们可以dump出文件头来查看一下

注意使用alter system dump datafile 6 block 0、1是无法获取文件头信息的,dump文件中会提示你使用dump file_hdrs

alter system set events 'immediate trace name file_hdrs level 10';

关于不同level获取到的信息内容自行百度吧

Trace file
/u01/app/oracle/diag/rdbms/prod/prod/trace/prod_ora_18177.trc Oracle
Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing
options ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1 System
name: Linux Node name: gc1 Release: 2.6.18-194.el5 Version: #1 SMP Tue
Mar 16 21:52:39 EDT 2010 Machine: x86_64 VM name: VMWare Version: 6
Instance name: prod Redo thread mounted by this instance: 1 Oracle
process number: 26 Unix process pid: 18177, image: oracle@gc1 (TNS
V1-V3)

* 2015-03-03 11:15:55.147
* SESSION ID:(37.495) 2015-03-03 11:15:55.147
* CLIENT ID:() 2015-03-03 11:15:55.147
* SERVICE NAME:(SYS$USERS) 2015-03-03 11:15:55.147
* MODULE NAME:(sqlplus@gc1 (TNS V1-V3)) 2015-03-03 11:15:55.147
* ACTION NAME:() 2015-03-03 11:15:55.147 Start dump data blocks tsn: 7 file#:6 minblk 0 maxblk 0 Block 1 (file header) not dumped:use
dump file header command End dump data blocks tsn: 7 file#: 6 minblk 2
maxblk 0

* 2015-03-03 11:17:50.688 DUMP OF DATA FILES: 8 files in database DATA FILE #1: name #7: /u01/app/oracle/oradata/prod/system01.dbf
creation size=0 block size=8192 status=0xe head=7 tail=7 dup=1
tablespace 0, index=1 krfil=1 prev_file=0 unrecoverable scn:
0x0000.00000000 01/01/1988 00:00:00 Checkpoint cnt:152 scn:
0x0000.001d5e22 03/02/2015 10:07:05 Stop scn: 0xffff.ffffffff
02/28/2015 00:20:44实力启动时stop scn是无穷大，如果关了库这个还是无穷大，说明是非正常关闭 Creation
Checkpointed at scn: 0x0000.00000007 09/17/2011 09:46:08 thread:0
rba:(0x0.0.0) enabled threads: 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 Offline scn: 0x0000.000f30db prev_range: 0 Online
Checkpointed at scn: 0x0000.000f30dc 02/08/2015 19:47:16 thread:1
rba:(0x1.2.0) enabled threads: 01000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 Hot Backup end marker scn: 0x0000.00000000
aux_file is NOT DEFINED Plugged readony: NO Plugin scnscn:
0x0000.00000000 Plugin resetlogs scn/timescn: 0x0000.00000000
01/01/1988 00:00:00 Foreign creation scn/timescn: 0x0000.00000000
01/01/1988 00:00:00 Foreign checkpoint scn/timescn: 0x0000.00000000
01/01/1988 00:00:00 Online move state: 0 V10 STYLE FILE HEADER:
Compatibility Vsn = 186646528=0xb200000控制文件的版本号 Db
ID=282994370=0x10de26c2, Db Name=’PROD’数据库的库名与dbid Activation
ID=0=0x0活动ID Control Seq=2739=0xab3, File size=93440=0x16d00control
seq表示控制文件序列号，更新控制文件的时候也会更新seq,如果控制文件中的control seq小于数据文件中的control
seq，表示控制文件来自于备份。 File Number=1, Blksiz=8192, File Type=3
DATA文件号，块大小，文件类型等等—TYPE=3表示普通的数据文件(包括undo,没有temp,temp的type=6,control
file 是type1) Tablespace #0 - SYSTEM rel_fn:1 这一片信息是从datafile header
block 2中得到的，转储level必须为3才能得到此信息
tablespace#0表示表空间序号可以查询vtablespace.ts#验证，rel_fn:1表示relative file  
  number可以通过vdba_data_files.relativ_fno查到 Creation at scn:
0x0000.00000007 09/17/2011
09:46:08这里表示这个数据文件建立的时间，因为我是通过DBCA创建数据库的，DBCA是根据模板克隆的，所以这里的建立时间为2011年
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00
thread:0RMAN是不会更新这个记录的，只有在SQL>中运行begin backup才会更新该信息 reset logs
count:0x33ecc944 scn: 0x0000.000f30dc prev reset logs
count:0x2d6c775c scn: 0x0000.00000001 recovered at 02/28/2015
00:20:57 status:0x2004 root dba:0x00400208 chkpt cnt: 152 ctl
cnt:151只有system文件才有root dba,用来定位bootstrap$
此外在控制文件和数据文件头都记录一个检查点计数(chkpt cnt或checkpoint
cnt)而且数据文件头还记录了一个控制文件检查点计数(ctl cnt),在以上输出中ctl cnt:151比控制文件中的checkpoint
cnt152要小1,这是因为当检查点更新控制文件和数据文件头上的chkpt cnt/checkpoint
cnt信息时,在更新控制文件之前,可以获得当前的控制文件的clt
cnt,这个信息被记入到数据文件头中,也就是ctlcnt:151,为什么要写这个ctl
cnt到数据文件头了.是因为不能保证当前更新控制文件上的checkpoint
cnt一定会成功(数据库可能突然crash了),记录之前成功的ctl
cnt可以确保上一次的checkpoint是成功完成的,从而节了校验步骤 数据库的启动验证 在数据库启动过程中的检验包含以下两个步骤;
第一步检查数据文件头中的checkpoint cnt是否与对应的控制文件中的checkpoint cnt一致.如果相等,则进行第二步检查.

第二步检查数据文件头的开始scn和对应的控制文件中的结束scn是否一致,如果控制文件中的结束scn等于数据文件头中的开始scn,则不需要对那个文件进行恢复.

对于每个数据文件都要完成检查后才打开数据库,同时将每个数据文件的结束的scn设置为无穷大也就是0xFFFFFFF.FFFFF

当使用alter session set events ‘immediate trace name file_hdrs level
10’来转储数据文件头信息时,oracle会转储两部分信息,一部分来自控制文件,另一部分来自数据文件,在数据库启动过程中,这两部分信息要用来进行启动验证.通过以下过程来进一步深入探讨一下这部分内容.
begin-hot-backup file size: 0当backup scn被更新，它才就更新 Checkpointed at scn:
0x0000.001d5e22 03/02/2015 10:07:05每个检查点都会更新此信息，除了在热备份的时候

位图块是干吗用的？

很容易理解，是用来记录表空间中区的分配情况的。位图块中的每一个二进制位对应一个区是否被分配给某个表、索引等对象。如果第一个二进制位为 0 说明表空间中第一个区未分配，如果为 1 说明已分配；第二个二进制位对应第二个区，以此类推
了解存储结构1

位图块又分两部分，其中第一个位图块又被当作位图段头，可以在 DUMP 文件中找到 Oracle 对此块类型的说明： Bitmapped File Space Header 。从第二个位图块也就是 3 号块开始，就是真正的位图数据了， DUMP 文件中这些块的类型说明为： Bitmap File Space Bitmap

Bitmapped File Space Header

sys@PROD>alter system dump datafile 6 block 2;
Start dump data blocks tsn: 7 file#:6 minblk 2 maxblk 2
Block dump from cache:
Dump of buffer cache at level 4 for tsn=7 rdba=25165826
Block dump from disk:
buffer tsn: 7 rdba: 0x01800002 (6/2)
scn: 0x0000.002260d2 seq: 0x02 flg: 0x04 tail: 0x60d21d02
frmt: 0x02 chkval: 0x8b5b type: 0x1d=KTFB Bitmapped File Space Header
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x00002B1A2D498200 to 0x00002B1A2D49A200

Bitmap File Space Bitmap

sys@PROD>alter system dump datafile 6 block 3;
Start dump data blocks tsn: 7 file#:6 minblk 3 maxblk 3
Block dump from cache:
Dump of buffer cache at level 4 for tsn=7 rdba=25165827
BH (0x703de178) file#: 6 rdba: 0x01800003 (6/3) class: 12 ba: 0x700a6000
  set: 3 pool: 3 bsz: 8192 bsi: 0 sflg: 1 pwc: 0,0
  dbwrid: 0 obj: -1 objn: 4 tsn: 7 afn: 6 hint: f
  hash: [0x83cae950,0x83cae950] lru: [0x707fc5b0,0x70fea8b0]
  lru-flags: hot_buffer
  ckptq: [NULL] fileq: [NULL] objq: [0x813feb38,0x813feb38] objaq: [0x813feb28,0x813feb28]
  st: XCURRENT md: NULL fpin: 'ktfbwh01: ktfbbfmt' tch: 0
  flags: foreground_waiting 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: 0x01800003 (6/3)
scn: 0x0000.002260d2 seq: 0x01 flg: 0x04 tail: 0x60d21e01
frmt: 0x02 chkval: 0x4ec6 type: 0x1e=KTFB Bitmapped File Space Bitmap
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x00002AADE8D5CA00 to 0x00002AADE8D5EA00

我们截一段3号快的信息

内容 注释
relfno 6 6号文件
beginblcok 128 前面讲过了从128开始才是第一个区
flag 0 0代表永久文件 1代表临时文件
first 1 free 63487 已经分配了1个区，还有63486个区未使用

下面就是位图了

File Space Bitmap Block: 
BitMap Control: 
RelFno: 6, BeginBlock: 128, Flag: 0, First: 1, Free: 63487 
0100000000000000 0000000000000000 0000000000000000 0000000000000000 
0000000000000000 0000000000000000 0000000000000000 0000000000000000 
0000000000000000 0000000000000000 0000000000000000 0000000000000000 
0000000000000000 0000000000000000 0000000000000000 0000000000000000 
0000000000000000 0000000000000000 0000000000000000 0000000000000000

这里位图要好好说明一下

块中用16进制来表示2进制，应该将16进制转化为2进制，查看二进制1的个数来计算起始区的个数。
更简单的计算方法是：每个16进制最多表示4个1，分别是十六进制1–二进制1，十六进制3–二进制11，十六进制7–二进制11，十六进制F–二进制1111

目前FAN表只有一个区，我们手动分配几个区来看一下

scott@PROD>alter table fan allocate extent(size 4m);

Table altered.

有分配了4个区

sys@PROD>select tablespace_name,extent_id,file_id,block_id,blocks from dba_extents where tablespace_name='FAN';

TABLESPACE_NAME                 EXTENT_ID    FILE_ID   BLOCK_ID     BLOCKS
------------------------------ ---------- ---------- ---------- ----------
FAN                                     0          6        128        128
FAN                                     1          6        256        128
FAN                                     2          6        384        128
FAN                                     3          6        512        128
FAN                                     4          6        640        128

重新dump datafile 6 block 3

File Space Bitmap Block: 
BitMap Control: 
RelFno: 6, BeginBlock: 128, Flag: 0, First: 5, Free: 63483 
1F00000000000000 0000000000000000 0000000000000000 0000000000000000 
0000000000000000 0000000000000000 0000000000000000 0000000000000000

注意First: 5, Free: 63483

已经分配了5个区，还剩63483个区未使用

1F00000000000000拿计算器算一下

了解存储结构1

这几个0001 1111要倒过来看,表示第1~5个区已经分配，用1标记为已分配

段中块的使用

Oracle 中，每个对象都有一个 ID 值，表有表的 ID ，段有段的 ID 
在 DBA_OBJECTS 数据字典视图中， object_id 列是表 ID ， data_object_id 列是段 ID ，下面查看了某个表的表 ID 和段 ID ：

初始情况下,表ID和段ID是一样的

scott@PROD>select object_id,data_object_id from dba_objects where object_name='FAN';

 OBJECT_ID DATA_OBJECT_ID
---------- --------------
     77411          77411

表ID一旦创建就不会变化，但是段ID会变化，比如当Truncate该表后

scott@PROD>truncate table fan;

Table truncated.

scott@PROD>select object_id,data_object_id from dba_objects where object_name='FAN';

 OBJECT_ID DATA_OBJECT_ID
---------- --------------
     77411          77412

scott@PROD>select tablespace_name,extent_id,file_id,block_id,blocks from dba_extents where tablespace_name='FAN';

TABLESPACE_NAME                 EXTENT_ID    FILE_ID   BLOCK_ID     BLOCKS
------------------------------ ---------- ---------- ---------- ----------
FAN                                     0          6        128        128

因为truncate是将原来的段删除，并新换一个段

段空间自动管理ASSM和ASSM三层位图块结构

了解存储结构1

第一个 L3 块一般是段头。如果段头中存放了太多 L2 块的信息，空间不足， Oracle 会再分配第二个 L3 块。当然，段头中会有第二个
L3 块的地址。如果第二个 L3 块空间也用完了，会再分配第三个。第二个 L3 块中会存放第三个 L3 块的地址。通常情况下，一个 L3
块就够了。有两个 L3 块就已经是非常罕有的情况了，基本上不会出现需要 3 个 L3 块的情况。

Oracle 是如何使用 4 层树状结构（ 3 层位图块 + 数据块）来确定向哪个块中插入的呢？

  • 第一步，查找数据字典（就是 dba_segments 数据字典视图的基表），确定段头位置。
  • 第二步，在段头中找到第一个 L2 块位置信息。
  • 第三步，到 L2 块中根据执行插入操作进程的 PID 号，做 HASH 运算，得到一个随机数 N ，在 L2 中，找到第 N 个 L1
    块的位置信息。
  • 第四步，到第三步中确定的 L1 块中，再根据执行插入操作进程的 PID 号，做 HASH 运算，得到一个随机数 M ，在 L1 中找到第
    M 号数据块。
  • 第五步，向第 M 号数据块中插入。

L3 块中虽然可以有多个 L2 块，但插入操作不会选择多个 L2 块，每次只会选择同一个 L2 块。直到这个 L2
块下面的所有数据块都被插满了，才会选择下一个 L2 块。 在 L2 中选择某个 L1 的时候，就是随机的了。不同 Session
，只要有可能，就会被分配到不同的 L1 中。在 L1 中找数据块时也是一样。

以FAN表为例

scott@PROD>select tablespace_name,extent_id,file_id,block_id,blocks from dba_extents where tablespace_name='FAN';

TABLESPACE_NAME                 EXTENT_ID    FILE_ID   BLOCK_ID     BLOCKS
------------------------------ ---------- ---------- ---------- ----------
FAN                                     0          6        128        128

DUMP128号块可以看出，他是一个L1块。129号块也是一个L1块，130号块是L2块，131号块是段头，也就是L3块

内容 注释
L1 FIRST LEVEL BITMAP BLOCK
L2 SECOND LEVEL BITMAP BLOCK
L3(段头) PAGETABLE SEGMENT HEADER 
sys@PROD>alter system dump datafile 6 block 128;

System altered.

sys@PROD>alter system dump datafile 6 block 129;

System altered.

sys@PROD>alter system dump datafile 6 block 130;

System altered.

sys@PROD>alter system dump datafile 6 block 131;

System altered.
Trace file /u01/app/oracle/diag/rdbms/prod/prod/trace/prod_ora_29124.trc
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1
System name:    Linux
Node name:  gc1
Release:    2.6.18-194.el5
Version:    #1 SMP Tue Mar 16 21:52:39 EDT 2010
Machine:    x86_64
VM name:    VMWare Version: 6
Instance name: prod
Redo thread mounted by this instance: 1
Oracle process number: 23
Unix process pid: 29124, image: oracle@gc1 (TNS V1-V3)


*** 2015-03-07 18:38:01.936
*** SESSION ID:(38.1491) 2015-03-07 18:38:01.936
*** CLIENT ID:() 2015-03-07 18:38:01.936
*** SERVICE NAME:(SYS$USERS) 2015-03-07 18:38:01.936
*** MODULE NAME:(sqlplus@gc1 (TNS V1-V3)) 2015-03-07 18:38:01.936
*** ACTION NAME:() 2015-03-07 18:38:01.936

Start dump data blocks tsn: 7 file#:6 minblk 128 maxblk 128
Block dump from cache:
Dump of buffer cache at level 4 for tsn=7 rdba=25165952
Block dump from disk:
buffer tsn: 7 rdba: 0x01800080 (6/128)
scn: 0x0000.0022b85a seq: 0x02 flg: 0x04 tail: 0xb85a2002
frmt: 0x02 chkval: 0x042e type: 0x20=FIRST LEVEL BITMAP BLOCK
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x00002AB30C980A00 to 0x00002AB30C982A00
2AB30C980A00 0000A220 01800080 0022B85A 04020000  [ .......Z.".....]
2AB30C980A10 0000042E 00000000 00000000 00000000  [................]
2AB30C980A20 00000000 00000000 00000000 00000000  [................]
        Repeat 1 times
2AB30C980A40 00000000 00000000 00000000 00000004  [................]
2AB30C980A50 FFFFFFFF 0000003C 00000004 00000040  [....<.......@...]
2AB30C980A60 00010001 00000000 00000000 00000000  [................]
2AB30C980A70 00000000 00000004 54FAC2AA 54FAC2AA  [...........T...T]
2AB30C980A80 00000000 00200006 00000594 00000009  [...... .........]
2AB30C980A90 01800082 00000000 00000000 00000004  [................]
2AB30C980AA0 00000080 01800084 00000000 00000000  [................]
2AB30C980AB0 00000000 00000000 00000000 00000021  [............!...]
2AB30C980AC0 00012E64 0022B85A 00000000 01800080  [d...Z.".........]
2AB30C980AD0 00000040 00000000 00000000 00000000  [@...............]
2AB30C980AE0 00000000 00000000 00000000 00000000  [................]
        Repeat 9 times
2AB30C980B80 00000000 00000000 00000000 00001111  [................]
2AB30C980B90 00000000 00000000 00000000 00000000  [................]
        Repeat 485 times
2AB30C9829F0 00000000 00000000 00000000 B85A2002  [............. Z.]
Dump of First Level Bitmap Block
 --------------------------------
   nbits : 4 nranges: 1         parent dba:  0x01800082   poffset: 0     
   unformatted: 60      total: 64        first useful block: 4      
   owning instance : 1
   instance ownership changed at 03/07/2015 17:19:38
   Last successful Search 03/07/2015 17:19:38
   Freeness Status:  nf1 0      nf2 0      nf3 0      nf4 0      

   Extent Map Block Offset: 4294967295 
   First free datablock : 4      
   Bitmap block lock opcode 9
   Locker xid:     :  0x0006.020.00000594
   Dealloc scn: 2275418.0 
   Flag: 0x00000021 (OBJD/-/-/-/-/HWM)
   Inc #: 0 Objd: 77412 
  HWM Flag: HWM Set
      Highwater::  0x01800084  ext#: 0      blk#: 4      ext size: 128   
  #blocks in seg. hdr's freelists: 0     
  #blocks below: 0     
  mapblk  0x00000000  offset: 0     
  --------------------------------------------------------
  DBA Ranges :
  --------------------------------------------------------
   0x01800080  Length: 64     Offset: 0      

   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: 7 file#: 6 minblk 128 maxblk 128

*** 2015-03-07 18:38:04.598
Start dump data blocks tsn: 7 file#:6 minblk 129 maxblk 129
Block dump from cache:
Dump of buffer cache at level 4 for tsn=7 rdba=25165953
Block dump from disk:
buffer tsn: 7 rdba: 0x01800081 (6/129)
scn: 0x0000.0022b85c seq: 0x02 flg: 0x04 tail: 0xb85c2002
frmt: 0x02 chkval: 0x1484 type: 0x20=FIRST LEVEL BITMAP BLOCK
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x00002AB30C980A00 to 0x00002AB30C982A00
2AB30C980A00 0000A220 01800081 0022B85C 04020000  [ .......\.".....]
2AB30C980A10 00001484 00000000 00000000 00000000  [................]
2AB30C980A20 00000000 00000000 00000000 00000000  [................]
        Repeat 1 times
2AB30C980A40 00000000 00000000 00000000 00000004  [................]
2AB30C980A50 FFFFFFFF 00000040 00000000 00000040  [....@.......@...]
2AB30C980A60 00010001 00000000 00000000 00000000  [................]
2AB30C980A70 00000000 00000000 00000000 00000000  [................]
2AB30C980A80 00000000 00200006 00000594 00000009  [...... .........]
2AB30C980A90 01800082 00000001 00000000 00000000  [................]
2AB30C980AA0 00000000 00000000 00000000 00000000  [................]
2AB30C980AB0 00000000 00000000 00000000 00000020  [............ ...]
2AB30C980AC0 00012E64 0022B85C 00000000 018000C0  [d...\.".........]
2AB30C980AD0 00000040 00000000 00000000 00000000  [@...............]
2AB30C980AE0 00000000 00000000 00000000 00000000  [................]
        Repeat 496 times
2AB30C9829F0 00000000 00000000 00000000 B85C2002  [............. \.]
Dump of First Level Bitmap Block
 --------------------------------
   nbits : 4 nranges: 1         parent dba:  0x01800082   poffset: 1     
   unformatted: 64      total: 64        first useful block: 0      
   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 : 0      
   Bitmap block lock opcode 9
   Locker xid:     :  0x0006.020.00000594
   Dealloc scn: 2275420.0 
   Flag: 0x00000020 (OBJD/-/-/-/-/-)
   Inc #: 0 Objd: 77412 
  --------------------------------------------------------
  DBA Ranges :
  --------------------------------------------------------
   0x018000c0  Length: 64     Offset: 0      

   0:unformatted   1:unformatted   2:unformatted   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
   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: 7 file#: 6 minblk 129 maxblk 129

*** 2015-03-07 18:38:07.526
Start dump data blocks tsn: 7 file#:6 minblk 130 maxblk 130
Block dump from cache:
Dump of buffer cache at level 4 for tsn=7 rdba=25165954
Block dump from disk:
buffer tsn: 7 rdba: 0x01800082 (6/130)
scn: 0x0000.0022b85e seq: 0x02 flg: 0x04 tail: 0xb85e2102
frmt: 0x02 chkval: 0xacd1 type: 0x21=SECOND LEVEL BITMAP BLOCK
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x00002AB30C980A00 to 0x00002AB30C982A00
2AB30C980A00 0000A221 01800082 0022B85E 04020000  [!.......^.".....]
2AB30C980A10 0000ACD1 00000000 00000000 00000000  [................]
2AB30C980A20 00000000 00000000 00000000 00000000  [................]
        Repeat 1 times
2AB30C980A40 00000000 00000000 00000000 01800083  [................]
2AB30C980A50 00000002 00000002 00000000 00000004  [................]
2AB30C980A60 00200006 00000594 00012E64 00000001  [.. .....d.......]
2AB30C980A70 00000000 01800080 00010005 01800081  [................]
2AB30C980A80 00010005 01800100 00010005 01800101  [................]
2AB30C980A90 00010005 01800180 00010005 01800181  [................]
2AB30C980AA0 00010005 01800200 00010005 01800201  [................]
2AB30C980AB0 00010005 01800280 00010005 01800281  [................]
2AB30C980AC0 00010005 00000000 00000000 00000000  [................]
2AB30C980AD0 00000000 00000000 00000000 00000000  [................]
        Repeat 497 times
2AB30C9829F0 00000000 00000000 00000000 B85E2102  [.............!^.]
Dump of Second Level Bitmap Block
   number: 2       nfree: 2       ffree: 0      pdba:     0x01800083 
   Inc #: 0 Objd: 77412
  opcode:4 
 xid: 
  L1 Ranges :
  --------------------------------------------------------
   0x01800080  Free: 5 Inst: 1 
   0x01800081  Free: 5 Inst: 1 

  --------------------------------------------------------
End dump data blocks tsn: 7 file#: 6 minblk 130 maxblk 130

*** 2015-03-07 18:38:10.406
Start dump data blocks tsn: 7 file#:6 minblk 131 maxblk 131
Block dump from cache:
Dump of buffer cache at level 4 for tsn=7 rdba=25165955
BH (0x73bda158) file#: 6 rdba: 0x01800083 (6/131) class: 4 ba: 0x7383a000
  set: 3 pool: 3 bsz: 8192 bsi: 0 sflg: 1 pwc: 0,0
  dbwrid: 0 obj: 77412 objn: 77411 tsn: 7 afn: 6 hint: f
  hash: [0x6dbf9e48,0x83cd4a10] lru: [0x717d8950,0x83d9c708]
  lru-flags: hot_buffer
  ckptq: [NULL] fileq: [NULL] objq: [0x813f40e0,0x813f40e0] objaq: [0x813f40d0,0x813f40d0]
  st: XCURRENT md: NULL fpin: 'ktswh53: ktstrn' tch: 0
  flags: block_written_once redo_since_read
  LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [1]
BH (0x6dbf9d98) file#: 6 rdba: 0x01800083 (6/131) class: 4 ba: 0x6db92000
  set: 3 pool: 3 bsz: 8192 bsi: 0 sflg: 1 pwc: 0,0
  dbwrid: 0 obj: 77412 objn: -1 tsn: 7 afn: 6 hint: f
  hash: [0x83cd4a10,0x73bda208] lru: [0x747e3450,0x70febe10]
  lru-flags: on_auxiliary_list
  ckptq: [NULL] fileq: [NULL] objq: [NULL] objaq: [NULL]
  st: CR md: NULL tch: 1
  cr: [scn: 0x0.22b869],[xid: 0x0.0.0],[uba: 0x0.0.0],[cls: 0x0.22b869],[sfl: 0x0],[lc: 0x0.0]
  flags:
Block dump from disk:
buffer tsn: 7 rdba: 0x01800083 (6/131)
scn: 0x0000.0022d23a seq: 0x01 flg: 0x04 tail: 0xd23a2301
frmt: 0x02 chkval: 0x85c8 type: 0x23=PAGETABLE SEGMENT HEADER
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x00002AB30C980A00 to 0x00002AB30C982A00
2AB30C980A00 0000A223 01800083 0022D23A 04010000  [#.......:.".....]
2AB30C980A10 000085C8 00000000 00000000 00000000  [................]
2AB30C980A20 00000000 00000001 00000080 00000A9C  [................]
2AB30C980A30 00000000 00000004 00000080 01800084  [................]
2AB30C980A40 00000000 00000000 00000000 00000000  [................]
        Repeat 1 times
2AB30C980A60 00000004 00000080 01800084 00000000  [................]
2AB30C980A70 00000000 00000000 00000000 01800080  [................]
2AB30C980A80 01800080 00000000 00000000 00000000  [................]
2AB30C980A90 00000000 00000000 00000000 00000000  [................]
        Repeat 3 times
2AB30C980AD0 00000001 00002000 00000000 00001434  [..... ......4...]
2AB30C980AE0 00000000 01800082 00000001 01800081  [................]
2AB30C980AF0 01800082 00000000 00000000 00000000  [................]
2AB30C980B00 00000000 00000000 00000001 00000000  [................]
2AB30C980B10 00012E64 10000000 01800080 00000080  [d...............]
2AB30C980B20 00000000 00000000 00000000 00000000  [................]
        Repeat 152 times
2AB30C9814B0 01800080 01800084 00000000 00000000  [................]
2AB30C9814C0 00000000 00000000 00000000 00000000  [................]
        Repeat 151 times
2AB30C981E40 00000000 00000000 01800082 00000000  [................]
2AB30C981E50 00000000 00000000 00000000 00000000  [................]
        Repeat 185 times
2AB30C9829F0 00000000 00000000 00000000 D23A2301  [.............#:.]
  Extent Control Header
  -----------------------------------------------------------------
  Extent Header:: spare1: 0      spare2: 0      #extents: 1      #blocks: 128   
                  last map  0x00000000  #maps: 0      offset: 2716  
      Highwater::  0x01800084  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::  0x01800084  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: 0x01800080
  Level 1 BMB for Low HWM block: 0x01800080
  --------------------------------------------------------
  Segment Type: 1 nl2: 1      blksz: 8192   fbsz: 0      
  L2 Array start offset:  0x00001434
  First Level 3 BMB:  0x00000000
  L2 Hint for inserts:  0x01800082
  Last Level 1 BMB:  0x01800081
  Last Level II BMB:  0x01800082
  Last Level III BMB:  0x00000000
     Map Header:: next  0x00000000  #extents: 1    obj#: 77412  flag: 0x10000000
  Inc # 0 
  Extent Map
  -----------------------------------------------------------------
   0x01800080  length: 128   

  Auxillary Map
  --------------------------------------------------------
   Extent 0     :  L1 dba:  0x01800080 Data dba:  0x01800084
  --------------------------------------------------------

   Second Level Bitmap block DBAs 
   --------------------------------------------------------
   DBA 1:   0x01800082

End dump data blocks tsn: 7 file#: 6 minblk 131 maxblk 131

我写烦了下一篇再解释dump出的L1 L2 L3内容所包含信息吧。。。

相关推荐