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

...начало

Этот конспект ещё не дописан. Здесь не хватает:    - примера попадания в БД записей незавершённых транзакций    - примера порядка выполнения 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;

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

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