Индекс-таблицы (index-organized table — IOT) в базе данных Oracle Database представляют собой некоторый гибрид, потому что им присущи свойства как индексов, так и таблиц. Таблицы IOT — это таблицы, в которых данные хранятся в виде индексной структуры B-дерева (в отсортированном по первичному ключу виде), но они отличаются от традиционных, или организованных в куче, таблиц тем, что последние не упорядочивают данные. Они отличаются от обычных индексов тем, что в то время как индексы состоят только из индексированных столбцов, IOT включают как ключевые, так и не ключевые столбцы. Oracle использует индексные структуры B-деревьев, чтобы хранить данные в отсортированном по первичному ключу виде.
Когда вы обновляете IOT, ее индексная структура действительно обновляется. Доступ к данным осуществляется намного быстрее, потому что приходится выполнять единственную операцию ввода-вывода к индексу/таблице. Нет необходимости читать данные из индекса и таблицы по отдельности, как в случае таблиц, индексированных традиционным способом. Сами данные строк, а не только ROWID, хранятся в листовом блоке индекса вместе с индексированным значением столбца. IOT особенно хорошо подходят для тех случаев, когда нужно выполнять запросы, основанные на значениях первичного ключа. IOT удобны для очень крупных баз данных (very large databases — VLDB) и приложений OLTP. Реорганизовать IOT можно без отдельной перестройки индексов, а это означает сокращение затрат времени на организацию по сравнению с обслуживанием традиционных таблиц. Главное отличие между традиционными таблицами и IOS показано в таблице ниже.
Традиционные таблицы Oracle | Индекс-таблицы |
Физические идентификаторы ROWID | Логические идентификаторы ROWID |
Уникальная идентификация строк по ROWID | Уникальная идентификация по первичному ключу |
Могут содержать данные типа LONG и LOB | Не могут содержать данных LONG |
Могут участвовать в кластерах таблиц | Не могут участвовать в кластерах |
Большая потребность в дисковом пространстве | Меньшая потребность в дисковом пространстве |
Медленный доступ к данным | Быстрый доступ к данным |
В листинге ниже продемонстрирован пример создания индекс таблицы IOT.
SQL> CREATE TABLE employee_new( employee_id NUMBER, dept_id NUMBER, name VARCHAR2(30), address VARCHAR2(120), CONSTRAINT pk_employee_new PRIMARY KEY (employee_id)) ORGANIZATION INDEX TABLESPACE empindex_01 PCTTHRESHOLD 25 OVERFLOW TABLESPACE overflow_tables;
Несколько ключевых слов в приведенном операторе CREATE TABLE требуют пояснений. Ключевая фраза ORGANIZATION INDEX указывает на то, что эта таблица является IOT, а не традиционной таблицей. С помощью ключевого слова PCTTHRESHOLD задается процент пространства, зарезервированного в индексных блоках для IOT employee_new.Любая часть строки таблицы, пересекающая 25-процентный барьер в каждом блоке данных, сохраняется в области переполнения. Оператор CREATE TABLE назначает табличное пространство overflow_tables для хранения переполнения данных из индексных блоков. Можно установить пороговое значение для подгонки под оба ключевых столбца,а также нескольких часто востребованных не ключевых столбцов. Определить, какие строки выходят за пороговое значение, можно, выполнив оператор ANALYZE TABLE...LIST CHAINED ROWS.
С помощью необязательной конструкции INCLUDING указываются не ключевые столбцы, которые должны храниться вместе с ключевыми. До тех пор, пока база данных не превысит заданное пороговое значение, она будет стараться подогнать все не ключевые столбцы и включить столбец, специфицированный в операторе INCLUDING, в индексный листовой блок. База данных хранит остальные не ключевые столбцы в сегменте переполнения. Конструкция PCTTRESHOLD переопределит конструкцию INCLUDING,если возникнет конфликт между значениями, указанными в двух конструкциях. В листинге ниже демонстрируется применение конструкции INCLUDING.
SQL> CREATE TABLE employee_new( employee_id NUMBER, dept_id NUMBER, name VARCHAR2(30), address VARCHAR2(120), CONSTRAINT pk_employee_new PRIMARY KEY (employee_id)) ORGANIZATION INDEX TABLESPACE empindex_01 PCTTHRESHOLD 25 INCLUDING name OVERFLOW TABLESPACE overflow_tables;
В листинге выше конструкция INCLUDING инструктирует базу данных о том, что следует включить столбцы employee_id, dept_id и name (все они являются не ключевыми) в индексный листовой блок, конечно же, вместе с ключевыми значениями столбцов.
Помните, что элементы индекса в IOT могут быть большими, поскольку содержат не только ключевые значения, но также значения строки. Поэтому IOT не обязательно хранят все свои данные в индексных блоках. Вполне вероятно, что ключ и часть строки будут находиться в индексных блоках, а остальная часть — в некотором другом табличном пространстве. Если значение параметра PCTTRESHOLD будет достаточно низким, существует риск столкнуться с проблемой, когда части строки располагаются в разных блоках данных, что замедлит выполнение ваших запросов.