Using the manage content tool to migrate an existing WSRR V8.5.0 or V8.5.5 installation

You can use the manage content tool in the WSRR web UI to migrate from an existing WSRR V8.5.0 or V8.5.5 installation to a new WSRR V8.5.5 installation. You might use this feature, for example, when a hardware move is required, or to move the WSRR database from one RDBMS to another.

Before you begin

Before using the manage content tool to migrate a WSRR V8.5.0 or V8.5.5 installation, you must have installed the target WSRR, and moved the configuration profile from the source WSRR to the target WSRR.

If you are moving the WSRR database from one RDBMS to another, then you must set up a shared library in WebSphere Application Server, and add it to the ServiceRegistry application in the target system (see the topic Managing shared libraries in the WebSphere Application Server documentation). Drivers for Microsoft SQL Server, Oracle and DB2 can be found in WSRR_install/jdbcdrivers.

Where Java 2 Security is enabled for the WebSphere Application Server, you must set up Java 2 permissions for the shared libraries. You set the permissions in the file profile_root/config/cells/cell_name/nodes/node_name/library.policy. By default, this grants no permissions. To grant all permissions for shared libraries on this node, set the file as follows:
grant {
permission java.security.AllPermission;
};
Then stop and restart the server. For more information about setting these permissions, see Java 2 security in the WebSphere Application Server documentation.

About this task

You use the manage content tool to retrieve the contents of the source WSRR database. You can specify that the contents are retrieved directly from the source database, or you can specify a JDBC connection. You can also run selected upgrade plug-ins to enhance your source WSRR data as you move it. You can use this feature to enable new WSRR functionality that you might not have enabled when you originally upgraded to V8.5.5.

You can use a response file to drive the upgrade if required. You run through the tool providing responses about your upgrade and then save these responses to a file, or you can specify a file using guidance from the topic Upgrade response file. You can then start the tool again and pass it upgrade settings from the saved file when you are ready to perform the upgrade. You import the file and start the upgrade by using the Manage content > Load Settings from a File option.

Note: If you are retrieving content from an Oracle RAC database, you must use Source type JDBC Source.

Procedure

  1. In the target WSRR web UI, go to the configuration perspective and select Manage content > Import from another WSRR 8.5.x.
  2. Select the Source type from the following options:
    • Database. If you select this option, you must supply all the details of the source database, including authentication details.
    • JDBC source. If your database administrator does not want to release authentication details, they can set up a JDBC source for the database, and you can specify that instead of full database details.
  3. Specify the details of your source WSRR system. The details that you specify depend on the Source type that you selected. The details might be database details or JNDI name of the JDBC data source. Click Next.
  4. Select any upgrade plug-ins that you want to process the data as you migrate it from source to target WSRR installation. Click Start Upgrade.
  5. Use the Manage content > Show Last Report option to view the results of the upgrade.

Results

The manage upgrade tool displays status information as it runs the selected upgrade plug-ins, so that you can monitor progress.
When loading a large database, you might get a message reporting that the UpgradeThread might be hung. The log contains a message starting with the following text:
[13/10/10 16:07:07:946 BST] 00000013 ThreadMonitor W WSVR0605W: Thread "WorkManager.WSRRWorkManager : 0" (00000035) has been active for 692920 milliseconds and may be hung. There is/are 1 thread(s) in total in the server that may be hung. 
This is reported because the process has been running a long time, not because the thread is actually hung, and so the message can be ignored.