WikiDer > Изоляция (системы баз данных)

Эта статья нужны дополнительные цитаты для проверка. Пожалуйста помоги улучшить эту статью к добавление цитат в надежные источники. Материал, не полученный от источника, может быть оспорен и удален. Найдите источники: Системы баз данных "Изоляция" – Новости · газеты · книги · ученый · JSTOR (Январь 2009 г.) (Узнайте, как и когда удалить этот шаблон сообщения)

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

Более низкий уровень изоляции увеличивает возможность одновременного доступа многих пользователей к одним и тем же данным, но увеличивает количество эффектов параллелизма (таких как грязное чтение или потерянные обновления), с которыми могут столкнуться пользователи. И наоборот, более высокий уровень изоляции уменьшает типы эффектов параллелизма, с которыми могут столкнуться пользователи, но требует больше системных ресурсов и увеличивает вероятность того, что одна транзакция заблокирует другую.^[1]

Изоляция обычно определяется на уровне базы данных как свойство, которое определяет, как и когда изменения, внесенные одной операцией, становятся видимыми для других. В старых системах это может быть реализовано системно, например, за счет использования временных таблиц. В двухуровневых системах диспетчер обработки транзакций (TP) необходим для поддержания изоляции. В многоуровневых системах (например, несколько веб-сайтов, пытающихся забронировать последнее место в рейсе) требуется комбинация хранимых процедур и управления транзакциями для подтверждения бронирования и отправки подтверждения клиенту.^[2]

Изоляция - одна из четырех КИСЛОТА свойства, наряду с атомарность, последовательность и долговечность.

Контроль параллелизма

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

Двухфазная блокировка - это наиболее распространенный метод управления параллелизмом транзакций в СУБД, используемый для обеспечения как сериализуемости, так и возможности восстановления для правильности. Чтобы получить доступ к объекту базы данных, транзакция сначала должна получить замок для этого объекта. В зависимости от типа операции доступа (например, чтение или запись объекта) и типа блокировки получение блокировки может быть заблокировано и отложено, если другая транзакция удерживает блокировку для этого объекта.

Читать явления

Стандарт ANSI / ISO SQL 92 относится к трем различным читать явления когда транзакция 1 считывает данные, которые транзакция 2 могла изменить.

В следующих примерах имеют место две транзакции. В первом выполняется Запрос 1. Затем во второй транзакции выполняется и фиксируется запрос 2. Наконец, в первой транзакции снова выполняется запрос 1.

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

Грязные чтения

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

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

В нашем примере транзакция 2 изменяет строку, но не фиксирует изменения. Затем транзакция 1 считывает незафиксированные данные. Теперь, если транзакция 2 откатывает свои изменения (уже прочитанные транзакцией 1) или обновляет различные изменения в базе данных, тогда представление данных может быть неправильным в записях транзакции 1.

/ * Запрос 1 * /ВЫБРАТЬ возраст ИЗ пользователи КУДА я бы = 1;/ * будет читать 20 * /

/ * Запрос 2 * /ОБНОВИТЬ пользователи НАБОР возраст = 21 КУДА я бы = 1;/ * Здесь нет фиксации * /

/ * Запрос 1 * /ВЫБРАТЬ возраст ИЗ пользователи КУДА я бы = 1;/ * будет читать 21 * /

ОТКАТ; / * ГРЯЗНОЕ ЧТЕНИЕ на основе блокировок * /

Но в этом случае не существует строки с идентификатором 1 и возрастом 21.

Неповторяющиеся чтения

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

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

/ * Запрос 1 * /ВЫБРАТЬ * ИЗ пользователи КУДА я бы = 1;

/ * Запрос 2 * /ОБНОВИТЬ пользователи НАБОР возраст = 21 КУДА я бы = 1;СОВЕРШИТЬ; / * в многоверсионном параллелизме   контроль, или на основе блокировки READ COMMITTED * /

/ * Запрос 1 * /ВЫБРАТЬ * ИЗ пользователи КУДА я бы = 1;СОВЕРШИТЬ; / * ПОВТОРНОЕ ЧТЕНИЕ на основе блокировки * /

