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

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

Лектор сам искать аудиторию не будет. В 16:30 лектор приезжает.

Очень хороший тест: когда спрашиваешь, это было на лекциях или не было.

Второй подход к восстановлению физической согласованности БД.

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

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

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

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

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

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

Скоро мы будем иметь БД в каждом холодильнике. Холодильник по этой БД выбирает, что купить на след неделю, покупает, заполняется и кормит след неделю. Но администратором холодильника лектор быть бы не хотел.

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

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

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

Представим, что такой журнал существует. Журнал, куда пишутся записи вида блок, его содержание, номер транзакции.

Опять же нужна операция чекпоин. Что в этом случае должно делаться в этом случае. Дожидаемся конца всех микроопераиций. Второе – выталкиваем все буфера во внеш память. И с этой точки начинаем вести журнал. Первое действие – должны запросить у буфера...

Порядок действий:

1. Обращение менеджером буферов с тем, чтобы выдали этому процессу-транзакции выдали область памяти, где находится требуемый блок.
2. Выполнение операции
3. Выполнение маленького коммита, и в этот момент все записи микрожурнала должны оказаться на диске

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

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

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

Две вещи: при заверш микрооп ывталк журнала при переполнении – выталкивание и сначала.

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

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

Лектор решил ещё раз всех переписать.

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

Восстановление после жёсткого сбоя

Должно что-то сохраниться

1. Архивная копия БД. Хотя бы пустая. Система фактически работоспособна, кроме того, что диск полетел. Сначала восст из архивной копии, а потом полное redo до конца журнала. И дальше можно просто продолжить работу приложения. Но так никто не делвает. Это тоже убого. Что такое архивная копия? Это не хухры-мухры. Архивные копии делаются очень долго
2. Делать копии журнала. Система проработала два года и будет восстанавливаться два года. Поэтому обычно компромиссный вариант – архивное копирование, две копии журнала. Ещё. Могут быть множественные изменения одного объекта, и если их объединить в одно, то восстановление становится достаточно быстрым.

Что ещё можно сказать: частичное восстановление в горячем режиме. Если часть упала, то разрешаем работать с другими частями и восстанавливаем упавшую.

Ещё не проигрывать транзакции, потому что они вносят существенные накладки.

Управление буферами основной памяти

Первое утверждение, в которое верят люди, которые работают на проф уровне.

У лектора был ученик, и он лектора сильно удивил, выбрав вместо аспирантуры работу в MySQL, но в одну вещь он перестал верить: «для того, чтобы любая СУБД работала эффективно, она должна сама управлять буферами».

К чему это приводит: всё из-за того, что так устроена ОС. Если какая-то программа хочет сама работать, то она должна иметь права суперпользователя, и простые пользователи не смогут без администратора поставить. В результате СУБД считает, что этот кусок ей важен и хранит его в буферах вирт памяти, а ОС так не считает и может спокойно слить его на диск.

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

• LRU. Существует в локальном и глобальном варианте. Для страницы оценивается время, которое со страницей не работали. Страница стареет

1. Приоритетное удержание. Представьте себе, что в какой-то транзакции, в какой-то операции открыто сканирование на уровне РСС. Фактически при каждом обащении по фетч берем следующую строку, и при каждом обращ к след сначала все предыдущ. Если произогло обращение было, то оно произойдёт ещё несколько раз. Человек может чидеть читать результат запроса построчно, нажимая на пробел, котрорый приводит к фетч. Он может уйти пить чай, но страница ещё будет нужна. Такие страницы должны стареть медленнее. Ещё есть Корневые блоки Б-деревьев. Любой поиск начинается с них. Для этих блоков выставляется максимальный приоритет удержания.
2. Упреждающее чтение. В ОС мы не знаем поведение процесса. А здесь знаем. И если мы знаем, что если идёт послед сканирование, мы знаем, через какое время условно говоря нам потребуется следующая страница. И тогда их можно запранее подкачать. Это время подсчитать нелегко.

Управление буферами в виртуальной памяти – фикция. Как работать на честной виртуальной памяти – у него есть некотороый кусочек виртуальной памяти с адреса 2400 до 1000056. У нег опросят «дай мне блок», он читает его, выдаёт ссылку.

Рабочие наборы здесь неприменимы.

Третье – то, что из известных лектору алгоритмов используется LRU с приоритетами и упр чтением.