Monthly Archive for 11月, 2008

Oracle index structure

今天早上有人问我,索引中相同的key是不是按照rowid排序的?我们都知道索引中是按照key的值来进行排序的,但是对于相同的key是如何排序的,我并不是很确定,所以做了一些测试。

构造一张表,每个key都在不同的block上,方便测试。

create table test (id number,name varchar2(10));
create index test_id_ind on test(id);
insert into test values(1,’block1′);
insert into test values(2,’block1′);
insert into test values(3,’block1′);

alter table test minimize records_per_block;

insert into test values(1,’block2′);
insert into test values(2,’block2′);
insert into test values(3,’block2′);
insert into test values(1,’block3′);
insert into test values(2,’block3′);
insert into test values(3,’block3′);

select DBMS_ROWID.ROWID_BLOCK_NUMBER(rowid) block,id from test;

BLOCK         ID
———- ———-
80698          1
80698          2
80698          3
80699          1
80699          1
80699          3
80700          1
80700          2
80700          3

如何找到leaf block对应的file#和block#,通过object_id dump出索引的结构信息

ALTER SESSION SET EVENTS  ‘immediate trace name TREEDUMP level object_id’;

—– begin tree dump
leaf: 0×4013cfa 67190010 (0: nrow: 9 rrow: 9)
—– end tree dump

因为索引很小,只有一个block即leaf block

select dbms_utility.data_block_address_file(67190010) file#,
dbms_utility.data_block_address_block(67190010) block# from dual

FILE#     BLOCK#
———- ———-
16      81146

alter system dump datafile 16 block 81146;

row#0[8020] flag: —–, lock: 2
col 0; len 2; (2):  c1 02
col 1; len 6; (6):  04 01 3b 3a 00 00

row#1[7984] flag: —–, lock: 2
col 0; len 2; (2):  c1 02
col 1; len 6; (6):  04 01 3b 3b 00 00
row#2[7948] flag: —–, lock: 2
col 0; len 2; (2):  c1 02
col 1; len 6; (6):  04 01 3b 3c 00 00
row#3[8008] flag: —–, lock: 2
col 0; len 2; (2):  c1 03
col 1; len 6; (6):  04 01 3b 3a 00 01
row#4[7972] flag: —–, lock: 2
col 0; len 2; (2):  c1 03
col 1; len 6; (6):  04 01 3b 3b 00 01
row#5[7936] flag: —–, lock: 2
col 0; len 2; (2):  c1 03
col 1; len 6; (6):  04 01 3b 3c 00 01
row#6[7996] flag: —–, lock: 2
col 0; len 2; (2):  c1 04
col 1; len 6; (6):  04 01 3b 3a 00 02
row#7[7960] flag: —–, lock: 2
col 0; len 2; (2):  c1 04
col 1; len 6; (6):  04 01 3b 3b 00 02
row#8[7924] flag: —–, lock: 2
col 0; len 2; (2):  c1 04
col 1; len 6; (6):  04 01 3b 3c 00 02

我们可以看到是按照key和rowid排序的,我们再做一个update操作,看看效果如何。

update test set id=1 where id=2 and name=’block2′;

row#0[8020] flag: —–, lock: 0
col 0; len 2; (2):  c1 02
col 1; len 6; (6):  04 01 3b 3a 00 00
row#1[7984] flag: —–, lock: 0
col 0; len 2; (2):  c1 02
col 1; len 6; (6):  04 01 3b 3b 00 00

row#2[7912] flag: —–, lock: 2
col 0; len 2; (2):  c1 02
col 1; len 6; (6):  04 01 3b 3b 00 01

