Откат и планирование в базе данных?

Ответ 1

Ну в общем, и по умолчанию читатели не блокируют писателей, а авторы не блокируют читателей.

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

Исходя из этого

• T1 может писать (y), потому что никакой другой сеанс не записывается в y, а затем удерживает блокировку y
• T2 никогда не пишет, поэтому никогда не блокируется.
• T3 пытается записать (y) после того, как T1 имеет, поэтому блокируется.
• T4 пишет (x), а чтение T5 на x не влияет на это.
• T5 попытка записи y блокируется блокировкой, выполняемой T1.

Однако это не должно быть причиной отката и не предполагает, чтобы явные коммиты или откаты не выдавались.

Ответ 2

Дело в том, что "читатели не блокируют писателей, а писатели не блокируют читателей", как указано @DavidAldridge. Транзакция 3 будет ждать транзакции 1, а транзакция 5 будет ожидать транзакции 1 и 3. Они могут либо долго ждать, ждать в течение n секунд или вообще не ждать, в зависимости от параметра, установленного для БД, В Oracle это как работает.

Ребята, так как это спорный вопрос, я возьму на себя логику и проследую.

Это много говорит о толковании и пытается придерживаться того, что дано. Данная информация здесь: TIMESTAMP ORDERING для управления concurrency. Затем он дает нам: T1, T2 до T5. Затем я предполагаю, что T1 на первом месте, затем T2 и т.д., Потому что транзакции всегда были сериализованы: один за другим, на основе их TIMESTAMP. Я думаю, что для того, чтобы можно было предположить, что "T5 Read (x)" является первой транзакцией только из-за способа размещения текста, добавляет информацию, которая просто не существует. Он говорит, что TIMESTAMP ORDERING и дает вам T1, T2... логика говорит, что один идет за другим. Никакая транзакция не откатывается, они просто ждут, а не только потому, что одна транзакция может содержать блокировку, а другая также пытается получить блокировку, что автоматически будет откат. В транзакции Oracle только автоматический откат в случае взаимоблокировок. Поскольку это не похоже на то, что откат не выполняется.

Ответ 3

Я думаю, вы сбиваете с толку всех здесь с тегом оракула. Я думаю, вам нужен алгоритм concurrency control на основе временной метки, основанный на первой строке вашего вопроса, которая является довольно распространенным алгоритмом для управления concurrency в теории информатики.

Легче понять ссылку.

Кроме того, использование отката неверно, так как транзакции не откатываются, а перезапускаются. (Это также происходит в oracle)

Алгоритм работает так:

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

На основании этого давайте нашим транзакциям отметку времени, например t = 1,2,3,4,5...

• T5 начинается с t = 1.
• T2 начинается с t = 2.
• T1 начинается с t = 3.
• T3 начинается с t = 4.
• T4 начинается с t = 5
• T5 имеет другую операцию при t = 6, но метка времени по-прежнему равна t = 1, поскольку временная метка назначается на основе того, когда транзакция началась.

Перемещение,

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

В начале обе X и Y имеют отметку времени записи и записи как 0.

Запрос на чтение обрабатывается следующим образом:

If TS < W-ts(x) then
    reject read request and abort corresponding transaction
    else
    execute transaction
    Set R-ts(x) to max{R-ts(x), TS}

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

  If TS < R-ts(x) or TS < W-ts(x) then
   reject write request
   else
   execute transaction
   Set W-ts(x) to TS. 

Пройдите через наши объекты и примените эти правила.

• T5 запускается и читает X. TS ₅= 1. WTS (X) = 0. Идет нормально. Установите RTS (x) = 1.
• T2 запускается и читается Y. TS ₂= 2. WTS (Y) = 0. Идет нормально. Установите RTS (Y) = 2.
• T1 запускается и записывается в Y. TS ₁= 3. RTS (Y) = 1. WTS (Y) = 0. Записать завершение. Установите WTS (Y) = 3.
• T3 запускается и записывается в Y. TS ₃= 4. RTS (Y) = 1. WTS (Y) = 3. Записать завершение. Установите WTS (Y) = 4.
• T4 запускается и записывается в X. TS ₄= 5. RTS (x) = 1. WTS (x) = 0. Запись завершается. Установите WTS (x) = 5.
• T5 записывает (y). TS ₅= 1. RTS (y) = 1. WTS (y) = 4. TS ₅ < WTS (y). Транзакция отменяется и перезапускается с новой меткой времени. (Вероятно, t = 7)

Таким образом, это дает нам ответ, отличный от вашего TA, который только T5 откатывается и перезапускается.

Я хотел бы исправить ошибки и узнать, почему T4 и T1 были прерваны и перезапущены.

Ответ 4

Вместо того, чтобы пытаться объяснить это своими словами, вот полезная ссылка MSDN, которая показывает вам ROLLBACK TRANSACTION и как она работает.

https://msdn.microsoft.com/en-us/library/ms181299.aspx?f=255&MSPPError=-2147217396

любые проблемы не стесняйтесь спрашивать меня.

Ответ 5

Что касается блокировок, это зависит от уровня изоляции, установленного в вашей БД.

Microsoft на уровнях изоляции:

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

Источник: https://technet.microsoft.com/en-us/library/ms189122(v=sql.105).aspx

например. если ваш уровень изоляции установлен на REPEATABLE READ:

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

Источник: https://technet.microsoft.com/en-us/library/ms173763(v=sql.105).aspx