對邏輯Oracle ROWID的存儲經驗的總結
以下的文章主要是對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。
【編輯推薦】