В этом примере транзакция 2 успешно фиксируется, что означает, что ее изменения в строке с идентификатором 1 должны стать видимыми. Однако транзакция 1 уже видела другое значение для возраст в этом ряду. На уровнях изоляции SERIALIZABLE и REPEATABLE READ СУБД должна возвращать старое значение для второго SELECT. При READ COMMITTED и READ UNCOMMITTED СУБД может вернуть обновленное значение; это неповторимое чтение.

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

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

При использовании метода управления параллелизмом на основе блокировки в режиме изоляции REPEATABLE READ строка с ID = 1 будет заблокирована, таким образом блокируя запрос 2 до тех пор, пока первая транзакция не будет зафиксирована или откат. В режиме READ COMMITTED при втором выполнении запроса 1 возраст изменился.

При мультиверсионном управлении параллелизмом на уровне изоляции SERIALIZABLE оба запроса SELECT видят моментальный снимок базы данных, сделанный в начале транзакции 1. Следовательно, они возвращают одни и те же данные. Однако, если транзакция 2 затем попытается ОБНОВИТЬ эту строку, произойдет сбой сериализации, и транзакция 1 будет вынуждена откатиться.

На уровне изоляции READ COMMITTED каждый запрос видит моментальный снимок базы данных, сделанный в начале каждого запроса. Таким образом, каждый из них видит разные данные для обновленной строки. В этом режиме невозможен сбой сериализации (поскольку не дается никаких обещаний о сериализуемости), и транзакцию 1 не нужно будет повторять.

Фантом читает

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

Это может произойти, когда замки диапазона не приобретаются при выполнении ВЫБРАТЬ ... КУДА операции. фантом читает аномалия - частный случай Неповторяющиеся чтения когда транзакция 1 повторяет ранжированный ВЫБЕРИТЕ ... ГДЕ запрос и, между обеими операциями, транзакция 2 создает (т. е. ВСТАВЛЯТЬ) новые строки (в целевой таблице), которые выполняют это КУДА пункт.

/ * Запрос 1 * /ВЫБРАТЬ * ИЗ пользователиКУДА возраст МЕЖДУ 10 И 30;

/ * Запрос 2 * /ВСТАВЛЯТЬ В пользователи(я бы, имя, возраст) ЗНАЧЕНИЯ (3, 'Боб', 27);СОВЕРШИТЬ;

/ * Запрос 1 * /ВЫБРАТЬ * ИЗ пользователиКУДА возраст МЕЖДУ 10 И 30;СОВЕРШИТЬ;

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

В режиме изоляции SERIALIZABLE запрос 1 приведет к блокировке всех записей с возрастом в диапазоне от 10 до 30, поэтому запрос 2 будет блокироваться до тех пор, пока не будет зафиксирована первая транзакция. В режиме REPEATABLE READ диапазон не будет заблокирован, что позволит вставить запись и второе выполнение запроса 1 для включения новой строки в результаты.

Уровни изоляции

Из четырех КИСЛОТА недвижимость в СУБД (Система управления базами данных) свойство изоляции чаще всего ослабляется. При попытке поддерживать наивысший уровень изоляции СУБД обычно получает замки на данных, которые могут привести к потере параллелизм, или орудия мультиверсионный контроль параллелизма. Это требует добавления логики для заявление правильно функционировать.

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

Поскольку каждый уровень изоляции сильнее, чем нижеприведенные, поскольку ни один из более высоких уровней изоляции не допускает действие, запрещенное более низким, стандарт разрешает СУБД выполнять транзакцию на более высоком уровне изоляции, чем запрошенный (например, «Чтение подтверждено» транзакция может фактически выполняться на уровне изоляции «Повторяющееся чтение»).

Уровни изоляции, определенные ANSI/ISO SQL Стандартные перечислены ниже.

Сериализуемый

Это наибольший уровень изоляции.

С замком на основе контроль параллелизма Внедрение СУБД, сериализуемость требует, чтобы блокировки чтения и записи (полученные для выбранных данных) были сняты в конце транзакции. Также замки дальности должен быть приобретен, когда ВЫБРАТЬ запрос использует ранжированный КУДА пункт, особенно во избежание фантом читает явление.

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

