11. Параллелизм и согласованность данных

В этой главе объясняется, как Oracle поддерживает согласованность данных в многопользовательской среде БД.

Введение в параллелизм (Concurrency) и согласованность (Consistency) данных

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

Многопользовательская база данных должна обеспечивать следующее:

• гарантировать, что пользователи могут получать доступ к данным одновременно (параллелизм данных)

• гарантировать, что каждый пользователь видит согласованное представление данных (data consistency), включая видимые изменения, внесенные в результате собственных транзакций пользователя и совершенных транзакций других пользователей

Чтобы описать согласованное поведение транзакций при одновременном выполнении транзакций, исследователи БД определили модель изоляции транзакций, называемую сериализуемостью. Сериализуемая транзакция выполняется в среде, которая создает впечатление, что никакие другие пользователи не изменяли данные в БД.

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

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

Согласованность многоверсионного чтения

В БД Oracle мультиверсионность – это возможность одновременной материализации нескольких версий данных. БД Oracle поддерживает согласованность чтения в нескольких версиях.

Запросы к базе данных Oracle обладают следующими характеристиками:

• Запросы, согласованные с чтением
  Данные, возвращаемые запросом, фиксируются и непротиворечивы для одного момента времени.
  Примечание: БД Oracle никогда не разрешает грязное чтение, которое происходит, когда транзакция считывает данные, незафиксированные в другой транзакции.
  Чтобы проиллюстрировать проблему с грязным чтением, предположим, что одна транзакция обновляет значение столбца без фиксации. Вторая транзакция считывает обновленное и грязное (незафиксированное) значение. Первый сеанс откатывает транзакцию, так что столбец сохраняет свое старое значение, но вторая транзакция продолжается, используя обновленное значение, повреждая БД. Грязные операции чтения нарушают целостность данных, нарушают внешние ключи и игнорируют уникальные ограничения.

• Неблокирующие запросы
  Устройства чтения и записи данных не блокируют друг друга.

Согласованность чтения уровня выражений

БД Oracle всегда обеспечивает согласованность чтения на уровне инструкций, что гарантирует, что данные, возвращаемые одним запросом, зафиксированы и непротиворечивы в течение одного момента времени.

Момент времени, до которого один оператор SQL является согласованным, зависит от уровня изоляции транзакции и характера запроса:

• На уровне изоляции зафиксированного чтения (read commited) этот момент является временем, в которое была открыта инструкция. Например, если оператор SELECT открывается в SCN 1000, то этот оператор соответствует SCN 1000.

• В сериализуемой транзакции (доступной только для чтения), этот момент является временем начала транзакции. Например, если транзакция начинается с SCN 1000, и если в этой транзакции встречается несколько инструкций SELECT, то каждая инструкция соответствует SCN 1000.

• В операции ретроспективного запроса (SELECT … AS OF), оператор SELECT явно указывает момент времени. Например, вы можете запросить таблицу в том виде, в каком она появилась в прошлый четверг в 14:00.

Согласованность чтения уровня транзакций

БД Oracle также может обеспечивать согласованность чтения для всех запросов в транзакции, известную как согласованность чтения на уровне транзакции.

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

Запросы, выполняемые сериализуемой транзакцией, видят изменения, внесенные самой транзакцией. Например, транзакция, которая обновляет сотрудников, а затем запрашивает сотрудников, увидит обновления. Согласованность чтения на уровне транзакции обеспечивает повторяемые чтения и не подвергает запрос фантомным чтениям.

Согласованность чтения и Undo-сегменты

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

БД Oracle обеспечивает согласованность чтения за счет данных Undo.

Всякий раз, когда пользователь изменяет данные, база данных Oracle создает записи Undo, которые она записывает в сегменты Undo. Сегменты Undo содержат старые значения данных, которые были изменены незафиксированными или недавно зафиксированными транзакциями. Таким образом, в БД может существовать несколько версий одних и тех же данных, все в разные моменты времени. БД может использовать моментальные снимки данных в разные моменты времени, чтобы обеспечить согласованное с чтением представление данных и включить неблокирующие запросы.

Согласованность чтения гарантируется в средах с одним экземпляром и Oracle Real Application Clusters (Oracle RAC). Oracle RAC использует механизм передачи блоков из кэша в кэш, известный как cache fusion, для передачи совместимых с чтением образов блоков данных из одного экземпляра БД в другой.

Согласованность чтения: пример

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

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

БД использует внутренний механизм упорядочения, называемый SCN (System Change Number. Примитив упорядочивания БД. Значение SCN – это логический момент времени, в который вносятся изменения в БД), чтобы гарантировать порядок транзакций. Когда оператор SELECT переходит в фазу выполнения, БД определяет SCN, записанный в момент начала выполнения запроса. На рисунке 11-1 этот SCN равен 10023. Запрос видит только зафиксированные данные в отношении SCN 10023.

На рисунке 11-1 блоки со SCN после 10023 указывают на измененные данные, как показано двумя блоками с SCN 10024. Для инструкции SELECT требуется версия блока, которая соответствует зафиксированным изменениям. БД копирует текущие блоки данных в новый буфер и применяет данные отмены для восстановления предыдущих версий блоков. Эти восстановленные блоки данных называются клонами согласованного чтения (CR, consistent read).

