|Oracle® Enterprise Data Quality for Product Data Oracle DataLens Server Administration Guide
Part Number E23614-02
This scenario may occur if there is a complete test system that needs to be copied to a production environment.
Note:In a topology with a central Oracle DataLens Administration Server and development and/or production server groups, then this is not needed because the package deployment will take care of this.
Prior to starting this procedure, stop the application server service for the target server.
Basically, the repository files need to be copied from the test system to the production system. The repository contains the following directories that will need to be copied.
Simply copy the data directory from the Oracle DataLens Administration Server data directory; defaults to
OPDQ_HOME/data (for more information about
OPDQ_HOME, see "SvrPaths.xml". For example,
This data directory contains the following subdirectories:
For example, you have a test server with the data repository in the root
You want to copy the repository to the prod server. You need to copy the data directory listed from the
//test/datalens/server directory to the
In the server with the newly copied directories, change the configuration to point to these new directories. Edit the file
SvrPaths.xml file if you have deviated from the standard directory location used in the test system. See the preceding information for information on editing the web.xml file.
Change the name of the server to the new server hosting the prod server.
Now, the target server can be restarted with the new data directories.
Browse to the Administration Web Page and re-create the following:
The database connections that are needed in the target system.
The FTP definitions that are needed.
User accounts, privileges and roles that will be used.
The Job continuation feature allows large batch jobs to continue to run and new API jobs to start and run even when Transform Servers lose connectivity with the internal database repository (Administration Server is down).
When this occurs, you can identify what step the DSA was processing by selecting the Job ID from the Job Status page. The step that was running when the Transform Server lost connectivity is identified by black in the Status column and a comment to this effect in the Comment column as in the following example:
The following table outlines the expected results for each job type and the DB connection status.
|Db down at startup||Db down - Interrupted||Reconnect|
Means that the Transform Servers do not have access to the database.
Note:If there is no DB connection when the job is started, all new jobs will get a JobID of a negative number. The JobID's negative number range is based on the server profile id * 100,000.
Means that the Transform Server had access to the database when the job began, but lost access to the database at some point during the running of the job.
Note the following:
Submitted from Services for Excel, Governance Studio, or from the Job Runner web page the text results are not retrievable. If the results are persisted in the file system or database, they are placed there by the job itself and those results are available.
Once the Administration server is back up, the Job status page will be incorrect for interrupted jobs in two ways. The job will be considered running and will have to be canceled to clear the job from the running list and it will have incomplete step information because the transform server could not write back the results to the database.
Means that the Transform Server access to the database has been fully re-established.