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

Проектирование пакетных программ

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

всегда более эффективна, чем транзакционная обработка;

считается более легкой для аудита и контроля, чем транзакционная обработка;

устраняет необходимость наличия ПО, управляемого событиями.

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

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

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

Регистрация хода выполнения задания

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

регистрировать свой запуск в базе данных;

регистрировать ход своего выполнения в базе данных;

регистрировать свое завершение в базе данных.

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

CREATE TABLE run log

run id task name command line invoked by started at ended at

NUMBER NOT NULL /*

VARCHAR2(16) NOT NULL /*

VARCHAR2(255) NOT NULL /*

VARCHAR2(30) NOT NULL /*

из запроса */

возможно, требуется путевое имя */ выдает список аргументов */ запрашивающий пользователь */

DATE NOT NULL

DATE

completion code VARCHAR2(72) rows processed NUMBER /*

cpu used NUMBER /*

memory used NUMBER /*

io used NUMBER /*

CONSTRAINT run log pk PRIMARY KEY (run id)

из управляющей таблицы */ если есть */ */

CREATE TABLE run

run id stage

rows processed reached at cpu used memory used io used

CONSTRAINT run

step

NUMBER VARCHAR2(16) NUMBER DATE NUMBER NUMBER NUMBER step pk

NOT NULL NOT NULL NOT NULL NOT NULL

PRIMARY KEY (run id, CONSTRAINT run step pk

FOREIGN KEY (run id)

/* из запроса */

если есть */

stage, rows processed) REFERENCES run log

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

Пр1шечание

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

fifdef DEBUG

/* диагностика */

fprintf(f logfile, About to update customer totals ); #endif

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

debug flag = getenv( DEBUG )

IF (*debug flag == Y) (

/* диагностика */

fprintf(f logfile, About to call function lb conmit );