На рисунке 11-1 БД создает два клона CR: один блок, соответствующий SCN 10006, и другой блок, соответствующий SCN 10021. БД возвращает восстановленные данные для запроса. Таким образом, БД Oracle предотвращает грязное чтение.

Согласованность чтения и список заинтересованных транзакций (ITL – interested transaction list)

Заголовок блока каждого блока сегмента содержит список заинтересованных транзакций (ITL).

БД использует ITL для определения того, была ли транзакция незафиксирована, когда БД начала изменять блок.

Записи в ITL описывают, в каких транзакциях заблокированы строки и какие строки в блоке содержат зафиксированные и незафиксированные изменения. ITL указывает на таблицу транзакций в сегменте Undo, которая предоставляет информацию о моментах внесения изменений в БД.

В некотором смысле заголовок блока содержит недавнюю историю транзакций, которые повлияли на каждую строку в блоке. Параметр INITRANS инструкций CREATE TABLE и ALTER TABLE управляет объемом сохраняемой истории транзакций.

Согласованность чтения и отложенные вставки

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

Отложенная вставка использует подсказку MEMOPTIMIZER_WRITE для вставки в таблицу, указанную как MEMOPTIMIZER FOR WRITE. БД буферизует эти вставки в большом пуле, а не в буферном кэше. БД не отслеживает изменения с помощью Undo. Вместо этого БД автоматически фиксирует изменения, когда координатор управления пространством (SMCO) записывает буфер на диск. Изменения не могут быть отменены.

Отложенные вставки отличаются от обычных важным образом:

• Данные, находящиеся в большом пуле, который, как предполагает приложение, зафиксирован, могут быть потеряны. Например, экземпляр БД может выйти из строя до того, как изменения будут сохранены на диске, даже если приложение сообщает, что изменения сохранены.

• Считывание данных непосредственно из памяти запрещено. Программа записи не может прочитать свои собственные изменения до тех пор, пока фоновые процессы не запишут их на диск. Ни один читатель не сможет увидеть зафиксированные изменения до тех пор, пока они не будут записаны на диск.

Клиентские приложения, которые должны избегать потери данных, должны сохранять локальную копию данных после записи в большой пул. Клиент может использовать пакет DBMS_MEMOPTIMIZER для отслеживания длительности операций записи в память и пакет DBMS_MEMOPTIMIZE_ADMIN для принудительной записи БД на диск.

Механизм блокирования

Как правило, многопользовательские БД используют ту или иную форму блокировки данных для решения проблем, связанных с параллелизмом, согласованностью и целостностью данных.

Блокировка – это механизм, предотвращающий деструктивное взаимодействие между транзакциями, обращающимися к одному и тому же ресурсу.

Уровни изоляции транзакций ANSI/ISO

Стандарт SQL, который был принят как ANSI, так и ISO/IEC, определяет четыре уровня изоляции транзакций. Эти уровни оказывают различное влияние на пропускную способность обработки транзакций.

Эти уровни изоляции определяются в терминах явлений, которые необходимо предотвращать между одновременно выполняемыми транзакциями. К предотвращаемым явлениям относятся:

• Грязное считывание
  Транзакция считывает данные, которые были записаны другой транзакцией, которая еще не была зафиксирована.

• Неповторяемое (нечеткое) считывание
  Транзакция перечитывает данные, которые она ранее прочитала, и обнаруживает, что другая зафиксированная транзакция изменила или удалила данные. Например, пользователь запрашивает строку, а затем позже запрашивает ту же строку, только чтобы обнаружить, что данные изменились.

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

Стандарт SQL определяет четыре уровня изоляции в терминах явлений, с которыми может столкнуться транзакция, выполняющаяся на определенном уровне изоляции. В таблице 11-1 приведены уровни.

Таблица 11-1 Феномены считывания, предотвращаемые уровнем изоляции

БД Oracle Database предлагает уровни изоляции: зафиксированного считывания (по умолчанию) и сериализуемый. Кроме того, БД предлагает режим только для чтения.

Обзор уровней изоляции транзакций БД Oracle

Стандарт ANSI для уровней изоляции транзакций определяется в терминах явлений, которые либо разрешены, либо предотвращены для каждого уровня изоляции.

БД Oracle обеспечивает следующие уровни изоляции транзакций:

• Уровень изоляции зафиксированного считывания

• Уровень изоляции сериализуемый

• Уровень изоляции, доступный только для чтения

Уровень изоляции зафиксированного считывания

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

Этот уровень изоляции установлен по умолчанию. Это подходит для сред БД, в которых вероятность конфликта между несколькими транзакциями невелика.

