|
|
|
Oracle基本数据类型存储格式浅析(一)—(五) |
热 ★★★★ |
|
Oracle基本数据类型存储格式浅析(一)—(五) |
|
作者:闵涛 文章来源:闵涛的学习笔记 点击数:3188 更新时间:2009/4/22 22:04:18 |
|
''); 已创建 1 行。 SQL> commit; 提交完成。 SQL> col dump_rowid format a60 SQL> select rowid, dump(rowid) dump_rowid from test_index; ROWID DUMP_ROWID --------------------------- ---------------------------------------- *BAFAB4wCwQL+ Typ=208 Len=10: 2,4,1,64,7,140,2,193,2,254 逻辑ROWID的DUMP结果前两位都是2和4,最后一位都是254,(我还没有发现其他的情况),由于逻辑ROWID和主键的值有关,所以长度是不定的,因此应该是用来表示开始和结束的。 第3、4位和物理ROWID一样,表示的是相对表空间的数据文件号乘以64的值。 第5、6位表示这条记录在数据文件的第几个BLOCK中。 从第7位开始到DUMP结果的倒数第二位,表示主键的值。首先是主键中第一个字段的长度,这里是2,然后是主键的值,由于是NUMBER类型,因此193,2表示数值1。如果是多个字段组成的主键,第一个字段之后是第二个字段的长度,然后是第二个字段的值……。 SQL> select (1*256 + 64)/64 from dual; (1*256+64)/64 ------------- 5 SQL> select 7*256 + 140 from dual; 7*256+140 ---------- 1932 SQL> alter system dump datafile 5 block 1932; 系统已更改。 找到相应的dump文件,可以发现刚才插入的记录。 Dump file f:oracleadmintest4udumptest4_ora_3828.trc Thu Dec 23 00:17:53 2004 ORACLE V9.2.0.4.0 - Production vsnsta=0 vsnsql=12 vsnxtr=3 Windows 2000 Version 5.1 Service Pack 1, CPU type 586 Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options JServer Release 9.2.0.4.0 - Production Windows 2000 Version 5.1 Service Pack 1, CPU type 586 Instance name: test4 Redo thread mounted by this instance: 1 Oracle process number: 9 Windows thread id: 3828, image: ORACLE.EXE *** 2004-12-23 00:17:53.361 *** SESSION ID:(8.82) 2004-12-23 00:17:53.301 Start dump data blocks tsn: 5 file#: 5 minblk 1932 maxblk 1932 buffer tsn: 5 rdba: 0x0140078c (5/1932) scn: 0x0000.00e9f122 seq: 0x01 flg: 0x02 tail: 0xf1220601 frmt: 0x02 chkval: 0x0000 type: 0x06=trans data Block header dump: 0x0140078c Object id on Block? Y seg/obj: 0x1e48 csc: 0x00.e9f113 itc: 2 flg: E typ: 2 - INDEX brn: 0 bdba: 0x1400789 ver: 0x01 inc: 0 exflg: 0 Itl Xid Uba Flag Lck Scn/Fsc 0x01 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000 0x02 0x0005.008.000000e7 0x00800226.005c.24 --U- 1 fsc 0x0000.00e9f122 Leaf block dump =============== header address 71963236=0x44a1264 kdxcolev 0 KDXCOLEV Flags = - - - kdxcolok 0 kdxcoopc 0x90: opcode=0: iot flags=I-- is converted=Y kdxconco 1 kdxcosdc 0 kdxconro 1 kdxcofbo 38=0x26 kdxcofeo 8026=0x1f5a kdxcoavs 7988 kdxlespl 0 kdxlende 0 kdxlenxt 0=0x0 kdxleprv 0=0x0 kdxledsz 0 kdxlebksz 8036 row#0[8026] flag: K----, lock: 2 col 0; len 2; (2): c1 02 tl: 5 fb: --H-FL-- lb: 0x0 cc: 1 col 0: [ 1] Dump of memory from 0x044A31C7 to 0x044A31C8 44A31C0 61010100 [...a] ----- end of leaf block dump ----- End dump data blocks tsn: 5 file#: 5 minblk 1932 maxblk 1932 可以看到,根据DUMP结果的3、4、5、6位可以定位记录的物理位置。 需要注意的是,索引组织表以主键的顺序存储数据,因此插入、更新和删除数据都可能造成一条记录的物理位置发生变化,这时通过ROWID中的DATAFILE和BLOCK的信息可能就无法正确定位到记录的物理位置。当根据逻辑ROWID访问索引组织表时,首先会根据DATAFILE和BLOCK信息去找到相应的BLOCK,检查数据是否在这个BLOCK中,如果不在,就通过逻辑ROWID中的主键信息去通过索引扫描,找到这条记录。这就是Oracle文档在提到的physical guess。 下面看一个由字符串和日期组成联合主键的例子。 SQL> create table test_index2 (id char(4), time date, 2 constraint pk_test_index2 primary key (id, time)) organization index; 表已创建。 SQL> insert into test_index2 values (''''1'''', sysdate); 已创建 1 行。 SQL> col dump_rowid format a75 SQL> select rowid, dump(rowid) dump_rowid from test_index2; ROWID DUMP_ROWID ---------------------------- ------------------------------------------------------------------ *BAFAB5QEMSAgIAd4aAwXASMT/g Typ=208 Len=20: 2,4,1,64,7,148,4,49,32,32,32,7,120,104,12,23,1,35,19,254 可以看出,第7位是字段id的长度4,然后是字符串1和三个空格的ASCII码,这是字符串的存储格式,后面跟着的7是字段time长度,后面七位是日期的存储格式。在逻辑ROWID中,数值、字符和日期类型的存储格式都和它们本身的存储格式一致,这里不在赘述。 一般情况下,使用一位来表示长度,但是如果长度超过了127(16进制DUMP的结果是7F),则长度开始用两位表示。第一位以8开头,这个8只是标识位,表明长度字段现在由两位来表示。例如长度128表示位8080,而支持的最大值3800表示为8ED8。 ============================================================== Oracle基本数据类型存储格式浅析(五)——RAW类型 发表人:yangtingkun | 发表时间: 2004年十二月23日, 15:20 和其他数据类型相比,RAW类型的存储显得直观多了,它和SELECT时数据展示的值完全一样。(SELECT时是按照16进制展示的) SQL> create table test_raw (id number, raw_date raw(10)); 表已创建。 SQL> insert into test_raw values (1, hextoraw(''''ff'''')); 已创建 1 行。 SQL> drop table test_raw; 表已丢弃。 SQL> create table test_raw (raw_col raw(10)); 表已创建。 SQL> insert into test_raw values (hextoraw(''''ff'''')); 已创建 1 行。 SQL> insert into test_raw values (hextoraw(''''0'''')); 已创建 1 行。 SQL> insert into test_raw values (hextoraw(''''23fc'''')); 已创建 1 行。 SQL> insert into test_raw values (hextoraw(''''fffffffffff'''')); 已创建 1 行。 SQL> insert into test_raw values (hextoraw(''''ffffffffffffffffffff'''')); 已创建 1 行。 SQL> insert into test_raw values (utl_raw.cast_to_raw(''''051'''')); 已创建 1 行。 SQL> select raw_col, dump(raw_col, 16) dump_raw from test_raw; RAW_COL DUMP_RAW -------------------- ----------------------------------------------- FF Typ=23 Len=1: ff 00 Typ=23 Len=1: 0 23FC Typ=23 Len=2: 23,fc 0FFFFFFFFFFF Typ=23 Len=6: f,ff,ff,ff,ff,ff FFFFFFFFFFFFFFFFFFFF Typ=23 Len=10: ff,ff,ff,ff,ff,ff,ff,ff,ff,ff 303531 Typ=23 Len=3: 30,35,31 已选择6行。 RAW类型的存储很简单,对比字段的查询结果和DUMP的结果就一目了然了。 需要注意的是,两种转化为RAW的函数之间的差别。当使用HEXTORAW时,会把字符串中数据当作16进制数。而使用UTL_RAW.CAST_TO_RAW时,直接把字符串中每个字符的ASCII码存放到RAW类型的字段中。 SQL> insert into test_raw values (''''gg''''); insert into test_raw values (''''gg'''') * ERROR 位于第 1 行: ORA-01465: 无效的十六进制数字 SQL> insert into test_raw values (hextoraw(''''gg'''')); insert into test_raw values (hextoraw(''''gg'''')) * ERROR 位于第 1 行: ORA-01465: 无效的十六进制数字 SQL> insert into test_raw values (utl_raw.cast_to_raw(''''gg'''')); 已创建 1 行。 SQL> select raw_col, dump(raw_col, 16) dump_raw from test_raw; RAW_COL DUMP_RAW -------------------- ---------------------------------------------- FF Typ=23 Len=1: ff 00 Typ=23 Len=1: 0 23FC Typ=23 Len=2: 23,fc 6767 Typ=23 Len=2: 67,67 0FFFFFFFFFFF Typ=23 Len=6: f,ff,ff,ff,ff,ff FFFFFFFFFFFFFFFFFFFF Typ=23 Len=10: ff,ff,ff,ff,ff,ff,ff,ff,ff,ff 303531 Typ=23 Len=3: 30,35,31 已选择7行。
上一页 [1] [2] [3] [4] [5] 没有相关教程
|
|
教程录入:mintao 责任编辑:mintao |
|
|
上一篇教程: 解析Oracle各种数据类型 下一篇教程: 如何使用Oracle的BFILE |
|
|
【字体:小 大】【发表评论】【加入收藏】【告诉好友】【打印此文】【关闭窗口】 |
|
注:本站部分文章源于互联网,版权归原作者所有!如有侵权,请原作者与本站联系,本站将立即删除! 本站文章除特别注明外均可转载,但需注明出处! [MinTao学以致用网] |
网友评论:(只显示最新10条。评论内容只代表网友观点,与本站立场无关!) |
|
|
|
|
|
|
|
同类栏目 |
|
|
赞助链接 |
|
|
500 - 内部服务器错误。
|
|
|
|
|
|