Программирование >>  Oracle 

1 ... 246 247 248 [ 249 ] 250 251 252 ... 469


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

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

EMPNO

7900

CLERK

CHICAGO

7876

CLERK

DALLAS

7369

CLERK

DALLAS

7934

CLERK

NEW YORK

Execution Plan

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

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

2 1 INDEX (RANGE SCAN) OF EMP JOB IDX (NON-UNIQUE) (Cost=l

Созданные индексы используются для обеспечения высокоскоростного доступа к дан-н]м в системе ООТ. Если бы они были фрагментированы, то должны были бы включать префикс, что позволило бы игнорировать фрагменты индекса; но и так масштабируемость вполне приемлема. Наконец, давайте разберемся с доступностью данных. Документация Oracle утверждает, что глобально фрагментированные индексы обеспечивают меньшую доступность данных, чем локально фрагментированные. Не могу пол-ноиью согласиться с этой безоговорочной характеристикой. Я уверен, что в системе ООТ обеспечивают такую же степень доступности, как и локально фрагментированные. Рассмотрим пример:

tkyte@TKYTE816> alter tablespace p1 offline; Tablespace altered.

tkyte@TKYTE816> alter tablespace p2 offline; Tablespace altered.

tkyte@TKYTE816> alter tablespace p3 offline; Tablespace altered.

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

EMPNO JOB LOC

7782 MANAGER NEW YORK

Execution Plan

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=l 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)

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



1158 Глава 14

титься к каждому фрагменту локально фрагментированного индекса, и при попытке обратиться к недоступному фрагменту произошла бы ошибка.

Другие типы запросов не будут (и не могут) нормально выполняться в такой ситуации:

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

select empno,job,loc from emp where job = CLERK *

ERROR at line 1:

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

ORA-01110: data file 13: C:\ORACLE\ORADATA\TKYTE816\P2.DBF

Данные о клерках разбросаны по всем фрагментам; то, что три табличных пространства недоступны, не будет учтено. Это неизбежно, если только данные не фрагменти-рованы по столбцу JOB, но тогда проблемы возникли бы с запросами, обращающимися к данным по значению столбца LOC. Каждый раз, когда необходимо обращаться к данным по нескольким различным ключам, возникают подобные проблемы. Сервер Oracle предоставит данные, если только это вообще возможно.

Учтите, однако, что если ответ на запрос можно бтло бы получить по индексу, избежав доступа к таблице TABLE ACCESS BY ROWID, фактор недоступности данных не был бы столь критичным:

tkyte@TKYTE816> select count(*) from emp where job = CLERK;

COUNT(*)

Execution Plan

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=l Card=l Bytes=6)

1 0 SORT (AGGREGATE)

2 1 INDEX (RANGE SCAN) OF EMP JOB IDX (NON-UNIQUE) (Cost=l

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

Резюме

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



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

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

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

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

Предоставляемые СУБД Oracle возможности фрагментации постоянно развиваются, причем, на следующие версии запланированы существенные улучшения. Со временем, вследствие увеличения размеров баз данных и сложности приложений, фрагментация будет, как мне кажется, использоваться еще более широко. Сеть Internet и присущие ей аппетиты в отношении баз данных приводят к созданию все больших подборок данных, а фрагментация является естественным средством, позволяющим справиться с возникающими при этом проблемами.



1 ... 246 247 248 [ 249 ] 250 251 252 ... 469

© 2006 - 2025 pmbk.ru. Генерация страницы: 0
При копировании материалов приветствуются ссылки.
Яндекс.Метрика