Промышленная эксплуатация

Опытная эксплуатация

Сдача в эксплуатацию

Сдача в эксплуатацию ведется в два этапа:

· опытная эксплуатация

· промышленная эксплуатация.

На этом этапе происходит загрузка БД. Загрузку проводит разработчик специальной программой загрузки. После заполнения БД необходимо приступать к опытной эксплуатации. Для опытной эксплуатации достаточно загрузить часть записей БД. Но при этом все тестовые примеры должны охватываться БД – это условие для проверки запросов. Запросы должны иметь неоднократную проверку для того, чтобы быть уверенным в правильности работы БД. Опытная эксплуатация необходима для нахождения и устранения ошибок, допущенных заказчиком и разработчиком. Иногда на этом этапе приходится заново проектировать БД. Кроме того, во время опытной эксплуатации разработчик обязан обучить реальных пользователей БД работе по ее эксплуатации. Опытная эксплуатация длится около года, в течение которого БД проверяется. Если ошибки не выявляются, БД считается составленной верно.

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

Для восстановления базы данных в случае ее разрушения рекомендуется принять следующие меры:

· Выявить ошибку, которая привела к БД; выяснить, когда она возникла, какая часть БД разрушена, какова причина возникновения ошибки: прикладная программа, транзакция, логический или физический терминал в оперативном режиме или пользователь.

· Проследить все действия с базой данных, выполнявшиеся с момента разрушения до начала восстановления.

· Восстановить базу данных до состояния, свободного от ошибок, и выполнить действия, определенные в предыдущем пункте.

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

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

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

· состояние базы данных до изменения. Записывается копия состояния блока, сегмента, страницы или записи до изменения;

· состояние базы данных после изменения. Записываются копии состояний после изменений.

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

Контрольные точки

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

· по команде оператора;

· по истечении определенного временного интервала, который в течение дня может изменяться. При «пиковой» нагрузке он может уменьшаться и возрастать, когда нагрузка уменьшается;

· после определенного числа изменений базы данных;

· после внесения определенного числа записей в журнал или после обработки определенного числа транзакций.

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

Дата добавления: 2014-01-07