(Oracle) Возможен ли откат после COMMIT (UNDO Segment?)?

Question

[KTG]

Вычитал что есть некий UNDO-сегмент, но не могу найти информацию как с ним работать.

Нужно обновить на боевой базе данные в 3 таблицах по большой выборке.
Хотелось бы иметь возможность отката.

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

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

Пяток ораклистов из контакт-листа опросил - вытаращили глаза, говорят первый раз слышим.

Answer 1

[Евгений]

Есть Flashback. Много чего умеет, в том числе Flashback Transaction. Возможно вам подойдет.

Comments

[KTG]

Спасибо почитаю.
Но на текущей базе он отключен.

Answer 2

[Saboteur]

undo нужен самому ораклу как раз для того, чтобы хранить все изменения до Commit, и следовательно было можно их откатить до commit-а, либо в случае если система грохнулась (опять таки до коммита).

В оракле есть arclogs, то есть обычный журнал транзакций. Используя его и используя бэкап, можно восстановить копию и докатить ее до определенного состояния используя эти arclogs (зависит от объема и когда был сделан бэкап).

В вашем случае действительно flashback может помочь.
Переводите Оракл в flasback режим, создаете grp (guarantee restore point) и выполняете любые действия. Если что не так - flashback to restore point.

Перевод оракл в flashback и обратно и флешбек на рестор поинт, в отличие от восстановления из бэкапа, очень быстрая операция.
А создание GRP вообще мгновенно и онлайн.
Но в режиме flashback генерятся дополнительные логи.

Обычно flashback удобен в девелопмент базе, или во время релиза.

Comments

[Евгений]

Замечу, что что guarantee restore point уронит (или "заморозит", не помню точно) экземпляр БД, если кончится место, отведенное под логи. Поэтому как вариант можно указать адекватный DB_FLASHBACK_RETENTION_TARGET.

[KTG]

почитаю поподробнее про flashback. спасибо.

А по UNDO, я думал это уже другой сегмент. До коммита вроде как есть ROLLBACK сегмент.
Вернее да же так (как я понимаю), после коммита, можно все ещё использовать механизм роллбэк.

Если транзакция, которая сгенерировала данные отмены, не активна (зафиксирована), то данные отмены считаются зафиксированными (commited). Зафиксированные данные отмены могут быть либо устаревшими (expired), либо не устаревшими (unexpired). Устаревшие данные могут быть переписаны новыми транзакциями.Oracle постарается сохранить не устаревшие данные как можно дольше, в пределах ограничений пространства отмены. Когда не останется места в табличном пространстве отмены для новых транзакций, Oracle в конечном итоге перепишет не устаревшие данные, в зависимости от того, как сконфигурирован параметр UNDO_RETENTION.

Источник

и

Перед выполнением COMMIT Oracle генерирует логи данных отмены (undo) и повторного выполнения (redo) (они могут быть даже записаны на диск). При выполнении оператора COMMIT таблицы транзакций redo-записей отмечаются SCN (англ. system change number, «номер изменения системы»), буферы redo-журнала сбрасываются на диск (на этом этапе транзакция считается завершённой), освобождаются блокировки, а транзакция отмечается как завершённая

источник

[Freeman]

KTG, раньше, до 9-й (или 8-й?) версии Oracle были отдельные сегменты отката, которые надо было создавать и админить вручную. Позже этот процесс автоматизировали, передали самой СУБД и свели к особому табличному пространству отката.