|
Oracle® Application Server Administrator's Guide
10g Release 2 (10.1.2) Part No. B13995-01 |
|
 Previous |
 Next |
|
Oracle® Application Server Administrator's Guide
10g Release 2 (10.1.2) Part No. B13995-01 |
|
|
Previous |
Next |
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 Crashes 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 (middle tier, Infrastructure, or both) can be restarted and continue with normal processing.
The strategies in this section use point-in-time recovery of the middle tier and Infrastructure. This means that, no matter where the loss occurred, the Infrastructure and the middle tier are always restored together so they are in sync as they were at the time of the last backup. Notice that in an Oracle Application Server environment recovery, the Infrastructure is always restored before the middle tier.
Assumptions
The following assumptions apply to the recovery strategies in this section:
ARCHIVELOG mode was enabled for all Metadata Repository backups.
Complete recovery of the database can be performed, that is, no redo log files have been lost.
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 G, "Examples of Administrative Changes" to learn more about administrative changes |
Determining Which Strategy To Use
Recovery strategies are listed in the following tables:
Table 20-1, "Recovery Strategies for Data Loss, Host Failure, and Media Failure in Infrastructures"
Use this table if you experience data loss, host failure, or media failure in an Infrastructure installation. Find the type of loss and follow the recommended procedure. The procedures apply to Infrastructure that are installed into a single Oracle home, as well as Infrastructures with Identity Management in one Oracle home and a Metadata Repository in another Oracle home or host.
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.
If the loss occurred in both the Infrastructure and middle tier, follow the Infrastructure recovery strategy first, then the middle tier.
Table 20-1 Recovery Strategies for Data Loss, Host Failure, and Media Failure in Infrastructures
| Type of Loss | Recovery Strategies |
|---|---|
| Loss of host | You can restore to a new host that has the same hostname and IP address.
Follow the procedure in Section 20.2.2, "Restoring an Infrastructure to a New Host". |
| Oracle software/binary loss or corruption | If any Oracle binaries have been lost or corrupted, you must recover the entire Infrastructure.
Follow the procedure in Section 20.2.1, "Restoring an Infrastructure to the Same Host". |
| Database or data failure of the Metadata Repository (datafile loss, control file loss, media failure, disk corruption) | If the Metadata Repository is corrupted due to data loss or media failure, you can restore and recover it.
Follow the procedure in Section 20.2.4, "Restoring and Recovering the Metadata Repository". |
| Deletion or corruption of configuration files | If you lose any configuration files in the Infrastructure Oracle home, you can restore them.
Follow the procedure in Section 20.2.5, "Restoring Infrastructure Configuration Files". |
| Deletion or corruption of configuration files and data failure of the Metadata Repository | If you lose configuration files and the Metadata Repository is corrupted, you can restore and recover both.
Follow these procedures: |
Table 20-2 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 20.2.7, "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 20.2.6, "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 20.2.8, "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 the following tables:
Table 20-3, "Recovery Strategies for Process Crashes and System Outages in Infrastructures"
Use this table if you experience a failure or outage in an Infrastructure. Find the type of outage and follow the recommended procedure. The procedures apply to Infrastructures that are installed into a single Oracle home, as well as Infrastructures with Identity Management in one Oracle home and a Metadata Repository in another Oracle home or host.
Table 20-4, "Recovery Strategies for Process Crashes 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, or you can use the Services tool in the Control Panel.
Table 20-3 Recovery Strategies for Process Crashes and System Outages in Infrastructures
| Type of Outage | How to Check Status and Restart |
|---|---|
| Host failure - no data loss | To restart:
|
| Metadata Repository instance failure (loss of the contents of a buffer cache or data residing in memory) | To check status:
SQL> select status from v$instance; To restart: sqlplus /nolog
SQL> connect sys/password as sysdba
SQL> startup
SQL> quit
|
| Metadata Repository listener failure | To check status:
lsnrctl status To restart: lsnrctl start |
Oracle Internet Directory server process (oidldapd) failure
|
To check status:
ldapcheck To restart: opmnctl startproc ias-component=OID |
Oracle Internet Directory monitor process (oidmon) failure
|
To check status:
ldapcheck To restart: opmnctl startproc ias-component=OID |
| Application Server Control Console failure | To check status:
To restart: emctl start iasconsole |
| 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
|
| Delegated Administration Service instance failure | To check status:
opmnctl status To restart: opmnctl startproc ias-component=OC4J process-type=OC4J_SECURITY |
| OPMN daemon failure | To check status:
opmnctl status To restart: opmnctl start |
Table 20-4 Recovery Strategies for Process Crashes and System Outages in Middle-tier Instances
| Type of Outage | How to Check Status and Restart |
|---|---|
| Host crash - no data loss | To restart:
|
| Application Server Control Console failure | To check status:
To restart: emctl start iasconsole |
| 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 |
| OracleAS Web Cache failure | To check status:
opmnctl status To restart: opmnctl startproc ias-component=WebCache |
This section contains the procedures for performing different types of recovery.
It contains the following topics:
This section describes how to restore an Infrastructure to the same host. You can use this procedure when you have lost some or all of your Oracle binaries.
It contains the following tasks:
Task 1: Stop the Infrastructure
Refer to Section 3.2.2, "Stopping OracleAS Infrastructure" for instructions.
Task 2: Restore the Infrastructure Oracle Home
|
Note: If your Infrastructure is split and has Identity Management in one Oracle home, and the Metadata Repository in another Oracle home, perform this task on both Oracle homes. |
Restore the backup (tar, cpio) of the Infrastructure Oracle home from your complete Oracle Application Server environment backup. Be sure your method of restoring the files preserves the original owner, group, permissions, and timestamps.
Task 3: Restore Infrastructure Configuration Files
|
Note: If your Infrastructure is split and has Identity Management in one Oracle home, and the Metadata Repository in another Oracle home, perform this step on both Oracle homes. |
Restore all configuration files from your most recent backup. You can perform this task using your own procedure or the OracleAS Backup and Recovery Tool. For example, to do this using the tool:
For UNIX systems:
bkp_restore.sh -m restore_config -t timestamp
For Windows systems:
bkp_restore.bat -m restore_config -t timestamp
Task 4: Restore and Recover the Metadata Repository
Restore and recover the Metadata Repository from your latest backup. You can perform this task using your own procedure or the OracleAS Backup and Recovery Tool.
|
See Also: Section 20.2.4, "Restoring and Recovering the Metadata Repository" to determine the best method for restoring and recovering the Metadata Repository |
Task 5: Start the Infrastructure
Refer to Section 3.2.1, "Starting OracleAS Infrastructure" for instructions.
|
Note: If you receive a WWC-41439 error while trying to login to the Portal Home page, do one or all of the following:
|
This section describes how to restore an Infrastructure to a host with the same hostname and IP address as the original host. You can use this procedure to:
Restore an Infrastructure to the same host after the operating system has been reinstalled. The hostname and IP address must remain the same on the host.
Restore an Infrastructure to a new host that has the same hostname and IP address as the original host.
It contains the following tasks:
Task 1: Prepare the New Host
If you are restoring to a new host, make sure it has an identical system configuration to the original host. Refer to the record you created in Section 19.2.3, "Creating a Record of Your Oracle Application Server Configuration".
On the new host, make sure the following is identical to the original host:
Hostname
Virtual hostname
Domain name
IP address
Hardware platform
Operating system release and patch levels
Make sure the entry for the new host in /etc/hosts is identical to the original /etc/hosts file. Make sure the values for IP address, hostname, and aliases are identical and in the same order.
Check port usage on the new host. Make sure there aren't any processes using the same ports as the Oracle Application Server installations you are about to restore. If there are, you must reconfigure these processes to use different ports before you begin restoring your Oracle Application Server installations.
On the new host, create an operating system user that is identical to the user who installed Oracle Application Server on the original host. The following attributes should be the same:
User name
Numerical userid
Group name
Numerical groupid
Environment profile
Shell
The user may have the same password or a different password than the original user.
Create the Infrastructure Oracle home:
Create an empty Oracle home directory using the same mount point and full path as the original Infrastructure Oracle home. Do not use symbolic links anywhere in the path. Make sure the directory is on a file system with enough space to hold the Infrastructure and that the directory is owned by the same user and group as on the original host.
Task 2: Restore Oracle System Files and the Infrastructure Oracle Home
This step varies for UNIX and Windows systems.
On UNIX systems:
Restore the Oracle system files from your complete Oracle Application Server environment backup. For example, these files may be in /var/opt/oracle or /etc.
If the oraInventory directory resided in a directory that was separate from the Infrastructure Oracle home, restore it.
Restore the backup (tar, cpio) of the Infrastructure Oracle home from your complete Oracle Application Server environment backup. Be sure your method of restoring the files preserves the original owner, group, permissions, and timestamps.
|
Note: If your Infrastructure is split and has Identity Management in one Oracle home, and the Metadata Repository in another Oracle home, perform this step on both Oracle homes. |
On Windows systems:
Export registry entries pertaining to HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE by running regedit and exporting to a file.
Using the SC tool from the Windows Resource Kit, create services for the following:
opmn
sc create Oracle<home name>ProcessManager start= auto binPath= "ORACLE_HOME\opmn\bin\opmn.exe -S" For example: sc create OracleINFRAProcessManager start= auto binPath= "INFRAHOME\opmn\bin\opmn.exe -S"
em
sc create Oracle<home name>ASControl start= auto binPath="ORACLE_HOME\bin\nmesrvc.exe" For example: sc create OracleINFRAASControl start= auto binPath="INFRAHOME\bin\nmesrvc.exe"
listener
sc create Oracle<home name>TNSListener start= auto binPath="ORACLE_HOME\bin\TNSLSNR" For example: sc create OracleINFRATNSListener start= auto binPath="INFRAHOME\bin\TNSLSNR"
cluster services
sc create OracleCSService start= auto binPath="ORACLE_HOME\bin\ocssd.exe service" For example: sc create OracleCSService start= auto binPath="INFRAHOME\bin\ocssd.exe service"
database console
sc create OracleDBConsole<oracle_sid> start= auto binPath="ORACLE_HOME\bin\nmesrvc service" For example: sc create OracleDBConsoleorcl start= auto binPath="INFRAHOME\bin\nmesrvc service" Note: oracle_sid should be in lower case.
job scheduler
sc create OracleJobScheduler<oracle_sid> start= auto binPath="ORACLE_HOME\bin\extjob.exe <oracle_sid>" For example: sc create OracleJobSchedulerORCL start= auto binPath="INFRAHOME\bin\extjob.exe <oracle_sid>" Note: oracle_sid should be in upper case.
db service
sc create OracleService<oracle_sid> start= auto binPath="ORACLE_HOME\bin\extjob.exe <oracle_sid>" For example: sc create OracleServiceORCL start= auto binPath="INFRAHOME\bin\extjob.exe <oracle_sid>" Note: oracle_sid should be in upper case.
Task 3: Restore and Recover the Metadata Repository
Restore and recover the Metadata Repository from your latest complete Oracle Application Server environment backup or online backup, whichever was most recent.
|
See Also: Section 20.2.4, "Restoring and Recovering the Metadata Repository" to determine the best method for restoring and recovering the Metadata Repository |
After restoring the metadata repository, perform the following steps:
Start the listener process using the following command:
ORACLE_HOME/bin/lsnrctl start
Start the opmn process using the following command:
opmnctl start
Start the Oracle Internet Directory process using the following command:
opmnctl startproc ias-component=OID
Task 4: Restore Infrastructure Configuration Files
|
Note: If your Infrastructure is split and has Identity Management in one Oracle home, and the Metadata Repository in another Oracle home, perform this task on both Oracle homes. |
Restore all configuration files from your most recent backup:
On UNIX systems:
bkp_restore.sh -m restore_config -t timestamp
On Windows systems:
bkp_restore.bat -m restore_config -t timestamp
Task 5: Start the Infrastructure
Start OracleAS Infrastructure by performing the following steps:
Start all OPMN-managed processes (such as DCM, Oracle HTTP Server, and OC4J instances):
ORACLE_HOME/opmn/bin/opmnctl startall
Start the Application Server Control Console:
ORACLE_HOME/bin/emctl start iasconsole
This section describes how to restore an Identity Management instance to a new host with the same hostname as the original host. You can use this procedure to:
Restore Identity Management to the same host after the operating system has been reinstalled. The hostname and IP address must remain the same on the host.
Restore Identity Management to a new host that has the same hostname as the original host. The IP address may not be the same.
This section contains the following tasks:
Task 3: Restore Oracle System Files and the Identity Management Oracle Home
Task 4: Start Processes on Metadata Repository Instance (DCM Database Repository Only)
Task 7: Restart the Mid-tier Instances Using the Identity Manangement Host
Task 1: Restart the Metadata Repository Host
If the IP Address of the new host is different from the original host, perform the following steps on the Metadata Repository host:
Shutdown the Metadata Repository instance.
Startup the Metadata Repository instance.
Task 2: Prepare the New Host
If you are restoring to a new host, use the following steps to configure the host. Refer to the record you created in Section 19.2.3, "Creating a Record of Your Oracle Application Server Configuration" for information about the configuration of the old host.
To prepare the host, in the same directory as in Task 1, perform the following steps:
On the new host, ensure the following parameter values are identical to the original host, and in the same order:
Hostname
Virtual hostname
Domain name
Hardware platform
Operating system release and patch levels
If you want the new host to be indentical to the old host, set the IP address to the IP address of the old host.
Check port usage on the new host. Ensure that there are not any processes using the same ports as the Oracle Application Server installation you are about to restore. If there are, you must reconfigure these processes to use different ports before you begin restoring your Oracle Application Server installation.
On the new host, create an operating system user that is identical to the user who installed Oracle Application Server on the original host. The following attributes should be the same:
User name
Numerical userid
Group name
Numerical groupid
Environment profile
Shell
The user may have the same password or a different password than the original user password.
Create an empty Oracle home directory using the same mount point and full path as the original Identity Management Oracle home. Do not use symbolic links anywhere in the path. Ensure that the directory is on a file system with enough space to hold Identity Management, and that the directory is owned by the same user and group as on the original host.
Task 3: Restore Oracle System Files and the Identity Management Oracle Home
Use the following procedures to restore Oracle system files and the Identity Management Oracle home.
On UNIX systems:
Restore the Oracle system files from your complete Oracle Application Server environment backup. These files might be located inon of these directories: /var/opt/oracle or /etc.
If the oraInventory directory resided in a directory that was separate from the Identity Management Oracle home, restore it.
Restore the backup (tar, cpio) of the Identity Management Oracle home from your complete Oracle Application Server environment backup. Be sure your method of restoring the files preserves the original owner, group, permissions, and timestamps.
On Windows systems:
Restore oraInventory and Oracle home backup. Import registry entries pertaining to HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE from the original host by running regedit.
Use the SC tool from the Windows Resource Kit to create services for the following:
opmn
sc create Oracle<Home name>ProcessManager start= auto binPath=ORACLE HOME\opmn\bin\opmn.exe -S
For example, if the Oracle home name is im, then the service name is OracleimProcessManager.
em
sc create Oracle<home name>ASControl start= auto binPath=ORACLE HOME\bin\nmesrvc.exe
For example, if the Oracle home name is im, then the service name is OracleimASControl.
Task 4: Start Processes on Metadata Repository Instance (DCM Database Repository Only)
If the DCM repository is a database, start the opmn and Oracle Internet Directory processes on the corresponding Metadata Repository instance.
Use the following command to start the OPMN process:
opmnctl start
Use the following command to start the Oracle Internet Directory process:
opmnctl startproc ias-component=OID
Use the following command to check if the DCM repository is a database or a file-based repository:
ORACLE_HOME/dcm/bin/dcmctl whichfarm
The command returns one of the following messages:
Repository Type: Database => uses a database repository Repository Type: Distributed File Based => uses a file based repository
Task 5: Restore Identity Management Configuration Files
Restore all configuration files from your most recent backup.
On UNIX systems:
bkp_restore.sh -m restore_config -t timestamp
On Windows systems:
bkp_restore.bat -m restore_config -t timestamp
Task 6: Start the Identity Management Instance
Start the Identity Management instance by performing the following steps:
Start all OPMN-managed processes (such as DCM, Oracle HTTP Server, and OC4J instances):
ORACLE_HOME/opmn/bin/opmnctl startall
Start the Application Server Control Console:
ORACLE_HOME/bin/emctl start iasconsole
Task 7: Restart the Mid-tier Instances Using the Identity Manangement Host
Perfom the following steps to restart the mid-tier instances using the Identity Management host:
On UNIX systems:
Stop all OPMN-managed processes (such as DCM, Oracle HTTP Server, and OC4J instances):
ORACLE_HOME/opmn/bin/opmnctl stopall
Stop the Application Server Control Console:
ORACLE_HOME/bin/emctl stop iasconsole
Start all OPMN-managed processes (such as DCM, Oracle HTTP Server, and OC4J instances):
ORACLE_HOME/opmn/bin/opmnctl startall
Start the Application Server Control Console:
ORACLE_HOME/bin/emctl start iasconsole
On Windows systems:
Stop all OPMN-managed processes (such as DCM, Oracle HTTP Server, and OC4J instances):
ORACLE_HOME\opmn\bin\opmnctl stopall
Stop the Application Server Control Console:
ORACLE_HOME\bin\emctl stop iasconsole
Start all OPMN-managed processes (such as DCM, Oracle HTTP Server, and OC4J instances):
ORACLE_HOME\opmn\bin\opmnctl startall
Start the Application Server Control Console:
ORACLE_HOME\bin\emctl start iasconsole
The section describes how to restore and recover the Metadata Repository. You can use this when there has only been corruption to the Metadata Repository, and not to any other files in the Oracle home.
Restore and recover the Metadata Repository from your latest backup using your own procedure or the OracleAS Backup and Recovery Tool. Restart all Infrastructure processes after restoring a Metadata Repository.
The following sections describe Oracle recommended procedures for using the OracleAS Backup and Recovery Tool to restore and recover the Metadata Repository:
Restoring and Recovering the Metadata Repository to the Same Host
Restoring and Recovering the Metadata Repository to a New Host
This section covers several circumstances under which you may need to restore and recover the Metadata Repository to the same host:
Corrupted or Lost Datafile
If a datafile is corrupted or lost, you can use the following command to restore from the latest backup and perform a full recovery:
For UNIX:
bkp_restore.sh -m restore_repos
For Windows:
bkp_restore.bat -m restore_repos
Corrupted or Lost Control File
If a control file is corrupted or lost, you can use the following command to restore a control file backup, restore the datafiles, and perform a full recovery:
For UNIX:
bkp_restore.sh -m restore_repos -c
For Windows:
bkp_restore.bat -m restore_repos -c
When you use the -c option, it restores the control file. This causes entries for tempfiles in locally-managed temporary tablespaces to be removed. You must add a new tempfile to the TEMP tablespace, or Oracle will display error ORA-25153: Temporary Tablespace is Empty.
To add a tempfile to the TEMP tablespace:
SQL> alter tablespace "TEMP" add tempfile 'ORACLE_HOME/oradata/GDB/ temp01.dbf' size 5120K autoextend on next 8k maxsize unlimited;
GDB is the first part of the global database name.
Note that when you restore a control file, the tool performs an "alter database open resetlogs." This invalidates all backups and archivelogs. You should immediately perform a complete cold backup of the Metadata Repository, which will serve as the new baseline for your subsequent partial online backups.
Point-in-time Recovery and Flashback Recovery
If you lost configuration files in your middle-tier or Infrastructure installation and restored those, you may want to restore or flashback the database to the same point-in-time as the configuration file backup. You can do this using one of the following commands:
For UNIX:
bkp_restore.sh -m restore_repos -u timestamp
bkp_restore.sh flashback_repos -u timestamp
For Windows:
bkp_restore.bat -m restore_repos -u timestamp
bkp_restore.bat flashback_repos -u timestamp
Flashback recovery to a point-in-time can undo any logical data corruption or user error. Flashback cannot undo physical data corruption due to media failure. Using the restore-repos command, you can recover and restore the database to a point-in-time for both logical and physical data corruption. However, Flashback is faster at recovering logical data corruption because it does not require restoring backups.
You can specify any time between the time of your first backup and the current time, as long as none of the online redo logs were compromised. If any online redo logs are missing or corrupted, the latest time that can be specified is the time at which the last backup was made.
Note that when you do point-in-time recovery, the tool performs an "alter database open resetlogs." This invalidates all backups and archivelogs. You should immediately perform a complete cold backup of the Metadata Repository, which will serve as the new baseline for your subsequent partial online backups.
When you restore the Metadata Repository to a new host (with the same hostname and IP address), the new host will not have the online redo logs that existed on the original host. Therefore, you cannot perform a full recovery—RMAN would give an error stating that it cannot find a certain log file (the online redo log file). Instead, you should do a point-in-time recovery using a time sometime between the first and most recent backup. You can do this using the following command:
For UNIX:
bkp_restore.sh -m restore_repos -c -u timestamp
For Windows:
bkp_restore.bat -m restore_repos -c -u timestamp
If this command returns an error and the log shows that the datafiles were restored and recovered, then issue an "alter database open resetlogs" and the database will be opened in a consistent state. If no datafiles were restored and recovered, it is most likely that an early timestamp was specified and you should retry the command with a later timestamp.
When you use the -c option, it restores the control file. This causes entries for tempfiles in locally-managed temporary tablespaces to be removed. You must add a new tempfile to the TEMP tablespace, or Oracle will display error ORA-25153: Temporary Tablespace is Empty.
To add a tempfile to the TEMP tablespace:
SQL> alter tablespace "TEMP" add tempfile 'ORACLE_HOME/oradata/GDB/ temp01.dbf' size 5120K autoextend on next 8k maxsize unlimited;
GDB is the first part of the global database name.
Note that whenever you restore the Metadata Repository to a new host, the control file will be restored from backup. This means that an "alter database open resetlogs" is always done, which invalidates all backups and archivelogs. You should immediately perform a complete cold backup of the Metadata Repository, which will serve as the new baseline for your subsequent partial online backups.
This section describes how to restore the configuration files in an Infrastructure Oracle home. You can use this procedure when configuration files have been lost or corrupted.
It contains the following tasks:
Task 1: Stop the Infrastructure
Refer to Section 3.2.2, "Stopping OracleAS Infrastructure" for instructions.
Task 2: Restore Infrastructure Configuration Files
|
Note: If your Infrastructure is split and has Identity Management in one Oracle home, and the Metadata Repository in another Oracle home, perform this task on both Oracle homes. |
Restore all configuration files from your most recent backup. You can perform this task using your own procedure or the OracleAS Backup and Recovery Tool. For example, to do this using the tool:
On UNIX systems:
bkp_restore.sh -m restore_config -t timestamp
On Windows systems:
bkp_restore.bat -m restore_config -t timestamp
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 G, "Examples of Administrative Changes" to learn more about administrative changes |
Task 4: Start the Infrastructure
Refer to Section 3.2.1, "Starting OracleAS Infrastructure" for instructions.
This section describes how to restore a middle-tier installation to the same host. You can use this procedure when you have lost some or all of your Oracle binaries.
It contains the following steps:
Task 1: Stop the Middle-tier Instance
Refer to Section 3.2.4, "Stopping a Middle-Tier Instance" for instructions.
If the middle-tier instance uses a DCM repository (file-based or database), make sure the DCM repository is up.
Task 2: Restore the Middle-tier Oracle Home
Restore the backup (tar, cpio) of the middle-tier Oracle home from your complete Oracle Application Server environment backup. Be sure your method of restoring the files preserves the original owner, group, permissions, and timestamps.
Task 3: Restore Middle-tier Configuration Files
Restore all configuration files from your most recent backup. You can perform this task using your own procedure or the OracleAS Backup and Recovery Tool. For example, to do this using the tool:
For UNIX systems:
bkp_restore.sh -m restore_config -t timestamp
For Windows systems:
bkp_restore.bat -m restore_config -t timestamp
|
Note: For a file-based repository, ensure that DCM is up on the repository host. |
Task 4: Start the Middle-tier Instance
Refer to Section 3.2.3, "Starting a Middle-Tier Instance" for instructions.
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.
It contains the following tasks:
Task 4: Start the Processes on the Infrastructure Instance (DCM Database Repository Only)
Task 5: Restore the Middle-tier Configuration Files for Non-DCM Managed Components
Task 6: Update the Host Information for DCM Managed Components
Task 7: Update the Host Information for Non-DCM Managed Components
Task 1: Prepare the New Host
If you are restoring to a new host, make sure it has an identical system configuration to the original host. Refer to the record you created in Section 19.2.3, "Creating a Record of Your Oracle Application Server Configuration".
On the new host, make sure the following is identical to the original host:
Hardware platform
Operating system release and patch levels
The new host may have the same or different hostname and IP address.
Make sure the entry for the new host in /etc/hosts lists the IP address, hostname, and aliases in the same order as the original /etc/hosts file.
Check port usage on the new host. Make sure there are not any processes using the same ports as the Oracle Application Server installations you are about to restore. If there are, you must reconfigure these processes to use different ports before you begin restoring your Oracle Application Server installations.
On the new host, create an operating system user that is identical to the user who installed Oracle Application Server on the original host. The following attributes should be the same:
User name
Numerical userid
Group name
Numerical groupid
Environment profile
Shell
The user may have the same password or a different password than the original user.
Create the middle-tier Oracle home:
Create an empty Oracle home directory using the same mount point and full path as the original middle-tier Oracle home. Do not use symbolic links anywhere in the path. Ensure that the directory is on a file system with enough space to hold the middle-tier installation, and that the directory is owned by the same user and group as on the original host.
Task 2: Restore Oracle System Files
This task varies for UNIX and Windows systems.
On UNIX systems:
Restore the Oracle system files from your complete Oracle Application Server environment backup. For example, these files may be in /var/opt/oracle or /etc.
On Windows systems:
Import registry entries, from the original node, pertaining to HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE by running regedit.
Using the SC tool from the Windows Resource Kit, create services for the following:
opmn
sc create Oracle<home name>ProcessManager start= auto binPath= "ORACLE_HOME\opmn\bin\opmn.exe -S" For example: sc create OracleMIDTIERProcessManager start= auto binPath= "MIDTIERHOME\opmn\bin\opmn.exe -S"
em
sc create Oracle<home name>ASControl start= auto binPath= "ORACLE_HOME\bin\nmesrvc.exe" For example: sc create OracleMIDTIERASControl start= auto binPath= "MIDTIER\bin\nmesrvc.exe"
Task 3: Restore the Middle-tier Oracle Home
Use the following procedure to restore the middle-tier Oracle home:
If the oraInventory directory resided in a directory that was separate from the middle-tier Oracle home, restore it.
Restore the backup (tar, cpio) of the middle-tier Oracle home from your complete Oracle Application Server environment backup. Ensure that your method of restoring the files preserves the original owner, group, permissions, and timestamps.
Check ORACLE_HOME/opmn/conf/opmn.xml for <variable id="TMP" value="XXX"/>. If the XXX dir doesn't exist, create it.
Task 4: Start the Processes on the Infrastructure Instance (DCM Database Repository Only)
If the DCM repository is a database, start the opmn and Oracle Internet Directory processes on the corresponding infrastructure instance.
Use the following command to start the OPMN process:
opmnctl start
Use the following command to start the Oracle Internet Directory process:
opmnctl startproc ias-component=OID
Use the following command to check if the DCM repository is a database or a file-based repository:
ORACLE_HOME/dcm/bin/dcmctl whichfarm
The preceding command returns one of the following messages:
Repository Type: Database => uses a database repository Repository Type: Distributed File Based => uses a file based repository
Task 5: Restore the Middle-tier Configuration Files for Non-DCM Managed Components
For non-DCM managed components, restore all configuration files from your most recent backup:
For UNIX systems:
bkp_restore.sh -m restore_config -t timestamp -F noDCM
For Windows systems:
bkp_restore.bat -m restore_config -t timestamp -F noDCM
Task 6: Update the Host Information for DCM Managed Components
Run the following command to modify the host information for DCM managed components:
ORACLE_HOME/dcm/bin/dcmctl resethostinformation
Task 7: Update the Host Information for Non-DCM Managed Components
Create a backup copy of the configtool.xml.tmpl file. The file directory is ORACLE_HOME/chgip/config/. Save the backup copy to another directory. Edit the original configtool.xml.tmpl file and remove the following lines pertaining to the updateConfig parameter:
<ConfigTool Name="DCM" Desc="Distributed Configuration Manager" InstallType="Core"> <Command>%ORACLE_HOME%\dcm\bin\dcmctl.bat</Command> <Parameter Name="" Value="updateConfig"/> </ConfigTool> <ConfigTool Name="DCM" Desc="Distributed Configuration Manager" InstallType="Portals"> <Command>%ORACLE_HOME%\dcm\bin\dcmctl.bat</Command> <Parameter Name="" Value="updateConfig"/> </ConfigTool> <ConfigTool Name="DCM" Desc="Distributed Configuration Manager" InstallType="BIServices"> <Command>%ORACLE_HOME%\dcm\bin\dcmctl.bat</Command> <Parameter Name="" Value="updateConfig"/> </ConfigTool> <ConfigTool Name="DCM" Desc="Distributed Configuration Manager" InstallType="Infrastructure_ID"> <Command>%ORACLE_HOME%\dcm\bin\dcmctl.bat</Command> <Parameter Name="" Value="updateConfig"/> </ConfigTool> <ConfigTool Name="DCM" Desc="Distributed Configuration Manager" InstallType="Infrastructure"> <Command>%ORACLE_HOME%\dcm\bin\dcmctl.bat</Command> <Parameter Name="" Value="updateConfig"/> </ConfigTool> <ConfigTool Name="DCM" Desc="Distributed Configuration Manager" InstallType="OCS"> <Command>%ORACLE_HOME%\dcm\bin\dcmctl.bat</Command> <Parameter Name="" Value="updateConfig"/> </ConfigTool>
Save the file, and then run the chgiphost script:
On UNIX:
ORACLE_HOME/chgip/scripts/chgiphost.sh -mid
On Windows:
ORACLE_HOME/chgip/scripts/chgiphost.bat -mid
Task 8: Restore DCM Managed Components
Use the following commands to restore DCM managed components:
On UNIX:
bkp_restore.sh -m restore_config -F dcm-resyncforce
On Windows:
bkp_restore.bat -m restore_config -F dcm-resyncforce
Task 9: Start the Middle-tier Instance
Perform the following steps to start the Middle-tier instance.
Start OPMN and OPMN-managed processes:
ORACLE_HOME/opmn/bin/opmnctl startall
Start the Application Server Control Console:
ORACLE_HOME/bin/emctl start iasconsole
Task 10: Update Host Information for DCM Managed Components
The chgiphost script must be run with the updateConfig parameter in ORACLE_HOME/chgip/config/configtool.xml.tmpl file. Use the original version of configtool.xml.tmpl file. Replace the modified version of this file (from task 7) with the backed-up copy.
Run the chgiphost script to update the host information for DCM managed components:
chgiphost.sh -mid
|
Note: There is a special step required for updating OracleAS Portal and OracleAS Wireless when you change the hostname.When you change the hostname, the OracleAS Wireless server URL changes to use the new hostname. You must update OracleAS Portal with the new OracleAS Wireless service URL.Refer to the section on "Updating the Oracle AS Wireless Portal Service URL Reference" in "Oracle Application Server Portal Configuration Guide" for instructions. |
Task 11: Set the New Hostname and IP Address (If Required)
If the new host has a different hostname or IP address as the original host, follow the procedures in Section 8.2, "Changing Your Hostname, Domain Name, or IP Address" to change the hostname, IP address, or both, as required.
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.4, "Stopping a Middle-Tier Instance" for instructions.
If the middle-tier instance uses a DCM repository (file-based or database), make sure the DCM repository is up.
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 the OracleAS Backup and Recovery Tool. For example, to do this using the tool:
For UNIX systems:
bkp_restore.sh -m restore_config -t timestamp
For Windows systems:
bkp_restore.bat -m restore_config -t timestamp
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 G, "Examples of Administrative Changes" to learn more about administrative changes |
Task 4: Start the Middle-tier Instance
Refer to Section 3.2.3, "Starting a Middle-Tier Instance" for instructions.
This section describes how to restore a DCM file-based repository to a new host. This section contains the following tasks:
Task 4: Restore the Middle-tier Configuration Files for Non-DCM Managed Components
Task 5: Update the Host Information for DCM Managed Components
Task 6: Update the Host Information for Non-DCM Managed Components
Task 11: Inform the Original Host That It Is No Longer a Repository Host (If Required)
Task 1: Prepare the New Host
Ensure that the system configuration for the new host is identical to the original host. Refer to the record you created in Section 19.2.3, "Creating a Record of Your Oracle Application Server Configuration".
On the new host, make sure the following is identical to the original host:
Hardware platform
Operating system release and patch levels
The new host can have the same or different hostname and IP address.
Make sure the entry for the new host in /etc/hosts file lists the IP address, hostname, and aliases in the same order as the original /etc/hosts file.
Check port usage on the new host. Ensure that there are not any processes using the same ports as the Oracle Application Server installations you are about to restore. If there are, you must reconfigure these processes to use different ports before you begin restoring your Oracle Application Server installations.
On the new host, create an operating system user that is identical to the user who installed Oracle Application Server on the original host. The following attributes should be the same:
User name
Numerical userid
Group name
Numerical groupid
Environment profile
Shell
The user may have the same password or a different password than the original user.
Create the middle-tier Oracle home. Create an empty Oracle home directory using the same mount point and full path as the original Oracle home. Do not use symbolic links anywhere in the path. Ensure that the directory is on a filesystem with enough space to hold this installation, and that the directory is owned by the same user and group as on the original host.
Task 2: Restore the Oracle System Files
This task varies for UNIX and Windows systems.
For UNIX systems:
Restore the Oracle system files from your complete Oracle Application Server environment backup. For example, these files may be in /var/opt/oracle or /etc directory.
For Windows systems:
Import registry entries, from the original node, pertaining to HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE by running regedit.
Using the SC tool from the Windows Resource Kit, create services for the following:
opmn
sc create Oracle<home name>ProcessManager start= auto binPath= "Oracle_Home\opmn\bin\opmn.exe -S" For example: sc create OracleINFRAProcessManager start= auto binPath= "INFRAHOME\opmn\bin\opmn.exe -S"
em
sc create Oracle<home name>ASControl start= auto binPath= "Oracle_Home\bin\nmesrvc.exe" For example: sc create OracleINFRAASControl start= auto binPath="INFRAHOME\bin\nmesrvc.exe"
Task 3: Restore the Oracle Home
Use the following procedure to restore the Oracle home:
If the oraInventory directory resided in a directory that was separate from the Oracle home, restore it.
Restore the backup (tar, cpio) of the Oracle home from your complete Oracle Application Server environment backup. Ensure that your method of restoring the files preserves the original owner, group, permissions, and timestamps.
Check ORACLE_HOME/opmn/conf/opmn.xml for <variable id="TMP" value="XXX"/>. If the XXX directory does not exist, create it.
Task 4: Restore the Middle-tier Configuration Files for Non-DCM Managed Components
For non-DCM managed components, restore all configuration files from your most recent backup.
For UNIX systems:
bkp_restore.sh -m restore_config -t timestamp -F noDCM
For Windows systems:
bkp_restore.bat -m restore_config -t timestamp -F noDCM
Task 5: Update the Host Information for DCM Managed Components
Run the following command to modify the host information for DCM managed components:
ORACLE_HOME/dcm/bin/dcmctl resethostinformation
Task 6: Update the Host Information for Non-DCM Managed Components
Create a backup copy of the configtool.xml.tmpl file. The file directory is ORACLE_HOME/chgip/config/. Save the backup copy to another directory. Edit the original configtool.xml.tmpl file and remove the following lines pertaining to the updateConfig parameter:
<ConfigTool Name="DCM" Desc="Distributed Configuration Manager" InstallType="Core"> <Command>%ORACLE_HOME%\dcm\bin\dcmctl.bat</Command> <Parameter Name="" Value="updateConfig"/> </ConfigTool> <ConfigTool Name="DCM" Desc="Distributed Configuration Manager" InstallType="Portals"> <Command>%ORACLE_HOME%\dcm\bin\dcmctl.bat</Command> <Parameter Name="" Value="updateConfig"/> </ConfigTool> <ConfigTool Name="DCM" Desc="Distributed Configuration Manager" InstallType="BIServices"> <Command>%ORACLE_HOME%\dcm\bin\dcmctl.bat</Command> <Parameter Name="" Value="updateConfig"/> </ConfigTool> <ConfigTool Name="DCM" Desc="Distributed Configuration Manager" InstallType="Infrastructure_ID"> <Command>%ORACLE_HOME%\dcm\bin\dcmctl.bat</Command> <Parameter Name="" Value="updateConfig"/> </ConfigTool> <ConfigTool Name="DCM" Desc="Distributed Configuration Manager" InstallType="Infrastructure"> <Command>%ORACLE_HOME%\dcm\bin\dcmctl.bat</Command> <Parameter Name="" Value="updateConfig"/> </ConfigTool> <ConfigTool Name="DCM" Desc="Distributed Configuration Manager" InstallType="OCS"> <Command>%ORACLE_HOME%\dcm\bin\dcmctl.bat</Command> <Parameter Name="" Value="updateConfig"/> </ConfigTool>
Save the file, and then run the chgiphost script:
For UNIX systems:
ORACLE_HOME/chgip/scripts/chgiphost.sh -mid
For Windows systems:
ORACLE_HOME/chgip/scripts/chgiphost.bat -mid
Task 7: Restore DCM Managed Components
Use the following command to restore DCM managed components:
For UNIX systems:
bkp_restore.sh -m restore_config -F dcm-resyncforce
For Windows systems:
bkp_restore.bat -m restore_config -F dcm-resyncforce
Task 8: Start the Middle-tier Instance
Perform the following steps to start the Middle-tier instance.
Start OPMN and OPMN-managed processes
ORACLE_HOME/opmn/bin/opmnctl startall
Start the Application Server Control Console:
ORACLE_HOME/bin/emctl start iasconsole
Task 9: Update Host Information for DCM Managed Components
The chgiphost script must be run with the updateConfig parameter in ORACLE_HOME/chgip/config/configtool.xml.tmpl file. Use the original version of configtool.xml.tmpl file. Replace the modified version of this file (from task 6) with the backed-up copy.
Run the chgiphost script to update the host information for DCM managed components:
chgiphost.sh -mid
Task 10: Set the New Hostname and IP Address (If Required)
If the new host has a different hostname or IP address from the original host, follow the procedures in Section 8.2, "Changing Your Hostname, Domain Name, or IP Address" to change the hostname, IP address, or both, as required.
Task 11: Inform the Original Host That It Is No Longer a Repository Host (If Required)
Now that the file-based repository is restored to the new host, the original host may need to be informed that it is no longer a repository host. If the new host was already a part of the farm and is not a replacement for the original host, and the original host is still part of the farm, execute the following command on the original host:
dcmctl repositoryrelocated