row#3[7948] flag: —–, lock: 0
col 0; len 2; (2):  c1 02
col 1; len 6; (6):  04 01 3b 3c 00 00
row#4[8008] flag: —–, lock: 0
col 0; len 2; (2):  c1 03
col 1; len 6; (6):  04 01 3b 3a 00 01
row#5[7972] flag: —D-, lock: 2
col 0; len 2; (2):  c1 03
col 1; len 6; (6):  04 01 3b 3b 00 01
row#6[7936] flag: —–, lock: 0
col 0; len 2; (2):  c1 03
col 1; len 6; (6):  04 01 3b 3c 00 01
row#7[7996] flag: —–, lock: 0
col 0; len 2; (2):  c1 04
col 1; len 6; (6):  04 01 3b 3a 00 02
row#8[7960] flag: —–, lock: 0
col 0; len 2; (2):  c1 04
col 1; len 6; (6):  04 01 3b 3b 00 02
row#9[7924] flag: —–, lock: 0
col 0; len 2; (2):  c1 04
col 1; len 6; (6):  04 01 3b 3c 00 02

可以看到原来的一行被删除,并在适当的位置新插入了一条(注意红色部分),这样就证明索引中相同的key是按照rowid排序的,后来在文档中也找到了这个问题的证明:Multiple rows with identical values are sorted in ascending order by rowid.

Oracle这样做会带来什么好处?我们理所当然的会想到,对于相同的key又在同一个block中的column,那么只需要访问这个block一次就可以了。而不需要每行访问block一次,这样就可以在某些情况下降低逻辑读,打开autotrace很容易得到证明。

后来在网上搜了一下,才发现七公早就对这个问题做过测试了,非常详细。有兴趣的可以去看:non-unique index branch and leaf block structure

–EOF–

Oracle dump命令

Oracle常用dump命令,备查。

一.Memory Dumps

1).Global Area
ALTER SESSION SET EVENTS ‘immediate trace name global_area level n’;
1 包含PGA
2 包含SGA
4 包含UGA
8 包含indrect memory

2).Library Cache
ALTER SESSION SET EVENTS ‘immediate trace name library_cache level n’;
1 library cache统计信息
2 包含hash table histogram
3 包含object handle
4 包含object结构(Heap 0)

3).Row Cache
ALTER SESSION SET EVENTS ‘immediate trace name row_cache level n’;
1 row cache统计信息
2 包含hash table histogram
8 包含object结构

4).Buffers
ALTER SESSION SET EVENTS ‘immediate trace name buffers level n’;
1 buffer header
2 level 1 + block header
3 level 2 + block contents
4 level 1 + hash chain
5 level 2 + hash chain
6 level 3 + hash chain
8 level 4 + users/waiters
9 level 5 + users/waiters
10 level 6 + users/waiters

5).Buffer
ALTER SESSION SET EVENTS ‘immediate trace name buffer level n’;
n为某个指定block的rdba,该命令可以转储某个block在buffer中的所有版本。

6).Heap
ALTER SESSION SET EVENTS ‘immediate trace name heapdump level level’;
1 PGA摘要
2 SGA摘要
4 UGA摘要
8 Current call(CGA)摘要
16 User call(CGA)摘要
32 Large call(LGA)摘要
1025 PGA内容
2050 SGA内容
4100 UGA内容
8200 Current call内容
16400 User call内容
32800 Large call内容

7).Sub Heap
Oracle 9.0.1版本之前
ALTER SESSION SET EVENTS ‘immediate trace name heapdump_addr level n’;
若n为subheap的地址,转储的是subheap的摘要信息
若n为subheap的地址+1,转储的则是subheap的内容
Oracle 9.2.0版本之后
ALTER SESSION SET EVENTS ‘immediate trace name heapdump_addr level n, addr m’;
其中m为subheap的地址
n为1转储subheap的摘要,n为2转储subheap的内容

8).Process State
ALTER SESSION SET EVENTS ‘immediate trace name processstate level n’;

9).System State
ALTER SESSION SET EVENTS ‘immediate trace name systemstate level n’;

10).Error State
ALTER SESSION SET EVENTS ‘immediate trace name errorstack level n’;
0 Error stack
1 level 0 + function call stack
2 level 1 + process state
3 level 2 + context area
11).Hang Analysis
ALTER SESSION SET EVENTS ‘immediate trace name hanganalyze level n’;

12).Work Area
ALTER SESSION SET EVENTS ‘immediate trace name workareatab_dump level n’;
1 SGA信息
2 Workarea Table摘要信息
3 Workarea Table详细信息

13).Latches
ALTER SESSION SET EVENTS ‘immediate trace name latches level n’;
1 latch信息
2 统计信息

