Appendix G DBMS Recovery and the Repository

This chapter discusses strategies for backing up and recovering the repository.

Recovering the Repository

Disaster recovery planning is an essential part of deploying any business-critical system. Each supported DBMS has multiple mechanisms for data backup and restoration. Any of these are appropriate. Identity Manager has no implicit requirements.

Typically, if a database fails, it would only be necessary to restore the repository to the point just before the database failure. However, if business requirements dictate that the repository be restored to any given point in time (through use of the appropriate vendor-specific methods such as ARCHIVELOG mode or Flashback in Oracle or FULL logging mode in SQL Server), this can be done as well. Regardless of the recovery method used, it is necessary to consider some implications of restoring a version of the repository that is not completely up-to-date.

While the state of the repository will be self-consistent after the data restoration, it will not necessarily be consistent (or even compatible) with external objects such as the resources. The following items demonstrate some possible inconsistencies that might arise:

• Restored resources might be configured incorrectly, if resource attributes were changed.

• Restored users might have pending attribute changes that are no longer desirable, because of more recent changes.

• Restored workflows and tasks might be in a state that no longer matches the environment. For instance, formerly completed tasks could attempt to run again, and approvals might re-appear, requesting action from an administrator.

Additionally, resources are themselves the repository of account attributes. Restoring the repository to a specific point in time may not aid in restoring resources to prior states, since the information required to do so may never have been stored in the repository.

redo Logs

Point-in-time recovery methods require the existence of an unbroken set of change records (typically referred to as “redo logs”). This can often present logistical challenges if the rate of change is high, generating a large volume of redo.

Identity Manager tries to minimize the need to write to the redo logs. However, database activity cannot be completely eliminated. Even when Identity Manager appears to be idle, each server polls the repository in order to detect changes to repository objects, tasks ready to run, tasks ready to clean up, and so forth.

The intervals on which these activities occur are configurable, and increasing these configured intervals will reduce the frequency of (but will not eliminate) database operations that Identity Manager executes against the repository when idle. To configure these intervals, define new values for the cache.pollingInterval and other properties that begin with cache and ChangeNotifier in the Waveset.properties file.

In addition, disable the listcache.size property on any application server in a cluster that does not serve the Identity Manager Graphic User Interface. Disabling this property reduces number of operations that Identity Manager executes against the repository when the application is idle.