Насколько Oracle ACID совместим, если он не учитывает свойство «изоляции» полностью? - PullRequest
Новая
       84

Насколько Oracle ACID совместим, если он не учитывает свойство «изоляции» полностью?

0 голосов
/ 28 июня 2019

Заявка: Oracle не учитывает свойство изоляции в свойствах ACID.Согласно странице Википедии на ACID

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

Это может произойти, только если транзакции сериализуемы.Да, у Oracle есть уровень транзакции, называемый Serializable, но это не настоящая сериализуемость, а только изоляция моментальных снимков.

Read https://blog.dbi -services.com / oracle-serializable-is-not-serializable / Выдержка из вики-страницы об изоляции моментальных снимков (https://en.wikipedia.org/wiki/Snapshot_isolation)

"Несмотря на отличие от сериализуемости, изоляция моментальных снимков иногда называется Oracle для сериализации".

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

Q1) Поскольку Oracle не предоставляет его (его сериализуемость не является истинной), он не соблюдает изоляцию на 100 процентов.Как тогда это можно назвать ACID-совместимым?

Q2) Похоже, что к Oracle относились здесь снисходительно в отношении изоляции.Распространяется ли эта снисходительность и на другие базы данных?

Q3) Если мы примем неумолимую позицию и скажем (изоляция означает 100-процентную изоляцию - не меньше, она принимается), не пойдет ли утверждение Oracle на совместимость с ACIDкуски?А как насчет других реляционных баз данных?Смогут ли они сделать сокращение или потерпят неудачу, как Oracle?

1 Ответ

0 голосов
/ 28 июня 2019

SQL Server имеет SERIALIZABLE в дополнение к SNAPSHOT.Но, по крайней мере в SQL Server, для большинства практических целей SERIALIZABLE бесполезен, так как он слишком дорогой и не очень эффективен.И вы используете специальные конструкции для нескольких транзакций, которые на самом деле должны быть сериализованы (т.е. выполняются по одному).

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

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

SELECT salary FROM emp where id = 1

изатем вычислите новое значение на основе существующего в клиенте, а затем 

UPDATE emp set salary = :newSalary

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

В Oracle это выполняется с помощью SELECT ... FOR UPDATE и в SQL Server с подсказкой UPDLOCK.Или с явной «блокировкой приложения», DMBS_LOCK от Oracle или sp_getapplock для SQL Server.

...