C Server Configuration

Copying the Repository

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.

Copy the Directories

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, C:\Oracle\Middleware\opdq\server\data.

This data directory contains the following subdirectories:

• repository

• shared

For example, you have a test server with the data repository in the root DataLensData directory.

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 //prod/datalens/server directory.

Configure the New Server

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.

Edit the C:\Oracle\Middleware\opdq\server\data\shared\config\DbInfo.xml .

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.

Job Continuation

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:

Expected Results

The following table outlines the expected results for each job type and the DB connection status.

	Db down at startup	Db down - Interrupted	Reconnect
Governance Studio	fail	run	run
Scheduled Jobs	fail	run	run
Java API	run	run	run
COM API	run	run	run

DB down at startup:

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.

DB down - Interrupted:

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.

Reconnect:

Means that the Transform Server access to the database has been fully re-established.