Oracle DB: SELECT может генерировать REDO
Версия от 13:36, 18 января 2023; Admin (обсуждение | вклад)
Здесь я описал то как я понял статью, ссылка на которую указана ниже.
Договоримся о терминах:
- Транзакция - то что изменяет данные (INSERT,UPDATE,DELETE,MERGE)
- Запрос - то что только читает данные (SELECT)
Последовательность событий приводящая к записи блоков в REDO запросом SELECT:
- Выполняется большая транзакция над таблицей T1, которая занимает более 10% всего буферного кэша.
- При выполнении COMMIT, для повышения производительности в REDO сбрасывается сначала первые 10% блоков буферного кэша, при этом с них снимается блокировка. Остальные блоки транзакции в буферном кэше еще находятся в состоянии блокировки INACTIVE. Данная ситуация называется COMMIT DELAY.
- Сразу после COMMIT выполняется SELECT над всей таблицей T1, когда транзакция еще находится в состоянии COMMIT DELAY. SELECT видит, что нужные ему блоки уже находятся в буферном кэше и операций чтения с диска не происходит. Разблокированные блоки используются без проблем. При обращении к заблокированным INACTIVE блокам в буферном кэше, SELECT не ждет их разблокировки, а сам снимает ее изменяя заголовок. Т.к. это изменение, то блок скидывается в REDO.
- Когда COMMIT транзакции завершается, остальные блоки сбрасываются в REDO (предположительно повторно)
Таким образом, получается что SELECT сбрасывает в REDO лишние блоки данных. Для восстановления базы данных они не используются, т.к. связаны с изменением в буферном кэше, а не в файлах данных.
Ссылки по теме: