以下的文章主要是对Oracle ROWID数据类型的相关存储格式的介绍，我们都知道Oracle的相关文档上一般是没有关于逻辑Oracle ROWID的相关编码规则的介绍，而且通过DUMP的结果也很难反推出编码规则。
因此，本文只简单讨论一下逻辑Oracle 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: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位可以定位记录的物理位置。
需要注意的是，索引组织表以主键的顺序存储数据，因此插入、更新和删除数据都可能造成一条记录的物理位置发生变化，这时通过Oracle ROWID中的DATAFILE和BLOCK的信息可能就无法正确定位到记录的物理位置。
当根据逻辑Oracle 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长度，后面七位是日期的存储格式。在逻辑Oracle ROWID中，数值、字符和日期类型的存储格式都和它们本身的存储格式一致，这里不在赘述。
一般情况下，使用一位来表示长度，但是如果长度超过了127（16进制DUMP的结果是7F），则长度开始用两位表示。第一位以8开头，这个8只是标识位，表明长度字段现在由两位来表示。例如长度128表示位8080，而支持的最大值3800表示为8ED8。
【编辑推荐】
