When working with an existing database, we need a baseline that reflects the state of your objects and reference data that have already been deployed to production so that you can generate new migrations based on changes in your development environment from this point forward.  A baseline is also necessary to spin up new environments for testing purposes or to deploy to new client sites.

Baselines are also necessary if you are using a build database with the check command for drift detection and change reports.   

Example

In this example, TableA and TableB have already been deployed to our downstream environments (Test, Staging, and Production).  Our baseline needs to capture TableA and TableB to bring the Shadow Database in our development environment up-to-date with what has already been deployed.  Therefore, when we go to generate our next migration script, it will know that TableC is the only new development and capture this change in the next migration script.

In this case, Test, Staging, and Production are in synch, so any of these environments can be used for the baseline source.  It's ok for Dev to be ahead of where your downstream environments are.

If your downstream environments are not in synch, then you have 2 options:

1. Reset them so that they are in synch.  This might mean waiting until after your next deployment.
2. Create multiple baselines.

There are a few options for getting a baseline:

• Creating a baseline script
• Clones as baselines
• Backups as baselines
• Using Oracle's Flashback Technology