Oracle UNDO vs REDO: The Difference, Explained

Undo stores what a row looked like before your change, powering rollback and read consistency. Redo records every change for crash recovery. They sound similar but solve opposite problems — and undo itself generates redo, which is the detail that catches people out.

Two logs, two different jobs

Undo and redo are Oracle's two change-tracking mechanisms, and they solve opposite problems. Undo stores before-images of changed data — what a row looked like before your transaction touched it. Redo records every change made to the database, committed or not, so the instance can recover after a crash.

UNDO vs REDO at a glance

	UNDO	REDO
Stores	the before-image of changed data	a record of every change made
Purpose	rollback, read consistency, flashback queries	crash recovery, durability (the "D" in ACID)
Location	the UNDO tablespace (undo segments)	online redo log files
Written for	your own transaction's changes, to undo them if needed	all changes, so committed work survives a crash even if not yet on disk
Read by other sessions?	yes — powers read consistency for concurrent queries (MVCC)	no — redo is for recovery, not queried during normal operation

Why the database needs both

Redo is what makes a COMMIT durable: Oracle writes the change to the redo log before confirming the commit, so even if the instance crashes before the actual data block is written to disk, the committed change can be replayed from redo during recovery. This is standard write-ahead logging.

Undo is what makes ROLLBACK possible, and what lets another session read a consistent snapshot of a row while your transaction is still mid-flight, uncommitted — Oracle shows them the undo (before-image) version instead of your in-progress change.

The fact that trips people up: undo generates redo too

Because undo segments are themselves part of the database, changes to them also need to be durable and recoverable — so writing an undo record also generates a redo entry. A single row update therefore produces both an undo record (to allow rollback) and redo entries covering both the data change and the undo change itself. This is a common exam and interview point precisely because it's counter-intuitive at first.

Frequently asked questions

Does a ROLLBACK use undo or redo?

Undo. Rolling back a transaction applies the before-images stored in undo to reverse the transaction's changes. Redo is not involved in a normal rollback — it exists for recovering committed work after a crash, not for undoing uncommitted work.

What happens if the undo tablespace runs out of space?

Active transactions needing more undo space can fail with an out-of-space error (ORA-30036 or similar), and long-running queries needing an old undo version that's been overwritten can fail with ORA-01555 "snapshot too old". Sizing the undo tablespace and undo retention appropriately for the workload avoids both.

Is redo the same thing as a backup?

No. Redo logs support crash/instance recovery (replaying changes since the last checkpoint) and, combined with archived redo logs and RMAN backups, media recovery. They're a component of a backup and recovery strategy, not a backup by themselves.

Does this concept apply to PostgreSQL too?

Postgres has a conceptually similar write-ahead log (WAL) for durability and crash recovery — playing a redo-like role. But PostgreSQL's MVCC keeps old row versions directly in the table heap rather than in a separate undo-like structure, relying on VACUUM to reclaim them — a real architectural difference, not just a naming one. See the PostgreSQL vs Oracle differences article.