[转帖]Oracle基本数据类型存储格式浅析(四)_MySQL, Oracle及数据库讨论区_Weblogic技术|Tuxedo技术|中间件技术|Oracle论坛|JAVA论坛|Linux/Unix技术|hadoop论坛_联动北方技术论坛  
网站首页 | 关于我们 | 服务中心 | 经验交流 | 公司荣誉 | 成功案例 | 合作伙伴 | 联系我们 |
联动北方-国内领先的云技术服务提供商
»  游客             当前位置:  论坛首页 »  自由讨论区 »  MySQL, Oracle及数据库讨论区 »
总帖数
2
每页帖数
101/1页1
返回列表
0
发起投票  发起投票 发新帖子
查看: 4211 | 回复: 1   主题: [转帖]Oracle基本数据类型存储格式浅析(四)        下一篇 
kim
注册用户
等级:中校
经验:1729
发帖:222
精华:0
注册:2011-7-21
状态:离线
发送短消息息给kim 加好友    发送短消息息给kim 发消息
发表于: IP:您无权察看 2011-8-1 11:29:31 | [全部帖] [楼主帖] 楼主

ROWID类型(一)

Oracle的ROWID用来唯一标识表中的一条记录,是这条数据在数据库中存放的物理地址。

Oracle的ROWID分为两种:物理ROWID和逻辑ROWID。索引组织表使用逻辑ROWID,其他类型的表使用物理ROWID。其中物理ROWID在Oracle的8版本中进行了扩展,Oracle7及以下版本使用约束ROWID,Oracle8及以上版本使用扩展ROWID。本文描述物理扩展ROWID,由于约束ROWID仅仅是为了兼容早期版本,因此不做讨论。

SQL> create table test_rowid (id number, row_id rowid);


表已创建。

SQL> insert into test_rowid values (1, null);


已创建 1 行。

SQL> update test_rowid set row_id = rowid where id = 1;


已更新 1 行。

SQL> commit;


提交完成。

SQL> select rowid, row_id from test_rowid;
ROWID              ROW_ID
------------------ ------------------
AAABnRAAGAAAACWAAA AAABnRAAGAAAACWAAA


Oracle的物理扩展ROWID有18位,每位采用64位编码,分别用A~Z、a~z、0~9、+、/共64个字符表示。A表示0,B表示1,……Z表示25,a表示26,……z表示51,0表示52,……,9表示61,+表示62,/表示63。

ROWID具体划分可以分为4部分。

1.OOOOOO:前6位表示DATA OBJECT NUMBER,将起转化位数字后匹配DBA_OBJECTS中的DATA_OBJECT_ID,可以确定表信息。

如上面例子中的DATA OBJECT NUMBER是AAABnR,转化位数字是1×64×64 +39×64 + 17。

SQL> select owner, object_name from dba_objects
2  where data_object_id = 1*64*64 + 39*64 + 17;
OWNER                          OBJECT_NAME
------------------------------ -----------------------------
YANGTK                         TEST_ROWID


2.FFF:第7到9位表示相对表空间的数据文件号。

上面的例子中是AAG,表示数据文件6。

SQL> select file_name, tablespace_name from dba_data_files where relative_fno = 6;
FILE_NAME                                     TABLESPACE_NAME
--------------------------------------------- ---------------
E:ORACLEORADATATESTYANGTK01.DBF           YANGTK


3.BBBBBB:第10到15位表示这条记录在数据文件中的第几个BLOCK中。

上面的例子是AAAACW,转化位数字是2×64+22,表示这条记录在数据文件中的第150个BLOCK。

4.RRR:最后3位表示这条记录是BLOCK中的第几条记录。

上面的例子是AAA,表示第0条记录(总是从0开始计数)。

SQL> alter system dump datafile 6 block 150;


系统已更改。

SQL> select row_id, dump(row_id, 16) dump_rowid from test_rowid;
ROW_ID             DUMP_ROWID
------------------ -------------------------------------------------
AAABnRAAGAAAACWAAA Typ=69 Len=10: 0,0,19,d1,1,80,0,96,0,0


找到对应的dump文件,可以发现类型的信息

*** 2004-12-21 17:58:26.000
*** SESSION ID


北京联动北方科技有限公司13.91) 2004-12-21 17:58:26.000

Start dump data blocks tsn: 6 file#: 6 minblk 150 maxblk 150
buffer tsn: 6 rdba: 0x01800096 (6/150)
scn: 0x0000.2e389c16 seq: 0x01 flg: 0x06 tail: 0x9c160601
frmt: 0x02 chkval: 0xc97d type: 0x06=trans data
Block header dump:  0x01800096
Object id on Block? Y
seg/obj: 0x19d1  csc: 0x00.2e389c0f  itc: 2  flg: O  typ: 1 - DATA
fsl: 0  fnx: 0x0 ver: 0x01
Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0003.009.00000057  0x0080004b.0042.56  --U-    1  fsc 0x0000.2e389c16
0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
data_block_dump,data header at 0x651105c
===============
tsiz: 0x3fa0
hsiz: 0x14
pbl: 0x0651105c
bdba: 0x01800096
76543210
flag=--------
ntab=1
nrow=1
frre=-1
fsbo=0x14
fseo=0x3f89
avsp=0x3f7b
tosp=0x3f7b
0xe


