ORACLE空间管理实验(八)数据块格式分析--DUMP结合BBED

使用DUMP 数据块格式结合BBED进行查看。

####################实验准备步骤:

BYS@ bys3>create table test6(aa int,bb varchar2(10));

Table created.

BYS@ bys3>insert into test6 values(89,'bys');

1 row created.

BYS@ bys3>insert into test6 values(69,'hello');

1 row created.

BYS@ bys3>commit;

Commit complete.

BYS@ bys3>alter system checkpoint;

System altered.

BYS@ bys3>select dbms_rowid.rowid_relative_fno(rowid) file#,dbms_rowid.rowid_block_number(rowid) block#,aa,bb from test6;

    FILE#     BLOCK#         AA BB

---------- ---------- ---------- ----------

        4        477         89 bys

        4        477         69 hello

BYS@ bys3>alter system dump datafile 4 block 477;

System altered.

BYS@ bys3>select value from v$diag_info where name like 'De%';

VALUE

----------------------------------------------------------------------------------------------------

/u01/diag/rdbms/bys3/bys3/trace/bys3_ora_8109.trc

DUMP数据块的信息解读

Start dump data blocks tsn: 4 file#:4 minblk 477 maxblk 477

Block dump from cache:  --这段信息来自buffer cache,详见: 详解Buffer Header--DUMP buffer结合X$BH视图各字段

Dump of buffer cache at level 4 for tsn=4 rdba=16777693

BH (0x22be4e74) file#: 4 rdba: 0x010001dd (4/477) class: 1 ba: 0x2286e000

 set: 3 pool: 3 bsz: 8192 bsi: 0 sflg: 1 pwc: 0,0

 dbwrid: 0 obj: 23326 objn: 23326 tsn: 4 afn: 4 hint: f

 hash: [0x227e6b54,0x2a7f74ac] lru: [0x217ee3d4,0x20ff4e64]

 ckptq: [NULL] fileq: [NULL] objq: [0x217ee3ec,0x20ff4e7c] objaq: [0x217ee3f4,0x20ff4e84]

 st: XCURRENT md: NULL fpin: 'ktspbwh2: ktspfmdb' tch: 3

 flags: block_written_once redo_since_read

 LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [1]

 ###########################################数据块头部分

Block dump from disk:   --下面的信息才是来自数据文件中的块。

buffer tsn: 4 rdba: 0x010001dd (4/477)  --数据块中4-8字节是RDBA--下面BBED部分可以看到

scn: 0x0000.00874dbb seq: 0x01 flg: 0x06 tail: 0x4dbb0601

frmt: 0x02 chkval: 0xeb56 type: 0x06=trans data   --第四个字节对应

---flg:0x01 (新建块)0x2(数据块延迟清洗推进scn和seq) 0X04(设置校验和) 0x08(临时块)     type:0x06(表/索引块)

--frmt:  0x01(v7)  0x02(v8)   --与第三字节A2对应,表示8I以上版本

Hex dump of block: st=0, typ_found=1

Dump of memory from 0xB68A9200 to 0xB68AB200

B68A9200 0000A206 010001DD 00874DBB 06010000  [.........M......]  ---这一行的信息可以与块头中的SCN TYPE之类对应的。

