WebSphere Application Server V8.5 Administration and Configuration Guide for the Full Profile

1064 WebSphere Application Server V8.5 Administration and Configuration Guide for the Full Profile

There is no automatically archive function provided by WebSphere Application Server V8.5,

but you can use any archive tools to archive these two location files.

To delete checkpoints use the delete option on the administrative console Repository

checkpoints page as previously shown in Figure 30-2 on page 1062. To access the delete

option complete the following steps:

1. Select System administration  Extended repository service  Repository

checkpoints  checkpoint_name.

2. Click the Delete button.

30.3.3 Restoring checkpoints

To restore the checkpoints, refer to Figure 30-2 on page 1062, and complete the following

steps:

1. Click System administration  Extended repository service  Repository

checkpoints.

2. Select one checkpoint_name you want to restore and then click Restore.

3. Logout and Login again.

Delta checkpoints must be restored in descending sequence number order only. Selecting

multiple checkpoints for restoration is not supported because it can only restore one

checkpoint at each time.

30.3.4 Configuring change audit

You can also use a delta checkpoint to audit what changes were made to the configuration. A

delta checkpoint can be exported as a compressed file. This file contains the before and after

versions of configuration files that have been changed.

To export a delta checkpoint:

1. Click System administration  Extended repository service  Repository

checkpoints, as previously shown in Figure 30-2 on page 1062.

2. Select the delta_checkpoint_name, and click Export.

3. On the Export repository checkpoints page, select the name of the compressed file.

4. Save the file to a specified location.

5. Extract files from the exported compressed file, and examine the changes in the

configuration.

30.4 Restoring transactions

WebSphere Application Serverstores information about transactions that it manages in the

form of persistent logs. The default directory for the transaction logs is:

profile_root/tranlog

These logs can be used to recover transactions that did not complete due to, for example, a

hardware or software server failure. The WebSphere Application Server recovers transactions

during startup. You can also force it to recover transactions by specifying the -recovery

parameter in the startServer command.

Chapter 30. System recovery 1065

The WebSphere Application Server also supports more complex recovery cases when in a

clustered environment, referred to as

transactional high availability. The high availability of

the transaction service enables any server in a cluster to recover the transactional work for

any other server in the same cluster. For more information about the high availability concept,

refer to chapter and section 15.3, “High availability and failover” on page 538.

30.4.1 Restarting an application server in recovery mode

When starting a server with the -recovery parameter after a failure, shown in Example 30-9,

the transaction service uses recovery logs to complete the recovery process. You must issue

the command from the profile_root/bin directory of the profile with which the server is

associated.

Example 30-9 Start server in recovery mode

startServer.sh server1 -recovery

Using the additional -recovery parameter specifies that the server starts in the special

recovery mode. The special recovery mode engages the following actions:

 Transactional resources complete the actions in their recovery logs. This action frees up

any resource locks that the application server held prior to the failure.

 During the recovery period, only a subset of the application server functions are

accessible. The subset includes only those that are necessary for the transactional

recovery to proceed.

 The application server does not accept transactions during recovery.

 The application server shuts down when the recovery is complete.

30.4.2 Administering the transaction service

You can view or change settings for the transaction service and manage active and prepared

transactions. You can configure transaction properties to enable peer recovery of failed

application servers in a cluster. You can manage transaction logging to optimize the

availability of application servers. The following list describes the configurations that are

available and what they manage:

 Configuring transaction properties for an application server

Change the location or default file size of the transaction log files, transaction timeout

properties, or heuristic-related properties.

 Configuring transaction properties for peer recovery

Peer recovery for the transaction service enables servers in a cluster to complete

outstanding work for a failed cluster member. You can configure and manage the manual

and automated peer recovery.

 Managing active and prepared transactions

In some circumstances, you might have to resolve a transaction manually:

– Manual transactions: Transactions awaiting administrative completion.

– Retry transactions: Transactions with some resources being retried.

– Heuristic transactions: Transactions that have completed heuristically.

– Imported prepared transactions: Transactions that are imported and prepared but not

yet committed.