Skip Headers

Oracle® Application Server Administrator's Guide 10g Release 3 (10.1.3) B25209-01 |
| Home | Solution Area | Contents | Index

Previous | Next |

# 18 Recovery Strategies and Procedures

This chapter describes Oracle Application Server recovery strategies and procedures for different types of failures and outages.

It contains the following topics:

- Recovery Strategies

- Recovery Procedures

## 18.1 Recovery Strategies

This section describes Oracle Application Server recovery strategies for different types of failures and outages. It contains the following topics:

- Recovery Strategies for Data Loss, Host Failure, or Media Failure (Critical)

- Recovery Strategies for Process Failures and System Outages (Non-Critical)

### 18.1.1 Recovery Strategies for Data Loss, Host Failure, or Media Failure (Critical)

This section describes recovery strategies for outages that involve actual data loss or corruption, host failure, or media failure where the host or disk cannot be restarted and are permanently lost. This type of failure requires some type of data restoration before the Oracle Application Server environment can be restarted and continue with normal processing.

The strategies in this section use point-in-time recovery of the middle tier.

Assumptions

The following assumption applies to the recovery strategies in this section:

- No administrative changes were made since the last backup. If administrative changes were made since the last backup, they will need to be reapplied after recovery is complete.

  See Also: Appendix E, "Examples of Administrative Changes" to learn more about administrative changes

Determining Which Strategy to Use

Recovery strategies are listed in the following tables:

- Table 18-1, "Recovery Strategies for Data Loss, Host Failure, and Media Failure in Middle-Tier Instances"

  Use this table if you experience data loss, host failure, or media failure in a middle-tier installation. Find the type of loss and follow the recommended procedure.

Table 18-1 Recovery Strategies for Data Loss, Host Failure, and Media Failure in Middle-Tier Instances

Type of Loss | Recovery Strategies
--- | ---
Loss of host | If the host has been lost, you have two options: You can restore to a new host that has the same hostname and IP address. You can restore to a new host that has a different hostname and IP address. In either case, follow the procedure in Section 18.2.2, "Restoring a Middle-Tier Installation to a New Host". Note that if the original host had a middle-tier installation and an Infrastructure, you cannot restore the middle-tier to a host with a different hostname or IP address.
Oracle software/binary deletion or corruption | If any Oracle binaries have been lost or corrupted, you must restore the entire middle tier to the same host. Follow the procedure in Section 18.2.1, "Restoring a Middle-Tier Installation to the Same Host".
Deletion or corruption of configuration files | If you lose any configuration files in the middle-tier Oracle home, you can restore them. Follow the procedure in Section 18.2.3, "Restoring Middle-Tier Configuration Files".

### 18.1.2 Recovery Strategies for Process Failures and System Outages (Non-Critical)

This section describes recovery strategies for process failures and system outages. These types of outages do not involve any data loss, and therefore do not require any files to be recovered. In some cases, failure may be transparent and no manual intervention is required to recover the failed component. However, in some cases, manual intervention is required to restart a process or component. While these strategies do not strictly fit into the category of backup and recovery, they are included in this book for completeness.

Determining Which Strategy to Use

Recovery strategies for process failures and system outages are listed in Table 18-2, "Recovery Strategies for Process Failures and System Outages in Middle-Tier Instances"

Use this table if you experience a failure or outage on a middle-tier installation. Find the type of outage and follow the recommended procedure. The table contains UNIX commands. You can use the same commands on Windows by inverting the slashes.

Table 18-2 Recovery Strategies for Process Failures and System Outages in Middle-Tier Instances

Type of Outage | How to Check Status and Restart
--- | ---
Host failure—no data loss | To restart: Restart the host. Start the middle tier. Refer to Section 3.2.1, "Starting a Middle-Tier Instance"
Application Server Control Console failure | To check status:
    opmnctl status
To restart:
    opmnctl startproc process-type=OC4J_instance_name
Oracle HTTP Server process failure | To check status:
    opmnctl status
To restart:
    opmnctl startproc ias-component=HTTP_Server
OC4J instance failure | To check status:
    opmnctl status
To restart:
    opmnctl startproc process-type=OC4J_instance_name
OPMN daemon failure | To check status:
    opmnctl status