北京联动北方科技有限公司ti[0] nrow=1 offs=0

0x12


北京联动北方科技有限公司ri[0] offs=0x3f89

block_row_dump:
tab 0, row 0, @0x3f89
tl: 17 fb: --H-FL-- lb: 0x1  cc: 2
col  0: [ 2]  c1 02
col  1: [10]  00 00 19 d1 01 80 00 96 00 00
end_of_block_dump
End dump data blocks tsn: 6 file#: 6 minblk 150 maxblk 150


有时需要查看表的DUMP信息,但是很难准确定位表中数据开始于哪个BLOCK,根据ROWID中包含的信息就可以方便的找到起始BLOCK。

下面简单描述一下ROWID类型是如何存储的。

SQL> select row_id, dump(row_id, 16) dump_rowid from test_rowid;
ROW_ID             DUMP_ROWID
------------------ -------------------------------------------------
AAABnRAAGAAAACWAAA Typ=69 Len=10: 0,0,19,d1,1,80,0,96,0,0


前4位表示ROWID的前6位,也就是DATA_OBJECT_ID信息。数据以数值���格式保存。

SQL> select to_number('19d1', 'xxxxxx') from dual;
TO_NUMBER('19D1','XXXXXX')
--------------------------
6609
SQL> select 1*64*64 + 39*64 + 17 from dual;
1*64*64+39*64+17
----------------
6609


这里存在一个问题,根据ROWID的取值范围,OBJECT_DATA_ID最大的值是64的6次方,而根据DUMP,oracle只用了4位保存,因此取值范围是256的4次方。

SQL> set numwid 12
SQL> select power(64, 6), power(256, 4), power(64, 6)/power(256, 4) from dual;
POWER(64,6) POWER(256,4) POWER(64,6)/POWER(256,4)
------------ ------------ ------------------------
68719476736   4294967296                       16


可见,OBJECT_DATA_ID的最大值是4294967296,当超过这个值时会出现重复的情况。(当然,现实中不大可能)。

后面4位比较特殊,是数据文件号和BLOCK数的“和”值构成。

数据文件的数值乘64后保存在5、6位上。

SQL> select to_number('0180', 'xxxx') from dual;
TO_NUMBER('0180','XXXX')
------------------------
384
SQL> select 6*64 from dual;
6*64
------------
384


同时,6位BLOCK的值,也保存在这4位上,并与数据文件转存结果相加。仍然是以数字格式存放。

SQL> select to_number('96', 'xxx') from dual;
TO_NUMBER('96','XXX')
---------------------
150
SQL> select 2*64 + 22 from dual;
2*64+22
----------
150


由于采用两位保存数据文件的值,且最小单位是64,因此,ROWID中可以保存的数据文件数是1024,超过1024会造成ROWID的重复。

SQL> select 256*256/64 from dual;
256*256/64
----------
1024


由于BLOCK的值和数据文件共用这4位,因此BLOCK的第3位最大值应小于64,这样才能保证ROWID的不重复。因此BLOCK值的最大值应该是4194304。

SQL> select 64*256*256 from dual;
64*256*256
----------
4194304


最后两位保存BLOCK中记录的值。这个值的最大值是65536。

SQL> select 256*256 from dual;
256*256
----------
65536


Oracle的文档上没有介绍逻辑ROWID的编码规则,而且通过DUMP的结果也很难反推出编码规则。因此,本文只简单讨论一下逻辑ROWID的存储。

下面来看例子。

SQL> create table test_index (id number primary key, name varchar2(20)) organization index;


表已创建。

SQL> insert into test_index values (1, 'a');


已创建 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


北京联动北方科技有限公司racleadmintest4udumptest4_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。




赞(0)    操作        顶端 
kim
注册用户
等级:中校
经验:1729
发帖:222
精华:0
注册:2011-7-21
状态:离线
发送短消息息给kim 加好友    发送短消息息给kim 发消息
发表于: IP:您无权察看 2011-8-1 11:31:42 | [全部帖] [楼主帖] 2  楼

RAW类型

和其他数据类型相比,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行。



赞(0)    操作        顶端 
总帖数
2
每页帖数
101/1页1
返回列表
发新帖子
请输入验证码: 点击刷新验证码
您需要登录后才可以回帖 登录 | 注册
技术讨论