If a release has occurred and it is deemed necessary to roll back the state of the schema, the best practice is to roll forward to that previous state, thereby preserving the true historical chain of events.

It is also often the case that a problematic release relates to not all, but a subset of specific changes, so it can be desirable to cherry pick changes to revert to.

A roll forward can simply be regarded as a new migration, and should therefore follow the same release procedure.

Rolling forward using undo scripts

If undo scripts are being maintained already, the simplest way to roll foward is to copy the undo script as the next migration script. If there are programmable objects that need to be reverted, these will need to be copied into the from the previously deployed release package.

Cherry picking changes

If not all of the changes need to be reverted, it is simply a question of editing the migration script and removing changes that are to be preserved. Likewise for programmable objects, only copy those that need to be reverted.

Rolling forward using  Schema Compare for Oracle

If undo scripts aren't being maintained, the roll forward script will need to either be authored manually, which can be time-consuming, or generated using Schema Compare for Oracle.

Schema snapshots are created by Redgate Change Automation for drift detection purposes. These snapshots can be extracted from the release package and loaded as the "source" in Schema Compare for Oracle, setting the "target" as the target database to roll back. After a comparison, specific changes can be cherry picked for reverting. Run through the Deploy wizard but don't apply the changes to the target directly as they must be applied via the proper process to be registered in the history table and not be regarded as "drift". Instead, copy the script and apply it to a development environment, and commit, push and deploy the changes as per the normal process.