СПАСОИ (10) - Лекция №11 - Восстановление БД после сбоя: различия между версиями
ILobster (обсуждение | вклад) (Новая страница: «{{Backward|l=СПАСОИ (10) - Лекция №10 - SQL (продолжение)}} {{Tabli4ka warning undone summary|text= - примера п…») |
ILobster (обсуждение | вклад) мНет описания правки |
||
Строка 11: | Строка 11: | ||
После выполнения <code>COMMIT</code> записи из сегмента отката удаляются не сразу. Это связано с ведением версий записей. | После выполнения <code>COMMIT</code> записи из сегмента отката удаляются не сразу. Это связано с ведением версий записей. | ||
[[Файл:10semSPASOIl11pic1.png|center| | [[Файл:10semSPASOIl11pic1.png|center|400px]] | ||
Предположим, что в момент {{Формула|l=T_1}} выполняется SELECT и проверяется время обновления записи. Если {{Формула|l=T_1 > t_1}}, то запись читается из БД. Если {{Формула|l=T_1 < t_{обновления} }}, то записи читаются из сегмента отката (до обновления). Представленный механизм ведения версии записей обеспечивает целостность чтения данных в интервале {{Формула|l=T_1-T_2}}. | Предположим, что в момент {{Формула|l=T_1}} выполняется SELECT и проверяется время обновления записи. Если {{Формула|l=T_1 > t_1}}, то запись читается из БД. Если {{Формула|l=T_1 < t_{обновления} }}, то записи читаются из сегмента отката (до обновления). Представленный механизм ведения версии записей обеспечивает целостность чтения данных в интервале {{Формула|l=T_1-T_2}}. | ||
Строка 35: | Строка 35: | ||
==== Пример восстановления БД после сбоя ==== | ==== Пример восстановления БД после сбоя ==== | ||
[[Файл:10semSPASOIl11pic3.png|center| | [[Файл:10semSPASOIl11pic3.png|center|800px]] | ||
Здесь выполняется только докат. Отката нет, потому что в сегменте отката нет незавершённых транзакций. | Здесь выполняется только докат. Отката нет, потому что в сегменте отката нет незавершённых транзакций. | ||
Строка 46: | Строка 46: | ||
=== Обработка тупиковых ситуаций === | === Обработка тупиковых ситуаций === | ||
Предположим, что процедура проверки реализутся иначе чем в [[прошлой лекции]]: | Предположим, что процедура проверки реализутся иначе чем в [[СПАСОИ (10) - Лекция №10 - SQL (продолжение)#Блокировка обновляемых записей | прошлой лекции]]: | ||
проводка(счёт1, счёт2, остаток) | проводка(счёт1, счёт2, остаток) |
Версия от 11:20, 26 апреля 2013
...начало
Этот конспект ещё не дописан. Здесь не хватает: - примера попадания в БД записей незавершённых транзакций - примера порядка выполнения COMMIT |
Особенности разработки приложений для работы с БД в сети
Ведение версий записи
Она же блокировка по чтению.
После выполнения COMMIT
записи из сегмента отката удаляются не сразу. Это связано с ведением версий записей.
Предположим, что в момент $${{{f}}}$$ выполняется SELECT и проверяется время обновления записи. Если $${{{f}}}$$, то запись читается из БД. Если $${{{f}}}$$, то записи читаются из сегмента отката (до обновления). Представленный механизм ведения версии записей обеспечивает целостность чтения данных в интервале $${{{f}}}$$.
Схема восстановления данных после сбоя
При восстановлении данных используются два системных файла:
- журнал транзакций;
- сегмент отката.
В журнале транзакции сохраняются полные транзакции (записываются записи после обновления). В этом же журнале записываются метки по перезаписи всех "грязных" блоков.
В сегменте отката для каждой незавершённой транзакции записываются записи до и после обновления.
Предположим, что произошёл сбой. После восстановления выполняются следующие действия:
- докат системы - ищется последняя метка о перезаписи всех "грязных" блоков на диск, и начиная с этой отметки и до конца файла читаются записи полных транзакций, и они перезаписываются в БД;
- откат незавершённых транзакций - потому что в БД могли попасть записи незавершённых транзакций. Из сегмента отката с конца транзакции читаются записи до обновления и записываются в БД.
По оператору COMMIT
сначала необходимо записать обновлённые записи транзакции в БД, а только потом эти записи записать в журнал транзакций.
Пример восстановления БД после сбоя
Здесь выполняется только докат. Отката нет, потому что в сегменте отката нет незавершённых транзакций.
Перезапись "грязных" блоков из общесистемного буфера на диск выполняется в следующей строгой последовательности:
- блоки сегмента отката;
- блоки журнала транзакций;
- блоки БД.
Обработка тупиковых ситуаций
Предположим, что процедура проверки реализутся иначе чем в прошлой лекции:
проводка(счёт1, счёт2, остаток)
-- дебет
UPDATE счёт1 -- запись автоматически блокируется до завершения операции (до COMMIT)
...
-- кредит
UPDATE счёт2 -- запись автоматически блокируется до завершения операции (до COMMIT)
...
COMMIT;
При одновременном обращении к этой процедуре двух процессов возможно возникновение тупиковой ситуации.
Современные СУБД отслеживают такие ситуации. Процесс с наименьшим приоритетом (или произвольный) аварийно завершается с некоторым кодом. В программе, выдавшей запрос на обновление, должна быть предусмотрена обработка данной ошибки.