DeepEdit!

Оптимальное число экстентов для каждого объекта равно 1. I

Нет ничего более далекого от правды, чем это заявление. Мы называем этот миф отцом всех мифов об Oracle. Давайте сразу договоримся: никакого магиче­ского числа для оптимального количества экстентов объектов Oracle не сущест­вует. Распространители данного утверждения не представляют себе кошмаров

потенциальной фрагментации и управления пространством, которые создает

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

вышеупомянутым кошмарам. Абсолютно нормально, если объект состоит из не­скольких экстентов. Однако если мы попадаем в другую часть спектра и наш объект состоит из многих тысяч экстентов, возникают совсем другие вопросы. Но сам по себе факт, что объект имеет 1000 экстентов, не вызывает никаких проблем с производительностью, если только размер этих экстентов кратен (DB_FILE_MULTIBLOCK_READ_COUNT * DB BLOCK SIZE).

Это служит гарантией того, что Oracle выдаст одно и то же число системных вы­зовов по чтению независимо от того, состоит ли объект из одного экстента или их целая тысяча. Если же экстенты не выровнены в соответствии с приведен­ным выше размером, дополнительные системные вызовы чтению вызовут дополнительную нагрузку на подсистему ввода/вывода. При нали­чии самого тяжелого сценария можно считать, что для большинства самых тя­жело нагруженных объектов на каждый дополнительный экстент приходится

по одному системному вызову по чтению. Если база данных содержит множест-
во объектов со множеством невыровненных экстентов в каждом из них, это не-
избежно приводит к большим накладным расходам для подсистемы
ввода/вывода.        

Реорганизация таблицы (операция, состоящая из следующих шагов:

удаление, повторное создание, импорт), содержащей много сотен экстентов, в один экстент обеспечивает повышение производительности.

Такое утверждение, несомненно, является производным от первого мифа. Экс­порт данных, за которым следует импорт, уничтожает фрагментацию на уровне блоков, на уровне строк (если это применимо) и переустанавливает отметку вы­сшей точки таблицы, что, в свою очередь, приводит к повышению производи­тельности. Значит, именно операция дефрагментации (внутри блока и/или строк) и уменьшение числа блоков, которые будут прочитаны при выполнении полного сканирования таблицы, в конечном счете, приводят к повышению про­изводительности .

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

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

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

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

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

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

pctfree 

(для уменьшения фрагментации на уровне строк) и 

pctused 

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

initial next 

(если они слишком'малы), чтобы не дать таблице достичь состояния 

тахехкпВЪъше 

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

unlimited maxextents.

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

Далее для полноты картины мы затронем отдельные вопросы, с которыми нам приходилось сталкиваться в процессе работы с гибридными базами данных и базами данных для хранилищ данных. Это вне всякого сомнения более чем полный охват всех тем, поэтому речь о них пойдет, как мы уже отмечали, только для полноты картины. Хотя хранилищам данных сейчас уделяется немало вни­мания и имеется множество книг, написанных только на эту тему Gary Dodge, Tim Gorman. 

Oracle8iData Warehousing), 

мы хотели хотя бы коснуться

основных вопросов и проблем управления большими базами данных Oracle.