../E26585-05.epub /> ../E26585-05.mobi />
Oracle Business Transaction Management stores a large amount of data. This data describes the system's configuration, what the system is monitoring, and the current and past states of monitored applications. All of this data is needed for the operation of the system; if something happens that causes this data to be lost or damaged, the system can no longer perform as you expect. This is why it is important to create a backup of the system's data and to be able to recover this data.
You might need to back up Business Transaction Management for different reasons:
on a regular basis to enable recovery from unforeseen events
before migrating to a new sphere
before upgrading an application server in the Business Transaction Management environment or adding an application server
before installing a new version of Business Transaction Management
This section offers general guidelines for backup and recovery, and suggests milestones for testing the process you have defined. How often you create a checkpoint by backing up your data depends entirely on the lifecycle stage of your application and on business requirements.
Backing up and restoring Business Transaction Management does not include the backup and recovery of the hosting application server and its configuration settings, some of which Business Transaction Management needs to function properly: JVM settings, Java System parameters, and so on. You should already have processes in place for backing up your application servers and their configurations.
Business Transaction Management operates in a complex environment. For this reason, before backing up, it is important to make sure that you can isolate Business Transaction Management components and that you can identify any other systems that might be affected by the backup and recovery process. Consider issues like the following:
Databases might be shared with components other than Business Transaction Management. Unless the problem is database failure itself, it is important to restore only those database instances that are used by Business Transaction Management.
Recovery might affect other systems. For example, if Business Transaction Management shares JDBC drivers with other applications, recovery might restore a driver to a previous version and cause other applications using the driver to fail.
You should test your backup process periodically by attempting a recovery and making sure the system can be brought up to the desired state with no side effects. Identifying and resolving problems with the backup process will ensure successful recovery when recovery matters. Your backup verification checklist should include things like the following:
database and file system structure, and permissions are as expected
Business Transaction Management is functional and in the expected state: the console shows everything is running, services are reachable, traffic flows normally, and so on.
no application sharing the same resources is adversely affected.
This section describes how Business Transaction Management data is organized, explains how you back up each type of data, and discusses timing issues related to backups.
With reference to the figure, the basic principle of backing up data is as follows:
All data contained in databases is backed up by backing up the database.
All data contained in files or directories is backed up by backing up the
btmstorage directory, which can be found on every host where one of the Business Transaction Management system services or monitors is deployed. The location of this directory for your server is specified in Backing up Business Transaction Management Data.
The rest of this section provides more information about elements shown in the previous figure. You do not need to know this level of detail just to do backup and recovery. But this detail might be helpful in troubleshooting and in understanding the resources used by Business Transaction Management. If you want, you can skip ahead to Backing up Business Transaction Management Data.
As the figure shows, Business Transaction Management is composed of multiple system services:
The sphere, responsible for the overall operation of Business Transaction Management and coordination of its member services
The SLM service, responsible for gathering performance measurements
The ExM service, responsible for transaction management
Monitor agents, responsible for collecting data from observers
Each of these services depends upon data that specifies the system's configuration, describes what it is monitoring, and records the state of monitored applications. This data can be grouped into the three categories shown in the figure.
The Sphere database contains data that describes Business Transaction Management as well as the monitored user systems. It includes a description of the users' applications, the policies used to monitor them, and transaction definitions.
Monitor agent configuration files contain data that describes whether and how each user endpoint is being monitored.
Operational data is the information Business Transaction Management gathers about user applications: performance and behavioral metrics, logged messages, transaction instances, and generated alerts. This information is stored in the Measurement, Transaction, and Agent Message log databases shown in the figure.
System configuration data controls the basic behavior of Business Transaction Management: what databases it connects to, the address a container should use to connect to the sphere, default GUI views and layout. This information is saved in various configuration files: initial configuration data, GUI customization, setup data, container registration, and miscellaneous configuration files.
Backing up Business Transaction Management is fairly simple: you back up data contained in databases by backing up the respective database; you back up data contained in files or directories by backing up the
btmstorage directory can be found on every host where one of the Business Transaction Management system services or monitors is deployed. The location varies with your server.
For WebLogic, the location is the following:
For WebSphere, the location is the following:
Once you have backed up the databases and the
btmstorage directory, you are done with the backup process.
In general it is best to back up and recover all data, even if only a subset of your data has been damaged or lost. However, if you would like a more detailed understanding of the individual components used by Business Transaction Management, see Data Storage Reference.
The timing of backups is important: you should back up the databases and the
btmstorage directory as close together in time as possible. If possible, follow these guidelines:
Quiesce the system if possible.
Back up the
Back up the databases, with the Sphere data last.
The goal of restoring Business Transaction Management is to bring it back to the desired state with no side effects. Before you start this process, make sure that you have complete and accurate information about the Business Transaction Management system you are trying to restore.
It is assumed that you are restoring Business Transaction Management to the same environment from where it was backed up. If you need to recover to a different environment, for example, in the case of hardware failure; you will need to change the host name of the machine where you restore to (at the operating system level) to the host name of the machine that failed. You will also need to make sure that Business Transaction Management services hosted on the new machine can run on the same ports as on the old machine. It will then be possible to recover services to the new machine without disruption.
The restore procedure recovers the whole system to the last checkpoint created by the backup process.
Note:After the restore, the database schema and the file system must reflect the state they were in at the time of the backup. To make sure this happens, before you restore, check that the existing database and storage directory is completely clean. Because the data in the two storage locations are connected in various ways, problems can arise if either holds data that is newer than the backed up data. Thus, you should never restore a backup on top of an existing
btmstoragedirectory. Most database restores take care of this issue; be sure yours does.
The restore procedure consists of two steps:
btmstorage directory on each server hosting a system service or monitor.
In the case where there is some damage to the Business Transaction Management software itself because something has damaged or corrupted the installed instance, we recommend that you do the following.
Reinstall the Business Transaction Management software.
btmstorage directory on each server hosting a system service or monitor agent.
Restore the databases.
Note:If the damage affects only the EAR, WAR, or JAR files themselves, a simple re-installation of the Business Transaction Management software is all that is required
The following table offers some additional detail about the Business Transaction Management components. This detail might be helpful to understand the role of each component or to locate specific information.
|Sphere database||Description of Business Transaction Management system, monitoring and logging policies, transaction definitions, user application definitions.||Use the backup features of the Oracle database to create a backup.|
|Monitoring state||Information about whether and how each user endpoint is being monitored.
This data is also replicated in the sphere database; however the monitor agent's configuration file is considered the master source for this information. Although monitoring state data is backed up when you back up the sphere database (and restored when you restore it), that copy does not count, and if you recover an agent without capturing its original monitoring state, your endpoints will end up unmonitored.
|Back up the
|Operational data||Information Business Transaction Management gathers about user applications. This data is stored in the Performance Manager's database, the Transaction Manger's database, and the message log database. These might be located on the same physical database, but they are considered to be distinct databases.||Use the backup features of the Oracle database to create backups.|
|Initial configuration data||By default, information gathered from the user's initial configuration of Business Transaction Management is saved in the file
This information includes the location of databases used by Business Transaction Management, deployment credentials, and database type.
|Back up the
|UI customization||Information about customizations done by the administrator and preferences and views created by the user. By default, this information is stored in files in the following directories:
|Back up the
|Monitor registration||Registration information about monitor agents that you have added to the system.||Back up the
|System Service setup||Setup data for each of the Business Transaction Management system services.||Back up the
|Miscellaneous scripts and configuration||In the course of configuring Business Transaction Management, you might create various configuration scripts: for example, scripts to configure email subscriptions known to the notifier service or scripts to set up baseline performance values.||Back up the
If you have stored scripts anywhere else, back up that directory as well.