+

Search Tips   |   Advanced Search

 

Moving a transaction log from one server to another

 

This topic describes some considerations and actions that you can take to move the transaction logs for an appserver to another server.

 

Overview

To move transaction logs from one appserver to another, consider the following steps:

 

Procedure

  1. Move all the transaction log files for the appserver. The transaction log directory for each server contains a number of files and subdirectories. When moving transaction logs from one server to another move all of the files and subdirectories together as a single unit; otherwise recovery may not complete resulting in data inconsistency.

  2. For a server configuration where there are no distributed transactions, move the transaction logs to any server that has access to the same resource managers. For a single server or network-deployed server configuration where it is known there are no distributed transactions present in the logs, the transaction logs can be moved to any server (on any node) that has access to the same resource managers as the original server. For example, the server needs communication and valid security access to databases or message queues.

    If the server is in a different cell from the original server, ensure that there is a JAAS alias available to the server that was used by the original server for accessing XA resources. In this case you should use wsadmin to construct the aliases, because if you use the console to create the alias, then the node name gets prefixed to the alias.

    All the transaction log files for the original server need to be moved to a directory accessible by the new server. This can be accomplished by either renaming the transaction log directory or copying all the contents to the new server's transaction log directory before starting the new server.

    To complete transaction recovery, the appserver uses the resource manager configuration information in the transaction logs. However, for the appserver to continue to do new work with the same resource managers, the server must have an appropriate resource manager configuration (as for the original server).

  3. For a network-deployed server configuration where there are distributed transactions, move the transaction logs to a server that has the same name and host IP address, and access to the same resource managers. For a network-deployed server configuration, when it is known there are distributed transactions present in the logs, there are more restrictions. Distributed transactions that access multiple servers log information about each server involved in the transaction. This information includes the server name and the IP address of the machine on which the server is running. When recovery is taking place on server restart, the server uses this information to contact the distributed servers and similarly, the distributed servers try to contact the server with the same original name. So, if a server fails and the logs need to the recovered on an alternative server, that alternative server needs to have the same name and host IP address as the original server. The alternative server also needs to have access to the same resource managers as the original server. For example, the server needs communication and valid security access to databases or message queues.

    All servers within a cell must have unique names.

    To complete transaction recovery, the appserver uses the resource manager configuration information in the transaction logs. However, for the appserver to continue to do new work with the same resource managers, the server must have an appropriate resource manager configuration (as for the original server).


 

Related tasks


Manage transaction logging for optimum server availability