理解存储结构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(还未分配)

[email protected]>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;

查看是否分配了区

[email protected]>select extent_id,file_id,tablespace_name,block_id,blocks from dba_extents where tablespace_name=‘FAN‘;

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

为啥建了表没分配区呢?

在11g中由于新特性deferred segment creation的作用创建表时默认采用这个特性,即只在insert一行后才分配段

create table fan(id number) segment creation immediate;立即分配段

create table fan(id number) segment creation deferred;延迟分配段

插入一行数据

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

查看是否分配了区

[email protected]>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一开始只包含一个区,6号文件的128~255号块,共128个块,128*8=1024k

当手动allocate后,又增加了一个区

也就是说,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: [email protected] (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:([email protected] (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 说明已分配;第二个二进制位对应第二个区,以此类推

位图块又分两部分,其中第一个位图块又被当作位图段头,可以在 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个区

[email protected]>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那计算器算一下

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


段中块的使用

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

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

[email protected]>select object_id,data_object_id from dba_objects where object_name=‘FAN‘;

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

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

[email protected]>truncate table fan;

Table truncated.

[email protected]>select object_id,data_object_id from dba_objects where object_name=‘FAN‘;

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

[email protected]>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三层位图块结构

第一个 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表为例

[email protected]>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  [....<[email protected]]
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  [[email protected]@...]
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内容所包含信息吧。。。

时间: 2024-10-14 15:18:37

理解存储结构1的相关文章

理解存储结构2

接上篇http://blog.csdn.net/ashic/article/details/44117867 上篇中我们dump出了L1 L2 L3块,现在来了解一下它们中包含的信息 内容 注释 L1 FIRST LEVEL BITMAP BLOCK L2 SECOND LEVEL BITMAP BLOCK L3(段头) PAGETABLE SEGMENT HEADER 通过上面的表格再去看Dump文件我们可以很清楚的发现 在这个uniform size 1M的表空间中,一个区中又两个L1块,1

浅析理解Oracle数据库体系结构和存储结构

一.Oracle体系结构 个人比喻帮助理解:类似于图书馆,去图书馆的客户(用户进程和服务进程等)需要调取资料,求助于图书管理员(实例)进入图书分区(数据库)进行资料查找.[如果比喻不当,欢迎指正,尽请谅解] - 第一部分是实例部分(为用户提供服务,管理数据库): 主要理解分成两个主要部分: (1)内存结构:(2)后台进程:与数据库进行交互 - 第二部分是数据库部分物理结构:(为实例提供服务,处理数据文件) 主要文件:数据文件,控制文件,重做日志文件 其他文件:归档日志文件,参数文件,口令文件等

Caffe源码理解1:Blob存储结构与设计

博客:blog.shinelee.me | 博客园 | CSDN Blob作用 据Caffe官方描述: A Blob is a wrapper over the actual data being processed and passed along by Caffe, and also under the hood provides synchronization capability between the CPU and the GPU. Mathematically, a blob is

图的理解:存储结构与邻接矩阵

存储结构 要存储一个图,我们知道图既有结点,又有边,对于有权图来说,每条边上还带有权值.常用的图的存储结构主要有以下二种: 邻接矩阵 邻接表 邻接矩阵 我们知道,要表示结点,我们可以用一个一维数组来表示,然而对于结点和结点之间的关系,则无法简单地用一维数组来表示了,我们可以用二维数组来表示,也就是一个矩阵形式的表示方法. 我们假设A是这个二维数组,那么A中的一个元素aij不仅体现出了结点vi和结点vj的关系,而且aij的值正可以表示权值的大小. 以下是一个无向图的邻接矩阵表示示例: 从上图我们可

SQL SERVER大话存储结构(2)

阅读目录(Content) 1 行记录如何存储 1.1 堆表 1.2 聚集索引表格 2 非聚集索引结构 3 非聚集索引键值内容 3.1 堆表上的非聚集索引 3.2 聚集索引表(唯一)的非聚集索引 3.3 聚集索引表(非唯一)的非聚集索引 4 非聚集索引如何查找页 如果转载,请注明博文来源: www.cnblogs.com/xinysu/   ,版权归 博客园 苏家小萝卜 所有.望各位支持! 本系列上一篇博文链接:SQL SERVER大话存储结构(1)_数据页类型及页面指令分析 回到顶部(go t

SQL SERVER大话存储结构(3)

阅读目录(Content) 1 引入 2 数据行 2.1 数据行结构 2.2 特殊情况(大对象.行溢出及forword) 2.2.1 大对象 2.2.2 行溢出 2.2.3 forword 3 测试存储情况 3.1 堆表分析 3.2 添加主键 3.3 增加一列:可空变长列 3.4 增加一列:非空变长列+默认值 3.4.1 非大对象列 3.5 删除无数据的列 3.6 删除有数据的列 3.7 行溢出 3.8 Forword 4 行结构与DDL 一行数据是如何来存储的呢? 变长列与定长列,NULL与N

字符串和字符串的常见存储结构

继续接去年的常见数据结构和算法总结 系列随笔记录 一.计算机里进行非数值处理的对象基本上是字符串数据,比处理浮点和整数都要复杂 string串定义:由 0 个或多个 字符 组成的 有限的 序列,通常记为:s =“a1 a2 a3 … ai …an”  ( n≥0 ,且n是有限的).其中的引号不属于串,只是一个标记作用! n就是串的长度,且字符串里的字符 ai 的值由 字母.数字或其他字符 组成的. 二.字符串为什么要用双引号标记 作用:避免字符串与变量名或数的常量混淆. char *str =

队列的存储结构和常见操作(c 语言实现)

一.队列(queue) 队列和栈一样,在实际程序的算法设计和计算机一些其他分支里,都有很多重要的应用,比如计算机操作系统对进程 or 作业的优先级调度算法,对离散事件的模拟算法,还有计算机主机和外部设备运行速度不匹配的问题解决等,很多很多.其实队列的本质还是线性表!只不过是一种特殊的或者说是受限的线性表,是这样的: 1).限定在表的一端插入.另一端删除. 插入的那头就是队尾,删除的那头就是队头.也就是说只能在线性表的表头删除元素,在表尾插入元素.形象的说就是水龙头和水管,流水的水嘴是队头,进水的

solr中文搜索倒排索引和数据存储结构

作为搜索,我们传统的方式(正排索引)是从关键点出发,然后再通过关键点找到关键点代表的信息中能够满足搜索条件的特定信息,既通过KEY寻找VALUE.而Lucene的搜索则是采用了倒排索引的方式,即通过VALUE找KEY.而在中文全文搜索中VALUE就是我们要搜索的单词,存放所有单词的地方叫词典.KEY是文档标号列表(通过文档标号列表我们可以找到出现过要搜索单词VALUE的文档).正排索引从文档编号找词: 倒排索引是从词找文档编号: 当文档数据来临时,solr会首先对文档数据进行分词,创建索引库和文