To restart:
    opmnctl start

## 18.2 Recovery Procedures

This section contains the procedures for performing different types of recovery.

It contains the following topics:

- Restoring a Middle-Tier Installation to the Same Host

- Restoring a Middle-Tier Installation to a New Host

- Restoring Middle-Tier Configuration Files

- Restoring an Oracle Application Server Instance

### 18.2.1 Restoring a Middle-Tier Installation to the Same Host

To restore a middle-tier installation to the same host, refer to Section 17.3.4, "Recovering an Instance on the Same Host".

### 18.2.2 Restoring a Middle-Tier Installation to a New Host

This section describes how to restore and recover a middle-tier installation to a new host. You can use this procedure to:

- Restore a middle-tier installation to the same host after the operating system has been reinstalled.

- Restore a middle-tier installation to a new host. The new host may have the same hostname and IP address as the original host, or a different hostname, IP address, or both.

Perform the steps in Section 17.3.3, "Restoring a Node on a New Host" to restore the image backup, system files, and instance reconfiguration. Note that the middle tier configuration remains in the same state as the original instance. If the hostname remains the same, run an instance restore to bring the instance to the desired point in time. If the hostname is different, the state cannot be changed since backups of the original host are not valid for a different hostname.

### 18.2.3 Restoring Middle-Tier Configuration Files

This section describes how to restore the configuration files in a middle-tier Oracle home. Use this procedure when configuration files have been lost or corrupted.

It contains the following tasks:

- Task 1: Stop the Middle-Tier Instance

- Task 2: Restore Middle-Tier Configuration Files

- Task 3: Apply Recent Administrative Changes

- Task 4: Start the Middle-Tier Instance

Task 1: Stop the Middle-Tier Instance

Refer to Section 3.2.2, "Stopping a Middle-Tier Instance" for instructions.

Task 2: Restore Middle-Tier Configuration Files

Restore all configuration files from your most recent backup. You can perform this task using your own procedure or OracleAS Recovery Manager. For example, to do this using OracleAS Recovery Manager:

- For UNIX systems:

      bkp_restore.sh -m restore_config -t timestamp

- For Windows systems:

      bkp_restore.bat -m restore_config -t timestamp

See Also: Chapter 16, "Oracle Application Server Recovery Manager" for more information

Task 3: Apply Recent Administrative Changes

If you made any administrative changes since the last time you did an online backup, reapply them now.

See Also: Appendix E, "Examples of Administrative Changes" to learn more about administrative changes

Task 4: Start the Middle-Tier Instance

Refer to Section 3.2.1, "Starting a Middle-Tier Instance" for instructions.

### 18.2.4 Restoring an Oracle Application Server Instance

Use the following command to restore an Oracle Application Server instance to a particular point in time:

    bkp_restore.sh -m restore_instance -t 2004-09-21_06-12-45

    bkp_restore.bat -m restore_instance -t 2004-09-21_06-12-45

Before performing a restore operation (`restore_instance` or `restore_config`) on an instance in a cluster, all OC4J processes across the cluster must be stopped. Use the following command to stop the processes:

    ORACLE_HOME/opmn/bin/opmnctl @cluster stopproc ias-component=OC4J

Some OC4J components do not have `ias-component=OC4J`. For these components use the uniqueid value to stop the OC4J process. To determine which components have a uniqueid, use the following command:

    ORACLE_HOME\opmn\bin\opmnctl @cluster status -fmt %typ%uid%prt -noheaders

The following is an example of the output from the command:

    CUSTOM | N/A | ASG
    LOGLDR | N/A | logloaderd
    OHS | 1500577870 | HTTP_Server
    performance | 1500577873 | performance_server
    messaging | 1500577874 | messaging_server

Stop all the OC4J processes, for which the second column (uid) value is not "N/A", with the following command:

    ORACLE_HOME\opmn\bin\opmnctl @cluster stopproc uniqueid=1500577865

    opmnctl: stopping opmn managed processes...

After the restore operation is complete, use the following command to restart the OC4J processes across the cluster:

    ORACLE_HOME/opmn/bin/opmnctl @cluster startproc ias-component=OC4J

For components that use `uniqueid`, you can restart their process by using the appropriate ias-component value or by using the following command:

    opmnctl startall