1130

Глава 14

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

Фрагменты повышают доступность также благодаря сокращению времени простоя. Например, если таблица размером 100 Гбайт разбита на 50 фрагментов размером 2 Гбайт, восстановление в случае ошибок выполняется в 50 раз быстрее. Если один из фрагментов размером 2 Гбайта поврежден, для его восстановления нужно намного меньше времени, чем для восстановления таблицы размером 100 Гбайт. Таким образом, доступность повышается по двум направлениям: многие пользователи могут вообще не заметить, что данные были недоступны, благодаря тому, что сбойный фрагмент пропускается, а время простоя при сбое сокращается вследствие существенно меньшего объема работы, необходимой для восстановления.

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

Упрощение администрирования связано с тем, что операции с маленькими объектами выполнять гораздо проще, быстрее и при этом требуется меньше ресурсов, чем в случае больших объектов. Например, если оказалось, что 50 процентов строк в таблице фрагментированы (подробнее о фрагментации и переносе строк см. в главе 6, посвященной таблицам), и необходимо это исправить, фрагментация таблицы очень пригодится. Чтобы исключить фрагментацию строк, как правило, пересоздается объект, в данном случае - таблица. Если таблица размером 100 Гбайт, придется выполнять эту операцию одним большим куском , последовательно, с помощью оператора ALTER TABLE MOVE. Если же эта таблица разбита на 25 фрагментов размером 4 Гбайта, можно перестраивать фрагменты по одному. Более того, если это делается в период минимальной загруженности сервера, можно даже выполнять операторы ALTER TABLE MOVE параллельно в отдельных сеансах, что позволяет сократить время пересоздания. Практически все, что делается с нефрагментированным объектом, можно сделать и с частью фрагментированного объекта.

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

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

полностью проиндексировать таблицу (эти шаги можно сделать вообще в другом экземпляре, а результаты перенести в текущую базу данных);

добавить ее в конец фрагментированной таблицы;

удалить самый старый фрагмент с другого конца фрагментированной таблицы.

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

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

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

Еще одним преимуществом фрагментации является повышение производительности запросов и операторов ЯМД. Мы рассмотрим преимущества фрагментации для этих двух категорий операторов отдельно.

Повышение производительности операторов ЯМД связано с потенциальной возможностью распараллеливания. При распараллеливании операторов ЯМД сервер Oracle использует несколько потоков или процессов для выполнения операторов INSERT, UPDATE или DELETE. На многопроцессорной машине с большой пропускной способностью ввода-вывода потенциальное ускорение для операторов ЯМД, выполняющих множественные изменения, может быть весьма большим. В отличие от параллельных запросов (обработки несколькими процессами/потоками оператора SELECT), для распараллеливания операторов ЯМД требуется фрагментация (есть специальный случай параллельной непосредственной вставки, задаваемой с помощью подсказки /*+ APPEND */> когда фрагментация не требуется). Если таблицы не фрагментированы, распараллелить операторы ЯМД не удастся. Сервер Oracle присваивает каждому объекту максимальную степень распараллеливания в зависимости от количества составляющих его фрагментов.

Не стоит ожидать от распараллеливания операторов ЯМД ускорения работы приложений оперативной обработки транзакций (ООТ). В этом отношении есть много заблуждений. Я много раз слышал: Параллельно выполняемые операции должны давать результаты быстрее, чем при последовательном выполнении . Это не всегда верно. При параллельном выполнении некоторых операций требуется во много раз больше времени, чем при последовательном. На организацию параллельного выполнения расходуются определенные ресурсы, необходима дополнительная координация. Более того, распараллеливание вообще не стоит использовать в среде интенсивной оперативной обработки транзакций - в этом просто нет смысла. Распараллеливание операций предназначено исключительно для максимального использования ресурсов системы. При параллельном выполнении один пользователь может единолично использовать все диски, процессоры и всю свободную память машины. В среде хранилища данных, где данных много, а пользователей мало, именно это и требуется. В системе ООТ (большое количество пользователей, выполняющих короткие, быстрые транзакции) предоставление пользователю возможности полностью использовать ресурсы машины отрицательно скажется на масштабируемости.

В этом есть кажущееся противоречие: мы используем распараллеливание запроса для ускорения работы с большими объемами данных, как же это решение может быть не-масштабируем1м? Применительно к системе ООТ, однако, это утверждение абсолютно

1132 Глава 14

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

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

С точки зрения производительности фрагментация обеспечивает две специализированные операции.

И1норирование фрапмента. Некоторые фрагменты данных не просматриваются при обработке запроса. Пример игнорирования фрагмента был представлен ранее, когда мы отключили одно из табличных пространств и смогли, тем не менее, выполнить запрос. Отключенное табличное пространство при выполнении запроса было пропущено.

Параллельное вшолнение операций. Распараллеливать можно соединения по фрагментам, если объекты фрагментированы по ключам соединения, или просмотр индексов.

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