14).Events
ALTER SESSION SET EVENTS ‘immediate trace name events level n’;
1 session
2 process
3 system

15).Locks
ALTER SESSION SET EVENTS ‘immediate trace name locks level n’;

16).Shared Server Process
ALTER SESSION SET EVENTS ‘immediate trace name shared_server_state level n’;
n取值为1~14

17).Background Messages
ALTER SESSION SET EVENTS ‘immediate trace name bg_messages level n’;
n为pid+1

二.File Dumps

1).Block
Oracle 7之前
ALTER SESSION SET EVENTS ‘immediate trace name blockdump level n’;
n为block的rdba
Oracle8以后
ALTER SYSTEM DUMP DATAFILE file# BLOCK block#;
ALTER SYSTEM DUMP DATAFILE file#
BLOCK MIN minimum_block#
BLOCK MAX maximum_block#;

2).Tree Dump
ALTER SESSION SET EVENTS ‘immediate trace name treedump level n’;
n为object_id

3).Undo Segment Header
ALTER SYSTEM DUMP UNDO_HEADER ’segment_name’;

4).Undo for a Transaction
ALTER SYSTEM DUMP UNDO BLOCK ’segment_name’ XID xidusn xidslot xidsqn;

5).File Header
ALTER SESSION SET EVENTS ‘immediate trace name file_hdrs level n’;
1 控制文件中的文件头信息
2 level 1 + 文件头信息
3 level 2 + 数据文件头信息
10 level 3

6).Control file
ALTER SESSION SET EVENTS ‘immediate trace name controlf level n’;
1 文件头信息
2 level 1 + 数据库信息 + 检查点信息
3 level 2 + 可重用节信息
10 level 3

7).Redo log Header
ALTER SESSION SET EVENTS ‘immediate trace name redohdr level n’;
1 控制文件中的redo log信息
2 level 1 + 文件头信息
3 level 2 + 日志文件头信息
10 level 3

8).Redo log
ALTER SYSTEM DUMP LOGFILE ‘FileName’;
ALTER SYSTEM DUMP LOGFILE ‘FileName’
SCN MIN MinimumSCN
SCN MAX MaximumSCN
TIME MIN MinimumTime
TIME MAX MaximumTime
LAYER Layer
OPCODE Opcode
DBA MIN FileNumber . BlockNumber
DBA MAX FileNumber . BlockNumber
RBA MIN LogFileSequenceNumber . BlockNumber
RBA MAX LogFileSequenceNumber . BlockNumber;
其中time = (((((yyyy - 1988)) * 12 + mm - 1) * 31 + dd - 1) * 24 + hh) * 60 + mi) * 60 + ss;

9).Loghist
ALTER SESSION SET EVENTS ‘immediate trace name loghist level n’;
1 dump控制文件中最早和最迟的日志历史项
1 dump 2^n个日志历史项

–EOF–

我家的老永久

总是非常怀念家里的那辆永久28寸自行车,当时那是家里唯一的车,爸爸总是把它擦的干干净净,我学骑自行车就是从它开始,车子太大,我只能从中间的横梁下面钻过去那样骑,现在的小孩肯定是想象不到的,但是我们当时都是那样骑的。还记得刚学会骑自行车那会,每天都在院门口等着爸爸下班,这样我就可以骑车出去玩了,那种感觉,难以用语言表达。

现在买了这么多辆自行车,还没发现有一辆比它好骑的。曾经过年回家的时候骑了一次,感觉依然是那么舒服,骑行姿势非常自然,虽然没变速,但是惯性大,随便蹬几下,可以跑很远,而且骑起来非常稳,驮两罐液化气,一点都不飘,勤勤恳恳为我们家服务二十年,还是那么好用。再看看现在的自行车,死贵不说,屁股撅得比头高,不蹬还不跑,东西全在自己身上驮着,走哪都怕丢,除了可以摆酷,我还真没想到什么优点。

可惜啊,一代名车,就这样陨落了。现在国产自行车都是低端低质低价的代名词,市场上不是台湾货就是外国货,可悲可叹。

永久28寸 永久28寸 憨豆先生的永久车

–EOF–