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

Вопрос: для того, чтобы выполнить какую-либо операцию на уровне РСС, нужно, вообще говоря, выполнить следующие действия: поменять данные, установить блокировку, нужно поместить запись в журнал. В каком порядке их выполнять? На самом деле, правильный ответ на этот вопрос такой – сначала блокировка, потом запись в журнал, последнее – физические изменения. До тех пор, пока не установлена блокировка, мы не имеем права делать что-либо с объектами. Второе, почему запись сначала в журнала – это общее правило протокол Write Ahead Lock (Пиши Сначала в Журнал). Если бы сначала менялась страница, то могло бы так оказаться, что на диске присутствуют изменённые страницы, а записи нет. Если начала пишется в журнал, то гарантируется, что такого не будет. Лектор не слышал и не читал, что без него нельзя жить, но этот протокол является достаточным, т.е. если ему следовать, то восстановление проходит.

В журналах с теневым механизмом:

Логический журнал содержит всю информацию, которая нужна для отката. Т.о., если ведётся логич журнал, избыточным становится индивид журнал. Что для этого нужно – хранить для каждой транзакции последнюю запись в журнале (?)

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

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

Недостаток теневого механизма – мы долго храним старые копии. Тут же мы храним старые копии, пока не сохраним новый блок.

Оказывается, можно отказаться от дяденьки и можно регулировать время остановок просто размером журнала. Известно, сколько потребуется места в журнале для n микроопераций. Как это работает – запустилась система, начинаем заполнять журнал. Заполняем до того момента, пока не поймём, что этого куска хватит, чтобы закончить все микрооперации. Как закончили – сбрасываем на диск. Единственное, что нужно сдклать – синхронизнуться с логическим. И потом можно опять начинать с начала. Он небольшой.

Две вещи: можно было бы обйтись только физ журналом, и всё бы работало. Было бы гораздо проще. Но. Когда есть лог журнал, то физический может быть маленьким. Но когда он один, нужно его весь тянуть, иначе не сможем восстановиться после сбоя. А тогда логический журнал компактнее. Насколько помнит лектор, идея комбинир логического и физического журналов появилась ещё в систем Р. Вначале у них исп. теневой механизм, но у них были диски маленькие и его было тяжело поддерживать.

Это ужасная головная боль для администратора. Он переполняется. Переполн логического журнала это неприятная ситуация, потому что требуются долгие действия по архивации. Выход – не всё журнализовать. Но это опять же головная боль для администратора.

Как должна работать операция коммит – если каждый раз при завершениее микроопеации происходит выталкивание из микрожурнала, то тут выталкивается содержимое логического журнала.