Oracle · error reference

ORA-01466: table definition has changed

ORA-01466: unable to read data - table definition has changed

A flashback or as-of query crossed a DDL change, or the undo it needed has aged out. Why long-running CDC polls hit it and short ones do not.

What the database is telling you

A consistent read at a past point in time needs the table's definition and its undo to be intact since then. If DDL ran in between — or the undo tablespace has recycled those blocks — Oracle cannot reconstruct that view and refuses rather than returning something approximate.

Why it shows up in a migration

Change capture on Oracle without LogMiner works by querying versions of rows between two SCNs. The wider the SCN window, the likelier the undo it needs has been overwritten, so this appears under exactly the conditions you least want it: a busy source, a slow consumer, or a stream restarted after an outage.

Common causes

  • DDL on the table between the flashback SCN and now.
  • UNDO_RETENTION too low for the polling interval, so undo aged out.
  • A stream resumed from a checkpoint older than the retained undo.
  • Flashback across a truncate, which resets the segment entirely.

How to fix it

  1. 1

    Raise undo retention comfortably past your polling window, and give the tablespace room to honour it.

    ALTER SYSTEM SET UNDO_RETENTION = 3600 SCOPE=BOTH;
  2. 2

    Check the retention you are actually getting, which is not always what you set.

    SELECT MAX(maxquerylen) FROM v$undostat;
  3. 3

    Poll more frequently so each window is smaller, or move to LogMiner-based capture for long windows.

What DBShifts does about it

The Oracle CDC poller treats this as a per-table condition rather than a stream-ending one: the failure is logged and surfaced through the stream's error tracking, and polling continues for the other tables instead of the whole stream stopping because one table's undo aged out.

Oracle change capture

Migrating between engines?

DBShifts converts the schema, moves the data, and then proves the two sides match with a type-aware checksum per table — not just a row count. Errors like this one are handled on the way, and the ones that cannot be handled are reported rather than logged and forgotten.

Related errors

← All database errors