1154

Глава 14

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

Системы ООТ и глобально фрагментированные индексы

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

Глобально фрагментированные индексы имеет смысл использовать в системах ООТ. Данные таблицы могут быть фрагментированы только по одному ключу, по одному набору столбцов. Однако могут понадобиться различные способы доступа к данным. Можно фрагментировать данные в таблице EMPLOYEE по местонахождению офиса. Однако при этом необходимо также обеспечить быстрый доступ к данным по следующим столбцам.

DEPARTMENT. Отделы географически разнесены, и однозначного соответствия между отделом и его местонахождением нет.

EMPLOYEE ID. Хотя идентификатор сотрудника определяет его местонахождение, не хотелось бы искать данные по EMPLOYEE ID и LOCATION, поскольку при этом не удастся обеспечить игнорирование фрагментов индекса. Кроме того, значения столбца EMPLOYEE ID сами по себе должны быть уникально!.

JOB TITLE.

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

Итак, необходимо достичь следующих целей:

быстрый доступ;

целостность данных;

доступность данных.

В системе ООТ этого позволяют добиться глобально фрагментированные индексы, поскольку характеристики этой системы существенно отличаются от хранилища данных. Не будут использоваться перемещающиеся окна, не придется делить фрагменты (разве

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

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

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

tkyte@TKYTE816> create table emp

NUMBER(4) NOT NOLL, VARCHAR2(10),

VARCHAR2(9), NUMBER(4), DATE,

NUMBER(7,2), NUMBER(7,2) ,

NUMBER(2) NOT NULL, VARCHAR2 (13) NOT NULL

range(loc)

values less than(C) tablespace p1,

values less than(D) tablespace p2,

values less than(N) tablespace p3,

values less than(Z) tablespace p4

Table created.

tkyte@TKYTE816> alter table emp add constraint emp pk

2 primary key(empno)

Table altered.

tkyte@TKYTE816> create index emp job idx on emp(job)

2 GLOBAL

Index created.

tkyte@TKYTE816> create index emp dept idx on emp(deptno)

2 GLOBAL

Index created.

tkyte@TKYTE816> insert into emp

2 select e.*, d.loc

3 from scott.emp e, scott.dept d

4 where e.deptno = d.deptno

14 rows created.

1156

Глава 14

Итак, мы начинаем с таблицы, фрагментированной по местонахождению, LOC, в соответствии с нашими правилами. Существует глобальный уникальный индекс по столбцу EMPNO как побочный эффект выполнения оператора ALTER TABLE ADD CONSTRAINT. Это показывает, что можно обеспечить целостность данных. Кроме того, мы добавили еще два глобальных индекса по столбцам DEPTNO и JOB для ускорения доступа к строкам по этим атрибутам. Теперь добавим в таблицу немного данных и посмотрим, что оказалось в каждом из фрагментов:

tkyte@TKYTE816> select empno,job,loc from emp partition(p1);

no rows selected

tkyte@TKYTE816> select empno,job,loc from emp partition(p2); EMPNO JOB LOC

7900 CLERK 7844 SALESMAN 7 698 MANAGER

7654 7521 7499

SALESMAN SALESMAN SALESMAN

CHICAGO CHICAGO CHICAGO CHICAGO CHICAGO

CHICAGO

6 rows selected.

tkyte@TKYTE816> select empno,job,loc from emp partition(p3);

EMPNO JOB LOC

tkyte@TKYTE816> select empno,job,loc from emp partition(p4);

EMPNO JOB LOC

7934 CLERK NEW YORK 7839 PRESIDENT NEW YORK 7782 MANAGER NEW YORK

Этот пример показывает распределение данных по фрагментам в соответствии с местонахождением сотрудника. Теперь можно выполнить несколько запросов для оценки производительности:

tkyte@TKYTE816> select empno,job,loc from emp where empno = 7782;

EMPNO JOB LOC

7782 MANAGER

Execution Plan

NEW YORK

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=4 Bytes=108)

1 0 TABLE ACCESS (BY GLOBAL INDEX ROWID) OF EMP (Cost=l Card

2 1 INDEX (RANGE SCAN) OF EMP PK (UNIQUE) (Cost=l Card=4)