Table created.

tkyte@TKYTE816> create table emp

2 3 4 5 6 7 8

9 10

(empno number primary key, ename varchar2(10) ,

job mgr

hiredate sal

comm

varchar2(9),

number,

date,

number,

number,

deptno number(2) references dept(deptno)

cluster emp dept cluster(deptno)

Table created.

Здесь единственное отличие от обычной таблицы связано с использованием конструкции CLUSTER, которая сообщает серверу Oracle, какой столбец таблицы будет соответствовать ключу кластера. Теперь можно загружать в таблицу начальный набор данных:

tky(e@TKYTE81 begin

3 4 5 6

8 9 10 11 12

for x in loop

(select * from scott.dept)

insert into dept values (x.deptno, insert into emp select *

from scott.emp where deptno = x.deptno;

x.dname, x.loc);

end loop;

end;

PL/SQL procedure successfully completed.

Возможно, вы задаете себе вопрос: Почему бы просто не вставить все данные таблица: DEPT, а потом все данные таблицы ЕМР; или почему мы загружаем данные вот так, по отделам? . Причина в структуре кластера. Я имитировал начальную загрузку большого объема данных в кластер. Если бы я сначала загрузил все строки из таблицы DEPT, мы бы точно получили по 7 ключей в блоке (в соответствии с заданным параметром SIZE 1024), поскольку строки таблицы DEPT - очень маленькие, всего несколько байтов. Когда же дело дойдет до загрузки строк таблицы ЕМР, может оказаться, что в некоторых отделах данных намного больше, чем 1024 байт. В результате потребуется создание больших цепочек блоков для соответствующих ключей кластера. Загружая все данные для одного ключа кластера сразу, мы максимально упаковываем блоки и начинаем новый блок, когда в текущем уже нет места. Сервер Oracle разместит не до семи ключей кластера в одном блоке, а столько, сколько вместится. Простой пример покажет различие между двумя подходами к загрузке данных.

Добавим в таблицу ЕМР большой столбец типа CHAR(1000). Он сделает строки таблицы ЕМР намного больше. Будем загружать таблицы кластера двумя способами. Сначала загрузим всю таблицу DEPT, а затем - всю таблицу ЕМР. После этого будем загружать данные по отделам: строку - из таблицы DEPT, а затем - все строки из таблицы ЕМР с соответствующим номером отдела; потом - следующую строку из таблицы DEPT. Посмотрим, в каком блоке окажутся строки в каждом из случаев, чтобы понять, какой из способов больше соответствует цели совместного размещения данных с общим значением в столбце DEPTNO. В этом примере таблица ЕМР имеет следующий вид:

create table emp (empno number primary key, ename varchar2(10), job varchar2(9), mgr number, hiredate date, sal number, conm number,

deptno number(2) references dept(deptno) , data char (1000) default *

cluster emp dept cluster(deptno) /

При загрузке данных последовательно в таблицы DEPT и ЕМР окажется, что многие строки таблицы ЕМР больше не попадают в тот же блок, что и строка DEPT (DBMSROWID - это стандартный пакет, позволяющий анализировать значение идентификатора строки):

tkyte@TKYTE816> insert into dept

2 select * from scott.dept

4 rows created.

tkyte@TKYTE816> insert into emp

2 select emp.*, * from scott.emp

14 rows created.

tkyte@TKYTE816> select dbms rowid.rowid block number(dept.rowid) dept rid,

2 dbms rowid.rowid block number(emp.rowid) emp rid,

3 dept.deptno

4 from emp, dept

5 where emp.deptno = dept.deptno

14 rows selected.

Более половины строк таблицы ЕМР не попали в блок с соответствующей строкой таблицы DEPT. При загрузке данных не по ключам таблиц, а по ключу кластера получаем:

tkyte@TKYTE816> begin

2 3 4

8 9 10 11 12

for x loop

in (select

from scott.dept)

insert values insert select

into dept (x.deptno, into emp emp.*, x

x.dname, x.loc);

from scott.emp where deptno = x.deptno; loop;

end;

PL/SQL procedure successfully completed.

tkyte@TKYTE816> select dbms rowid.rowid block number(dept.rowid)

dept rid,

dbms rowid.rowid block number dept.deptno from emp, dept

where emp.deptno = dept.deptno

(emp.rowid) emp rid.

DEPT RID

EMP RID DEPTNO