Основы AS/400
Шрифт:
Журналы базы данных используются для восстановления, как при сбоях системы, так и в случаях ошибок в программах. При аварийной остановке системы из-за аппаратного или программного сбоя файлы базы данных, для которых велся журнал, автоматически восстанавливаются при перезагрузке и будут обновлены в соответствии с информацией, записанной в приемниках журнала. Если программа ввела в файл, для которого ведется журнал, ошибочные данные, то AS/400 может восстановить такой файл как прямым, так и обратным способом. В первом случае сначала восстанавливается резервная версия файла, затем к нему применяются записи журнала, сделанные до того момента времени, когда произошел сбой. При обратном восстановлении
Системная защита пути доступа SMAPP
В прошлом пользователи AS/400 были вынуждены мириться с долгим временем перезагрузки после аварийной остановки: пути доступа [ 54 ] , открытые для обновления файла, должны были быть построены заново. Вспомните, что в главе 5 мы упомянули возможность отложенной коррекции логического файла. Вследствие этого целостность логического файла при аварийной остановке может нарушиться. В зависимости от числа и размера открытых путей доступа по ключу, временной промежуток, требуемый для их восстановления, может быть значительным, для больших систем — несколько часов.
54
Те читатели, у которых понятие «пути доступа» вызывает затруднения, могут (с известной натяжкой) считать, что это примерно то же самое, что и индекс. — Прим. консультанта.
Как мы только что говорили, в AS/400 имеются средства журналирования, в том числе и для логических файлов. Если пользователь задействует ведение журнала для путей доступа, то время перезагрузки системы может быть значительно сокращено. Потенциальная трудность состоит в том, что пользователь должен сначала определить, для каких файлов следует вести журнал, оценить размер приемников журнала и дать команду активизации журналирования. Некоторые так и поступают, но, увы, таких пользователей меньшинство.
Для автоматического ведения журнала IBM разработала SMAPP (System-Managed Access Path Protection). Система сама вычисляет максимальное время, требуемое на восстановление путей доступа после сбоя и соответственно определяет необходимый объем журналирования путей доступа. Пользователь всегда может увеличить или уменьшить вычисленное системой время. Чем время меньше, тем больше системных ресурсов потребуется для ведения журнала. Таким образом, ведение журнала предполагает выбор между системными ресурсами, предназначенными для нормальной работы, и мерами предосторожности на случай аварийной перезагрузки.
После вычисления или задания пользователем максимально допустимого времени, система просматривает все пути доступа по ключу, существующие в базе данных; затем вычисляет общее время, требуемое для восстановления всех этих путей. Если время превышает максимально допустимое, то система автоматически начинает ведение журнала для отдельных путей доступа, чтобы гарантировать минимизацию времени на восстановление.
SMAPP использует специальную область ведения журнала, не требующую действий со стороны пользователя. Эта область — циклическая, то есть по достижении конца запись продолжается с начала. Система всегда поддерживает в этой области достаточное число записей.
Управление транзакциями
Иногда целостность данных может быть нарушена, особенно, если с записями физического файла работают несколько пользователей. Предположим, что один пользователь считывает запись, собираясь обновить какое-то ее поле. Что произойдет, если то же самое поле записи одновременно обновляет и другой пользователь? Если второй пользователь изменит поле после того, как значение поля считано первым пользователем, нарушится ли целостность данных? К счастью, этого не произойдет, так как база данных обеспечивает защиту от параллельного обновления. Однако, при более сложных вариантах одновременного изменения нескольких записей, система не гарантирует автоматической защиты.
Допустим, что необходимо одновременно изменить несколько взаимосвязанных записей. Часто, для описания такой ситуации используется пример с банкоматом. Пользователь банковского терминала запускает транзакцию: вставляет в машину кредитную карту, вводит идентификационный код и выбирает тип транзакции. В результате этого клиентская запись считывается из базы данных центрального компьютера, который может располагаться на другом конце города или земного шара. Если клиент запрашивает выдачу наличности, то по содержимому записи проверяется, достаточен ли остаток денег на счете. Затем остаток уменьшается на затребованную величину и банкомату посылается команда на выдачу денег. Что если случилась поломка, и банкомат не может выдать наличность? Прежде чем эта неудавшаяся транзакция завершится, следует отменить изменение остатка на счете клиента. Средство, используемое для этого в AS/400, — управление транзакциями (commitment control).
Так как все изменения невозможно выполнить одновременно, система обязана защитить группу взаимосвязанных записей и не освобождать ее до тех пор, пока все изменения не будут внесены. Команда «Commit» позволяет изменить группу записей так, чтобы она выглядела как одна операция. Если нельзя выполнить какое-либо изменение, то вся группа изменений может быть отменена по команде «Rollback». Для этих операций управление транзакциями использует журналирование.
Триггеры
Триггер — действие, выполняемое автоматически всякий раз, когда содержимое физического файла изменяется — удобный способ связать одну операцию с другой. Триггеры — разновидность пользовательского средства обеспечения целостности базы данных, встроенная в определение файла. Часто изменение базы данных, например, добавление или удаление записи, требует некоторых дополнительных действий. В этих случаях триггер может запустить соответствующую программу. В других случаях, при изменении записи может требоваться запустить программу проверки нового значения поля записи: например, если при обновлении данных в файле инвентарной описи число учитываемых предметов упадет ниже допустимого уровня. Триггер для такого файла может при каждом обновлении запускать программу, проверяющую значение и отправляющее поставщику в случае необходимости дополнительный заказ.
При добавлении к физическому файлу триггера необходимо определить три атрибута. Первый — событие, приводящее к запуску триггера: вставка, обновление или удаление записи из файла. Второй атрибут задает, когда следует запустить триггер — до или после события. Наконец, третий атрибут задает программу запуска триггера. Обычно это пользовательская программа, написанная на любом ЯВУ, поддерживаемом AS/400.
Таким образом, для каждого физического файла можно назначить до шести триггеров: по два триггера для обновления, вставки и удаления записей, так чтобы один триггер запускался до события, второй — после. Триггеры добавляют командой «ADDPFTRG» (Add Physical File Trigger), а удаляют командой «RMVPFTRG» (Remove Physical File Trigger).