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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. UNDO
2. REDO

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

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

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

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

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

Подходы к восст физ соглас БД:

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

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

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

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

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

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