Запрос в транзакции зафиксированного считывания позволяет избежать чтения данных, которые фиксируются во время выполнения запроса. Например, если запрос находится на середине сканирования таблицы с миллионом строк, и если другая транзакция фиксирует обновление строки 950 000, то запрос не видит этого изменения при чтении строки 950 000. Однако, поскольку БД не запрещает другим транзакциям изменять данные, считываемые запросом, другие транзакции могут изменять данные между выполнением запроса. Таким образом, транзакция, которая дважды выполняет один и тот же запрос, может столкнуться с нечеткими считываниями и фантомными считываниями.

Согласованность чтения на уровне изоляции зафиксированного считывания

БД предоставляет согласованный набор результатов для каждого запроса, гарантируя согласованность данных без каких-либо действий со стороны пользователя.

Неявному запросу, такому как запрос, подразумеваемый предложением WHERE в инструкции UPDATE, гарантируется согласованный набор результатов. Однако каждый оператор в неявном запросе не видит изменений, внесенных самим оператором DML, но видит данные такими, какими они существовали до внесения изменений.

Если список SELECT содержит функцию PL/SQL, то БД применяет согласованность чтения на уровне инструкции для SQL, выполняемого в коде функции PL/SQL, а не на родительском уровне SQL. Например, функция может получить доступ к таблице, данные которой изменены и зафиксированы другим пользователем. Для каждого выполнения SELECT в функции создается новый моментальный снимок, совместимый с чтением.

Конфликтующие записи в транзакциях зафиксированного считывания

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

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

Возможны следующие варианты:

• Если блокирующая транзакция откатывается, то ожидающая транзакция переходит к изменению ранее заблокированной строки, как если бы другая транзакция никогда не существовала.

• Если блокирующая транзакция фиксируется и снимает свои блокировки, то ожидающая транзакция переходит к запланированному обновлению вновь измененной строки.

В следующей таблице показано, как транзакция 1, которая может быть либо сериализуемой, либо зафиксированного считывания, взаимодействует с транзакцией 2, зафиксированного считывания. Это показывает классическую ситуацию, известную как потерянное обновление. Обновление, внесенное транзакцией 1, отсутствует в таблице, даже несмотря на то, что транзакция 1 зафиксировала его. Разработка стратегии обработки потерянных обновлений является важной частью разработки приложений.

Таблица 11-2 Конфликтующие записи и потерянное обновление в транзакциях зафиксированного считывания

Уровень изоляции сериализуемый

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

Сериализуемая транзакция выполняется в среде, которая создает впечатление, что никакие другие пользователи не изменяли данные в БД. Сериализуемая изоляция подходит для различных сред:

• С большими БД и короткими транзакциями, которые обновляют всего несколько строк

• Где вероятность того, что две одновременные транзакции изменят одни и те же строки, относительно невелика

• Где относительно длительные транзакции в основном доступны только для чтения

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

БД Oracle разрешает сериализуемой транзакции изменять строку только в том случае, если изменения в строке, внесенные другими транзакциями, уже были зафиксированы на момент начала сериализуемой транзакции. БД выдает ошибку, когда сериализуемая транзакция пытается обновить или удалить данные, измененные другой транзакцией, которая была зафиксирована после начала сериализуемой транзакции:

ORA-08177: Cannot serialize access for this transaction

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

• Закоммитить выполненную работу до этого момента

• Произвести дополнительные (но отличающиеся) инструкции, возможно, после отката к точке сохранения, установленной ранее в транзакции

• Откатить всю транзакцию

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

Таблица 11-3 Сериализуемая транзакция

Уровень изоляции, доступный только для чтения

Уровень изоляции только для чтения аналогичен сериализуемому уровню изоляции, но транзакции только для чтения не позволяют изменять данные в транзакции, если пользователь не является SYS.

Транзакции, доступные только для чтения, не подвержены ошибке ORA-08177. Транзакции, доступные только для чтения, полезны для создания отчетов, содержимое которых должно соответствовать времени начала транзакции.

БД Oracle обеспечивает согласованность чтения за счет восстановления данных по мере необходимости из Undo-сегментов. Поскольку Undo-сегменты используются циклически, БД может перезаписывать данные отмены. Длительно работающие отчеты сопряжены с риском того, что данные Undo, необходимые для обеспечения согласованности чтения, могли быть повторно использованы другой транзакцией, что приведет к ошибке snapshot too old. Установка периода хранения Undo, который представляет собой минимальное количество времени, в течение которого БД пытается сохранить старые данные отмены перед их перезаписью, соответствующим образом позволяет избежать этой проблемы.

Обзор механизма блокирования БД Oracle

Блокировка – это механизм, который предотвращает деструктивные взаимодействия.

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

Изложение поведения блокировки

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

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

Блокировки влияют на взаимодействие читателей и писателей. Читатель – это запрос к ресурсу, тогда как писатель – это оператор, изменяющий ресурс. Следующие правила обобщают поведение блокировки БД Oracle для чтения и записи:

• Строка блокируется только при изменении писателем.
  Когда оператор обновляет одну строку, транзакция получает блокировку только для этой строки. Блокируя данные таблицы на уровне строк, БД сводит к минимуму конкуренцию за одни и те же данные. При обычных обстоятельствах (1) БД не увеличивает блокировку строки до уровня блока или таблицы.

