Фрагментация 1145

Представленный выше план будет обрабатываться следующим образом.

1. С помощью индекса TEST PK находим строки в таблице TEST, соответствующие условию test.pk = 1.

2. Обращаемся к таблице TEST для выборки значений остальных столбцов TEST - range key column и х.

3. По выбранным на преды1дущем шаге значениям с помощью RANGE EXAMPLE PK находим единственный соответствующий фрагмент со строками таблицы RANGE EXAMPLE.

4. Обращаемся к одному фрагменту таблицы RANGE EXAMPLE для выбора значений столбца данных.

Это кажется достаточно очевидным, но давайте посмотрим, что произойдет при изменении порядка следования столбцов range key column и х и превращении индекса в индекс без префикса:

tkyte@TKn3816> alter table rangeexample

2 drop constraint range example pk

Table altered.

tkyte@TKYTE816> alter table range example

2 add constraint range example pk

3 primary key (x,range key column)

4 using index local

Table altered.

tkyte@TKYTE816> select * from test, range example

2 where test.pk - 1

3 and test.range key column = range example.range key column

4 and test.x = range example.x

PK RANGE KEY X RANGE KEY X DATA

1 01-JAN-94 1 01-JAN-94 1 xxx

Execution Plan

0 SELECT STATEMENT Qptimizer=CHOOSE (Cost=2 Card=l Bytes=69)

1 0 NESTED LOOPS (Cost=2 Card=l Bytes=69)

2 1 TABLE ACCESS (BY INDEX ROWID) OF TEST (Cost=l Card=l

3 2 INDEX (RANGE SCAN) OF TEST PK (UNIQUE) (Cost=l Card=l)

4 1 PARTITION RANGE (ITERATOR)

5 4 TABLE ACCESS (FULL) OF RANGE EXAMPLE (Cost=l Card=164

Неожиданно оказывается, что с точки зрения сервера Oracle этот новый индекс слишком неэффективен. Это один из случаев, когда использование индекса с префиксом гораздо предпочтительнее.

1146

Глава 14

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

Локально фрагментированные индексы и уникальность

Для поддержки уникальности, задаваемой требованиями целостности UNIQUE PRIMARY KEY, ключ фрагментации индекса должен входить в соответствующее требование. По-моему, это самая главная особенность локально фрагментированных индексов. Сервер Oracle обеспечивает уникальность только в пределах фрагмента индекса, но не среди нескольких фрагментов. Это означает, например, что нельзя фрагментиро-вать данные по диапазону значений столбца TIMESTAMP и обеспечить поддержку первичного ключа по столбцу ID с помощью локально фрагментированного индекса. Сервер Oracle для обеспечения уникальности создаст один глобальный индекс.

Например, если выполнить следующий оператор CREATE TABLE в схеме, где объектов (чтобы можно бтло легко понять, какие объекты созданы, просто запросив сегменты данного пользователя), окажется:

tkyte@TKYTE816> CREATE TABLE partitioned

2 (timestamp date,

3 id int primary key

5 PARTITION BY RANGE (timestamp)

7 PARTITION part l VALUES LESS THAN

8 (to date(Ol-jan-2000,dd-mon-yyyy)),

9 PARTITION part 2 VALUES LESS THAN

10 (to date(01-jan-2001,dd-mon-yyyy))

11 )

12 /

Table created.

tkyte@TKYTE816>selectsegment name, partition name, segment type 2 from user segments;

SEGMENT NAME PARTITION NAME SEGMENT TYPE

PARTITIONED PART 2 TABLE PARTITION

PARTITIONED PART 1 TABLE PARTITION

SYS C003582 INDEX

Индекс SYS C003582 - нефрагментированный, он и не мог таким оказаться. означает, что вы теряете ценные для хранилищ данных свойства фрагментации. Обыч-

Фрагментация 1147

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

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

tkyte@TKYTE816> CREATE TABLE partitioned

2 (timestamp date,

3 id int

5 PARTITION BY RANGE (timestamp)

7 PARTITION part l VALUES LESS THAN

8 (to date(Ol-jan-2000,dd-mon-yyyy)),

9 PARTITION part 2 VALUES LESS THAN

10 (to date(01-jan-2001,dd-mon-yyyy))

11 )

12 /

Table created.

tkyte@TKni816> create index partitionedindex

2 on partitioned(id)

3 LOCAL

Index created.

tkyte@TKni816> select segmentname, partitionname, segmenttype 2 from usersegments;

SEGMENT NAME PARTITION NAME SEGMENT TYPE

PARTITIONED PART 2 TABLE PARTITION

PARTITIONED PART 1 TABLE PARTITION

PARTITIONED INDEX PART 2 INDEX PARTITION

PARTITIONED INDEX PART 1 INDEX PARTITION

tkyte@TKYTE816> alter table partitioned

2 add constraint partitioned pk.

3 primary key(id)

alter table partitioned ECR at line 1:

ORA-01408: such column list already indexed

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