Как известно, идея параллелизма поддерживается многими процессами,

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

Например, необходимо создать большие сегменты отката для задействова-
ния их групповыми операциями PDML. Рассмотрим создание этих сегментов в
разных табличных пространствах на различных устройствах (и предпочтитель-
но на различных дисковых контроллерах). Это послужит гарантией уменьше-
ния конкуренции        за доступ к сегментам отката, так же как и для

любого отката операции DML.

Следует рассмотреть и вопрос создания стольких сегментов отката, какова степень параллелизма для секционированной таблицы. Если число разделов таблицы превосходит степень параллелизма, убедитесь, что сегменты отката смогут содержать образы разделов до обновления, над которыми выполняются манипуляции операторами PDML. Так, к примеру, если таблица имеет 36 разде­лов, хранящихся на 6 устройствах, а у сервера есть шесть ЦП, оптимальная сте­пень параллелизма для таблицы будет равна 12 (по формуле, приведенной в разделе "Проектирование базы данных для параллелизма"). Следовательно, для достижения оптимальной производительности необходимо 12 больших сегмен­тов отката. Тем не менее следует принять все предосторожности и убедиться,

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

ЕСЛИ настраиваемая система сталкивается со сбоем экземпляра и операция PDML заканчивается аварийно, после запуска экземпляра должен быть выпол­нен параллельный запрос, подобный приведенному ниже, для таблицы, с кото­рой в момент аварийного завершения проводились манипуляции PDML:

□ select /*+ FULL (tablename) PARALLEL (tablename. 6) */ count(.) from tablename;

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

Далее, если параметр инициализации RECOVERY_PARALLELISiV установ­лен на значение, большее 1 (например, 8, поскольку, по мнению Oracle, именно таким является пороговое значение, начиная с которого параллельное восста­новление становится предпочтительнее последовательного), SMON запустит множество процессов для выполнения восстановления параллельным образом. Необходимо отметить, что оптимальное число процессов восстановления в ко­нечном счете определяется числом независимых запоминающих устройств, на которое конфигурированы файлы данных Oracle.

Если пользователь работает с Oracle 8.1.3 (или с более поздними версиями) и параметр COMPATIBLE установлен по крайней мере на 8.1.3, в его распоряжении оказываются две новые опции - быстрый старт отката по требованию (fast start on-demand rollback) и быстрый старт параллельного отката (fast start parallel rollback), способствующие увеличению доступности базы данных, а значит, и его данных. С помощью этих опций база данных быстрее выполняет откат, оставаясь при этом в онлайновом режиме. Быстрый старт отката по требованию позволяет выполнить по требованию пользователя откат аварийно завершившихся транзакций (по одному блоку за один запрос). При быстром старте параллельного отката происходит откат целого набора транзакций. Данная опция является конфигурируемой, для чего применяется параметр инициализации FAST_START_PARALLEL_ROLLBACK. Выбор режима восстановления транзакции - параллельно или последовательно - возлагается на SMON и зависит от объема работы, которая должна быть выполнена в процессе восстановления.