Блог

Если доступен журнал WAL (повтор), это позволит нам сохранить записи на диске и зафиксировать транзакцию без необходимости предварительного обновления структур данных.

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

Я понимаю этот вопрос так, что нам все еще нужен журнал отмены, потому что:

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

Правильно ли я понимаю, почему нам нужно отменить ведение журнала, даже если журнал повтора существует?

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

Когда вы выполняете изменение, оно записывается на страницы данных, а старая версия страницы записывается в журнал отмены. Изменение также записывается в журнал повтора для восстановления после сбоя. При фиксации единственное, что должно произойти, — это то, что новая версия теперь считается зафиксированной. Копия в журнале отмены может быть запланирована для удаления как мусор, по крайней мере, как только другим параллельным транзакциям она больше не понадобится для их моментального снимка MVCC. На самом деле, в журнале отмены может быть несколько версий данной строки, чтобы удовлетворить разные моментальные снимки.

Если бы не было журнала отмены, и все зависело бы от журнала повтора, то последствия были бы:

• Выполнение изменений будет записываться только в журнал повтора. Это небольшое ускорение во время выполнения запроса.
• Но коммиту пришлось бы проделать гораздо больше работы. В принципе, эквивалентная работа, выполняемая во время аварийного восстановления, сверяет записи журнала повтора с существующими страницами и восстанавливает «текущую» зафиксированную версию там.
• Повторное согласование журнала не могло произойти до тех пор, пока не будут завершены все другие одновременные транзакции с возможностью повторного чтения, поскольку им все еще необходимо просмотреть старую версию данных на страницах данных. Это было бы проблемой, учитывая, что журнал повтора имеет фиксированный размер; незавершенная транзакция может привести к заполнению журнала повтора, а затем может быть заблокирована дальнейшая запись (теоретически это может произойти и с журналом отмены, но это занимает намного больше времени).
• Клиенты, которые начинают новые транзакции, будут вынуждены выполнять динамическую сверку журнала повтора со старой страницей данных при каждом чтении, по крайней мере, до тех пор, пока журнал повтора не будет окончательно объединен. Для них это большая напряженная работа, и немного обидно, потому что в базе данных OLTP чаще всего запускаются новые транзакции.

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