B68A9210 0000EB56 00130001 00005B1E 00874DB6  [V........[...M..]

B68A9220 1FE80000 00321F02 010001D8 001A0002  [......2.........]

B68A9230 00001382 00C00B70 00070569 00002002  [....p...i.... ..]

………………………………

B68AB1D0 54415453 4D5F5355 454B5241 71780752  [STATUS_MARKER.xq]

B68AB1E0 2618100B 012C021E 46C10202 6C656805  [...&..,....F.hel]

B68AB1F0 012C6F6C 5AC10202 73796203 4DBB0601  [lo,....Z.bys...M]

##########################################下面是ITL

Block header dump:  0x010001dd

Object id on Block? Y

seg/obj: 0x5b1e  csc: 0x00.874db6  itc: 2  flg: E  typ: 1 - DATA      --数据类型是DATA。

-- seg/obj: 0x5b1e--对应的是dba_objects.data_object_id,未TRUNCATE操作过的表data_object_id与object_id相等。格式化也就是在块上写入这个seg/obj:

--csc: 0x00.874db6 延迟块清除时的SCN--查询时、第三次提交时--三个ITL会做延迟块清除

--flg: E   --指用的是ASSM,如果是O表示用的是free list

--typ: 1 - DATA 事务型的数据块(并且:数据块头的type:0x06),存放表和索引数据。

    brn: 0  bdba: 0x10001d8 ver: 0x01 opc: 0

    inc: 0  exflg: 0

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc

0x01   0x0002.01a.00001382  0x00c00b70.0569.07  --U-    2  fsc 0x0000.00874dbb

0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000

--11G默认用快速提交,Flag是U,正常提交是C。

--Itl: ITL事务槽号的流水编号

--Xid:transac[X]tion identified(事务ID),由und的段号+undo的槽号+undo槽号的覆盖次数三部分组成

--Uba:undo block address记录了最近一次的该记录的前镜像(修改前的值)

--Flag:C是提交,U是快速提交,---是未提交(Flg C=Committed  U=Commit Upper Bound T=Active at CSC)

--Lck:锁住了几行数据,对应有几个行锁

--Scn/Fsc:Scn=SCN of commited TX; Fsc=Free space credit(bytes)

--这里fsc 0x0000.00874dbb是指提交的scn,这个值大于上次清除块时的scn=csc: 0x00.874db6(此scn是这个块中最小的SCN of commited)

--SCN WRAP:如果事务已提交并完成清洗,该字段保存事务提交SCN的SCN WRAP部分,否则该字段保存空闲预支字节数(FSC).比如删除了一行数据10个字节,在事务提前前,这10个字节就属于fsc(即会写到SCN WRAP),只有事务提交后,才能正式返回到空闲空间。

#################################################用户数据头

bdba: 0x010001dd --当前数据块的DBA

data_block_dump,data header at 0xb68a9264

===============

tsiz: 0x1f98  块的total总可用空间 1f98--8088字节

hsiz: 0x16  --数据头部占的字节数-不固定

pbl: 0xb68a9264

    76543210

flag=--------

ntab=1              --数据块属于一个表, cluster表时不是1

nrow=2             --行数

frre=-1               --The first free row entry in the row directory 要加1

fsbo=0x16        --Free space begin offset  叫起始空间:可以存放数据空间的起始位置(即定义了数据层中空闲空间的起始offset)

fseo=0x1f82     -- Free space end offset  叫结束空间:可以存放数据空间的结束位置(即定义了数据层中空闲空间的结束offset)插入数据从此处开始--从后往前用

avsp=0x1f6c    -- --Available space for new entries  叫空闲空间:定义了数据层中空闲空间的字节数

tosp=0x1f6c     -- --Total space   叫最终空闲空间:定义了ITL中事务提交后,数据层中空闲空间的字节数

0xe:pti[0]      nrow=2  offs=0   --Table directory,整个表的开始,共2行数据 ,定义了该表在行索引中使用的插槽数

0x12:pri[0]     offs=0x1f8e   -Row index,叫行索引,定义了该块中包含的所有行数据的位置

0x14:pri[1]     offs=0x1f82

#######################################用户数据

时间: 2024-12-29 13:22:27

ORACLE空间管理实验(八)数据块格式分析--DUMP结合BBED的相关文章

ORACLE空间管理实验(六)块管理之ASSM下插入操作

高水位的影响及大并发插入的性能问题 一.数据块的插入时寻找可用块的规则总结: 高水位与低高水位:低高水位与高水位之间存在的数据块的状态可能是未格式化或格式的.低高水位以下的是格式化了的,可以被使用. 1.首先,插入一条数据,只会使用高水位以下的数据块. 高水点的位置:L1块所包含数据块的边界,要么是区的边界 2.第一次插入一行数据,格式化块数? 并没有一个一定的数值,从DUMP L1块中看,有格式化5个,32个64个等. 3.插入一行数据,如何通过L3-->L2-->L1--数据块,这个过程来

ORACLE空间管理实验(五)块管理之ASSM下高水位的影响--删除和查询

高水位概念: 所有的oracle段(segments,在此,为了理解方便,建议把segment作为表的一个同义词) 都有一个在段内容纳数据的上限,我们把这个上限称为"high water mark"或HWM.这个HWM是一个标记,用来说明已经有多少没有使用的数据块分配给这个segment.HWM原则上HWM只会增大,不会缩小,即使将表中的数据全部删除,HWM还是为原值,由于这个特点,使HWM很象一个水库的历史最高水位,这也就是HWM的原始含义. 这个概念百度下一大把,可以参考: htt

ORACLE空间管理实验(四) 块管理之ASSM三级位图结构

L1.L2.L3块的作用:--方便查找数据块. L1中有指向L3的指针,L2有指向L3的指针,L3中有多个数据块的指针和状态. 1.每个L3中,有多个L2的地址(第一个L3是段头). 2.每个L2中,有多个L1的地址. 3.每个L1中,有多个数据块地址. ORACLE最多支持三级位图. 一级位图用于管理具体数据块的使用. 二级位图块记录了一级位图块的地址. 三级位图块记录了二级位图块的地址.Segment Heade可以管理极大数据量的对象的空间,很难出现另一个三级位图块. 1.如何查找段头--

ORACLE空间管理实验(二) 区的管理与分配

内容基于LMT管理的表空间,字典管理已经不用了. 本篇主要验证了这些问题: 1.LMT管理的表空间,区的分配有两种方法: 系统分配和UNIFORM固定大小-->见实验 2.验证Oracle找寻可用区的方式: 从数据文件开头的位图块中获得可用区的信息,DUMP时可见FIRST:3这种,表示已经使用3个区.详见:点击打开链接 3.在表空间中建第一个表(注意,第一个),这个表从数据文件的第几个块开始使用 11G下,LMT管理的表空间,数据文件中0-127号块做位图区域用,第128个块才开始存放表的数据

ORACLE空间管理实验(一)

探索LMT表空间管理下数据文件头的结构及位图中区的记录方式 实验分两步: 1.LMT本地管理的表空间,ASSM 自动段管理时数据文件的结构分析 ORACLE 11G:0号操作系统块,1-2是文件头,3-127是位图信息.128号开始及之后存放的是数据了-可能是段头或段的数据. ORACLE 10G时数据文件头只有8个块存放位图信息.--本文未实验. 2.位图块中对于区的使用情况的记录--第一个记录区使用情况的是3号块,本文查看的就是3号块. 在位图块中用二进制数值1来表示区的起始个数--或者叫第

ORACLE空间管理实验2:区的管理与分配

  内容基于LMT管理的表空间,字典管理已经不用了. 本篇主要验证了这些问题: 1.LMT管理的表空间,区的分配有两种方法: 系统分配和UNIFORM固定大小-->见实验 2.验证Oracle找寻可用区的方式: 从数据文件开头的位图块中获得可用区的信息,DUMP时可见FIRST:3这种,表示已经使用3个区.详见:点击打开链接 3.在表空间中建第一个表(注意,第一个),这个表从数据文件的第几个块开始使用 11G下,LMT管理的表空间,数据文件中0-127号块做位图区域用,第128个块才开始存放表的

ORACLE空间管理实验(三) 区管理之大区小区对I/O性能的影响

大小区优缺点,超过一M区有意义吗?  表空间管理技术管理的是区,本地管理表空间LMT在每个数据文件头部加入位图区域管理的是EXTENT的使用情况. EXTENT的使用和释放时ORACLE会在数据文件头的位图区域更新记录. 对于大小区,事实上即使在系统自动分配区大小的管理方式下,8M的区也很普遍,如下: 系统管理区大小由系统自动分配扩展的区大小, 在段的前1M空间:区大小8个块=64K,前16个区是这样. 在段1M---64M之间:区大小1M,128个块 在段64M之后,区大小8M. 大小区优点缺

ORACLE空间管理实验(七) 块管理之MMSM

为什么SYSTEM/UNDO/TEMP是MMSM管理? ASSM和MSSM的优缺点. ASSM:优点,可以支持大并发插入 :缺点,索引的聚簇因子会很差  --可以用反向键索引.Hash分区. MSSM不支持大并发插入.在索引范围扫描较多.并发插入很少.索引列顺序增加:使用MSSM更合适. SYSTEM.回滚表空间.临时表空间是MSSM表空间 BYS@ bys3>select tablespace_name,EXTENT_MANAGEMENT ,ALLOCATION_TYPE,SEGMENT_SP

明明白白使用数据块:数据块格式深入解析

Data Block是数据库中最小的I/O单元,下面我来简单介绍下数据块的基本结构. OK!跟着我一步步实验: 一.建表空间 SQL>create tablespace tp1 datafile '/oradata/bxocp/tp01.dbf' size 10M; 二.建用户及授权 SQL>create user gyj identified by gyj default tablespace tp1; SQL>grant dba to gyj; 三.建表 SQL>conn gy