WAS v8.5 > Set up the application serving environment > Administer nodes and resources > Configure checkpoints

Restoring checkpoints

Use a full checkpoint to restore the entire configuration repository back to the state it was in at the time the full checkpoint was made.

Privileges for managing repository checkpoints differ, depending on the administrative role of the user. Roles include monitor, operator, configurator, and administrator. If we are a user with either a monitor or an operator role, we can only view the repository checkpoint information. If we are a user with either a configurator or an administrator role, we have all configuration privileges for repository checkpoints.

Ensure that we have an adequate number of open file descriptors available. The default number of open files setting is 2000, which is typically sufficient for most applications. If the value set for this parameter is too low, errors might occur when opening files or establishing connections. Because this value limits the number of file descriptors that a server process might open, a value that is too low prevents optimum performance. For more information, see Tuning operating systems. Use delta checkpoints to undo recent changes. Restore delta checkpoints only in the reverse order in which they were created. Each delta checkpoint has a sequence number. The highest sequence number represents the most recent delta checkpoint. Thus, restore delta checkpoints in descending sequence number only. After the configuration repository is restored from a delta checkpoint, the product creates a checkpoint containing the configuration before restoration.

To restore a checkpoint, from the dmgr console select System administration > Extended repository service > Repository checkpoints.

When you restore a checkpoint, save conflicts occur if we have uncommitted changes in your workspace. The checkpoint gets restored, but the uncommitted changes are flagged as a save conflict when we attempt to save them. Also, if more than one user is working on configuration changes to the repository through the dmgr console or otherwise, then other users with uncommitted changes get save conflicts as well if one user performs a checkpoint restoration.

  1. Select a repository checkpoint.

  2. Click Restore.

    Delta checkpoints must be restored in descending sequence number order only. Selecting multiple checkpoints for restoration is not supported. Restore checkpoints one at a time. Select the latest delta checkpoint, the one with the largest sequence number, then restore it. Do this for each checkpoint to restore.

    To restore a delta checkpoint that is the oldest saved checkpoint, we might need to increase the number of delta checkpoints. The Automatic checkpoint depth field on the Extended repository service page specifies the number of saved delta checkpoints. After the number of delta checkpoints is reached, the product deletes the oldest delta checkpoint each time a new delta checkpoint is made. When you restore a delta checkpoint, a new delta checkpoint is made.

Before you attempt to verify the success of a checkpoint restoration, you must log out of the dmgr console and log in again. This prevents problems or abnormal behavior resulting from workspace issues.


Related concepts:

Repository checkpoint and restore function


Related


Tune operating systems


Reference:

RepositoryCheckpointCommands command group for AdminTask using wsadmin.sh


+

Search Tips   |   Advanced Search