1632
правки
Изменения
м
Очевидно, самое простое==Изоляция транзакций==Свойство изолированности говорит нам о том, что можно сделать {{---}} сделать исполнение всех наших запросов полностью упорядочиваемыми. К сожалению:* в системе могут параллельно исполняться две и более транзакции; * при этом транзакция должна уметь выполняться так, у такого подхода есть большой минус {{---}} это слишком долго. Вследствие этого появились уровни изоляциикак будто она в сисетме одна;* кроме того, которые позволяют архитектору базы указатьесли мы выполнили по отдельности набор транзакций параллельно, то при каких транзакциях нам действительно нужнопопытке посмотреть на все эти транзакции в совокупности мы должны увидеть, например, полное упорядочивание, а при каких нам будет выгоднее пожертовать некоторыми гарантиями для ускорения выполнениячто их совместный результат также корректен.
rollbackEdits.php mass rollback
В контексте баз данных очень часто возникает параллельное исполнение возникаеттранзакций, когда два или если в системе параллельно с одними и теми же данными работает более клиента пытаются обратиться к базе данныходного полльзователя. При Тем не менее, при такой работе мы все еще должны уметь обеспечивать все четыре свойства ACID (атомарность, согласованность, изоляцию и устойчивость). Следовательно, при проектировании СУБД необходимо учесть проблемы, которые могут возникнуть при параллельной обработке транзакций. Транзакция {{---}} это логическая единица работы, в ходе которой может выполняться некоторый набор действий с объектами базы данных.
==Проблемы (аномалии) при параллельной обработке транзакций==
===Косая запись===
Аномалия "косой записи" {{---}} аномалия, которая возникает при ситуации когда мы из двух разных транзакций пытаемся изменить одни и те же данные (например, ячейки А и В) так, что общий первая транзакция затронет ячейку A, а вторая {{---}} ячейку В и мы получим неконсистентный результат.
Пример возникновения аномалии:
Название этого уровня изоляции на русский язык можно перевести как слепок, что, на самом деле, приводит к тому, что если две транзакции совершаются прааллельно, то каждой из них выдают свой "слепок" базы данных в какой-то определенный момент.
После выполнения всех операций со слепком базы данных (удаление/запись/изменение/чтение) все изменения "вливаются" в основную версию базы. Транзакция будет завершена успешно, если в основной версии базы данных к моменту окончания транзакции не было изменений ни в одной из ячеек базы, измененных в ходе транзакции, не было изменений за время ее выполнения. Таким образом, если две транзакции выполняли операции над разными частями базы данных, то конфликтов у нас не возникнет и соответствующее слияние произойдет безболезненно. Если же изменялись одни и те же данные, мы можем получить аномалию "косой записи" (см. выше).
Стоит отметить, что формально такого уровня изоляции нет в стандарте языка SQL.
===Уровень изоляции Repeatable read===
При данном уровне изоляции выполняется гарантия, что при повторном чтении одного и того же поля записи в базе мы будем получать одни и те же значения в ходе транзакции. Исключение составляют те изменения, которые мы сами внесли в базу.
commit;
===Уровень изоляции Read uncommitted===
При таком уровне изоляции транзакций у нас вовсе отсутствуют какие-либо блокировки, следовательно мы ничего не можем гарантировать пользователю. При таком уровне изоляции пользователь увидит любые текущие данные в базе данных, в том числе, он сможет увидеть "граязные грязные данные" {{---}} то етсь есть данные, которые еще не были зафиксированы ни одной из транзакций и впоследствии могут быть вовсе откачены.
Вследствие того, что идея изменять данные в базе основываясь на еще незакомиченных данных звучит совсем безумно, стандартом SQL прописано, что транзакции, работающие на уровне изоляции read uncommitted, могут только читать данные, но не изменять их.
