An Oracle index is removed during a maintenance change. The migration files stay untouched. Before the next release, the DBA needs to know whether the database still matches the schema the team expects.
A migration-history check can confirm that the recorded scripts are consistent. Reviewing the current database against an earlier schema baseline answers another question: what has changed in the environment?
DBLift Pro compares the live Oracle schema with its stored snapshot and names the differences for review. That gives the DBA a concrete starting point for investigating changes made outside the migration workflow.
See the missing object in the comparison
In this controlled example, a migration created an orders table and an index named DL_ORDERS_CUSTOMER_IX on CUSTOMER_ID. DBLift captured the schema baseline after the migration. Its initial comparison reported that the schema was in sync.
The index was then dropped directly in Oracle. The migration file and its history entry remained unchanged.
Migration validation still passed. To compare the live Oracle schema with the retained baseline, I ran the following command. The private dblift.yml configuration identifies the Oracle connection, schema and migration directory.
dblift --config dblift.yml --no-progress diffActual comparison output:
WARNING: Snapshot accuracy check detected differences between snapshot and live database (1 error(s), 0 warning(s)). Diff results may reflect schema drift.
================================================================================
INTROSPECTION QUALITY & VALIDATION
Introspection Quality:
Completeness: 100.0%
Confidence Level: HIGH
✓ No errors or warnings
Validation Results:
Overall Status: ✓ PASSED
Confidence: HIGH (100.0%)
Score Breakdown:
Accuracy: 100.0%
Completeness: 100.0%
Consistency: 100.0%
Success_Rate: 100.0%
✓ No validation issues
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ SCHEMA DIFFERENCES FOUND ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Differences detected — see sections below ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
Missing Indexes (1)
└── DL_ORDERS_CUSTOMER_IX
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ SUMMARY ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Total differences: 1 ┃
┃ Warnings: 1 ┃
┃ Status: WARNING ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
policy 62d66618c41bThe command returned exit code 1 and named `DL_ORDERS_CUSTOMER_IX` as the single missing index. The introspection-quality panel's “PASSED” label describes the capture checks; the difference list and WARNING summary show that the schemas differ. After the index was restored as a control, the comparison returned to “schema is in sync”.
For the DBA, the useful result is specific: the expected index is missing from the live schema. The review can now address that discrepancy before accepting the environment for the next release.
Turn the difference into a review decision
A missing index needs context. Its removal might have been intentional. The report gives the reviewer an object to investigate; the team decides how that change should be handled.
With the index named, the DBA can establish:
- Whether its removal was an approved maintenance decision.
- Which application queries and release assumptions need checking.
- Whether to restore the expected index or formally accept and record the changed schema.
This example does not measure a query slowdown. Performance assessment still belongs to the target workload. The comparison makes the schema discrepancy visible so that assessment starts from a known difference.
The check also left the decision with the team: native Oracle queries confirmed that the index stayed absent after comparison. All 1,000 data rows, the migration history and the stored snapshot were unchanged by the validation and diff checks.
Keep a baseline you can explain
A useful comparison needs a reference captured before the change you want to detect. In this example, DBLift's paid migration workflow stored the baseline after the setup migration, while the expected index was present.
Keep track of when that reference was captured and which migration state it represents. Review differences before refreshing or accepting a new baseline: a comparison against an already changed reference cannot establish what used to be there.
This is where the two checks help the release conversation. Migration validation confirms the recorded migration state; schema comparison shows whether the live objects still match the retained reference. Together, they give the DBA more evidence for the next release decision.
Use the result in your release review
This example uses DBLift Pro's paid stored-snapshot comparison on Oracle AI Database 26ai Free, version 23.26.3.0.0, with published Pro/Enterprise 5.0.0 and OSS 5.1.7. It covers one ordinary table and one non-unique index. It demonstrates detection of that discrepancy; performance, automatic remediation and other Oracle object types need their own assessment.
Run the schema comparison against your retained Oracle baseline before release review, and keep the output with the change record. The named difference gives the DBA and release owner a specific question to resolve before accepting the environment.