Функции администратора. Управление памятью. Управление многопользовательским доступом. Экспорт и импорт данных, страница 5

Характеристики режимов сведены в таблицу

Если приложению отказано в запрошенном доступе, то оно задерживается до разблокирования объекта. Во всех рассмотренных нами СУБД предусмотрена возможность установки предельного времени задержки: если за это время объект не разблокирован, то ожидающее приложение возобновляет выполнение, но тот его SQL-оператор, в котором содержался запрос на доступ, завершается с признаком ошибки. Крайними случаями являются установки нулевого или бесконечно большого времени ожидания.

При параллельной работе приложений возможны "неразрешимые" конфликты доступа – тупики. Методы обнаружения тупиков в СУБД – те же, что и в ОС. СУБД выполняет проверку наличия тупиковой ситуации при отказе в доступе или периодически через установленные интервалы времени (DB2). Ликвидация тупика состоит в отмене транзакции одного из приложений, участвующих в тупике. Объекты, заблокированные в этой транзакции, при этом освобождаются, и оставшееся приложение получает возможность удовлетворить свой запрос. Когда оставшееся приложение закончит свою транзакцию и освободит объекты, может быть повторно запущена отмененная транзакция. В качестве "жертвы" выбирается та транзакция, по которой был выполнен наименьший объем работы. Приложение, ставшее "жертвой" может определить свое состояние по коду ошибки, установленному при завершении SQL-оператора и повторить принудительно отмененную транзакцию.

4. Копирование и восстановление данных

4.1. Рестарт, резервное копирование, прокрутка вперед

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

Восстановление данных после таких ошибок включает в себя три аспекта:

·  рестарт системы;

·  восстановление по резервной копии;

·  восстановление с прокруткой вперед.

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

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