Для индекса выделено 192 блока, 35 из которых не содержат данных (всего используется 157 блоков). Понятно, что компонент OWNER повторяется многократно. Один блок индекса будет включать десятки записей вида:

Sys, Package, Dbms Alert

Sys,Package,Dbms Application lnfo

Sys,Package,Dbms Aq

Sys, Package, Dbms Aqadm

Sys,Package,Dbms Aqadm Sys

Sys,Package,Dbms Aqadm Syscalls

Sys,Package,Dbms Aqin

Sys,Package,Dbms Aqjms

Можно вынести (факторизовать) один повторяющийся столбец, OWNER, и получить в результате блок, выглядящий примерно так:

Package,Dbms Alert Package, Dbms Application lnfo Package,Dbms Aq Package, Dbms Aqadm Package,Dbms Aqadm Sys Package,Dbms Aqadm Syscalls Package, DbmsAqin Package,Dbms Aqjms

Здесь имя владельца появляется в листовом блоке только один раз, а не для каждой записи. Если пересоздать индекс со сжатием первого столбца:

tkyte@TKYTE816> drop index t idx; Index dropped.

tkyte@TKYTE816> create index t idx on

2 t(owner,object type,object name)

3 compress 1; Index created.

tkyte@TKYTE816> exec show space(T IDX,user,INDEX)

Free Blocks......................0

Total Blocks.....................192

Total Bytes......................1572864

Unused Blocks....................52

Unused Bytes.....................425984

Last Used Ext FileId............6

Last Used Ext BlockId...........649

Last Used Block..................12

PL/SQL procedure successfully completed.

Размер индексной структуры уменьшается со 157 блоков до 140, примерно на 10 процентов. Можно продолжить эксперимент и сжать два первых столбца. Это приведет к созданию блоков, в котор1х вынесены повторяющиеся элементы столбцов OWNER и OBJECT TYPE:

Sys,Package

Dbms Application ino DbmsAq Dbms Aqadm Dbms Aqadm Sys Dbms Aqadm Syscalls DbmsAqin Dbms Aqjms

Теперь, после сжатия первых двух столбцов:

tkyte@TKYTE816> drop index t idx; Index dropped.

tkyte@TKYTE816> create index t idx on

2 t(owner,objecttype,object name)

3 compress 2; Index created.

tkyte@TKYTE816>

tkyte@TKE816> exec show space(T IDX,user,INDEX)

Free Blocks.......................0

Total Blocks......................128

Total Bytes.......................104857 6

Unused Blocks.....................15

Unused Bytes......................122880

Last Used Ext FileId.............6

Last Used Ext BlockId............585

Last Used Block...................49

PL/SQL procedure successfully completed.

мы получили индекс из 113 блоков, почти на тридцать процентов меньше исходного. В зависимости от повторяемости данных, экономия может оказаться и более существенной. Но это сжатие не дается даром. Структура сжатого индекса усложняется. Сервер Oracle будет тратить больше времени на обработку данных в этой структуре как при поддержке индекса в ходе изменения, так и при поиске в ходе выполнения запроса. Мы пошли на увеличение процессорного времени обработки при одновременном уменьшении времени на выполнение ввода/вывода. В буферный кэш поместится больше записей индекса, чем при отсутствии сжатия, процент попадания в буферный кэш может увеличиться, объем физического ввода/вывода - уменьшится, но на обработку индекса потребуется больше времени, да и вероятность конфликтов при доступе к блоку возрастает. Как и в случае хеш-кластера, когда для извлечения миллиона случайных строк потребовалось больше процессорного времени, но в два раза меньше операций ввода/ вывода, необходимо помнить об этом компромиссе. Если вычислительная мощность

Индексы с обращенным ключом

Еще одна особенность индексов на основе В*-дерева - возможность обратить ключи. Сначала может показаться странным, зачем это вообще нужно? Они созданы для специфической среды и с конкретной целью. Они предназначены для уменьшения количества конфликтов при доступе к листовым блокам индекса в среде Oracle Parallel Server (OPS).

Конфигурация OPSописана в главе 2, посвященной архитектуре сервера Oracle.

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

В индексе с обращенным ключом просто обращается порядок байтов в каждом столбце ключа индекса. Если взять числа 90101, 90102, 90103 и посмотреть на их внутреннее представление с помощью встроенной функции DUMP, окажется, что они представлены следующим образом:

tkyte@TKYTE816> select 90101, dump(90101,16) from dual

2 union all

3 select 90102, dump(90102,16) from dual

4 union all

5 select 90103, dump(90103,16) from dual

90101 DUMP(90101,16)

90101 Typ=2 Len=4: c3,a,2,2

90102 Typ=2 Len=4: c3,a,2,3

90103 Typ=2 Len=4: c3,a,2,4

Каждое число представлено четырьмя байтами, и отличаются они только последним байтом. В структуре индекса эти числа окажутся рядом. Если же обратить порядок следования байтов, сервер Oracle вставит следующие значения:

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