В Oracle реализована уникальная модель поддержки конкурентного доступа, именуемая многоверсионной моделью согласованности по чтению (Multiversion Read Consistency - MVRC). Эта модель дает огромное преимущество для разработчиков, поскольку снимает с них большую часть забот о блокировках, возникающих в коде. Возможность поддержки MVRC встроена в самые глубины архитектуры СУБД Oracle.
Для осознания самой идеи конкурентного доступа и его реализации в СУБД Oracle необходимо знать несколько рассмотренных ранее базовых понятий: транзакция, синтаксис команд COMMIT и ROLLBACK, блокировка, сериализация.
Обычно для разрешения проблем применяются блокировки двух типов.
Первый тип - это блокировка записи (write lock), или монопольная блокировка (exclusive lock). Монопольная блокировка применяется и удерживается в течение того времени, когда транзакция изменяет данные, а освобождается при завершении транзакции командой COMMIT или ROLLBACK. Блокировка записи предоставляет право на доступ к ресурсам единственному пользователю, который только и может изменять заблокированные данные.
В некоторых СУБД также применяются блокировки чтения (read locks), или разделяемые блокировки (shared locks). Блокировка чтения может применяться любым количеством пользователей, которые просто читают данные, т.к. доступ только для чтения не создаёт конфликтных ситуаций. Однако блокировка чтения означает, что для данных нельзя будет применить блокировку записи, т.к. блокировка записи является монопольной. Обычно в Oracle применяются блокировки чтения, только если операция SQL специально запрашивает их в инструкции FOR UPDATE команды SELECT.
Несмотря на то, что применение блокировок может привести к их конфликтам и ухудшению производительности, они всё же необходимы для того, чтобы избежать перечисленных ниже проблем с нарушением целостности данных:
“Грязное” чтение (dirty reads). Считывание данных называется “грязным”, если СУБД разрешает одной транзакции читать данные, изменённые другой транзакцией, когда эти изменения ещё не были зафиксированы. Изменения, сделанные второй транзакцией, могут быть отменены, и тогда считанные данные окажутся некорректными. Многие СУБД разрешают “грязное” чтение для того, чтобы избежать конфликтов, создаваемых блокировками чтения.
Невоспроизводимое чтение (nonrepeatable reads). Речь идёт о ситуации, когда данные изменяются другой транзакцией. Одна транзакция выполняет запрос по какому то определённому условию. После того как данные отправлены в транзакцию, но до того, как она зафиксирована, другая транзакция изменяет данные так, что некоторые из извлечённых ранее данных перестают удовлетворять условию выбора. Если бы запрос в первой транзакции был повторён ещё раз, он вернул бы другое результирующее множество, поэтому любые изменения, выполненные на основе исходных результатов, могут уже не быть корректными. При повторном чтении уже прочитанных ранее данных в рамках одной и той же транзакции могут быть получены отличающиеся результаты.
Фантомное чтение (phantom reads). Такой вид чтения также вызван изменениями, выполненными другой транзакцией. Одна транзакция выполняет запрос по какому-то определённому условию. После того как данные отправлены в транзакцию, но до того, как она зафиксирована, другая транзакция вставляет в базу данных новые строки, которые удовлетворяют условию и могли бы быть выбраны первой транзакцией. Если транзакция выполняет изменения, считая, что условию удовлетворяют только строки, возвращённые запросом, то фантомное чтение может привести к получению ошибочных данных. Все данные, которые были прочитаны первым запросом, будут возвращены и вторым, но могут быть возвращены и дополнительные данные, поэтому может оказаться, что любые изменения, сделанные на основе исходных результатов, больше не являются корректными.
Полное решение задачи конкурентного доступа заключается в обеспечении наивысшего уровня изоляции для действий различных пользователей, обращающихся к одним и тем же данным. Согласно стандарту SQL92 высший уровень изоляции называется сериализацией (serialization). Сериализуемые транзакции характеризуются предсказуемостью и воспроизводимостью, а это две главных добродетели целостности данных.
Конечно, сделать так, чтобы сервер базы данных поддерживал работу тысяч пользователей и при этом каждый из них считал себя единственным, нелёгкая задача. Но модель MVRC Oracle её решает.
