14 rows selected.

Большинство строк таблицы ЕМР теперь в том же блоке, что и соответствующая строка таблицы DEPT. Этот пример - несколько надуманный, поскольку я умышленно занизил параметр SIZE для кластера, чтобы продемонстрировать проблему более наглядно, но рекомендуемый метод подходит для начальной загрузки кластера. Он гарантирует, что если для некоторых ключей кластера предполагаемое значение SIZE будет превышено, большинство данных все равно будет кластеризовано в одном блоке. Если загружать таблицы поочередно, так не получится.

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

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

tkyte@TKYTE816> select rowid from emp

2 intersect

3 select rowid from dept; ROWID

AAAGBOAAFAAAAJyAAA AAAGBOAAFAAAAJyAAB AAAGBOAAFAAAAJyAAC AAAGBOAAFAAAAJyAAD

Идентификаторы строк в таблице DEPT выделялись и строкам в таблице ЕМР. Дело в том, что для уникальной идентификации строки надо знать таблицу и идентификатор строки. Псевдостолбец rowid уникален только в пределах таблицы.

Я также обнаружил, что многие считают кластер объектом загадочным и реально не используемым. Все используют обычные таблицы. Фактически же кластеры используются при любом обращении к СУБД Oracle. Значительная часть словаря данных хранится в различных кластерах. Например:

sys@TKYTE816> select cluster name, tablename from user tables

2 where cluster name is not null

3 order by 1

CLUSTER NAME TABLE КАМЕ

C COBJ# CCOL$

CDEF$

С FILE# BLOCK# SEG$

C MLOG# C OBJ#

C OBJ# INTCOL# C RG#

C TOID VERSION#

C TS# C OSER#

UET$

MLOG$

SLOG$

ATTRCOL$

COL$

COLTYPE$

CLUS

ICOLDEP$

LIBRARY$

LOB$

VIEWTRCOL$

TYPE MISC$

TAB$

REFCON$

NTAB$

IND$

ICOL$

HISTGRM$

RGCHILD$

RGROUPS

ATTRIBUTE$

COLLECTION$ METHOD$ RESULT$ TYPE$

PARAMETER$

FET$

TSQ$

USER$

33 rows selected.

Как видите, большинство связанных с объектами данных хранится в одном кластере (в кластере C OBJ#), 14 таблиц используют одни и те же блоки. В нем хранится в основном информация о столбцах, поэтому вся информация о наборе столбцов таблицы или индекса хранится физически в том же блоке. В этом есть смысл; когда сервер Oracle анализирует запрос, ему необходим доступ к данным обо всех столбцах соответствующей таблицы. Если эти данные разбросаны, для их сбора потребуется больше времени. Здесь же они обычно находятся в одном блоке и сразу доступны.

Когда же использовать кластеры? Пожалуй, проще сформулировать, когда их не надо использовать.

Кластеры отрицательно сказаться на производительности операторов ЯМД.

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

Полн1й просмотр таблиц в кластере выполняется медленнее. Приходится просмотреть больше данных, поскольку вместо данных только одной таблицы просмат-

риваются данные нескольких таблиц. Поэтому полный просмотр выполняется дольше.

Если предполагается частое усечение (TRUNCATE) и загрузка данн1х в таблицу.

Таблицы в кластере нельзя усечь. Это очевидно, поскольку в блоках кластера хранятся данные нескольких таблиц, строки в таблице, входящей в кластер, придется просто удалять.

Итак, если данные в основном считываются (это не означает никогда не изменяются - данные таблиц в кластере можно изменять), причем - по индексам (либо по индексу кластера, либо по другим индексам) и полученная информация часто соединяется с другими таблицами кластера, кластер имеет смысл использовать. Ищите таблицы, логически взаимосвязанные и используемые совместно, по примеру разработчиков словаря данных Oracle, кластеризовавших вместе всю информацию о столбцах.

Итак, размещение таблиц в кластере позволяет заранее соединить их данные. Кластеры используются для хранения взаимосвязанных данных из многих таблиц в одном блоке базы данных. Кластеры позволяют ускорить операции, с помощью которых интенсивно считываются данные и соединяются таблицы или происходит обращение к взаимосвязанным данным (например, для получения информации обо всех сотрудниках отдела 10). Они сокращают количество блоков, которые должен кэшировать сервер Oracle; вместо хранения 10 блоков для 10 сотрудников одного отдела, будет храниться один блок, т.е. увеличится эффективность буферного кэша. С другой стороны, если неправильно задать параметр SIZE, кластеры могут неэффективно использовать пространство и замедлять работу операторов ЯМД.

Таблицы в хеш-кластере

Таблицы в хеш-кластере по сути очень похожи на представленные выше таблицы в индексном кластере, за одним исключением: вместо индекса по ключу кластера используется хеш-функция. Данные в таблице и есть индекс - отдельного индекса нет. Сервер Oracle берет значение ключа для строки, хеширует его с помощью внутренней или указанной администратором функции и использует результат для определения местонахождения данных на диске. Однако при использовании для поиска данных алгоритма хеширования невозможно просматривать диапазон значений ключей в хеш-кластере, не добавив для соответствующей таблицы обычный индекс. В рассмотренном ранее индексном кластере при выполнении запроса:

select * from emp where deptno between 10 and 20

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

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