Вордовские лекции (1121814), страница 17

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 17)

//В любом серьёзном проекте должен быть один математик, и полчать должен не меньше программиста, хоть ничего не делает

Идея простая, и, видимо, у них не было того самого математика. Был уровень SQL и был уровень RSS. Эти сложные условия сществуют на уровне SQL, между SQL и RSS их уже нет, а что остаётся. На уровне RSS есть два режима сканирования – последовательное сканирование и скаинрование через индекс. Обновление схожим образом. В действительности, этот интерфейс не должен быть перегружен. Когда мы строим взаимод откомпилир запроса и работы с памятью нужно добиться того, чтобы поступало как можно меньше кортежей, отсеить как можно больше. Максимум, что может сделать RSS, если удаётся от начального условия некий набор условий, которые явно задают условие на эту таблицу, то это спокойненько можно спихнуть на RSS. RSS считывает блок в память и последовательно их просматривать. Ничего не стоит для этих кортежи проверить на условия и передать только те которые удовлетворяют. А условия такого рода: (25<a<30)&(26<b<30)&c=13. Вот это вот условие естественно принять как то самое условие, по которому ставятся блокировки. Open Scan это болоьшая операция над всей таблицей. Если у нас есть таблица R(A1...An), тогда что представляет собой область опред этой таблицы? Это будет конечное н-мерное пространство. И система условий – м-(мама)-мерный куб в н-мерном пространстве. И условия пересекаются, когда кубы пересекаются. Такая простая геометрическая интерпретация позволяет делать такие блокировки за ту же цену, что блокировки s и x. Одно но: когда мы блокируем прямоугольник, мы блокируем гораздо больше, чем выбранные строки.

Изолированность транзакции

Чего мы добиваемся? Чтобы при работе транзакции она не ощущала других транзакций. Как этого добиться? А не допускать конкурентных транзакций вообще. Т. е. запускать их последовательно. Этот план выполнения транзакций называется сериальный (последовтаельный). Любой алгоритм, котороый выполняет транзакции одновременно, и при этом сохраняет их изолированность, обладает след свойством: есть транзакции {T1...Tn} и есть некоторый алгоритм полной изоляции, то после завершения этих транзакций, то суммарный их эффект будет таким же, как если бы они выполнялись в некотором порядке Ti1...Tin. Такие алгоритмы называются алгоритмами сериализации. Способ выполнения смеси транзакций... они же выполняются по кусочкам, и то, ч то врезультате возникает при выполнений, называется планом, процесс – планированием. План, который приводит к эффекту серивального выполнения транзакций, называется сериализуемым. Сериальный – когда выполняем последовательно. Сериализуемость – когда выполняем так, как быдто мы выполняем их сериально. Сериальный план – когда выполняем так, что результат эквивалентен последовательному.

//прослушал определение двухфазного протокола блокировку (2PL) :(

Хороший вопрос: почему протокол двухфазный. Одна фаза трабочая – от начала транзакции, до rollback-commit, на которой накапливаются блокировки. Выполняется операция коммит, и все блокировки освобождаются.

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

БД_2006-12-08

Функции «систем ар»:

Интерф. Доступ

Упр. Буферами

Упр. Блокировками

Журнализация и восстановление

Единица блокировки – строка в таблице. Это очень удобно: таблицы большие, в ней много строк, все строки блокировать нельзя.

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

Правильный ответ: Уничтожение заполненной таблицы.

Во время удаления таблицы кто-то может вставить кортеж.

Чтобы всё удалить, нужно блокировать всю таблицу.

Если нет понятия «несколько баз данных», нет единицы блокировка БД.

Джим Грей – великий писатель БД.

Гранулированная синхр. Блокировки.

Блокировки намерения (intended locks)

Intended to Share (IS)

Intended to Exclusive (IX)

Shared, intended to exclusive (SX)

X (min₁ <= A₁ <=max, .. min_n <= A_n <= max_n)

Deadlock (синхрониз. Тупик)

«Смертельные объятия». Это не самоблокировка, а блокировка друг друга.

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

Распознавание и разрушение тупиков.

Нельзя использовать в ОС, так как в ней слишком много объектов.

Один из способов: Граф ожидания транзакции (в виде двудольного графа: в вершине либо особая транзакция, либо объект). Есть цикл => есть тупик.

RSS запустила процедуру, обнаружила цикл, в нём замкнуты две транзакции. Далее осуществляется «выбор жертв».

Лучше убивать более молодую транзакцию.

Логическая и физическая блокировка.

Поиск свободного места.

На физ уровне приход делать синх на Ур блоков – блоки сложно использ на лог уровне. Лог и физ уровни не должны знать друг друга.

Эта синхронизация не такая страшная. Микро операции – это некий микронабор действий. Их может быть сотни.

Позиция пессимиста если хотим писать, кто-то читает и т.д.

БД 14.12.06

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. UNDO

2. REDO

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

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

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

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

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

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

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

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

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

Характеристики

Список файлов лекций