• Запись строки блокирует одновременную запись той же строки.
  Если одна транзакция изменяет строку, то блокировка строки не позволяет другой транзакции изменять ту же строку одновременно.

• Читатель никогда не блокирует писателя.
  Поскольку средство чтения строки не блокирует ее, средство записи может изменить эту строку. Единственным исключением является SELECT ... FOR UPDATE, которая представляет собой специальный тип инструкции SELECT, который блокирует строку, которую он считывает.

• Писатель никогда не блокирует читателя.
  Когда писатель изменяет строку, БД использует Undo-данные, чтобы предоставить читателям согласованное представление строки.

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

Использование блокировок

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

Блокировки удовлетворяют следующим важным требованиям к БД:

• Согласованность
  Данные, которые просматривает или изменяет сеанс, не должны изменяться другими сеансами до тех пор, пока пользователь не завершит работу.

• Целостность
  Данные и структуры должны отражать все внесенные в них изменения в правильной последовательности.

БД Oracle обеспечивает параллелизм данных, согласованность и целостность транзакций с помощью своих механизмов блокировки. Блокировка происходит автоматически и не требует никаких действий пользователя.

Необходимость блокировок может быть проиллюстрирована одновременным обновлением одной строки. В следующем примере простое веб-приложение предоставляет конечному пользователю адрес электронной почты сотрудника и номер телефона. Приложение использует инструкцию UPDATE, такую как следующая, для изменения данных:

UPDATE employees
SET    email = ?, phone_number = ?
WHERE  employee_id = ?
AND    email = ?
AND    phone_number = ?

В предыдущей инструкции UPDATE значения электронной почты и номера телефона в предложении WHERE являются исходными, неизмененными значениями для указанного сотрудника. Это обновление гарантирует, что строка, которую изменяет приложение, не была изменена после того, как приложение в последний раз прочитало и отобразило ее пользователю. Таким образом, приложение позволяет избежать проблемы с потерей обновления, при которой один пользователь перезаписывает изменения, внесенные другим пользователем, фактически теряя обновление вторым пользователем (в таблице 11-2 показан пример потерянного обновления).

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

Таблица 11-4 Пример блокировки строки

БД Oracle автоматически получает необходимые блокировки при выполнении SQL-инструкций. Например, прежде чем БД разрешит сеансу изменять данные, сеанс должен сначала заблокировать данные. Блокировка предоставляет сеансу исключительный контроль над данными, так что никакая другая транзакция не сможет изменить заблокированные данные до тех пор, пока блокировка не будет снята.

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

В следующих разделах объясняются концепции, важные для понимания того, как Oracle обеспечивает параллелизм данных.

Режимы блокировок

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

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

Oracle использует два режима блокировки в многопользовательской БД:

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

• Режим разделяемой блокировки
  Этот режим позволяет совместно использовать связанный ресурс в зависимости от выполняемых операций. Несколько пользователей, считывающих данные, могут совместно использовать их, каждый из которых имеет разделяемую блокировку, чтобы предотвратить одновременный доступ пользователя, которому требуется эксклюзивная блокировка. Несколько транзакций могут получать блокировки общего доступа к одному и тому же ресурсу.

Предположим, что транзакция использует SELECT ... FOR UPDATE, чтобы выбрать одну строку таблицы. Транзакция получает эксклюзивную блокировку строки и разделяемую блокировку таблицы для доступа к строкам. Блокировка строки позволяет другим сеансам изменять любые строки, отличные от заблокированной строки, в то время как блокировка таблицы не позволяет сеансам изменять структуру таблицы. Таким образом, БД допускает выполнение как можно большего количества инструкций.

Преобразование и эскалация блокировок

БД Oracle выполняет преобразование блокировки по мере необходимости.

При преобразовании блокировки БД автоматически преобразует блокировку таблицы с меньшим ограничением в блокировку с более высоким ограничением. Например, предположим, что транзакция выдает SELECT ... FOR UPDATE для сотрудника и последующего обновления заблокированной строки. В этом случае БД автоматически преобразует разделяемую блокировку в экслюзивную. Транзакция содержит эксклюзивные блокировки строк для всех строк, вставленных, обновленных или удаленных в рамках транзакции. Поскольку блокировки строк выполняются с наивысшей степенью ограниченности, преобразование блокировок не требуется и не выполняется.

Преобразование блокировок отличается от эскалации блокировок, которая происходит, когда многочисленные блокировки удерживаются на одном уровне детализации (например, строки), а БД поднимает блокировки на более высокий уровень детализации (например, таблица). Если сеанс блокирует много строк в таблице, то некоторые БД автоматически увеличивают блокировки строк до одной таблицы. Количество блокировок уменьшается, но увеличивается ограниченность того, что заблокировано.

БД Oracle никогда не эскалирует блокировоки. Эскалация блокировки значительно увеличивает вероятность взаимоблокировок. Предположим, что система пытается эсколировать блокировки от имени транзакции 1, но не может из-за блокировок, удерживаемых транзакцией 2. Взаимоблокировка создается, если транзакция 2 также требует эскалации блокировки тех же данных, прежде чем она сможет быть продолжена.

