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

Возможность фрагментации, то есть разбиения таблицы или индекса на несколько меньших, проще управляемых частей, впервые появилась в сервере Oracle версии 8.0. Логически для обращающегося к базе данных приложения есть только одна таблица или индекс. Физически же эта таблица или индекс могут состоять из многих десятков фрагментов. Каждый фрагмент - самостоятельный объект, с которым можно работать отдельно или как с частью большего объекта.

Фрагментация разрабатывалась для упрощения управления очень большими таблицами и индексами за счет применения подхода разделяй и властвуй . Предположим, в базе данн1х имеется индекс размером 10 Гбайт. Если необходимо перестроить этот не-фрагментированный индекс, придется перестраивать весь индекс в один прием. Хотя сервер способен перестраивать такие индексы динамически, объем ресурсов, необходи-м]х для полного пересоздания всего индекса размером 10 Гбайт, огромен. Потребуется еще не менее 10 Гбайт свободного пространства для хранения обоих экземпляров индекса, необходима временная таблица журнала транзакций для записи изменений, сде-ланн1х в базовой таблице за время пересоздания индекса, и т.д. С другой стороны, если индекс разбит на десять фрагментов размером 1 Гбайт, можно пересоздавать каждый фрагмент индекса отдельно, по одному. При этом потребуется только 10 процентов свободного пространства, которое понадобилось бы при пересоздании нефрагментирован-ного индекса. Пересоздание индекса пройдет намного быстрее (возможно, раз в десять), намного уменьшится объем выполненных транзакциями изменений, которые придется учесть в новом индексе, и т.д.

1128 Глава 14

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

Использование фрагментации

Для использования фрагментации имеются три причины:

повышение доступности данных;

упрощение администрирования;

повышение производительности запросов и операторов ЯМД.

Повышение доступности данных

Повышение доступности данных достигается за счет того, что фрагменты являются независимыми сущностями. Доступность (или недоступность) одного фрагмента объекта не означает, что весь объект доступен (или недоступен). Оптимизатор учтет реализованную схему фрагментации и удалит из плана выполнения запроса фрагменты, данные из которых не запрашиваются. Если недоступен один фрагмент большого объекта и запрос не обращается к данным в этом фрагменте, сервер Oracle успешно выполнит этот запрос. Давайте создадим фрагментированную по хеш-функции таблицу из двух фрагментов, хранящихся в разных табличных пространствах, и вставим в нее данные. Для каждой вставляемой в таблицу строки значение в столбце EMPNO хешируется с целью определения фрагмента (а значит, и табличного пространства, в данном случае), в который следует помещать данные. Затем, дополнив имя таблицы именем фрагмента, просмотрим содержимое каждого фрагмента:

tkyte@TKYTE816> CREATE TABLE emp

2 (empno int,

3 ename varchar2(20)

5 PARTITION BY HASH (empno)

6 (partition part l tablespace p1,

7 partition part 2 tablespace p2

Table created.

tkyte@TKYTE816> insert into emp select empno, ename from scott.emp 2 /

14 rows created.

tkyteeTKYTE816> select * from emp partition(part l) ; EMPNO ENAME

73 6 9 SMITH

7499 ALLEN 7654 MARTIN 7698 BLAKE

Фрагментация Ц29

7782 CLARK 7839 KING 7876 ADAMS 7934 MILLER 8 rows selected.

tkyte@TKYTE816> select * from enp partition (part 2) ;

EMPNO ENAME

7521 WARD 7566 JONES 7788 SCOTT 7844 TURNER 7900 JAMES 7902 FORD 6 rows selected.

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

tkyteeTKYTE816> alter tablespace p1 offline;

Tablespace altered.

tkyte@TKYTE816> select * from emp

2 /

select * from emp ERROR at line 1:

ORA-00376: file 4 cannot be read at this time

ORA-01110: data file 4: C:\ORACLE\ORADATA\TKYTE816\P1.DBF

tkyteeTKYTE816> variable n number tkyte@TKYTE816> exec :n := 7844

PL/SQL procedure successfully completed.

tkyte@TKYTE816> select * from emp where empno = :n

EMPNO ENAME

7844 TURNER

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