The shadow database is a separate database that is needed in development only.  When you go to the Generate migrations tab in Redgate Change Control, we run the scripts in the project against the shadow database.  Then, we use the Redgate Schema Compare for Oracle technology to compare the development database to the shadow database.  This allows us to show you what changes have been made to your development database that have not been imported into the project yet.  

Because we run all the migration scripts in your project on the shadow database/schema, this also helps you shift-left and identify any problems in your migration scripts as early as possible during development.  

You should never have to make changes to your shadow database/schema.  You also don't need to baseline your shadow database/schema.  It will be cleaned (meaning all objects will be dropped) as required when you visit the Generate migrations tab, so make sure that you are not using a database/schema that contains important data. 

The Shadow Database/Schema only gets updated with the migration scripts in your project, so the size should be small since there shouldn't be any transactional data in this database.  It will just contain the schema objects and reference data from your migration scripts and any data updates ran on these.  If you have a transactional data update in a migration script in your project, it won't do anything on the shadow since the transactional tables are empty. 

Options for Oracle

You need to create the Shadow Database/Schema prior to creating a Redgate Change Control project so you can provide us the connection details for this database.  There are a few options to use for the Shadow Database:

• Pluggable Database
  If you are using Oracle 12c and above, the easiest way might be to use another pluggable database on your development instance.
  
  
• Oracle Express Edition (XE)
  Oracle XE is a free version of Oracle that can be used for development purposes.  There are some size restrictions, but because the shadow database doesn't contain any transactional data, this should be ok.
  
  
• Containers
  If you're familiar with docker/containers, you could spin up an Oracle database in a container to use for the shadow. Since there is no transactional data, no persistence is required and therefore a transient container should just work.
  
  
• Create another Oracle instance for this.

• A separate schema within the same Oracle database
  

It is also possible to use a schema as a shadow database, which can be set through the shadow database connection dialog. This feature can only be used for projects that are tracking changes to a single schema. If your project contains multiple schemas then a separate shadow database is required so we maintain the schema name in object identifiers. When a shadow schema is being used it is recommended to set the ExcludeTargetSchemaName comparison option so that all migration scripts are created without the schema name in object identifiers making it possible to deploy the same script to both the development and shadow schemas.

There are a couple of caveats when writing migration scripts in this single-schema mode:

• • Any references to objects in the managed schema must not be schema-qualified. Since the migration scripts will run against different schemas with different names, managed objects must always be created in the current default schema.
  • Any references to objects in other schemas must be schema-qualified. You'll be responsible for making sure any dependencies of the managed schema are present in the database as appropriate.

For example:

CREATE TABLE log (
message VARCHAR2(50),
timestamp INTEGER
);

-- this object references log in the same schema, so log must not be schema-qualified
CREATE OR REPLACE TRIGGER SetTimestampForLog BEFORE INSERT ON log
FOR EACH ROW
DECLARE
v_today DATE;
BEGIN
SELECT CURRENT_DATE INTO v_today FROM DUAL;

-- date2epoch is in a different schema, so must be schema-qualified
:new.timestamp := util.date2epoch(v_today);
END;

• We're also wondering if we should provide a way to spin up database clones on the fly for this purpose. 
  
  

If you'd like to talk about these options more or have any questions about the Shadow Database/Schema, please reach out to the development team.

Technical details

Why is a shadow database/schema required?

A shadow database/schema is required so we can identify any changes to your development database that have not been scripted out to the project yet.  We consider the migration scripts in your project to be the source of truth. so we need to know what the final state of running all the migrations scripts produces to compare to the development database to show the differences when you go to the Generate migrations tab.  The only reliable way to get this final state is to actually run the scripts against a real database.  We considered using an offline schema model to represent the migration scripts, but if the migration scripts or offline schema model were edited outside of our tool, then they would be out of synch and we wouldn't be able to reliably generate the next migration script.  Learn more about this experimental Shadow Scripts Folder feature.

When is the shadow cleaned?

The shadow database/schema gets automatically updated from the migration scripts in your project when you visit/refresh the Generate migrations tab. This update involves potentially cleaning the database (i.e. dropping all objects) prior to updating it with the migration scripts depending upon the current state of the shadow.

If the project uses a database as the development source, and

• the schema history table in development contains no scripts, then the shadow will be cleaned.
• the schema history table in development contains only repeatable migration scripts, then the shadow will be cleaned before being migrated with the repeatable migration scripts.
• the shadow version is ahead of the development version, or the schema history table in development contains Missing or Future migrations (see Migration scripts), the shadow will be cleaned and then migrated up to the current development version.

Otherwise, the shadow will not be cleaned.  Only the pending migration scripts will be applied to have it reflect the end state of the migration scripts in the project.

If the project uses a Source Control for Oracle project as the development source (i.e. Hybrid mode), then the shadow will be cleaned only if the schema history table in the shadow contains Missing or Future migrations. The shadow will be migrated using all the scripts in the current project.