Продолжительность блокировки

БД Oracle автоматически снимает блокировку при возникновении какого-либо события, при котором транзакции больше не требуется данный ресурс.

Обычно БД хранит блокировки, полученные операторами в рамках транзакции, на время выполнения транзакции. Эти блокировки предотвращают деструктивные помехи, такие как грязное чтение, потерянные обновления и деструктивный DDL от конкурентных транзакций.

Примечание: Блокировка таблицы, примененная к дочерней таблице из-за неиндексированного внешнего ключа, удерживается на время выполнения инструкции, а не транзакции. Кроме того, пакет DBMS_LOCK позволяет освобождать и распределять пользовательские блокировки по желанию и даже удерживать их за пределами транзакций.

БД Oracle освобождает все блокировки, полученные операторами в транзакции, когда она фиксируется или откатывается. БД Oracle также освобождает блокировки, полученные после точки сохранения, при откате к точке сохранения. Однако только транзакции, не ожидающие ранее заблокированных ресурсов, могут получать блокировки для доступных в настоящее время ресурсов. Ожидающие транзакции продолжают ждать до тех пор, пока исходная транзакция не зафиксируется или полностью не откатится.

Блокировки и взаимоблокировки

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

БД Oracle автоматически обнаруживает взаимоблокировки и устраняет их путем отката одного оператора, вовлеченного в взаимоблокировку, освобождая один набор конфликтующих блокировок строк. БД возвращает соответствующее сообщение транзакции, которая подвергается откату на уровне инструкции. Откат инструкции принадлежит транзакции, которая обнаруживает взаимоблокировку. Обычно сигнализируемая транзакция должна быть явно откатана, но она может повторить операцию отката после ожидания.

В таблице 11-5 показаны две транзакции, находящиеся во взаимоблокировке.

Таблица 11-5 Взаимозаблокированные транзакции

Взаимоблокировки чаще всего возникают, когда транзакции явно переопределяют блокировку БД Oracle по умолчанию. Поскольку БД Oracle не эскалирует блокировки и не использует блокировки чтения для запросов, но использует блокировку на уровне строк (а не на уровне страницы), взаимоблокировки возникают нечасто.

Обзор автоматического блокирования

БД Oracle автоматически блокирует ресурс от имени транзакции, чтобы другие транзакции не могли выполнять что-либо, требующее эксклюзивного доступа к тому же ресурсу.

БД автоматически получает различные типы блокировок с различными уровнями ограниченности в зависимости от ресурса и выполняемой операции.

Примечание: БД никогда не блокирует строки при выполнении простого чтения.

Блокировки БД Oracle разделены на категории, указанные в следующей таблице.

Таблица 11-6 Категории блокировок

Блокировки DML

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

Например, блокировка DML не позволяет двум клиентам приобрести последний экземпляр книги, доступный в онлайн-магазине книг. Блокировки DML предотвращают деструктивное вмешательство одновременных конфликтующих операций DML или DDL.

Операторы DML автоматически получают следующие типы блокировок:

• Строковые блокировки (TX)

• Табличные блокировки (TM)

В следующих разделах аббревиатура в круглых скобках после каждого типа блокировки или режима блокировки является аббревиатурой, используемой в мониторе блокировок Oracle Enterprise Manager. Enterprise Manager может отображать TM для любой блокировки таблицы, а не указывать режим блокировки таблицы (такой, как RS или SRX).

Строковые блокировки (TX)

Строковая блокировка, также называемая TX-блокировкой, – это блокировка одной строки таблицы. Транзакция получает блокировку строки для каждой строки, измененной с помощью INSERT, UPDATE, DELETE, MERGE или SELECT ... FOR UPDATE. Строковая блокировка существует до тех пор, пока транзакция не зафиксируется или не выполнит откат.

Строковая блокировка в первую очередь служат механизмом постановки в очередь для предотвращения изменения одной и той же строки двумя транзакциями. БД всегда блокирует измененную строку в эксклюзивном режиме, так что другие транзакции не могут изменять строку до тех пор, пока транзакция, удерживающая блокировку, не зафиксирует или не откатит ее. Строковая блокировка обеспечивает наилучшую возможную грануляцию блокирования и, таким образом, обеспечивает наилучший параллелизм и пропускную способность.

Примечание: Если транзакция завершается из-за сбоя экземпляра БД, то восстановление на уровне блоков делает строку доступной перед восстановлением всей транзакции.

Если транзакция получает строчную блокировку, то транзакция получает также и блокировку таблицы, содержащей эту строку. Блокировка таблицы предотвращает конфликтующие операции DDL, которые переопределили бы изменения данных в текущей транзакции. На рисунке 11-2 показано обновление третьей строки в таблице. БД Oracle автоматически устанавливает эксклюзивную блокировку на обновленную строку и субэксклюзивную блокировку на таблицу.

Строковые блокировки и параллелизм

Этот сценарий иллюстрирует, как БД Oracle использует блокировки строк для обеспечения параллелизма.

