1000, а поскольку у меня размер блока - 8 Кбайт, то сервер Oracle должен б1л втде-лить (8192 * 1009) байт. Мы получили несколько больший результат; это связано с округлением количества выделяемых экстентов и/или использованием локально управляемого табличного пространства с экстентами одинакового размера.

Мы столкнулись с одной из проблем при использовании хеш-кластеров, которую необходимо учитывать. Обычно при создании пустой таблицы количество блоков до отметки максимального уровня равно 0. При ее полном просмотре сразу достигается отметка максимального уровня, и просмотр завершается. При использовании хеш-кластера таблицы - изначально большие и создаваться будут дольше, поскольку сервер Oracle должен проинициализировать каждый блок, что обычно происходит лишь при добавлении данных в таблицу. Таблицы могут иметь данные в первом и в последнем блоке, а остальные будут пустыми. Полный просмотр практически пустого хеш-кластера потребует столько же времени, как и полного. Это не всегда плохо: хеш-кластер создается для очень быстрого доступа к данным по ключу, а не для частого полного просмотра.

Теперь можно помещать таблицы в хеш-кластер точно так же, как это делается для индексных кластеров. Например:

tkyte@TKYTE816> create table hashed table

2 (x number, data1 varchar2(4000), data2 varchar2(4000))

3 cluster hash cluster(x);

Table created.

Чтобы продемонстрировать отличие хеш-кластера, я создал небольшой тестовый пример: создал хеш-кластер, загрузил в него немного данных, скопировал эти данные в обычную таблицу с обычным индексом, а затем выполнил 100000 случайных чтений из каждой таблицы (в равной степени случайные чтения). С помощью параметра SQLTRACE и утилиты TKPROF (подробнее об этих средствах см. в главе 10, посвященной стратегиям и средствам настройки) я определил производительность работы с каждой из них. Вот что я делал и как анализировал результаты:

tkyte@TKYTE816> create cluster hash cluster

2 (hash key number)

3 hashkeys 50000

4 size 45

Cluster created.

tkyte@TKYTE816> create table emp

2 cluster hash cluster(empno)

3 as

4 select rownum empno, ename, job, mgr, hiredate, sal, comra, deptno

5 from scott.emp

6 where 1=0

Table created.

Определив, что средний размер строки в таблице будет 45 байт (для этого я проанализировал таблицу SCOTT.EMP), я создал хеш-кластер с параметром SIZE, равным 45

байт. Затем я создал в кластере пустую таблицу, по структуре аналогичную таблице SCO.EMP. Единственное изменение - выбор ROWNUM вместо EMPNO, так что в созданной мной таблице этот столбец имеет тип NUMBER, а не NUMBER(4). В таблице заведомо должно быть более 9999 строк, поскольку я собираюсь вставить туда около 50000.

Затем я заполнил данными таблицу и создал ее обычный аналог:

tkyte@TKYTE816> declare

2 1 cnt number;

3 l empno number default 1;

4 begin

5 select count(*) into l cnt from scott.emp;

7 for x in (select * from scott.emp)

8 loop

9 for i in 1 .. trunc(50000/l cnt)+l

10 loop

11 insert into emp values

12 (l empno, x.ename, x.job, x.mgr, x.hiredate, x.sal,

13 x.comm, x.deptno) ;

14 l empno := l empno+l;

15 end loop;

16 end loop;

17 commit;

18 end;

19 /

PL/SQL procedure successfully completed.

tkyte@TKYTE816> create table emp reg

2 as

3 select * from emp; Table created.

tkyte@TKYTE816> alter table emp reg add constraint emp pk primary key(empno);

Table altered.

Теперь осталось только получить случайные данные для выборки строк из каждой таблицы:

tkyte@TKYTE816> create table random (x int) ; Table created.

tkyte@TKYTE816> begin

2 for i in 1 . . 100000

3 loop

4 insert into random values

5 (mod (abs(dbms random.random),50000)+l);

6 end loop;

7 end;

PL/SQL procedure successfully completed.

Теперь все готово для тестирования: tkyte@TKYTE816> alter session set sql trace=true; Session altered.

tkyte@TKYTE816> select count(ename)

2 from emp, random

3 where emp.empno = random.x;

COUNT (ENAME)

tkyte@TKYTE816> select count(ename)

2 from emp reg, random

3 where emp reg.empno = random.x;

COUNT (ENAME)

100000

Я знал, что оптимизатор должен выбрать метод FULL SCAN random в обоих случаях, поскольку другого метода доступа к этой таблице не существует. Я полагал, что будет выполняться соединение вложенными циклами с таблицами ЕМР и EMPREG (что и происходило). В результате б1ло выполнено 100000 случайных чтений из двух этих таблиц. В отчете TKPROF я обнаружил следующее:

select count(ename) from emp, random where emp.empno = random.x

Optimizer goal: CHOOSE Parsing user id: 66

Rows

Row Source Operation

1 SORT AGGREGATE

100000 NESTED LOOPS

100001 TABLE ACCESS FULL RANDOM 100000 TABLE ACCESS HASH EHF