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

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

Версия от 18:41, 15 декабря 2006; Esyr01 (Обсуждение)
(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Перейти к: навигация, поиск

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

Будет ещё 4 лекции, закончится всё в след пятницу.

Досрочный экзамен. Лектор хочет провести один или два экзамена до зачётной сессии. Формально он мог бы ограничить количество народа теми, кого переписали. Есди нахалов придёт слишком много, то их отсеят.

В след четверг лектор даст вопросы, но досрок – экзамен-экспромт, и никакой подготовки нет. Экзамен стремительный, лектор относится крайне разко к ответам, которые его не устраивают. Как правило, когда там ставятся тройки, в том случае, если удасться доказать, что нужно человек получить тройку досрочно. Первый досрок – 19 числа. Возможно, ещё 20. Можно провести ещё экзамен после зачётной, до НГ, если наберётся достаточно народа. Третий курс разросся до безобразия. Процент успеха – 25 процентов.

Был случай, когда человек приходил к лектору 4 раза и получил в итоге пятёрку, с каждым разом чуть-чуть продвигался. Экзамен будет принимать не только лектор, у каждого своя манера приёма экзамена.

Транзакции

begin trans
 ...
commit / rollback

Понятно, что если внутри транзакции возникает непредвиденное, то СУБД получает соотв образом информацию (в Систем Р, которая была менйфреймовской, всё запускалось в пределах сервера, и отлавливалось легко) м неявно считает, что в этой точке выполняется rollback. Это действительно атомарная последовательность действий, потому что либо она успешно завершается, либо её следов вообще не остаётся. свойство атомарности соблюдается за счёт скобок.

В Систем Р определялись два огрничения целостности – immediate, которые выполняются сразу после каждой операции, например, то, что зарплата должна повышаться не более чем на 20 процентов. Если не проходит, то транзакции не обрываются, но операция отвергается. А бывают ограничения, которые нельзя проверить сразу, и их отодвигают в конец транзакции.

Идея Дейта и Дарвина – идея здравая и полезная. Лбюбая операция изменения БД – операция присваивания. Нвапример, если добавляете строку в таблицу отношений, то в действиетльности это присваивание переменной отношение, которая соотв этой таблице, нового значения, в которое входит эта строка. То же про удаление. Главная идея Дейта и Дарвина – разрешается делать множественные присваивания. Это требуется,к когда нанимается на работу новый служащий, и требуется обновление двух переменных отношения. При старорежимном подходе это отложенное огранич целостности по Д. и Д. это обновить вот это, обновить вот это, проверить, и если плохо, то изменние отвергается, трпанзакция проболжается. Фактически, это маленькая транзакция внутри транзакции.

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

Из-за чего возн проблемы с изоляцией транзакций? Когда выполн смесь транзакций, concurrently, которые конкурируют за нечто. Concurrency без вреда – не concurrency. Очень часто это переводят как параллельно, но они не обязательно реально параллельны. При этом одна транзакции начинает чувствовать другую. Могут возникнуть конфликты трёх сортов: 1.write-write – если допустить наличие конфликтов, то наблюдаются феномены 1. феномен потерянных изменнией. Решение – монопольные (exclusive) блокировки. /* ен называть эксклюзивными */ 2.read-write (dirty read – грязное чткние). т1.писать, т2.читать, т1.ролбек, т2.коммит Решение: вводится ещё один механизм блокировок – совместные блокировки (s., shared). Читать можно вместе сколько угодно. Таблица совместимости:

н/б S X
S Y Y N
X Y N N

След таблицу совместимости лектор рисовать не будет.

s – Кратковрем блокировка до конца чтения.

Эффект фантомов

Сценарий очень похож. Вот транзакция т1 по некоторому условию, например, столобец а больше 5 меньше 25, а транзакция т2 в момент т2 записываем строки, у которых значение атрибута a равно 20. Понятно, что конфликта read-write нет, но при втором чтении возникнет кортеж-фантом. Как мы видим, в действительности, мы сделали всё, что было можно, потому что работают длинные блокировки по чтению-записи, и они не спасают. Есть один способ, очень грубый, и которым пользуются в непродуманных системах. Когда в стандарте СКЛ есть три режима выполн транзакции – грязное чтение, неповт чтение, допуск наличие фантомов, и режим, при котором транзакции работают абсолютно изолированно. В непродуманых системах, если выборка не по первичному ключу, тоблокируется таблица целиком до конца транзакции. Конечно, это достаточно грубый способ, рпотому что читается 10 строк из 5 миллионов, а мы блокируем 5 миллионов, чтобы не возникла 11. В Систем Р поняли, что природа фантома заключ в следующем. Блокируем мы физ объект, а условие логическое. Противоречие в том, что блок физ объекты, а выборка по логич усл, И рпидумали механизм предикатных синхронизированных блокировок. То есть я гворю системе, что хочу заблокировать все строки, которые удовлетворяют этому условию. И тогда они будут блокировать не свю таблицу, которую лектор стёр и вот от неё следы остались, а: если у нас блокировка по чтению по такому условию S(5<a<25), и X(26<a<27), то всё нормально, а если X(6<a<18), то происходит пересечение, и блокировка не выполнится.

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

В данном случае это проблему решает. Первая транзакция делает S()5<a<25, вторая X(a=20) и затормозится, пока первая не выполнится. Но это толдько в теории, и они долго изголялись, но таки сделали, тобы у них не было фантомов, но не так красиво. Дело в том, что они опирались на SQL, у которого условия могут быть очень сложные, и не смогли придумать способ проверки, когда эти условия совместимы. На самом деле, в течение долгого времени эта идея висела, и лучше всего эту идею реализовали мы в своём СКЛ-сервере. У нас в группе работали очень опытные программисты, и ни один не допёр. И был один неопытный программист и хороший алгебраист, и он до идеи допёр.

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

Идея простая, и, видимо, у них не было того самого математика. Был уровень 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, на которой накапливаются блокировки. Выполняется операция коммит, и все блокировки освобождаются.

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


Базы Данных


01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28


Календарь

пт чт пт чт пт чт пт чт пт чт
Сентябрь
01 07 14 15 21 22 28 29
Октябрь
  05 06 12 13 19 20 26 27
Ноябрь
  02 03 09 16 17 23 24 30
Декабрь
  07 08 14 15

Вопросы к экзамену
1999 2000 2001 2002 2003 2004 2005 2006


Дополнительная информация к экзамену


Эта статья является конспектом лекции.

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