Три сеанса запрашивают одни и те же строки одновременно. Сеансы 1 и 2 продолжают выполнять незафиксированные обновления для разных строк, в то время как сеанс 3 не производит обновлений. Каждый сеанс видит свои собственные незафиксированные обновления, но не незафиксированные обновления любого другого сеанса.

Таблица 11-7 Пример параллелизма данных

Хранилище строковых блокировок

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

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

Когда транзакция завершается, идентификатор транзакции остается в заголовке блока. Если другая транзакция хочет изменить строку, то она использует идентификатор транзакции, чтобы определить, активна ли блокировка. Если блокировка активна, то сеанс запрашивает уведомление о снятии блокировки. В противном случае транзакция получает блокировку.

Табличные блокировки (TM)

Табличная блокировка, также называемая TM-блокировкой, устанавливается транзакцией, когда таблица изменяется с помощью INSERT, UPDATE, DELETE, MERGE, SELECT ... FOR UPDATE или инструкции LOCK TABLE.

Для операций DML требуются блокировки таблиц, чтобы зарезервировать доступ DML к таблице от имени транзакции и предотвратить операции DDL, которые могли бы конфликтовать с транзакцией.

Блокировка таблицы может удерживаться в любом из следующих режимов:

• Строчная разделяемая (RS, row share)
  Эта блокировка, также называемая разделяемой табличной блокировкой (SS), указывает на то, что транзакция, удерживающая блокировку таблицы, заблокировала строки в таблице и намерена их обновить. Разделяемая строчная блокировка – это наименее ограничительный режим блокировки таблицы, обеспечивающий наивысшую степень параллелизма для таблицы.

• Строчная экслюзивная блокировка таблицы (RX)
  Эта блокировка, также называемая суб-эксклюзивной блокировкой таблицы (SX), обычно указывает на то, что транзакция, удерживающая блокировку, обновила строки таблицы или выдала SELECT ... FOR UPDATE. SX-блокировка позволяет другим транзакциям запрашивать, вставлять, обновлять, удалять или блокировать строки одновременно в одной и той же таблице. Таким образом, SX-блокировки позволяют нескольким транзакциям получать одновременные SX-блокировки и RS-блокировки для одной и той же таблицы.

• Разделяемая табличная блокировка (S)
  Разделяемая табличная блокировка, удерживаемая транзакцией, позволяет другим транзакциям запрашивать таблицу (без использования SELECT ... FOR UPDATE), но обновления разрешены только в том случае, если одна транзакция удерживает разделяемую табличную блокировку. Поскольку несколько транзакций могут одновременно удерживать разделяемую табличную блокировку, удержания этой блокировки недостаточно для обеспечения того, чтобы транзакция могла изменять таблицу.

• Эксклюзивная табличная блокировка для разделяемой строки (SRX)
  Эта блокировка, также называемая разделяемо-субэкслюзивной табличной блокировкой (SSX), является более ограничительной, чем разделяемая табличная блокировка. Только одна транзакция одновременно может получить SSX-блокировку для данной таблицы. SSX-блокировка, удерживаемая транзакцией, позволяет другим транзакциям запрашивать таблицу (за исключением SELECT ... FOR UPDATE), но не для обновления таблицы.

• Эксклюзивная табличная блокировка (X)
  Эта блокировка является наиболее ограничительной, запрещающей другим транзакциям выполнять любой тип инструкции DML или накладывать любой тип блокировки на таблицу.

Блокировки и внешние ключи

БД Oracle обеспечивает максимальное управление параллелизмом родительских ключей по отношению к зависимым внешним ключам.

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

Блокировки и неиндексированные внешние ключи

БД получает полную блокировку таблицы для дочерней таблицы, когда в столбце внешнего ключа дочерней таблицы не существует индекса, и сеанс изменяет первичный ключ в родительской таблице (например, удаляет строку или изменяет атрибуты первичного ключа) или объединяет строки в родительскую таблицу.

Когда оба из следующих условий выполняются, БД получает полную блокировку таблицы для дочерней таблицы:

• В столбце внешнего ключа дочерней таблицы не существует индекса.

• Сеанс изменяет первичный ключ в родительской таблице (например, удаляет строку или изменяет атрибуты первичного ключа) или объединяет строки в родительскую таблицу.

Примечание: Вставки в родительскую таблицу не получают блокирующих блокировок таблицы, которые предотвращают DML в дочерней таблице. В случае вставок БД получает блокировку дочерней таблицы, которая предотвращает структурные изменения, но не модификации существующих или вновь добавленных строк.

Предположим, что таблица hr.departments является родительской для hr.employees, которая содержит неиндексированный внешний ключ employees.department_id. На следующем рисунке показан сеанс, изменяющий атрибуты первичного ключа отдела 60 в таблице departments.

На рисунке 11-3 БД получает полную блокировку таблицы для hr.employees во время модификации первичного ключа отдела 60. Эта блокировка позволяет другим сеансам запрашивать таблицу employees, но не обновлять ее. Например, сеансы не могут обновлять телефонные номера сотрудников. Блокировка таблицы для employees снимается сразу после завершения модификации первичного ключа в таблице departments. Если несколько строк в отделах подвергаются изменениям первичного ключа, то блокировка таблицы для employees получается и снимается один раз для каждой строки, измененной в departments.

