Рубрики

Восстанавливаемость в СУБД

Необходимое условие:

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

Восстанавливаемые графики:

  • Расписания, в которых транзакции фиксируются только после того, как все транзакции, изменения которых они читают, фиксируются, называются восстанавливаемыми расписаниями. Другими словами, если некоторая транзакция T j считывает значение, обновленное или записанное другой транзакцией T i , то фиксация T j должна произойти после фиксации T i .
    Пример 1:
    S1: R1(x), W1(x), R2(x), R1(y), R2(y), 
             W2(x), W1(y), C1, C2; 

    Данный график следует порядку Ti-> Tj => C1-> C2 . Транзакция T1 выполняется до T2, следовательно, нет вероятности возникновения конфликта. R1 (x) появляется перед W1 (x), и транзакция T1 фиксируется перед T2, то есть завершение первой транзакции выполнило первое обновление элемента данных x, следовательно, данное расписание подлежит восстановлению.

    Пример 2. Рассмотрим следующий график, включающий две транзакции T 1 и T 2 .

    T1T2
    R(A)
    W(A)
    W(A)
    R(A)
    commit
    commit


    Это восстанавливаемый график, поскольку T 1 фиксируется до T 2 , что делает значение, считываемое T 2, правильным.

Неустранимый график:

  • В таблице ниже показано расписание с двумя транзакциями: T1 читает и записывает A, а это значение считывается и записывается T2. Т2 совершает. Но позже, T1 терпит неудачу. Таким образом, мы должны откат T1. Поскольку T2 прочитал значение, записанное T1, его также следует откатить. Но мы уже совершили это. Так что этот график невосполнимый график. Когда Tj читает значение, обновленное Ti, и Tj фиксируется перед фиксацией Ti, расписание будет необратимым.

Восстанавливаемый с каскадным откатом:

  • В таблице ниже показано расписание с двумя транзакциями: T1 читает и записывает A, а это значение считывается и записывается T2. Но позже, T1 терпит неудачу. Таким образом, мы должны откат T1. Поскольку T2 прочитал значение, записанное T1, его также следует откатить. Поскольку он еще не зафиксирован, мы также можем откатить T2. Так что это можно восстановить с помощью каскадного отката. Поэтому, если Tj считывает значение, обновленное Ti, и принятие Tj задерживается до принятия Ti, расписание называется восстанавливаемым с каскадным откатом.

Восстанавливаемый откат без каскада:

  • В приведенной ниже таблице показано расписание с двумя транзакциями, T1 читает и записывает A и фиксирует, и это значение считывается T2. Но если T1 терпит неудачу перед фиксацией, никакая другая транзакция не прочитала его значение, поэтому нет необходимости откатывать другую транзакцию. Так что это безкаскадный восстановительный график. Таким образом, если Tj считывает значение, обновленное Ti, только после фиксации Ti, расписание будет восстановлено без каскада.

Вопрос: Какой из следующих сценариев может привести к неисправимой ошибке в системе базы данных?

  1. Транзакция записывает элемент данных после того, как он прочитан незафиксированной транзакцией.
  2. Транзакция считывает элемент данных после того, как он прочитан незафиксированной транзакцией.
  3. Транзакция читает элемент данных после того, как он записан совершенной транзакцией.
  4. Транзакция читает элемент данных после того, как он записан незафиксированной транзакцией.

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

Эта статья предоставлена Sonal Tuteja . Пожалуйста, напишите комментарии, если вы обнаружите что-то неправильное, или вы хотите поделиться дополнительной информацией по обсуждаемой теме

Рекомендуемые посты:

Восстанавливаемость в СУБД

0.00 (0%) 0 votes