14 Backing Up and Restoring EDQ Server

This chapter provides an introduction to backing up and recovering Oracle Enterprise Data Quality server, including backup and recovery recommendations for performing disaster recovery.

Each EDQ server (Active/Passive/Production/DR) needs to be installed separately, i.e. has a separate installation of the Fusion Middleware Infrastructure and (especially) the FMW repository schemas.

Note:

For backup or restore of an EDQ server running on Tomcat, there is no FMW Infrastructure, but each server should be installed separately.

The timezone of each EDQ server must be the same in order to ensure that the configuration logic is identical, as the server timezone can play a role in Date/Time conversions in EDQ processes.

Perform the following steps for backing up and restoring an instance of EDQ on Oracle WebLogic server:

To back up an EDQ server:
  1. Stop the server (to ensure the database is static).
  2. Backup the EDQCONFIG schema.

    It is not normally necessary or advisable to backup the EDQSTAGING or EDQRESULTS schemas as they generally contain only temporary data that can be restored by re-running jobs. An exception is that EDQRESULTS should be backed up, if you need to see results (For example- in Director) of previously run jobs, for example any Results Books that have not been exported. In this case, it is advisable to minimize the size of the EDQRESULTS schema before backing up by purging any old projects for which results are not required, and deleting any projects that are no longer needed (backing them up by packaging them to DXI files first, if required).

  3. Backup the files in the EDQ Local Home area, with the exception of the logs directory.
To restore an EDQ server:
For WebLogic server:
  1. Stop the server.
  2. Restore the EDQCONFIG schema from backup, dropping the "fresh" schema created on the passive instance by RCU and restoring to the same database name. All other schemas, including the EDQSTAGING and EDQRESULTS schemas, should be freshly initialized as created by RCU, but with sufficient tablespace configured to be operational. If EDQRESULTS was backed up, restore this as well.
  3. Restore the files in the EDQ local home, with the exception of the backed up director.properties file. Settings from this should be merged carefully on to the restored instance, to ensure that the pointers to the EDQ databases are correct. This means, on the Oracle WebLogic server, the configured data sources in the domain are correct, and the director.properties file can be restored as is, with no impact.
  4. Restart the server and test by running jobs.
For Tomcat server:
  1. Stop the server.
  2. Restore the EDQCONFIG schema. Restore EDQRESULTS also if this was backed up. Otherwise, create empty EDQRESULTS schema for a new installation.
  3. Restore the files as above, with the exception of director.properties.
  4. Ensure the two pointers to EDQCONFIG and EDQRESULTS in director.properties are correct.
  5. Restart EDQ.