Примечание: DML в дочерней таблице не требуется табличная блокировка в родительской таблице.

Блокировки и индекированные внешние ключи

БД не получает полной блокировки таблицы для дочерней таблицы, когда столбец внешнего ключа в дочерней таблице индексируется, и сеанс изменяет первичный ключ в родительской таблице (например, удаляет строку или изменяет атрибуты первичного ключа) или объединяет строки в родительскую таблицу.

Блокировка родительской таблицы предотвращает получение транзакциями эксклюзивных табличных блокировок, но не предотвращает DML в родительской или дочерней таблице во время модификации первичного ключа. Эта ситуация предпочтительнее, если изменения первичного ключа происходят в родительской таблице, в то время как обновления происходят в дочерней таблице.

На рисунке 11-4 показана дочерняя таблица employees с индексированным столбцом department_id. Транзакция удаляет отдел 280 из таблицы departments. Это удаление не приводит к тому, что БД получает полную блокировку таблицы employees, как в сценарии, описанном в разделе “Блокировки и неиндексированные внешние ключи”.

Если дочерняя таблица специфицируется, как ON DELETE CASCADE, то удаления из родительской таблицы могут привести к удалениям из дочерней таблицы. Например, удаление отдела 280 может привести к удалению записей от сотрудников для employees в удаленном отделе departments. В этом случае правила ожидания и блокировки такие же, как если бы вы удалили строки из дочерней таблицы после удаления строк из родительской таблицы.

Блокировки DDL

Блокировка словаря данных (DDL) защищает определение объекта схемы, пока текущая операция DDL воздействует на объект или ссылается на него.

Только отдельные объекты схемы, которые изменены или на которые ссылаются, блокируются во время операций DDL. БД никогда не блокирует весь словарь данных.

БД Oracle автоматически получает блокировку DDL от имени любой транзакции DDL, требующей этого. Пользователи не могут явно запрашивать блокировки DDL. Например, если пользователь создает хранимую процедуру, то БД Oracle автоматически получает блокировки DDL для всех объектов схемы, на которые ссылаются в определении процедуры. Блокировки DDL предотвращают изменение или удаление этих объектов до завершения компиляции процедуры.

Эксклюзивные DDL-блокировки

Эксклюзивная DDL-блокировка не позволяет другим сеансам получать блокировку DDL или DML.

Большинство операций DDL требуют эксклюзивных DDL-блокировок для ресурса, чтобы предотвратить деструктивное вмешательство в другие операции DDL, которые могут изменять один и тот же объект схемы или ссылаться на него. Например, DROP TABLE не позволяет удалять таблицу, пока ALTER TABLE добавляет к ней столбец, и наоборот.

Эксклюзивные DDL-блокировки сохраняются на время выполнения инструкции DDL и автоматической фиксации. Во время получения эксклюзивной DDL-блокировки, если другая DDL-блокировка удерживается на объекте схемы другой операцией, то получение ожидает, пока более старая DDL-блокировка не будет снята, а затем продолжается.

Разделяемые DDL-блокировки

Разделяемая DDL-блокировка для ресурса предотвращает деструктивное вмешательство в конфликтующие операции DDL, но допускает параллелизм данных для аналогичных операций DDL.

Например, когда выполняется инструкция CREATE PROCEDURE, содержащая транзакция получает общие блокировки DDL для всех таблиц, на которые ссылаются. Другие транзакции могут одновременно создавать процедуры, которые ссылаются на одни и те же таблицы, и получать одновременные разделяемые DDL-блокировки для одних и тех же таблиц, но ни одна транзакция не может получить эксклюзивную DDL-блокировку для любой таблицы, на которую ссылается.

Разделяемая DDL-блокировка сохраняется на время выполнения инструкции DDL и автоматической фиксации. Таким образом, транзакция, содержащая разделяемую DDL-блокировку, гарантирует, что определение объекта схемы, на который ссылается ссылка, остается постоянным во время транзакции.

Разрушаемые блокировки синтаксического анализа

Блокировка синтаксического анализа удерживается оператором SQL или программным модулем PL/SQL для каждого объекта схемы, на который он ссылается.

Блокировки синтаксического анализа приобретаются таким образом, чтобы связанная общая область SQL могла быть признана недействительной, если объект, на который ссылается ссылка, изменен или удален. Блокировка синтаксического анализа называется разрушаемой блокировкой синтаксического анализа, поскольку она не запрещает какую-либо операцию DDL и может быть нарушена, чтобы разрешить конфликтующие операции DDL.

Блокировка синтаксического анализа устанавливается в общем пуле на этапе синтаксического анализа выполнения инструкции SQL. Блокировка удерживается до тех пор, пока общая область SQL для этого оператора остается в общем пуле.

Системные блокировки

Oracle использует различные типы системных блокировок для защиты внутренних структур БД и памяти. Эти механизмы недоступны для пользователей, поскольку пользователи не имеют никакого контроля над их возникновением или продолжительностью.

