Может ли оракул разрешить параметр незафиксированного чтения?

Ответ 1

Том дает отличный ответ на этот вопрос: О уровнях изоляции транзакций

Он говорит:

ЧИТАЙТЕ НЕКОТОРЫЕ уровень изоляции позволяет выполнять грязные чтения. База данных Oracle не использует грязные читает, и даже не позволяет им. Основная цель READ UNCOMMITTED уровень изоляции должен обеспечить основанное на стандартах определение, которое позволяет для неблокирующих считываний.

...

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

Дело в том, что грязное чтение не особенность; скорее, это ответственность. В Oracle Database это просто не нужно. Вы получаете все преимущества грязного read-no блокировка - без каких-либо неправильных Результаты.

Ответ 2

Tom Kyte ответ правильный WRT oracle, нет такой вещи, как грязное чтение из-за своей архитектуры Multi-Version Concurrency Control (MVCC).

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

Зачем использовать его вне Oracle? Где нет MVCC (например, MySQL, Ingres), это хитрость, чтобы обойти проблемы блокировки, которые могут замедлить производительность или заставить систему блокировки "запускать" из замков ", если он не настроен должным образом. Точно так же, как вам нужно настроить откат/отмену в Oracle, вам необходимо управлять системой блокировки в базах данных, отличных от MVCC.

Так почему это может быть полезно с Oracle - как повышение производительности для функций только для чтения, где "неправильные данные" маловероятны и крайне несущественны. В MySQL/DB2/Ingres/Informix (не уверен в SQL Server/Sybase) его можно использовать для обхода средства управления блокировкой для повышения производительности.

Здесь пример ситуации, когда чтение не требует согласованности:

• Список всех продуктов

Здесь пример ситуации, когда чтение требует согласованности:

• Список продуктов на складе

Oracle просто даже не задумывается о грязных чтениях и не может быть "добавлена ​​как функция", не теряя при этом никакой пользы от производительности (т.е. для получения грязных данных в Oracle true MVCC-архитектуре потребуется слишком много трюков).

Ответ 3

Объяснение WITH UR: когда дело касается запроса SELECT ONLY (report), нет смысла ждать фиксации. Если вы сообщаете о таблице, которая обновляется, то неважно, получаете вы это обновление или нет. Грязное чтение так же верно, как и данные после фиксации. Подумайте, должен ли запрос попасть в эту заблокированную запись на секунду раньше.

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

Использование WITH UR и других эквивалентов СУБД обеспечивает повышение производительности, так как запросы не ожидают фиксации и не приводит к потере целостности данных.

(ps. Просто настройте мою учетную запись, чтобы я не мог комментировать другие ответы.)

Ответ 4

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

Ответ 5

хорошо, UR означает незафиксированное чтение через границы фиксации других длительных транзакций. Грязное чтение - это старый термин для незафиксированного чтения. Читать в неполных физических страницах в DB2 невозможно, и я надеюсь, что и в Oracle. Я обнаружил, что УСТАНОВИТЬ УРОВЕНЬ ИЗОЛЯЦИИ ЧИТАЙТЕ БЕЗ КОММИТЕТЫ, Похоже, это возможно и в Oracle. С точки зрения получения согласованности я предпочитаю READ UNCOMMITTED, потому что CS может генерировать сериализованные разные возвраты одной таблицы из-за недостижения значений. Это не могло быть запрошено отчетом или дампом. Например. Если вы хотите знать - теоретические - значения транзакций, которые будут совершены позже, тоже..

https://docs.oracle.com/javadb/10.6.2.1/ref/rrefsqlj41180.html