Execution Flan

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=129 Card=9996 Bytes=839664)

1 0 TABLE ACCESS (BY INDEX ROWID) OF COLOCATED (Cost=129 Card=9996

2 1 INDEX (RANGE SCAN) OF COLOCATED PK (UNIQUE) (Cost=22 Card=9996) Statistics

0 recursive calls

0 db block gets

1478 consistent gets

107 physical reads

0 redo size

996087 bytes sent via SQL*Net to client

74350 bytes received via SQL*Net from client

668 SQL*Net roundtrips to/from client

1 sorts (memory) 0 sorts (disk)

10001 rows processed

tkyte@TKYTE816> select * from DISORGANIZED where x between 20000 and 30000; 10001 rows selected.

Elapsed: 00:00:00.42

Execution Plan

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=162 Card=9996 Bytes=839664)

1 0 TABLE ACCESS (FULL) OF DISORGANIZED (Cost=162 Card=9996

Statistics

0 recursive calls

15 db block gets

1725 consistent gets

707 physical reads

0 redo size

996087 bytes sent via SQL*Net to client 74350 bytes received via SQL*Net from client 668 SQL*Net roundtrips to/from client

1 sorts (memory) 0 sorts (disk)

10001 rows processed

Мы получаем те же структуры таблиц, те же индексы, но разные показатели кластеризации. Оптимизатор в этом случае выбрал доступ по индексу для таблицы COLOCATED и полный просмотр - для таблицы DISORGANIZED.

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

стеризации, но в большинстве случаев это будет напрасной потерей времени. Это повлияет только на просмотры диапазонов по индексу, затрагивающие значительную часть строк таблицы, - не такое уж типичное действие, по моему опыту. Кроме того, надо помнить, что обычно таблица имеет только один индекс с хорошим показателем кластеризации! Данные могут быть отсортированы только по одному критерию. В предыдущем примере, если бы был еще один индекс по столбцу Y, он оказался бы очень слабо кластеризованным в таблице DISORGANIZED. Если физическое упорядочение данных существенно, пересоздайте таблицу, организовав ее по соответствующему индексу.

Итак, индексы на основе В*-дерева, несомненно, - самые типичные и понятные индексные структуры в базе данных Oracle. Это отличный универсальный механизм индексирования. Они обеспечивают очень хорошее время доступа при масштабировании, возвращая данные из индекса по 100000 строк практически за то же время, что и из индекса по 1000 строк.

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

Проектированием и созданием индексов надо заниматься по ходу разработки приложения, а не после ее завершения (как часто происходит). При правильном планировании и учете способов доступа к данным, как правило, понятно, какие индексы необходимы.

Индексы на основе битовых карт

Индексы на основе битовых карт появились в версии 7.3 сервера Oracle. Сейчас они доступны в редакциях Oracle 8i Enterprise и Personal Edition, но не в Standard Edition. Индексы на основе битовых карт создавались для хранилищ данных или сред с произвольными запросами, где полный список возможных запросов к данным при реализации приложения не полностью известен. Они не походят для систем ООТ или систем, где данные часто изменяются несколькими одновременно работающими сеансами.

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

Предположим, создается индекс на основе битовых карт по столбцу JOB в таблице ЕМР:

scott@TKYTE816> create BITMAP index job idx on emp(job); Index created.

Сервер Oracle будет хранить в индексе примерно следующее:

Это показывает, что в строках 8, 10 и 13 находится значение ANALYST, тогда как в строках 4, 6 и 7 - значение MANAGER. Также понятно, что пуст1х строк нет (индексы на основе битовых карт содержат записи для пуст1х значений - отсутствие такой записи в индексе означает, что пуст1х строк нет). Если необходимо посчитать, в скольких строках хранится значение MANAGER, индекс на основе битовых карт позволит сделать это очень быстро. Если необходимо найти все строки, в которых в столбце JOB хранится значение CLERK или MANAGER, достаточно просто скомбинировать соответствующие битовые карты из индекса:

Это позволяет быстро понять, что критериям поиска удовлетворяют строки 1, 4, 6, 7, 11, 12 и 14. Битовая карта, которую сервер Oracle хранит для каждого значения ключа, устроена так, что каждая позиция представляет идентификатор строки базовой таблицы на случай, если понадобится выбрать для дальнейшей обработки соответствующую строку. На запросы вида:

select count(*) from emp where job = CLERK or job = MANAGER

можно ответить непосредственно по индексу на основе битовых карт. Для ответа на запрос вида:

select * from emp where job = CLERK or job = MANAGER

придется обратиться к таблице. Сервер Oracle применит функцию, преобразующую установленный бит i в битовой карте в идентификатор строки, по которому можно обратиться к таблице.