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