select count(ename)

Misses in library cache during parse: 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 BY INDEX ROWID EMP REG

200000 INDEX UNIQUE SCAN (object id 24743)

Хочу обратить ваше внимание на следующее.

Хеш-кластер требует существенно меньше операций ввода/вывода (столбец query)-Этого мы и ждали. При выполнении запроса брались случайные числа, к ним применялась хеш-функция и читался соответствующий блок. Для получения данных из хеш-кластера необходима минимум одна операция ввода/вывода. В обычной таблице с индексом придется просмотреть индекс, а затем выполнить доступ к таблице по идентификатору строки. Для получения данных из таблицы по индексу необходимо минимум две операции ввода/вывода.

Запрос к хеш-кластеру требует заметно больше процессорного времени. Это тоже можно было предсказать. Вычисление хеш-значения требует ресурсов процессора. Поиск по индексу требует выполнения нескольких операций ввода/вывода.

Общее время выполнения запроса к хеш-кластеру - меньше. Так будет не всегда. В моей системе (для этого теста использовался ноутбук с одним пользователем; медленно работающие диски, но все процессорное время принадлежит мне), ресурсов процессора хватало, но медленно работал диск. Поскольку я имел исключительный доступ к ресурсам процессора, время выполнения для запроса к хеш-кластеру оказалось близким к процессорному времени выполнения. Однако, поскольку диски моего ноутбука работают не слишком быстро, пришлось долго ждать выполнения операций ввода/вывода.

Последнее замечание наиболее существенно. При работе с компьютерами необходимо учитывать ресурсы и их использование. Если низка производительность процесса ввода/вывода и выполняются запросы, интенсивно выбирающие данные по ключу, как в приведенном примере, хеш-кластер может повысить производительность. Если же не

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

Особым случаем хеш-кластера является однотабличный хеш-кластер. Это - оптимизированная версия уже рассмотренного хеш-кластера общего вида. В таком кластере в каждый момент времени может находиться только одна таблица (необходимо удалить существующую таблицу в однотабличном хеш-кластере, прежде чем можно будет создать новую). Кроме того, при наличии однозначного соответствия между хеш-значениями и строкам данных, доступ к данным несколько ускоряется. Эти хеш-кластеры создавались для случаев, когда необходим быстрый доступ к таблице по первичному ключу, а не совместное размещение нескольких таблиц. Если необходим быстрый доступ к записи сотрудника по полю EMPNO, имеет смысл подумать об использовании однотаблично-го хеш-кластера. Я выполнил тест, аналогичный описанному выше, на однотабличном хеш-кластере, и получил еще более высокую производительность, чем при использовании обычного хеш-кластера. Однако в этом примере я пошел дальше, т.е. учел тот факт, что сервер Oracle позволяет задать собственную, специализированную хеш-функцию (вместо стандартной функции сервера). В хеш-функциях можно использовать только столбцы таблицы и встроенные функции Oracle (нельзя использовать свои хранимые функции, написанные, например, на языке PL/SQL). Учитывая, что столбец EMPNO в предыдущем примере - число от 1 до 50000, я создал свою хеш-функцию в виде столбца EMPNO. При этом гарантировано не будет совпадения хеш-значений. Итак, создаем однотабличный хеш-кластер с собственной хеш-функцией:

tkyte@TKYTE816> create cluster single table hash cluster

2 (hash key INT)

3 hashkeys 50000

4 size 45

5 single table

6 ash is ISH KEY

Cluster created.

Для того чтобы сделать хеш-кластер однотабличным, мы добавили ключевые слова SINGLE TABLE. Функция HASH IS в данном случае - просто ключ кластера, HASH KEY. Это SQL-функция; при желании можно б1ло бы использовать выражение trunc(mod(hash key/324+278555)/abs(hash key+l)) (я не утверждаю, что это хорошая хеш-функция, просто демонстрирую, что при необходимости можно задавать сложное выражение). Теперь создадим таблицу в кластере:

tkyte@KY816> create table single table jLnp

2 (empno INT ,

3 ename varchar2(10) ,

4 job varchar2(9),

5 mgr number,

6 hiredate date,

10 11 12

sal number, comm number, deptno number(2)

cluster /

single table hash cluster(empno)

Table created.

и загрузим в нее данные из таблицы ЕМР, оставшиеся в этой таблице после выполнения предыдущего примера:

tkyte@TKYTE816> insert into single table emp 2 select * from emp;

50008 rows created.

После выполнения того же запроса, что и для прежних двух таблиц, в отчете утилиты TKPROF можно обнаружить следующее:

select count(ename)

from single table emp, random where single table emp.empno = random.x

Optimizer goal: CHOOSE Parsing user id: 264

Rows

Row Source Operation

1 SORT AGGREGATE

100000 NESTED LOOPS

100001 TABLE ACCESS FULL RANDOM

100000 TABLE ACCESS HASH SINGLE TABLE EMP

Запрос обработал на четверть меньше блоков, чем в обычном хеш-кластере. Это произошло благодаря удачному сочетанию использования собственной хеш-функции, гарантирующей несовпадение ключей, и однотабличного хеш-кластера.

Мы рассмотрели основные особенности хеш-кластеров. Они сходны с рассмотренными ранее индексными кластерами, но при обращении к данным не используется индекс, поскольку сами данные и являются индексом. Ключ кластера хешируется в адрес блока, и предполагается, что данные находятся в этом блоке. Важно хорошо понять следующее.

Место под хеш-кластер выделяется сразу при создании. Сервер Oracle выделит HASHKEYS/trunc(blocksize/SIZE) байтов сразу же. При помещении в кластер