How do I fix ORA-02292?

Delete children first, or declare the cascade explicitly if that is genuinely the intent. For a replication sink, disable enforcement on the applying session rather than reordering events by hand. Find what still references the row before assuming the delete is wrong.

Oracle · error reference

ORA-02292: child record found when deleting

ORA-02292: integrity constraint violated - child record found

The mirror image of ORA-02291 — you deleted a parent that still has children. Common in CDC replication, where a delete can arrive before the child deletes that preceded it.

What the database is telling you

A DELETE (or a primary-key UPDATE) would leave rows pointing at something that no longer exists. Without ON DELETE CASCADE, Oracle refuses.

Why it shows up in a migration

This is a change-data-capture problem far more than a bulk-load one. The source deletes a customer and its orders in one transaction; the replication stream delivers those row events in an order that need not match, and the customer delete can arrive first. Applied naively it fails, and a stream that stops on the first ordering artefact will not stay running for long.

Common causes

A CDC delete applied before the child-row deletes from the same source transaction.
Replaying a stream from a checkpoint where the child events were already consumed.
A cleanup script deleting parents in the wrong order.
A foreign key defined without ON DELETE CASCADE where the application assumed cascade.

How to fix it

Delete children first, or declare the cascade explicitly if that is genuinely the intent.

ALTER TABLE orders DROP CONSTRAINT fk_cust;
ALTER TABLE orders ADD CONSTRAINT fk_cust FOREIGN KEY (cust_id)
  REFERENCES customers(id) ON DELETE CASCADE;

2
For a replication sink, disable enforcement on the applying session rather than reordering events by hand.
3
Find what still references the row before assuming the delete is wrong.
```
SELECT COUNT(*) FROM orders WHERE cust_id = :id;
```

What DBShifts does about it

The CDC applier detects foreign-key violations across Oracle and SQL Server drivers by matching the driver's message, then defers the event and retries it after later events land — up to five attempts, with a bounded deferral queue so one genuinely broken event cannot grow without limit. It also disables FK enforcement on the applying session, the same approach Debezium's sinks take.

Change-data-capture applier

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.

Start free See the migration paths

Related errors

Oracle

ORA-02291: parent key not found during a data load

A child row arrived before its parent. Why load order alone will not save you, and how deferred constraints turn an unsolvable ordering problem into a solved one.

SQL Server

SQL Server error 547: FOREIGN KEY constraint conflict

SQL Server's foreign-key violation, and the NOCHECK trap that makes it look solved when it is not — a constraint re-enabled without WITH CHECK is left untrusted.

← All database errors