Редактирование: Базы Данных, 27 лекция (от 14 декабря)

При сбоях БД смогла восстаносить последнее рабочее состояние. Явное или неявное выполнение rollback внутри транзакции. Оно может быть инициировано системой или юзером.

Самая частая причина – выключение питания. В результате теряем кусок буферов. Может быть так, что завершённые ситуации не сохранились, а незавершенные сбросили буфера. И в результате можем получить физическую несогласованность. В результате мы привыкли, что софтварь и другие мягкие штучки приятнее, чем хардвар и другие жесткие штучки, но тут это не так.

Все уже 25 лет ждём, когда появится быстрая память, которая позволяет сохранять состояние после выключения питания.

Потеря информации: перестаёт читаться внешний носитель.

Рассказ в предположении, что система знает, как устроен жесткий диск.

Логически это просто, вопрос, откуда взять минуса. Самый простой вариант – у каждой транзакции есть своя локальня память. Есть много вещей, которые связаны с транзакцией локально.

Компенсирующая информация – если была операция удаления, то записываем, что было удалено, если добавления – что и откуда.

Если мы транзакцию сделали, а потом сбой, то придётся выполнять её заново.

Журнал пишется в последовательном режиме, не разрешается менять уже записанные в память кусочки.

Журнал такого вида никак не может помочь, если потеряли буфера памяти. Соответственно, задача восстановить физически целостное наиболее близкое к сбою состояние.

Подходы к восстановлению физической согласованности БД:

Что такое теневой механизм в отрыве от БД. Этот механизм был придуман для работы с файлами. Какая была задача: операции с файлами синхронизуются на уровне файла целиком. Так вот, основная цель теневого механизма – если какой-то файл открыл файл на обновление (файл – набор блоков во внешней памяти), начинает менять блоки. Структура файла неизвестна, например, могут быть ссылки. Некий процесс начинает его менять. Требуется от механизма, что если в момент до закрытия файла происходит сбой, чтобы файл автоматически был в первоначальном состоянии, а если дошли до закрытия, то при следующем открытии в новом состоянии. У каждого файла есть таблица отображения. Когда файл открывается, вся таблица отображения считывается в основную память. После этого тот экземпляр, который попал в основную память называется текущим, а на внешней – теневым. До закрытия меняется только текущая таблица. Если процесс меняет блок 2, то система выделяет место под блок 2 и ставит ссылку на него. И так для всех. При закрытии всё записывается. Теперь если выключается питание, текущая таблица пропадает, остаётся теневая, то есть та, которая до открытия. При закрытии же есть вопрос, как это сделать. Если таблица занимала бы один блок, то можно было бы её обновить за один обмен с памятью. Дополнительно, на внешнем носителе иметь место под две карты, тогда пишем в неиспользуемую таблицу, если произодет сбой, то ссылка не поменяется, а если вдруг до конца записали и тогда меняем ссылку.

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

Как ведётся журнал. Есть компонент, который занимается блокировкой. Менеджер буферов единственный работает с внешней памятью. Менеджер журнала. Сидит администратор. Он должен всем сказать, что ребята притормозитесь. Они притормаживаются. После этого в пуле буферов полный порядок. После этого они говорят журналу «скажи нам журнал, а где мы находимся», журнал им говорит. Посде этого начинается длинная-длинная история. Поменять таблицы отображения, разгрузить буфера... Поле этого говорят, что поехали дальше. Это протокол операции выполнения контрольной точки.