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

Материал из eSyr's wiki.

Предыдущая лекция | Следующая лекция

Лектор вопросы подготовил, он распечатать не успел

Метод временных мерок.

Тупики в ситуациях, когда нет конфликтов, не возникают. Если БД распределённая, и если там конфликты вполне реальны... тупики могут быть распределёнными, и находить их трудно. В таких случаях можно использовать подход, в котором отсутствует синхронизация, но это балансируется частыми откатами транзакций. Метод оптимистический, то етсь работает в предположении, что конфликтов нет. Работает он просто, если не вдаваться в детали.

Каждая транзакция метится уникальной временной меткой. Если это централизованная система, то это астрономическая время начала транзакции. Если БД распределённая, то надо делать линеаризацию времени. И там надо делать, чтобы можно было их упорядочить: T1 tsT1 и T2 tsT2, тогда можно сказать, какая из них моложе.

В момент t1 есть операция, которая ображается к объекту, он помчается временной меткой транзакции, и эта метка сохраняется о коммита. Пусть Т2 трогает тот же объект. Если о не помечен, то нормально выполняется (добавляется метка, ...) если объект помечен и объект есть, то если tsT1 < tsT2 то Т2 откатывается, иначе откат. Если tsT1 > tsT2 то Т1 откатывается и Т2 выполняется.

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

Почему мы более молодой транзакции не можем дать почитать более моложо й транзакции посленюю зафикс версию?

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

Первой системо,Й которая стала использовать.

Какая тебе разница, что там было, какая тебе разница, что там будет в след раз?

На транзакциях всё

Долговечность

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

Ильдар: хотел бы я дожить до возраста, в котором забываешь, то ли я придумал, то ли кто-то ещё...

СУБДЖ всё грамотно делать, при этом как можно реже дёргаться с дисками.

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

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

//напомнить лектору про main memory БД

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

Если мы будем работать с интеллектуальными дисками, то оптимизации будут избыточными.

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

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

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

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

Рассм две операции в связи с этим:

1. UNDO
2. REDO

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

Хороший вопрос на экзамене – почему нельзя ставить ссылки вперёд.

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

Предположим, выполняем операцию вставки кортежа. Выполнили первую микрооперацию, нашли место, начали обновлять индекс, и если расщеспление дошло до корня, и записали только два блока, а три нет, то с ним мы не сможем работать.

Предположим, мы можем восстановить к томцу моменту, когда запись вставлена, а индексы не обновлены. В таком состоянии мы спокойно можем удалить запись.

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

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

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

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

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

Пишется журнал высокого уровня, куда пишутся логические операции. Это логические журналы.

Чекпоинты на 3-4-5 останавливают работы СУБД. Как ведётся логический журнал, который должен всегда расти. Но он не может расти бесконечно. Администратор определяет две точки – жёлтая зона (перестают запускаться новые транзакции) и красная зона (место на откат). Если выходим за красную, то будь что будет.