Защелки (Latches)

Защелка – это простой низкоуровневый механизм сериализации, который координирует многопользовательский доступ к общим структурам данных, объектам и файлам.

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

• Одновременное изменение несколькими сеансами

• Считывание в одном сеансе во время изменения в другом сеансе

• Перераспределение памяти при ее использовании

Как правило, одна защелка защищает несколько объектов в SGA. Например, фоновые процессы, такие как DBW и LGWR, выделяют память из общего пула для создания структур данных. Чтобы выделить эту память, эти процессы используют защелку для общего пула, которая сериализует доступ, чтобы предотвратить одновременную попытку двух процессов проверить или изменить общий пул. После выделения памяти другим процессам может потребоваться доступ к разделяемым областям пула, таким как библиотечный кэш, который необходим для синтаксического анализа. В этом случае процессы защелкивают только библиотечный кэш, а не весь общий пул.

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

Как правило, процесс Oracle получает защелку на чрезвычайно короткое время при манипулировании структурой данных или просмотре ее. Например, при обработке обновления заработной платы одного сотрудника БД может получать и освобождать тысячи защелок. Реализация защелок зависит от операционной системы, особенно в отношении того, ожидает ли процесс защелки и как долго.

Увеличение защелок означает уменьшение параллелизма. Например, чрезмерно сложные операции синтаксического анализа создают конфликт для блокировки библиотечного кэша. Представление V$LATCH содержит подробную статистику использования защелки для каждой защелки, включая количество раз, когда каждая защелка была запрошена и ожидалась.

Мьютексы

Взаимно-исключаемый объект (мьютекс) – это низкоуровневый механизм, который предотвращает устаревание или повреждение объекта в памяти при обращении к нему параллельных процессов. Мьютекс похож на защелку, но в то время как защелка обычно защищает группу объектов, мьютекс защищает один объект.

Мьютексы предоставляют несколько преимуществ:

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

• Мьютекс потребляет меньше памяти, чем защелка.

• В разделяемом режиме, мьютекс позволяет одновременные ссылки для нескольких сеансов.

Внутренние блокировки

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

БД использует следующие типы внутренних блокировок:

• Блокировки кэша словаря
  Эти блокировки имеют очень короткий срок действия и удерживаются для записей в кэшах словаря, пока эти записи изменяются или используются. Они гарантируют, что анализируемые операторы не увидят несогласованных определений объектов. Блокировки кэша словаря могут быть разделяемыми или эксклюзивными. Разделяемые блокировки снимаются по завершении синтаксического анализа, в то время как эксклюзивные блокировки снимаются по завершении операции DDL.

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

• Блокировки табличного пространства и Undo-сегментов
  Эти блокировки защищают табличные пространства и Undo-сегменты. Например, все экземпляры, обращающиеся к БД, должны согласовать, является ли табличное пространство интерактивным или автономным. Undo-сегменты блокируются, так что только один экземпляр БД может выполнять запись в сегмент.

Обзор ручного блокирования данных

Вы можете вручную переопределить механизмы блокировки БД Oracle по умолчанию.

БД Oracle выполняет блокировку автоматически, чтобы обеспечить параллелизм данных, целостность данных и согласованность чтения на уровне инструкций. Однако переопределение блокировки по умолчанию полезно в таких ситуациях, как следующие:

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

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

Вы можете переопределить автоматическую блокировку БД Oracle на уровне сеанса или транзакции. На уровне сеанса сеанс может установить требуемый уровень изоляции транзакции с помощью инструкции ALTER SESSION. На уровне транзакций транзакции, включающие следующие инструкции SQL, переопределяют блокировку БД Oracle по умолчанию:

• Инструкцией SET TRANSACTION ISOLATION LEVEL

• Инструкцией LOCK TABLE (которая блокироует либо таблицу, либо базовые таблицы, входящие в представление)

• Инструкцией SELECT ... FOR UPDATE

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

Если блокировка БД Oracle по умолчанию переопределена на любом уровне, то администратор БД или разработчик приложения должны убедиться, что переопределяющие процедуры блокировки работают правильно. Процедуры блокировки должны удовлетворять следующим критериям: целостность данных гарантирована, параллелизм данных приемлем, взаимоблокировки невозможны или обрабатываются надлежащим образом.

Обзор блокирования, определяемого пользователем

С помощью служб Oracle Database Lock Management services вы можете определять свои собственные блокировки для конкретного приложения.

Например, вы могли бы создать блокировку для сериализации доступа к журналу сообщений в файловой системе. Поскольку зарезервированная блокировка пользователя – это то же самое, что блокировка БД Oracle, она обладает всеми функциями блокировки БД Oracle, включая обнаружение взаимоблокировок. Пользовательские блокировки никогда не конфликтуют с блокировками БД Oracle, поскольку они идентифицируются с помощью префикса UL.

Службы управления блокировкой БД Oracle доступны с помощью процедур в пакете DBMS_LOCK. Вы можете включать инструкции в блоки PL/SQL, которые:

• Запрашивают блокировку определенного типа

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

• Изменяют тип блокировки

• Снимают блокровку