Использование обработки при смене объекта операции

Еще одна важная рекомендация, которую мы обязаны дать относительно проектирования пакетных заданий, - максимально использовать обработку при смене объекта операции (control break processing), сочетая ее с мягким отключением триггеров в ходе выполнения процесса.

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

Если сальдо по счету обычно ведется триггером, то для уменьшения числа выполняемых обновлений мы хотели бы отключить его для проводок, выполняемых пакетным процессом, потому что этот процесс сам ведет сальдо. Искусство проектирования в подобной ситуации заключается в том, чтобы определить, стоит ли выигрыш в производительности этих усилий и риска (если он есть). В данном случае наши усилия должны быть направлены на то, чтобы избежать любых рисков. Главное - обеспечить, чтобы в процессе обработки счета фиксация не выполнялась до тех пор, пока сальдо не будет обновлено.

Интервал фиксации

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

Если задание выполняет фиксацию один раз, например, через четыре часа обработки, то можно потерять 3 часа 59 минут сделанной работы в случае отказа носителя или аварии экземпляра. Кроме того, в процессе проектирования часто не учитывают и другие факторы - размер сегмента отката, который потребуется для поддержки модели с единичной фиксацией, и время, необходимое для запуска с восстановлением после аварии экземпляра. Если к моменту аварии задания программа использует 10 Гбайт сегмента отката, то при перезапуске Oracle придется обработать 10 Гбайт элементов сегмента отката. Это может существенно увеличить время простоя.

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

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

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

INSERT TABLE live orders SELECT *

FROM orders WHERE dead flag IS NULL UNRECOVERABLE;

Несомненно, это самый быстрый способ перемешения строк из одной таблицы в другую. В самой последней версии предложение CREATE TABLE... AS SELECT... можно снабдить атрибутом UNRECOVERABLE, предполагая, что проблемы с использованием сегмента отката и временем восстановления экземпляра преодолены. Однако все равно сушествует риск того, что авария экземпляра, операционной системы или аппаратных средств может привести к потере большого объема работы и, конечно, эта операция невосстановима, если требуется восстановление с повтором транзакций. Поэтому вы, возможно, решите не использовать опцию UNRECOVERABLE в заданиях промышленного уровня, а примените ее для основных служебных операций, за которыми сразу же следует резервное копирование. В приведенном ниже предложении продемонстрирован второй самый быстрый способ перемешения строк;

INSERT TABLE Iive orders SELECT *

FROM orders WHERE dead flag IS NULL /* UNRECOVERABLE нам нужна возможность восстановления */;

Однако в этом случае объем используемого пространства сегмента отката прямо пропорционален числу копируемых строк. Во многих случаях можно совершенно свободно превратить эту операцию в многошаговую, применяя управляющую таблицу, в которую помещаются записи заказов, соответствующие определенному диапазону значений ключей. Затем, используя цмсл, мы можем пересылать записи, соответствующие каждому диапазону значений ключей, и регистрировать конец каждого шага и выполнять фиксацию в конце каждого диапазона. Ниже показан пример реализации этого решения на PL/SQL;

DECLARE CURSOR cl IS

SELECT deptno , dname FROM dept

ORDER BY dname;-- благодаря этому журнал регистрации выглядит логичнее BEGIN

INSERT INTO run log (id, start at) VALUES (XX,SYSDATE); FOR this dept IN cl LOOP

INSERT INTO new emp

SELECT * FROM emp WHERE deptno = this dept.deptno; INSERT INTO run steps (id, step, ended at)

VALUES (XX, this dept.dname, SYSDATE);

COMMIT; END LOOP;

UPDATE run Iog SET ended at = SYSDATE

WHERE Id = XX; COMMIT; END;

Это один из тех немногих случаев, когда мы можем рекомендовать реализацию основного пакетного процесса на PL/SQL, поскольку почти все время выполнения будет затрачено на работу интерпретатора SQL и требования к процедурному языку минимальны (и потому, что PL/SQL очень облегчает реализацию курсорных циклов FOR).

Продемонстрированный нами подход связан с некоторым увеличением затрат на создание задания, и для его реализации необходимо использовать PL/SQL или 3GL, а не просто создать скрипт на SQL*Plus. Однако он позволит сэкономить большой объем пространства сегмента отката и обеспечит быстрое восстановление.

Вообше говоря, нас не впечатляют организации, где пакетная обработка реализована средствами SQL* Plus.

Если этот пример преобразовать в хранимую процедуру (что мы рекомендуем делать), то в этом сеансе должен быть включен режим COMMIT IN PROCEDURE. Собственные средства Oracle, главным образом Oracle Forms, тяготеют к выдаче команды ALTER SESSION, отключающей этот режим. Они делают это для того, чтобы можно было рассчитывать на то, что установленные ими блокировки все еше действуют. Если режим COMMIT IN PROCEDURE включен, то любая хранимая процедура или функция, вызываемая процессом, может выдать команду COMMIT или ROLLBACK, что приведет к снятию всех транзакционных блокировок, установленных сеансом.

Делать все там, где нужно

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