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.

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

  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.

    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 thecontents to the new server's transaction log directory before starting the new server.

    Note that To complete transaction recovery, the appserver uses the resource manager configuration information in the transaction logs. However, for the application server 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.

    Note that All servers within a cell must have unique names.

    Note that 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).

 

See Also

Managing transaction logging for optimum server availability