Oracle中聚簇表的使用.docx
《Oracle中聚簇表的使用.docx》由会员分享，可在线阅读，更多相关《Oracle中聚簇表的使用.docx（12页珍藏版）》请在冰豆网上搜索。
Oracle中聚簇表的使用
Oracle中ClusterTable的使用
大家通常oracle中的cluster的理解是不准确的，经常和sqlserver中的clusterindex混淆。
Cluster是存储一组table的一种方法，这些table共享同一数据块中的某些相同column，并把不同table在这一共享column上值相同的datarow存储到同一block上。
在sqlserver中的clusterindex强制行根据indexkey按存储顺序存储，这一点和oracle中的IOT类似。
从下图中我们可以清楚的看到cluster和非cluster的一组table的物理存储的区别。
在cluster中，单个block上的数据可能来自多个table，概念上可以存储“预连接”的数据。
单个table也可以使用cluster，即根据某些column按组存储数据。
如图中，所有部门ID为20和110的部门信息和员工信息的数据都将存储在同一block。
注意，这里存储的并不是排序的数据（那是IOT的任务），存储的是按部门ID分组集合的数据，是以heap的方式存储的。
因此，部门20刚好和部门110相邻，而部门99和部门100相距很远（硬盘的物理位置）。
当单个block放不下时，额外的block将链接到最初的block，来包容溢出的数据，这种方式和在IOT中溢出block非常相似。
现在我们看看如何创建一个cluster。
在cluster中创建一系列table是很简单的，对象存储定义如PCTFREE，PCTUSED，INITIAL都是和cluster相关的，而不是和table相关。
这是因为在cluster中存储了若干table，每个table在同一个block中拥有不同的PCTFREE没有意义。
SQL>createclustere_d_cluster
2（deptidnumber
（2））
3size1024
4/
Clustercreated
这里首先创建了一个indexcluster。
这个cluster的key为deptid，在table中这个列可以不命名为deptid，但数据类型number
（2）必须匹配。
Size选项是用来告诉oracle预计有1024
字节数据和每个cluserkey相关。
Oracle将使用这个信息来计算每个block能容纳的最大clusterkey数目。
因此size太高，在每一block将得到很少的key，并且将使用比需要的更多的空间；设置容量太低，将得到过多的数据连接，这将偏离使用cluster的目的。
Size是cluster的重要参数。
现在我们来创建clusterindex。
在把数据放入之前，需要索引cluster。
Clusterindex的作用是存储一个clusterkey，并且返回包含该key的block的地址。
SQL>createindexe_d_cluster_idx
2onclustere_d_cluster
3/
Indexcreated
Clusterkey的index可以使用index所有的正常的存储参数，并且可以位于另一个tablespace。
它是一个正常的index，能够索引到一个cluster，并且也包含一个完全null的条目。
我们在cluster中创建table：
SQL>createtabledepartment
2（deptidnumber
（2）primarykey,
3dnamevarchar2（14）,
4locvarchar2（13））
5clustere_d_cluster（deptid）;
Tablecreated
SQL>createtableemployee
2（empidnumberprimarykey,
3enamevarchar2（10）,
4jobvarchar2（10）,
5mgrnumber,
6hiredatedate,
7salnumber,
8commnumber,
9deptidnumber
（2）referencesdepartment（deptid））
10clustere_d_cluster（deptid）;
Tablecreated
这里创建table与普通的table唯一的区别就是使用了cluster关键字，我们往table中装载数据：
SQL>begin
2forxin（select*fromscott.dept）
3loop
4insertintodepartment
5values（x.deptno,x.dname,x.loc）;
6insertintoemployee
7select*fromscott.emp
8wheredeptno=x.deptno;
9endloop;
10end;
11/
PL/SQLproceduresuccessfullycompleted
我们可以看到目前table中装载了如下数据：
SQL>select*fromdepartment;
DEPTIDDNAMELOC
---------------------------------
10ACCOUNTINGNEWYORK
20RESEARCHDALLAS
30SALESCHICAGO
40OPERATIONSBOSTON
SQL>select*fromemployee;
EMPIDENAMEJOBMGRHIREDATESALCOMMDEPTID
-----------------------------------------------------------------------------
7782CLARKMANAGER78391981-6-9245010
7839KINGPRESIDENT1981-11-17500010
7934MILLERCLERK77821982-1-23130010
7369SMITHCLERK79021980-12-1780020
7566JONESMANAGER78391981-4-2297520
7788SCOTTANALYST75661982-12-9300020
7876ADAMSCLERK77881983-1-12110020
7902FORDANALYST75661981-12-3300020
7499ALLENSALESMAN76981981-2-20160030030
7521WARDSALESMAN76981981-2-22125050030
7654MARTINSALESMAN76981981-9-281250140030
7698BLAKEMANAGER78391981-5-1285030
7844TURNERSALESMAN76981981-9-81500030
7900JAMESCLERK76981981-12-395030
现在我们看看这两个table数据存储的位置：
SQL>selectdbms_rowid.rowid_block_number（department.rowid）dept_rid,
2dbms_rowid.rowid_block_number（employee.rowid）emp_rid,department.deptid
3fromdepartment,employee
4whereemployee.deptid=department.deptid;
DEPT_RIDEMP_RIDDEPTID
--------------------------
5587558710
5587558710
5587558710
5587558720
5587558720
5587558720
5587558720
5587558720
5587558730
5587558730
5587558730
5587558730
5587558730
5587558730
可以看到部门ID相同的数据存储在一个block上。
我们为什么推荐上述方法对cluster进行最初的装载呢？
这样能够保证如果有些clusterkey的相关数据超过了size，仍能使大部分数据聚集在一个block上。
这只适用于最初的数据装载，在这以后，可以使用事务对cluster中的tableinsert数据。
由于cluster中的特殊的数据存储方式，出现了这样一个问题，rowid出现了重复，现在rowid只能在一个table中唯一标识一行数据了（另一种rowid重复出现在transporttablespace的操作后）。
SQL>selectrowidfromdepartment
2intersect
3selectrowidfromemployee;
ROWID
------------------
AAAGWQAADAAABXTAAA
AAAGWQAADAAABXTAAB
AAAGWQAADAAABXTAAC
AAAGWQAADAAABXTAAD
我们还发现，重复的rowid的数量和主表中的记录数一样，即和cluster中的记录数一样。
我们把这个blickdump出来，看看是什么原因：
SQL>altersystemdumpdatafile3block5587;
Systemaltered
DumpfileD:
\database\oracle\admin\ora817\udump\ORA02628.TRC
WedDec3112:
31:
102003
ORACLEV8.1.7.4.1-Productionvsnsta=0
vsnsql=fvsnxtr=3
Windows2000Version5.0ServicePack4,CPUtype586
Oracle8iEnterpriseEditionRelease8.1.7.4.1-Production
WiththePartitioningoption
JServerRelease8.1.7.4.1-Production
Windows2000Version5.0ServicePack4,CPUtype586
Instancename:
ora817
Redothreadmountedbythisinstance:
1
Oracleprocessnumber:
17
Windowsthreadid:
2628,image:
ORACLE.EXE
***SESSIONID:
（17.1471）2003-12-3112:
31:
10.159
Startdumpdatablockstsn:
2file#:
3minblk4275maxblk4275
buffertsn:
2rdba:
0x00c010b3（3/4275）
scn:
0x0000.00142980seq:
0x01flg:
0x02tail:
0x29800601
frmt:
0x02chkval:
0x0000type:
0x06=transdata
Blockheaderdump:
0x00c010b3
ObjectidonBlock?
Y
seg/obj:
0x657d csc:
0x00.14297c itc:
2 flg:
O typ:
1-DATA
fsl:
0 fnx:
0x0ver:
0x01
Itl Xid Uba Flag Lck Scn/Fsc
0x01 xid:
0x0003.029.000002d2 uba:
0x00800466.006e.35 C--- 0 scn0x0000.0014297c －－－1.这两个transaction的flag和lck是什么意思？
0x02 xid:
0x0003.023.000002d2 uba:
0x00800467.006e.37 --U- 18 fsc0x0000.00142980
data_block_dump
===============
tsiz:
0x1fa0
hsiz:
0x46
pbl:
0x11ab745c
bdba:
0x00c010b3
flag=------K----
ntab=3 －－这是代表5587的block上有3个table
（e_d_cluster,department,employee）
nrow=22
frre=-1
fsbo=0x46
fseo=0x1ce3
avsp=0x1c9d
tosp=0x1c9d
0xe:
pti[0] nrow=4 offs=0 －－这是3个table的行数及开始的偏移量
0x12:
pti[1] nrow=4 offs=4
0x16:
pti[2] nrow=14 offs=8
0x1a:
pri[0] offs=0x1f8a
0x1c:
pri[1] offs=0x1eef
0x1e:
pri[2] offs=0x1e10
0x20:
pri[3] offs=0x1cf9
0x22:
pri[4] offs=0x1f72
0x24:
pri[5] offs=0x1edb
0x26:
pri[6] offs=0x1dfe
0x28:
pri[7] offs=0x1ce3
0x2a:
pri[8] offs=0x1f4c
0x2c:
pri[9] offs=0x1f29
0x2e:
pri[10] offs=0x1f05
0x30:
pri[11] offs=0x1eb8
0x32:
pri[12] offs=0x1e92
0x34:
pri[13] offs=0x1e6d
0x36:
pri[14] offs=0x1e4a
0x38:
pri[15] offs=0x1e26
0x3a:
pri[16] offs=0x1dd5
0x3c:
pri[17] offs=0x1dac
0x3e:
pri[18] offs=0x1d81
0x40:
pri[19] offs=0x1d5b
0x42:
pri[20] offs=0x1d32
0x44:
pri[21] offs=0x1d0f
block_row_dump:
tab0,row0,@0x1f8a －－从这开始是emp_dept_cluster
tl:
22fb:
K-H-FL--lb:
0x0cc:
1
curc:
4comc:
4pk:
0x00c010b3.0nk:
0x00c010b3.0
col 0:
[2] c10b
tab0,row1,@0x1eef
tl:
22fb:
K-H-FL--lb:
0x0cc:
1
curc:
6comc:
6pk:
0x00c010b3.1nk:
0x00c010b3.1
col 0:
[2] c115
tab0,row2,@0x1e10
tl:
22fb:
K-H-FL--lb:
0x0cc:
1
curc:
7comc:
7pk:
0x00c010b3.2nk:
0x00c010b3.2
col 0:
[2] c11f
tab0,row3,@0x1cf9
tl:
22fb:
K-H-FL--lb:
0x0cc:
1
curc:
1comc:
1pk:
0x00c010b3.3nk:
0x00c010b3.3
col 0:
[2] c129
tab1,row0,@0x1f72 －－从这开始是department
tl:
24fb:
-CH-FL--lb:
0x2cc:
2cki:
0
col 0:
[10] 4143434f554e54494e47
col 1:
[8] 4e455720594f524b
tab1,row1,@0x1edb
tl:
20fb:
-CH-FL--lb:
0x2cc:
2cki:
1
col 0:
[8] 5245534541524348
col 1:
[6] 44414c4c4153
tab1,row2,@0x1dfe
tl:
18fb:
-CH-FL--lb:
0x2cc:
2cki:
2
col 0:
[5] 53414c4553
col 1:
[7] 4348494341474f
tab1,row3,@0x1ce3
tl:
22fb:
-CH-FL--lb:
0x2cc:
2cki:
3
col 0:
[10] 4f5045524154494f4e53
col 1:
[6] 424f53544f4e
tab2,row0,@0x1f4c －－2从这开始是employee，因为department和
employee都从row0开始，所以rowid会出现重复
tl:
38fb:
-CH-FL--lb:
0x2cc:
6cki:
0 －－3.这为什么有tran的信息？
col 0:
[3] c24e53
col 1:
[5] 434c41524b
col 2:
[7] 4d414e41474552
col 3:
[3] c24f28
col 4:
[7] 77b50609010101
col 5:
[3] c21933
tab2,row1,@0x1f29
tl:
35fb:
-CH-FL--lb:
0x2cc:
6cki:
0
col 0:
[3] c24f28
col 1:
[4] 4b494e47
col 2:
[9] 505245534944454e54
col 3:
*NULL*
col 4:
[7] 77b50b11010101
col 5:
[2] c233
tab2,row2,@0x1f05
tl:
36fb:
-CH-FL--lb:
0x2cc:
6cki:
0
col 0:
[3] c25023
col 1:
[6] 4d494c4c4552
col 2:
[5] 434c45524b
col 3:
[3] c24e53
col 4:
[7] 77b60117010101
col 5:
[2] c20e
tab2,row3,@0x1eb8
tl:
35fb:
-CH-FL--lb:
0x2cc:
6cki:
1
col 0:
[3] c24a46
col 1:
[5] 534d495448
col 2:
[5] 434c45524b
col 3:
[3] c25003
col 4:
[7] 77b40c11010101
col 5:
[2] c209
tab2,row4,@0x1e92
tl:
38fb:
-CH-FL--lb:
0x2cc:
6cki:
1
col 0:
[3] c24c43
col 1:
[5] 4a4f4e4553
col 2:
[7] 4d414e41474552
col 3:
[3] c24f28
col 4:
[7] 77b50402010101
col 5:
[3] c21e4c
tab2,row5,@0x1e6d
tl:
37fb:
-CH-FL--lb:
0x2cc:
6cki:
1
col 0:
[3] c24e59
col 1:
[5] 53434f5454
col 2:
[7] 414e414c595354
col 3:
[3] c24c43
col 4:
[7] 77b60c09010101
col 5:
[2] c21f
tab2,row6,@0x1e4a
tl:
35fb:
-CH-FL--lb:
0x2cc:
6cki:
1
col 0:
[3] c24f4d
col 1:
[5] 4144414d53
col 2:
[5] 434c45524b
col 3:
[3] c24e59
col 4:
[7] 77b7010c010101
col 5:
[2] c20c
tab2,row7,@0x1e26
tl:
36fb:
-CH-FL--lb:
0x2cc:
6cki:
1
col 0:
[3] c25003
col 1:
[4] 464f5244
col 2:
[7] 414e414c595354
col 3:
[3] c24c43
col 4:
[7] 77b50c03010101
col 5:
[2] c21f
tab2,row8,@0x1dd5
tl:
41fb:
-CH-FL--lb:
0x2cc:
7cki:
2
col 0:
[3] c24b64
col 1:
[5] 414c4c454e
col 2:
[8] 53414c45534d414e
col 3:
升级会员 