СПАСОИ (10) - Лекция №11 - Восстановление БД после сбоя

Материал из Кафедра ИУ5 МГТУ им. Н.Э.Баумана, студенческое сообщество
Перейти к навигации Перейти к поиску
Версия для печати больше не поддерживается и может содержать ошибки обработки. Обновите закладки браузера и используйте вместо этого функцию печати браузера по умолчанию.

...начало

Этот конспект ещё не дописан.
Здесь не хватает:
   - примера попадания в БД записей незавершённых транзакций
   - примера порядка выполнения COMMIT


Особенности разработки приложений для работы с БД в сети

Ведение версий записи

Она же блокировка по чтению.

После выполнения COMMIT записи из сегмента отката удаляются не сразу. Это связано с ведением версий записей.

Предположим, что в момент $$T_1$$ выполняется SELECT и проверяется время обновления записи. Если $$T_1 > t_2$$, то запись читается из БД. Если $$T_1 < t_2 = t_{обновления}$$, то записи читаются из сегмента отката (до обновления). Представленный механизм ведения версии записей обеспечивает целостность чтения данных в интервале $$T_1-T_2$$.

Схема восстановления данных после сбоя

При восстановлении данных используются два системных файла:

  • журнал транзакций;
  • сегмент отката.

В журнале транзакции сохраняются полные транзакции (записываются записи после обновления). В этом же журнале записываются метки по перезаписи всех "грязных" блоков.

В сегменте отката для каждой незавершённой транзакции записываются записи до и после обновления.

Предположим, что произошёл сбой. После восстановления выполняются следующие действия:

  1. докат системы (rollforward) - ищется последняя метка о перезаписи всех "грязных" блоков на диск, и начиная с этой отметки и до конца файла читаются записи полных транзакций, и они перезаписываются в БД;
  2. откат незавершённых транзакций (rollback) - потому что в БД могли попасть записи незавершённых транзакций. Из сегмента отката с конца транзакции читаются записи до обновления и записываются в БД.

По оператору COMMIT сначала необходимо записать обновлённые записи транзакции в БД, а только потом эти записи записать в журнал транзакций.

Ещё можно почитать в этой статье.

Пример восстановления БД после сбоя

Здесь выполняется только докат. Отката нет, потому что в сегменте отката нет незавершённых транзакций.

Перезапись "грязных" блоков из общесистемного буфера на диск выполняется в следующей строгой последовательности:

  1. блоки сегмента отката;
  2. блоки журнала транзакций;
  3. блоки БД.

Обработка тупиковых ситуаций

Предположим, что процедура проверки реализуется иначе, чем в прошлой лекции:

проводка(счёт1, счёт2, остаток)
-- дебет
UPDATE счёт1 -- запись автоматически блокируется до завершения операции (до COMMIT)
...
-- кредит
UPDATE счёт2 -- запись автоматически блокируется до завершения операции (до COMMIT)
...
COMMIT;

При одновременном обращении к этой процедуре двух процессов возможно возникновение тупиковой ситуации.

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