| Oracle® Application Server Administrator's Guide 10g Release 3 (10.1.3.2.0) Part Number B32196-01 |
|
|
View PDF |
| Oracle® Application Server Administrator's Guide 10g Release 3 (10.1.3.2.0) Part Number B32196-01 |
|
|
View PDF |
This chapter describes Oracle Application Server recovery strategies and procedures for different types of failures and outages.
It contains the following topics:
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)
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 changesDetermining Which Strategy to Use
Recovery strategies are listed in Table 18-1.
Use the information in 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:
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". |
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.
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:
|
|
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 |
This section contains the procedures for performing different types of recovery.
It contains the following topics:
To restore a middle-tier installation to the same host, refer to Section 17.3.4, "Recovering an Instance on the Same 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.
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
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 informationTask 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 changesTask 4: Start the Middle-Tier Instance
Refer to Section 3.2.1, "Starting a Middle-Tier Instance" for instructions.
Use the following command to restore an Oracle Application Server instance to a particular point in time:
bkp_restore.sh -m restore_instance -t 2006-09-21_06-12-45 bkp_restore.bat -m restore_instance -t 2006-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 an 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 completes, 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
To recover the JPS portlet producer preference store, perform the following steps:
Stop the OC4J instance on which the container runs.
Run the migration tool to restore data from the source backup file to the destination preference store. For example:
java -classpath wsrp-container.jar:cache.jar:saaj-api.jar:orasaaj.jar:ojdbc14.jar oracle.portlet.server.containerimpl.PersistenceMigrationTool -sourceType file -destType db -sourcePath /tmp/portletbkp -destUsername p1 -destPassword p1 -destDatabase portaldb.mycompany.com:1521:orcl
Start the OC4J instance on which the portlet container runs.
For more information about the JPS portlet migration utility, refer to Oracle WebCenter Framework Developer's Guide.
To recover the PDK-Java portlet producer preference store, perform the following steps:
Stop the OC4J instance on which the container runs.
Run the migration tool to restore data from the source backup file to the destination preference store. For example:
java -classpath $ORACLE_HOME/portal/jlib/pdkjava.jar oracle.portal.provider.v2.preference.MigrationTool -mode filetodb -remap locale -countries AR,MX -pref1UseHashing true -pref1RootDirectory /tmp/portletbkp -pref2User portlet_prefs -pref2Password portlet_prefs -pref2URL jdbc:oracle:thin:@myserver.mydomain.com:1521:mysid
Start the OC4J instance on which the portlet container runs.
For more information on the PDK-Java migration and upgrade utility, refer to Oracle WebCenter Framework Developer's Guide.
