Docs/Reference/Recovery
OSS

Recovery

When dblift migrate fails half-way, start with two reads. Both are safe.

dblift info

Then inspect the history table the database actually has (dblift_schema_history by default).

Common cases

History row marked failed, scripts on disk unchanged. On engines with transactional DDL (PostgreSQL, SQL Server, Db2, SQLite, DuckDB, Redshift, Cockroach) the statements rolled back. Fix the script, repair if the failed row is stale, then migrate again.

Partial DDL on MySQL, MariaDB, Oracle, YugabyteDB, Snowflake, Cosmos, MongoDB. Those engines auto-commit or have no transactions. Statements that already ran are in place. Reconcile the schema by hand (or with a follow-up migration), then repair the failed history row.

Checksum drift. An applied script changed on disk. validate reports it. Restore the original file, or repair only after you intend the new checksum.

Duplicate or orphan history rows. repair rewrites metadata. It does not mutate schema objects.

Oracle lock timeout. Another session holds DBMS_LOCK. Find the blocker, release it, retry. Do not repair a still-running migrate.

Lost connection mid-run. info shows whether a history row was written. If the last version is missing and the objects exist, baseline or repair after you confirm the schema. If the row exists and the objects do not, undo is not enough — restore from backup.

See Troubleshooting, Schema history table and dblift repair.

On this page