Источник: (Второй проект неофициального обзора) ISO / IEC 9075: 1992, Язык баз данных SQL - 30 июля 1992 г .:Гарантированно сериализуемое выполнение параллельных SQL-транзакций на уровне изоляции SERIALIZABLE. Сериализуемое выполнение определяется как выполнение операций одновременного выполнения SQL-транзакций, которые производят тот же эффект, что и некоторое последовательное выполнение тех же самых SQL-транзакций. Последовательное выполнение - это то, при котором каждая SQL-транзакция выполняется до завершения до начала следующей SQL-транзакции.

Повторяющиеся чтения

На этом уровне изоляции блокировка на основе контроль параллелизма Реализация СУБД сохраняет блокировки чтения и записи (полученные для выбранных данных) до конца транзакции. Тем не мение, замки дальности не управляются, поэтому фантом читает может случиться.

На этом уровне изоляции возможен перекос при записи, явление, когда две записи разрешены в один и тот же столбец (столбцы) в таблице двумя разными авторами (которые ранее читали столбцы, которые они обновляют), в результате чего столбец имеет данные, которые сочетание двух транзакций.^[3][4]

Прочитано совершено

На этом уровне изоляции блокировка на основе контроль параллелизма Реализация СУБД сохраняет блокировки записи (полученные для выбранных данных) до конца транзакции, но блокировки чтения снимаются, как только ВЫБРАТЬ операция выполняется (поэтому явление неповторимого чтения может происходить на этом уровне изоляции). Как и на предыдущем уровне, замки дальности не управляются.

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

Читать незафиксированные

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

Уровень изоляции по умолчанию

В уровень изоляции по умолчанию разных СУБДs варьируется довольно широко. Большинство баз данных, в которых есть транзакции, позволяют пользователю устанавливать любой уровень изоляции. Некоторым СУБД также требуется дополнительный синтаксис при выполнении оператора SELECT для получения блокировок (например, ВЫБРАТЬ ... ДЛЯ ОБНОВЛЕНИЯ для получения исключительных блокировок записи для строк, к которым осуществляется доступ).

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

В этой статье показан ряд слабых мест аномального подхода к определению уровней изоляции. Три феномена ANSI неоднозначны, и даже в их самых вольных интерпретациях не исключаются некоторые аномальные поведения ... Это приводит к некоторым противоречащим интуиции результатам. В частности, уровни изоляции на основе блокировки имеют другие характеристики, чем их эквиваленты в ANSI. Это сбивает с толку, поскольку коммерческие системы баз данных обычно используют реализации блокировки. Кроме того, явления ANSI не различают несколько типов поведения на уровне изоляции, которые популярны в коммерческих системах.^[5]

Есть и другие критические замечания относительно определения изоляции ANSI SQL, поскольку оно побуждает разработчиков делать «плохие вещи»:

... он тонко полагается на предположение, что для управления параллелизмом используется схема блокировки, в отличие от оптимистичной или многоверсионной схемы параллелизма. Это означает, что предлагаемая семантика неопределенный.^[6]

Уровни изоляции, явления чтения и блокировки

Уровни изоляции против явлений чтения

'+' - невозможно
'-' - возможный

Аномалия Serializable - это не то же самое, что Serializable. То есть необходимо, но недостаточно, чтобы в сериализуемом расписании не было всех трех типов явлений.^[5]

Смотрите также

• Атомарность
• Последовательность
• Долговечность
• Замок (база данных)
• Оптимистичный контроль параллелизма
• Система управления реляционной базой данных
• Изоляция снимков

Рекомендации

внешняя ссылка

• Концепции Oracle® Database, Глава 13 Параллелизм и согласованность данных, предотвращаемые явления и уровни изоляции транзакций
• Справочник Oracle® Database SQL, Глава 19 Операторы SQL: СОХРАНИТЬ ДЛЯ ОБНОВЛЕНИЯ, УСТАНОВИТЬ СДЕЛКУ
• в JDBC: Поля констант подключения, Connection.getTransactionIsolation (), Connection.setTransactionIsolation (число)
• в Spring Framework: @Transactional, Изоляция
• П. Байлис. Когда "КИСЛОТА" КИСЛОТА? Редко