This chapter describes recommended recovery strategies and procedures for recovering Oracle Fusion Middleware from different types of failures and outages, such as media failures or loss of host.
This chapter includes the following sections:
Recovery strategies enable you to recover from critical failures that involve actual data loss. Depending on the type of loss, they can involve recovering any combination of the following types of files:
Oracle software files
Configuration files
Oracle system files
Windows Registry keys
Application artifacts
You can recover your Oracle Fusion Middleware environment while Oracle Fusion Middleware is offline.
The following topics describe recovery strategies:
You can recover your Oracle Fusion Middleware environment in part or in full. You can recover the following:
The Oracle home
WebLogic Server domains
Standalone domains
The Administration Server
Managed Servers
A component, such as Oracle SOA Suite or Oracle HTTP Server
WebLogic Server cluster
Deployed applications
The database
This section provides an overview of 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 they are permanently lost. This type of failure requires some type of data restoration before the Oracle Fusion Middleware environment can be restarted and continue with normal processing.
Note:
The procedures in this chapter assume that no administrative changes were made since the last backup. If administrative changes were made since the last backup, they must be reapplied after recovery is complete.Note the following key points about recovery:
Your Oracle Fusion Middleware environment must be offline while you are performing recovery.
Rename important existing files and directories before you begin restoring the files from backup so that you do not unintentionally override necessary files.
Although, in some cases, it may appear that only one or two files are lost or corrupted, you should restore the directory structure for the entire element, such as a domain, rather than just restoring one or two files. In this way, you are more likely to guarantee a successful recovery.
Recover the database to the most current state, using point-in-time recovery (if the database is configured in Archive Log Mode). This is typically a time right before the database failure occurred.
When you restore the files, use your preferred tool to extract the compressed files, as described in Section 16.3.
Ensure that the tool you are using preserves the permissions and timestamps of the files.
When you recover your environment, it is important to recover the entities in the correct order:
The database, if it needs to be recovered. See Section 18.2.9 and Section 18.3.7.
The Oracle Home, if it needs to be recovered. See Section 18.2.1.
The entire domain, if it needs to be recovered. See Section 18.2.2 and Section 18.3.1 for recovering a WebLogic Server managed domain. See Section 18.2.3 for recovering a standalone domain.
The Administration Server, if you do not need to recover the domain. See Section 18.2.4 and Section 18.3.3.
The Managed Servers, if they are not in the Administration Server domain directory and they need to be recovered. See Section 18.2.5 and Section 18.3.4.
Java components are recovered when you recover the Managed Server. System components are recovered when you recover the domain. In some circumstances, you may need to take certain steps as described in Section 18.2.6 and Section 18.3.5.
Some components require additional actions, which are described in the sections listed in Table 18-1.
Table 18-1 Additional Recovery Procedures for Particular Components
Component | For Data Loss, Corruption, Media Failure | For Loss of Host |
---|---|---|
Oracle B2B |
||
Oracle BI EE |
No additional steps needed if recovering to the same host. To recover to a different host, see Section 18.3.5.8. |
|
Oracle Business Intelligence Publisher |
NA |
No additional steps needed if recovering to the same host. To recover to a different host, see Section 18.3.5.9 |
Oracle Data Integrator |
NA |
|
Oracle Forms Services |
NA |
No additional steps needed if recovering to the same host. To recover to a different host, see Section 18.3.5.6. |
Oracle HTTP Server |
NA |
|
Oracle Platform Security Services |
||
Oracle Reports |
NA |
|
Oracle SOA Suite |
NA |
No additional steps needed if recovering to the same host. To recover to a different host, see Section 18.3.5.4. |
Oracle WebCenter Content |
||
Oracle WebCenter Content: Records |
Recover Oracle WebCenter Content. See Section 18.2.6.4. |
Recover Oracle WebCenter Content. See Section 18.3.5.11. |
Oracle WebCenter Portal Analytics |
||
Oracle WebLogic Server |
For Oracle WebLogic Server with whole server migration, see Section 18.2.2.1. |
For Oracle WebLogic Server with whole server migration, see Section 18.2.2.1. |
Applications, if they need to be recovered. See Section 18.2.8.
This section describes recovery strategies for outages that involve actual data loss or corruption, or media failure where the disk cannot be restored. It also describes recovery strategies for applications that are no longer functioning properly. This type of failure requires some type of data restoration before the Oracle Fusion Middleware environment can be restarted and continue with normal processing. It contains the following topics:
Note:
You can only restore an entity to the same path as the original entity. That path can be on the same host or a different host.You can recover the Oracle home that was corrupted or from which files were deleted.
To recover the Oracle home:
Stop all relevant processes. That is, stop all processes that are related to the domain, such as the Administration Server, Node Manager, and Managed Servers. For example, to stop the Administration Server on Linux:
DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]
Change to the directory that you want to be the parent directory of the Oracle home directory. Use the same directory structure as in the original environment.
Recover the Oracle home directory from backup. For example:
(UNIX) tar -xf oracle_home_backup_06052014.tar (Windows) jar xf oracle_home_backup_06052014.jar
Start all relevant processes. That is, start all processes that run in the Oracle home, such as the Administration Server and Managed Servers. For example, start the Administration Server:
DOMAIN_HOME/bin/startWebLogic.sh
You can recover an Oracle WebLogic Server domain that was corrupted or deleted from the file system, or when the host containing the domain was lost.
Caution:
Performing a domain-level recovery can impact other aspects of a running system and all of the configuration changes performed after the backup was taken will be lost.To recover an Oracle WebLogic Server domain that was corrupted or deleted from the file system:
If any relevant processes are running, stop them. That is, stop all processes that are related to the domain, such as the Administration Server, Managed Servers, and any system components. For example, stop the Administration Server:
DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]
For information on stopping system components such as Oracle HTTP Server, see Section 4.3.2.
Change to the directory that you want to be the parent directory of the domain home directory. Use the same directory structure as in the original environment.
Recover the domain directory from backup:
(UNIX) tar -xf domain_backup_06052014.tar (Windows) jar xf domain_backup_06052014.jar
Start all relevant processes. That is, start all processes that are related to the domain, such as the Administration Server, Managed Servers, and any system components. For example, start the Administration Server:
DOMAIN_HOME/bin/startWebLogic.sh
For information on starting system components such as Oracle HTTP Server, see Section 4.3.2.
If you cannot start the Administration Server, recover it, as described in Section 18.2.4.
If you cannot start a Managed Server, recover it, as described in Section 18.2.5.
When using database leasing (for example, with whole server migration), if you recover Oracle WebLogic Server, you should discard the information in the leasing table. You can simply drop and recreate the leasing table by running the leasing table creation script. (For more information about Whole Server Migration, see "Whole Server Migration" in Administering Clusters for Oracle WebLogic Server.)
You can recover a standalone domain that contains system components, such as Oracle HTTP Server, that was corrupted or deleted from the file system or if the host was lost and you want to recover to the same host.
To recover a standalone domain:
If Node Manager or a system component, such as Oracle HTTP Server are running, stop them.
If it is corrupted, recover the Oracle home:
(UNIX) tar xf oracle_home_backup_05_21_2013.tar (Windows) jar xf oracle_home_backup_05_21_2013.jar
Recover the domain home:
(UNIX) tar xf domain_backup_05_21_2013.tar (Windows) jar xf domain_backup_05_21_2013.jar
Start Node Manager:
(UNIX) DOMAIN_HOME/bin/startNodeManager.sh (Windows) DOMAIN_HOME\bin\startNodeManager.cmd
Start any system components, such as Oracle HTTP Server, that are in the domain:
(UNIX) Domain_Home/bin/startComponent.sh ohs1 (Windows) Domain_Home\bin\startComponent.cmd ohs1
If the Administration Server configuration has been lost because of file deletion or file system corruption, the Administration Server console continues to function if it was already started when the problem occurred. To prevent the Administration Server from prompting for a user name and password, see Section 4.2.4.
Caution:
Performing a domain-level recovery can impact other aspects of a running system and all of the configuration changes performed after the backup was taken will be lost.To recover the Administration Server configuration:
Stop all processes, including the Administration Server, Managed Servers, and Node Manager, if they are started. For example, to stop the Administration Server:
DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]
Recover the Administration Server configuration by recovering the domain home backup to a temporary location. Then, restore the config directory to the following location:
DOMAIN_HOME/config
Start the Administration Server. For example:
DOMAIN_HOME/bin/startWebLogic.sh
Verify that the Administration Server starts properly and is accessible.
On the next configuration change, the configuration from the Administration Server is pushed to the Managed Servers. On each Managed Server restart, the configuration is retrieved from the Administration Server.
You can recover a Managed Server's files, including its configuration files if they are deleted or corrupted.
In this scenario, the Managed Server is not on the same host as the Administration Server, and it does not operate properly or cannot be started because the configuration has been deleted or corrupted or the configuration was mistakenly changed and you cannot ascertain what was changed.
To recover a Managed Server:
If the Administration Server is not reachable, recover the Administration Server, as described in Section 18.2.4.
If the Managed Server is running, stop it. For example:
DOMAIN_HOME/bin/stopManagedWeblogic.sh managed_server_name admin_url username password
Recover the Oracle home from the backup, if required. For example:
tar -xf oracle_home_backup_06052014.tar
Stop Node Manager as described in Section 4.2.2.
Create a domain template jar file for the Administration Server, using the pack utility on the Administration Server host. For example:
pack.sh -domain=/scratch/oracle/config/domains/WLS_domain -template=/scratch/temp.jar -template_name=test_install -template_author=myname -log=/scratch/logs/my.log -managed=true
Specifying the -managed=true option packs up only the Managed Servers. If you want to pack the entire domain, omit this option.
Unpack the domain template jar file, using the unpack utility on the Managed Server host. In the following example, temp.jar is the archive created by the pack command:
unpack.sh -template=/scratch/temp.jar -domain=/scratch/oracle/config/domains/WLS_domain -log=/scratch/logs/new.log -log_priority=info
Note:
The following directory must exist. If it does not the unpack command fails.
ORACLE_HOME/config/domains/
The unpack command provides an -overwrite_domain option, which allows unpacking a Managed Server template into an existing domain and existing applications directories. For any file that is overwritten, a backup copy of the original is created. Use the -overwrite_domain option, if required for your deployment.
By default, applications are stored in the following directory unless you pass another location using the -app_dir argument:
ORACLE_HOME/user_projects/applications/Domain_Name
Start the Managed Server. For example:
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
The Managed Server connects to the Administration Server and updates its configuration changes.
You can recover a component if the component's files have been deleted or corrupted or if the component cannot be started or is not functioning properly because the component's configuration was changed and committed. You may not be able to ascertain what change is causing the problem and you want to revert to an earlier version.
For Java components, you recover the Managed Server, as described in Section 18.2.5.
For system components, such as Oracle HTTP Server, in a standalone domain, you recover the domain, as described in Section 18.2.3.
For system components, such as Oracle HTTP Server, in an Oracle WebLogic Server domain, you recover the domain as described in Section 18.2.2.
The following sections describes additional steps you must take for certain components:
For Oracle Platform Security Services, restore the following files:
DOMAIN_HOME/config/fmwconfig/jps-config.xml DOMAIN_HOME/config/fmwconfig/jps-config-jse.xml DOMAIN_HOME/config/fmwconfig/cwallet.sso DOMAIN_HOME/config/fmwconfig/bootstrap/cwallet.sso DOMAIN_HOME/config/fmwconfig/keystores.xml DOMAIN_HOME/config/config.xml DOMAIN_HOME/config/fmwconfig/ids_config.xml DOMAIN_HOME/config/fmwconfig/system-jazn-data.xml (if present) DOMAIN_HOME/config/fmwconfig/jps_mbeans.xml
After recovery, if the file Xengine.tar.gz is not unzipped, unzip the files. For example:
cd B2B_ORACLE_HOME/soa/thirdparty/edifecs
tar xzvf XEngine.tar.gz
To recover Oracle WebCenter Portal's Analytics:
Restore the domain, as described in Section 18.2.2.
Restore the Oracle home, as described in Section 18.2.1.
Restore the database containing the ACTIVITIES and MDS schemas, if necessary.
To recover Oracle WebCenter Content:
If necessary, restore the database, as described in Section 18.3.7.
Restore the domain, as described in Section 18.2.2.
If the Vault, WebLayout, or Search directories are not located in the domain directory, restore those directories, if necessary. For example, if the Vault directory is located on a shared drive in /net/home/vault, restore it from backup:
cd /net/home/vault tar -xf vault_backup_042012.tar
Note that you should restore the database and the shared file system at the same time. If you cannot do that, you can use the IDCAnalyse utility to determine if there are any inconsistencies between the database and the shared file system. If there are, you can perform a manual recovery using IDCAnalyse.
To recover Oracle BI EE in a clustered environment:
Reconcile the LDAP Database with the Oracle BI EE repository (RPD), as described in Section 18.2.6.5.1.
Reconcile the LDAP Database and with the Oracle BI Presentation Catalog, as described in Section 18.2.6.5.2.
You must reconcile the LDAP database with the Oracle BI EE repository (RPD).
Oracle BI Enterprise Edition provides a method to perform synchronization. You can enable automatic synchronization, at all times, or temporarily to perform the synchronization. (See "NQSConfig.INI File Configuration Settings" in the System Administrator's Guide for Oracle Business Intelligence Enterprise Edition for information about editing the NQSConfig.ini file.)
To enable synchronization:
Edit the following file:
INSTANCE_HOME/config/OracleBIServerComponent/coreapplication_obis1/NQSConfig.INI
Set the flag FMW_UPDATE_ROLE_AND_USER_REF_GUIDS to yes
.
Restart the servers. The information in the LDAP database and RPD is synchronized.
To disable synchronization:
To disable synchronization, edit the following file:
INSTANCE_HOME/config/OracleBIServerComponent/coreapplication_obis1/NQSConfig.INI
Set the flag FMW_UPDATE_ROLE_AND_USER_REF_GUIDS to no
.
Restart the servers.
On Windows, the Oracle BI Administration Tool provides a Consistency Check Manager that checks the validity of your repository and allows you to correct the inconsistencies. For more information, see "Checking the Consistency of Repository Objects" in the Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition.
If the LDAP database is restored to a previous point in time resulting in the LDAP database being behind in time to the Oracle BI Presentation Catalog, use the following command to reconcile the LDAP database with the Oracle BI Presentation Catalog:
runcat.cmd -cmd forgetAccounts
For information about the runcat command, see the help:
./runcat.sh -cmd maintenanceMode -help
You may need to recover a cluster in the following situations:
The cluster has been erroneously deleted, a cluster member was erroneously deleted.
The cluster-level configuration, such as the JMS configuration or container-level data sources, was mistakenly changed and committed. The component or server cannot be started or does not operate properly or the services running inside the server are not starting. You may not be able to ascertain what change is causing the problem and you want to revert to an earlier version.
Caution:
Performing a domain-level recovery can impact other aspects of a running system and all of the configuration changes performed after the backup was taken will be lost.If the configuration changes are few, then the easiest way is to redo the configuration changes. If that is not feasible, use the following procedure to recover the configuration:
Stop the cluster. You can use the Oracle WebLogic Server Administration Console or WLST. For example, to use WLST:
shutdown('cluster_name', 'Cluster')
Stop all processes, such as the Administration Server and Managed Servers. For example, to stop the Administration Server:
DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]
Recover the Administration Server configuration by recovering the domain home backup to a temporary location. Then, restore the config directory to the following location:
DOMAIN_HOME/config
Start the Administration Server. For example:
DOMAIN_HOME/bin/startWebLogic.sh
Any deleted members are now back in the cluster.
Start all processes, such as the Managed Servers. For example, to start the Managed Server on Linux, use the following script:
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
Start the cluster. You can use the Oracle WebLogic Server Administration Console or WLST. For example, to use WLST:
start('cluster_name', 'Cluster')
The following topics describe how to recover an application:
Note the following about recovering applications:
If the application is staged, the Administration server copies the application bits to the staged directories on the Managed Server hosts.
If the deployment mode is nostage or external_stage, ensure that additional application artifacts are available. For example, applications may reside in directories outside of the domain directory. Make your application files available to the new Administration Server by copying them from backups or by using a shared disk. Your application files should be available in the same relative location on the new file system as on the file system of the original Administration Server.
See Deploying Applications to Oracle WebLogic Server for information about deploying applications.
If an application's artifacts, such as the .ear file, have been lost or corrupted, you can recover the application.
To recover the application:
Start the Managed Server to which the application was deployed. For example:
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
This synchronizes the configuration with the Administration Server.
On each Managed Server restart, the configuration and application artifacts are retrieved from the Administration Server.
You can recover a Java EE application:
If a Java EE application was redeployed to a Managed Server (whether or not the Managed Server is part of a cluster) and the application is no longer functional.
If a deployed application was undeployed from Oracle WebLogic Server.
A new version of a composite application was redeployed to a Managed Server or cluster. The application is no longer functional.
To recover the application:
Recover the application files from backup, if needed.
Redeploy the old version of the application from the backup.
You cannot just copy the original ear file. Even if the original ear file (from the backup) is copied back to the Managed Server stage directory and you restart the Managed Server, the application is still not recovered. You must redeploy the original version.
If your database that contains your metadata repository, including the MDS Repository, is corrupted, you can recover it using RMAN. You can recover the database at the desired granularity, either a full recovery or a tablespace recovery.
For best results, recover the database to the most current state, using point-in-time recovery (if the database is configured in Archive Log Mode.) This ensures that the latest data is recovered. For example:
rman> restore database; rman> recover database;
See Creating Schemas with the Repository Creation Utility for the schemas used by each component.
For detailed steps, see the Oracle Database Backup and Recovery User's Guide.
This section describes how to recover your Oracle Fusion Middleware environment after losing the original operating environment. For example, you could have a serious system malfunction or loss of media. The sections includes the following topics:
Note:
When you are recovering in the case of loss of host, you must restore the files using the same path as on the original host.To recover an Oracle WebLogic Server domain after loss of host, follow the steps in Section 18.2.2.
If you lose a host that contains a standalone domain, you can recover it to the same host or a different host, as described in the following topics:
To recover the standalone domain to the same host after the operating system has been reinstalled, follow the procedures in Section 18.2.3.
In this scenario, you recover the standalone domain to a different host.
To recover the standalone domain to a different host:
Recover the Oracle home:
(UNIX) tar xf oracle_home_backup_05_21_2014.tar (Windows) jar xf oracle_home_backup_05_21_2014.jar
Recover the domain home:
(UNIX) tar xf domain_backup_05_21_2014.tar (Windows) jar xf domain_backup_05_21_2014.jar
In a standalone domain, by default, Node Manager is listening on localhost. However, if it is not, you can update the ListenAddress by using the following WLST commands:
readDomain('Domain_Home') cd('/') cd('NMProperties') set('ListenAddress','localhost') set('ListenPort',9001) updateDomain()
Start Node Manager:
(UNIX) DOMAIN_HOME/bin/startNodeManager.sh (Windows) DOMAIN_HOME\bin\startNodeManager.cmd
Update any system component configuration files manually.
See Section 18.3.5 for details for specific components.
Start any system components, such as Oracle HTTP Server, that are in the domain. For example:
(UNIX) Domain_Home/bin/startComponent.sh ohs1 (Windows) Domain_Home\bin\startComponent.cmd ohs1
Update the Oracle Inventory, as described in Section 18.3.6.4.
For Windows, update the Windows Registry, as described in Section 18.3.6.5.
If you lose a host that contains the Administration Server, you can recover it to the same host or a different host, as described in the following topics:
In this scenario, you recover the Administration Server either to the same host after the operating system has been reinstalled or to a new host that has the same host name. For example, the Administration Server is running on Host A and the Managed Server is running on Host B. Host A has failed for some reason and the Administration Server must be recovered.
To recover the Administration Server to the same host:
Recover the file system. For example, recover the domain containing the Administration Server, as described in Section 18.3.1.
Attempt to start the Administration Server. For example:
DOMAIN_HOME/bin/startWebLogic.sh
If the Administration Server starts, you do not need to take any further steps.
If the Administration Server fails to start, take the following steps on Host A:
Stop all relevant processes. That is, stop all processes that are related to the domain, such as the Managed Servers.
Recover the Oracle home, if needed:
tar -xf oracle_home_backup_06052014.tar
If the domain directory does not reside in the Oracle home, recover the domain directory from backup. First, change to the directory that you want to be the parent of the Domain home, then:
tar -xf domain_backup_06052014.tar
Start the Administration Server. For example:
DOMAIN_HOME/bin/startWebLogic.sh
Start the Managed Servers, specifying the Administration URL for the host:
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
Start Node Manager:
cd DOMAIN_HOME/bin
./startNodeManager.sh
In this scenario, the Administration Server is running on Host A and the Managed Server is running on Host B. Host A has failed for some reason and the Administration Server must be moved to Host C.
To recover the Administration Server to a different host:
Recover the Oracle home to Host C (the new Host):
tar -xf oracle_home_backup_06052014.tar
If the domain directory does not reside in the Oracle home, recover the domain directory from backup. First, change to the directory that you want to be the parent of the Domain home, then:
tar -xf domain_backup_06052014.tar
If the Administration Server has a Listen address, create a new machine with the new host name, as described in Section 18.3.6.3.
Start the Administration Server. For example:
DOMAIN_HOME/bin/startWebLogic.sh
Using WLST, connect to the Administration Server and then enroll Node Manager running in the new host with the Administration Server:
connect('username','password','t3://host:port') nmEnroll('/scratch/oracle/config/domains/domain_name', 'DOMAIN_HOME/nodemanager')
Note that on Windows, as on UNIX, you use slashes (/), not backslashes (\), in the nmEnroll command.
Edit the Node Manager properties file, changing the Listen Address property. For a domain-based Node Manager, the file is located at:
DOMAIN_HOME/nodemanager/nodemanager.properties
Alternatively, you can use the following WLST commands to change the property:
readDomain('Domain_Home')
cd('/')
cd('NMProperties')
set('ListenAddress','localhost')
set('ListenPort',port_num)
updateDomain()
Start Node Manager on Host C if it was configured on the original host:
cd DOMAIN_HOME/bin
./startNodeManager.sh
Start the Managed Servers. The section "Restarting a Failed Administration Server" in Administering Server Startup and Shutdown for Oracle WebLogic Server describes different ways to restart them, depending on how they were configured.
One option is to use the following script, specifying the Administration URL of the new host:
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
Ensure that additional application artifacts are available. For example, if the deployment mode is nostage or external_stage, applications may reside in directories outside of the domain directory. Make your application files available to the new Administration Server by copying them from backups or by using a shared disk. Your application files should be available in the same relative location on the new file system as on the file system of the original Administration Server.
If the application is staged, the Administration Server copies the application bits to the staged directories on the Managed Server hosts.
Update Oracle Inventory, as described in Section 18.3.6.4.
On Windows, recover the Windows Registry, as described in Section 18.3.6.5
If your environment contains Oracle HTTP Server, modify the mod_wl_ohs.conf file, as described in Section 18.3.6.2.
Now you can start and stop the Managed Server on Host B using the Administration Console running on Host C.
If you are recovering the Administration Server for a Web Tier installation, see Section 18.3.6 for information about additional actions you must take.
If you lose a host that contains a Managed Server, you can recover it to the same host or a different host, as described in the following topics:
In this scenario, you recover a Managed Server to the same host after the operating system has been reinstalled or to a new host that has the same host name. The Administration Server is running on Host A and the Managed Server is running on Host B. Host B failed for some reason and the Managed Server must be recovered to Host B.
To recover a Managed Server to the same host:
Start Node Manager on Host B:
cd DOMAIN_HOME/bin
./startNodeManager.sh
Start the Managed Server. For example:
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
If the Managed Server starts, it connects to the Administration Server and updates its configuration changes. You do not need to take any further steps.
If the Managed Server fails to start or if the file system is lost, take the following steps:
Recover the Oracle home to Host B from the backup, if required:
tar -xf oracle_home_backup_06052014.tar
Stop Node Manager as described in Section 4.2.2.
If the Managed Server contains Oracle Reports or Oracle Forms Services, and the Managed Server domain directories reside outside of the Oracle home, restore the domain, in addition to the Oracle home. For example:
cd Domain_Home
tar -xf domain_home_backup_042012.tar
Go to Step e.
If the Managed Server does not contain Oracle Forms Services or Oracle Reports, take the following steps:
Create a domain template jar file for the Administration Server running in Host A, using the pack utility. For example:
pack.sh -domain=/scratch/oracle/config/domains/domain_name
-template=/scratch/temp.jar -template_name=test_install
-template_author=myname -log=/scratch/logs/my.log -managed=true
Specifying the -managed=true option packs up only the Managed Servers. If you want to pack the entire domain, omit this option.
Unpack the domain template jar file in Host B, using the unpack utility:
unpack.sh -template=/scratch/temp.jar
-domain=/scratch/oracle/config/domains/domain_name
-log=/scratch/logs/new.log -log_priority=info
Ensure that the application artifacts are accessible from the Managed Server host. That is, if the application artifacts are not on the same server as the Managed Server, they must be in a location accessible by the Managed Server.
Note:
For applications that are deployed in nostage and external_stage mode, copy the application artifacts from the Administration Server host directory.
For applications that are deployed in stage mode, the Administration server copies the application bits to the staged directories on the Managed Server hosts.
See Deploying Applications to Oracle WebLogic Server for information about deploying applications.
Update the Node Manager property ListenAddress by using the following WLST commands:
readDomain('Domain_Home') cd('/') cd('NMProperties') set('ListenAddress','localhost') set('ListenPort',9001) updateDomain()
If Node Manager is not started, start it:
cd DOMAIN_HOME/bin
./startNodeManager.sh
Start the Managed Server. For example:
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
The Managed Server connects to the Administration Server and updates its configuration changes.
In this scenario, the Administration Server is running on Host A and the Managed Server is running on Host B. Host B failed for some reason and the Managed Server must be recovered to Host C. There are two machines, which are logical representations of the computer that hosts one or more WebLogic Servers, machine_1 on Host A and machine_2 on Host B.
Important:
Recover the Oracle home to the same location as the original.To recover a Managed Server to a different host:
Recover the Oracle home for the Managed Server to Host C.
tar -xf oracle_home_backup_06052014.tar
Reconfigure the topology to point to the new host:
To avoid an inconsistent backup, do not make any configuration changes until the backup is completed. To ensure that no changes are made in the WebLogic Server domain, lock the WebLogic Server configuration, as described in Section 2.2.5.
In the WebLogic Server Administration Console, change the configuration of machine_2, to point it to the new host:
From the left pane of the Console, expand Environment and then select Machines. Select machine_2 and select the Configuration tab. Then select the Node Manager tab. Change the Listen Address to the address for Host C. Click Save.
If you identify the Listen Address by IP address, you must disable Host Name Verification on the Administration Servers that access Node Manager. For more information and instructions, see "Using Hostname Verification" in Administering Security for Oracle WebLogic Server 12c (12.2.1).
Change the Managed Server configuration to point to the new host:
From the left pane of the Console, expand Environment and then Servers. Then, select the name of the server. Select the Configuration tab, then the General tab.
Change the Machine to machine_2.
Change Listen Address to the new host. (If the listening address was set to blank, you do not need to change it.)
Click Save, then click Activate Changes.
Unlock the Oracle WebLogic Server configuration by clicking Release Configuration on the WebLogic Server Administration Console,
Take any additional steps needed for components as described in Table 18-1.
Stop Node Manager as described in Section 4.2.2.
If the Managed Server contains Oracle Reports or Oracle Forms Services, and the Managed Server domain directories reside outside of the Oracle home, restore the domain, in addition to the Oracle home. For example:
cd Domain_Home
tar -xf domain_home_backup_042012.tar
Go to Step 7.
If the Managed Server does not contain the components listed in Step 5, take the following steps:
Create a domain template jar file from the Administration Server running in Host A, using the pack utility. For example:
pack.sh -domain=/scratch/oracle/config/domains/domain_name
-template=/scratch/temp.jar -template_name=test_install
-template_author=myname -log=/scratch/logs/my.log -managed=true
Specifying the -managed=true option packs up only the Managed Servers. If you want to pack the entire domain, omit this option.
Unpack the domain template jar file on Host C, using the unpack utility:
unpack.sh -template=/scratch/temp.jar
-domain=/scratch/oracle/config/domains/domain_name
-log=/scratch/logs/new.log -log_priority=info
If you are recovering to a different domain home, use the -app_dir switch in the unpack command.
Ensure that the application artifacts are accessible from the Managed Server host. That is, if the application artifacts are not on the same server as the Managed Server, they must be in a location accessible by the Managed Server.
Note:
For applications that are deployed in nostage and external_stage mode, copy the application artifacts from the Administration Server host directory.
For applications that are deployed in stage mode, the Administration server copies the application bits to the staged directories on the Managed Server hosts.
See Deploying Applications to Oracle WebLogic Server for information about deploying applications.
Update the ListenAddress by using the following WLST commands:
readDomain('Domain_Home') cd('/') cd('NMProperties') set('ListenAddress','localhost') set('ListenPort',9001) updateDomain()
Start Node Manager on Host C, if it is not started:
cd DOMAIN_HOME/bin
./startNodeManager.sh
Start the Managed Server. For example:
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
The Managed Server connects to the Administration Server and updates its configuration changes.
Update Oracle Inventory, as described in Section 18.3.6.4.
On Windows, recover the Windows Registry, as described in Section 18.3.6.5
If your environment contains Oracle HTTP Server, modify the mod_wl_ohs.conf file, as described in Section 18.3.6.2.
Now you can start and stop the Managed Server on Host C using the Administration Server running on Host A.
If you lose a host that contains a component (and its Managed Server, if applicable), you can recover most components to the same host or a different host using the procedures described in the following topics:
Some components require additional actions, which are described in the sections listed in Table 18-1.
To recover a Java component to the same host:
Recover the Managed Server, as described in Section 18.3.4.1.
If the component requires additional steps, as noted in Table 18-1, take those steps.
To recover a Java component to a different host:
Recover the Managed Server, as described in Section 18.3.4.2.
If the component requires additional steps, as noted in Table 18-1, take those steps.
To recover a system component, such as Oracle HTTP Server, to the same host or a different host:
For system components, such as Oracle HTTP Server, in a standalone domain, you recover the domain, as described in Section 18.3.2.
For system components, such as Oracle HTTP Server in an Oracle WebLogic Server domain, you recover the domain, as described in Section 18.3.1.
However, note that some components require additional steps, as noted in Table 18-1.
To recover the Oracle SOA Suite Managed Server to the same host, recover the Managed Server, as described in Section 18.3.4.1.
To recover the Oracle SOA Suite Managed Server to a different host after loss of host:
Before you recover, update the WSDL file to point to the new host name and port.
Recover the Managed Server, as described in Section 18.3.4.2.
After you recover the Oracle SOA Suite Managed Server, take the following actions:
Change the host name in the soa-infra MBean:
In Fusion Middleware Control, navigate to the Managed Server.
From the WebLogic Server menu, choose System MBean Browser.
Expand Application Defined MBeans, then oracle.as.soainfra.config, then Server: server_name and then SoaInfraConfig. Select soa-infra.
In the Attributes tab, click ServerURL. If the ServerURL attribute contains a value, change the host name to the new host name.
Click Apply.
Redeploy all applications which have the WSDL files updated to the new host name.
Note:
If there is no Load Balancer configured with the environment and Oracle SOA Suite must be recovered to a different host, then in-flight instances that are pending a response from task flow and asynchronous responses are not recovered. Oracle recommends that you use a Load Balancer to ensure that you can recover to a different host.If a Load Balancer is configured with the environment, take the following additional steps:
Log in to the Oracle WebLogic Server Administration Console.
In Domain Structure, navigate to Clusters. Select the cluster you want to configure, then go to the HTTP tab under the Configuration tab.
For Frontend Host, enter the new host name.
For Frontend HTTP Port and Frontend HTTPs Port, if applicable, enter the new port number.
Restart each Managed Server.
The Web tier consists of Oracle HTTP Server. The following topics describe how to recover it to a different host:
Recovering Oracle HTTP Server in a Standalone Domain to a Different Host
Recovering Oracle HTTP Server in a WebLogic Server Domain to a Different Host
To recover Oracle HTTP Server in a standalone domain:
Follow steps 1 through 4 in Section 18.3.2.
Update the configuration files in the following directory:
(UNIX) DOMAIN_HOME/config/fmwconfig/components/OHS/instance_name (Windows) DOMAIN_HOME\config\fmwconfig\components\OHS\instance_name
For example, update the IP Address and host name in httpd.conf, admin.conf, and mod_wl_ohs.conf (if required).
Follow steps 6 through 8 in Section 18.3.2.
To recover Oracle HTTP Server in an Oracle WebLogic Server domain to a different host:
Recover the domain, as described in Section 18.3.1.
Change the configuration of the Oracle HTTP Server instance that was on Host B:
In Fusion Middleware Control, from the navigation pane, expand HTTP_Server.
Select the Oracle HTTP Server instance, such as ohs1.
From the Oracle HTTP Server menu, select Administration, then Ports Configuration.
For each port in the table, select the port, then click Edit. Change the IP Address.
Note that if ANY is selected, you do not need to make any changes.
Click OK.
Update the mod_wl_ohs wiring for each Oracle HTTP Server instance:
In Fusion Middleware Control, from the navigation pane, expand HTTP_Server.
Select the Oracle HTTP Server instance, such as ohs1.
From the Oracle HTTP Server menu, select Administration, then mod_wl_ohs Configuration.
In the Locations section, click AutoFill.
All valid WebLogic Server endpoint locations are displayed.
Click Apply.
Restart any Oracle HTTP Server instances that are not on the failed machine by navigating to that instance and clicking Start Up.
Start the Oracle HTTP Server instances on Host C by navigating to that instance and clicking Start Up.
To recover Oracle Forms Services to a different host:
Recover the Managed Server, as described in Section 18.3.4.2.
On the Administration Server host, edit the following file:
DOMAIN_HOME/opmn/topology.xml
Add properties for the <ias-component id> element for Oracle Forms Services. The following example shows the element after you modify it:
</ias-component> <ias-component id="forms" type="FormsComponent" > <em-properties> <property name="OracleHome" value="/path_to_oracle_home" /> <property name="instName" value="instance_name" /> <property name="EMTargetType" value="oracle_forms" /> <property name="version" value="12.2.1" /> </em-properties> </ias-component>
Run the ssoreg script, which is located in:
Identity_Management_ORACLE_HOME/sso/bin
Use the following command:
ssoreg.sh -site_name newhost:http_listen_port -mod_osso_url http://newhost:http_listen_port -config_mod_osso TRUE -oracle_home_path $ORACLE_HOME -config_file any_new_file_path -admin_info cn=orcladmin -virtualhost -remote_midtier
For example:
ssoreg.sh -site_name example.com:8090 -mod_osso_url http://example.com:8090 -config_mod_osso TRUE -oracle_home_path $ORACLE_HOME -config_file /tmp/loh_osso.conf -admin_info cn=orcladmin -virtualhost -remote_midtier
Copy the file from the previous step to the new host.
In the new host, modify the OssoConfigFile section in the following file to include the path of the file in step 3:
ORACLE_INSTANCE/config/OHS/ohs1/moduleconf/mod_osso.conf
For example:
<IfModule mod_osso.c>
OssoIpCheck off
OssoSecureCookies off
OssoIdleTimeout off
OssoConfigFile /tmp/path_of_file_created
To recover Oracle Reports to a different host:
Recover the Managed Server, as described in Section 18.3.4.2.
Edit the following files, replacing the previous host name with the new host name:
nodemanager.properties. The file is located in:
(UNIX) DOMAIN_HOME/nodemanager (Windows) DOMAIN_HOME\nodemanager
reports_ohs.conf. The file is located in:
(UNIX) DOMAIN_HOME/config/fmwconfig/components/OHS/instances/ohs_name/moduleconf (Windows) DOMAIN_HOME\config\fmwconfig\components\OHS\instances\ohs_name\moduleconf
rwservlet.properties. The file is located in:
(UNIX) DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration (Windows) DOMAIN_HOME\config\fmwconfig\servers\server_name\applications\reports_version\configuration
In the file, modify the <server> element to use the new host name.
mbeans.xml. The file is located in:
(Unix) DOMAIN_HOME/servers/server_name/tmp/_WL_user/reports_version/random_string/META-INF (Windows) DOMAIN_HOME\servers\server_name\tmp\_WL_user\reports_version\random_string\META-INF
You can recover Oracle BI EE to a different host.
The following topics describe how to move Oracle BI EE to a different host with the same name:
Recovering Oracle BI EE to a Different Host in a Non-Clustered Environment
Recovering Oracle BI EE to a Different Host in a Clustered Environment
On Windows, take the following additional steps after you have recovered the entity that failed:
Install the C++ libraries from Microsoft, by executing the following file:
Oracle_BI\bifoundation\install\vc80\vcredist_x86.exe
Import the Registry entries that you exported into the new host, as described in Section 18.3.5.8.3.
In this scenario, you have an Oracle BI EE cluster on two hosts, Host A and Host B. Host A contains instance1 and Host B contains instance2. Host A must be replaced for some reason, such as a host crash, and you must recover to Host C and scale out the system so that Host C contains instance3.
Take the following additional steps after you have recovered the failed entities:
On Windows, install the C++ libraries from Microsoft, by executing the following file:
Oracle_BI\bifoundation\install\vc80\vcredist_x86.exe
On Windows, import the Registry entries that you exported into the new host, as described in Section 18.3.5.8.3.
If the failed node contained the Administration Server, recover it, as described in steps 1 through 4 in Section 18.3.3.2.
Scale out the Oracle BI EE system, as described in "Scaling Out the BI System on APPHOST2" in the Enterprise Deployment Guide for Oracle Business Intelligence.
Note the following:
When you enter the directory specifications for the Domain Home and Applications Home, enter specifications for directories that do not yet exist or that are empty.
If the Domain Home field is empty, update the following file with the domain directory:
DOMAIN _HOME/wlserver_10.3/common/nodemanager/nodemanager.domains
Before you start Node Manager, take the following steps:
Stop Node Manager, if it is running.
Run the setNMProps.sh script, which is located in the ORACLE_COMMON_HOME/common/bin directory, to set the StartScriptEnabled property to true
before starting Node Manager:
cd ORACLE_COMMON_HOME/common/bin
./setNMProps.sh
Restart Node Manager and enable dynamic registration using the following commands:
cd WL_HOME/server/bin
export JAVA_OPTIONS=-DDomainRegistrationEnabled=true
./startNodeManager.sh
Note:
It is important that you set -DDomainRegistrationEnabled=true whenever you start a Node Manager which must manage the Administration Server. If there is no Administration Server on this computer, and if this computer is not an Administration Server failover node, then Node Manager can be started as follows:./startNodeManager.sh
Scale out the system components, as described in "Scaling Out the System Components" in the Enterprise Deployment Guide for Oracle Business Intelligence. Fusion Middleware Control prompts you to restart the instances after you have changed their configuration. Restart the instances.
Because instance1 on Host A is no longer available, you must modify its count of BI Servers, Presentation Services, and JavaHosts to be 0. Fusion Middleware Control prompts you to restart the instances after you have changed their configuration. Restart the instances.
Make instance2 the primary instance and instance3 the secondary instance using Fusion Middleware Control:
Make instance 2 the primary instance and specify the secondary instance as none. Activate and restart the instance as prompted by Fusion Middleware Control.
Make instance3 the secondary instance. Activate and restart the instance as prompted by Fusion Middleware Control.
See "Configuring Secondary Instances of Singleton System Components" in the Enterprise Deployment Guide for Oracle Business Intelligence for more information.
Set the listen address of the bi_servern Managed Server, as described in "Setting the Listen Address for the bi_server2 Managed Server" in the Enterprise Deployment Guide for Oracle Business Intelligence.
Disable host name verification for the bi_servern Managed Server, as described in "Disabling Host Name Verification for the bi_server2 Managed Server" in the Enterprise Deployment Guide for Oracle Business Intelligence.
Depending on your configuration, perform additional configuration, as described in "Performing Additional Configuration for Oracle Business Intelligence Availability" in the Enterprise Deployment Guide for Oracle Business Intelligence.
If Oracle HTTP Server is installed, set the frontend HTTP host and port for the Oracle WebLogic Server cluster to ensure that Oracle BI Search URLs are set correctly, as described in "Setting the Frontend URL for the Administration Console" in the Enterprise Deployment Guide for Oracle Business Intelligence.
Configure Node Manager for the Managed Servers as described in "Configuring Node Manager for the Managed Servers" in the Enterprise Deployment Guide for Oracle Business Intelligence.
Start the Oracle BI EE Managed Server and all of the OPMN-managed components.
Depending on your environment, you may need to take additional steps after you perform the previous steps:
If the failed host contained the master BI Server, primary cluster controller, and primary Oracle BI Scheduler and you want the new instance to be the master BI Server, take the following steps as appropriate. Note that if you want to leave instance2 as the master BI server, you do not need to take these additional steps.
If the master BI Server is lost:
Stop Oracle WebLogic Server and OPMN processes on all nodes.
Update the following configuration file to designate a new master BI Server:
DOAMIN_HOME/config/fmwconfig/biee-domain.xml
In the section <AvailabilityOptions>, edit the following:
masterBIServerOracleInstanceId="instance_name" masterBIServerComponentId="component_id"
Also update the following settings:
<OracleInstance id="instance1" host="hostname" instanceHome="path_to_instance_home" opmnLocalPort="9500" opmnRemotePort="number"> <SchedulerOptions dataSource="(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=hostname(PORT=number)))
Copy the file to the other host.
Restart the Administration Server and the Managed Servers.
If the primary cluster controller or scheduler is lost, it fails over to the standby cluster controller or scheduler. You must determine whether you want to reconfigure it to be the primary cluster controller or scheduler or leave it as secondary that has been activated because the primary components have failed. For more information, see "Configuring Secondary Instances of Singleton System Components" in the Enterprise Deployment Guide for Oracle Business Intelligence.
If the failed host contained the BI Server, the secondary cluster controller, and the secondary Oracle BI Scheduler, designate the new host as the secondary cluster controller or scheduler.
If the failed host contained the BI Server and system components such as BI Presentation Services and BI Java hosts, no additional steps are needed.
If the failed host contained the following related components, recover them:
Oracle Business Intelligence Publisher: See Section 18.3.5.9.
Oracle Real-Time Decisions.
On Windows, you must import the Oracle BI EE Registry entries to the new host. Section 17.3.3 describes how to export them from the original host.
Copy all the files that you exported from the original host to the new host.
Double-click each file you copied from the original host. Click Yes when prompted, to import the file into the Registry.
Take the following additional steps after you have recovered the failed entities:
Modify the server value for Oracle BI Presentation Services:
Open the BI Publisher application at http://hostname:port/xmlpserver
and log in.
Click Administration, then Integration, then Oracle BI Presentation Services.
Change Server to the new host name.
Click Apply.
To transform Oracle BI Publisher to work in a Cold Failover Cluster environment, you must change the BI Scheduler 's JMS configuration:
In the BI Publisher application, click Administration.
In the System Administration section, click Scheduler Configuration.
Change Weblogic JNDI URL to the new host URL. For example, t3://hostname:port
.
Click Apply.
If you are using a Cold Failover Cluster, configure the Managed Server to listen on the virtual IP address. See "Transforming Oracle WebLogic Managed Servers" in the High Availability Guide. Then restart the Managed Server using the Administration Console or the WLST command line.
In BI Publisher, data sources that refer to this BI Enterprise Edition instance should change or be created (if new using the new virtual host). To change the data sources:
In the BI Publisher application:
Click JDBC Connection under Data Sources.
Edit any data source for BI Enterprise Edition for this instance to reflect the values for the new host.
If backup artifacts are restored from different time, then user accounts, user reports, and user permissions revert to the restored version. Restore all artifacts from the same point in time.
To recover Oracle Data Integrator, follow the procedures in one or both of these topics, depending on the failure:
If the Oracle Data Integrator Repository must be restored to a different host:
Restore the database, as described in Section 18.3.7.
Connect to the restored Oracle Data Integrator repository using ODI Studio. Create a new connection for the master repository to the new database host, as described in "Connecting to the Master Repository" in Developing Integration Projects with Oracle Data Integrator.
Edit each of the Work Repositories. Click Connection and edit the connection information so that the JDBC URL points to the new database host containing the work repository.
For the Oracle Data Integrator JEE Agent repository configuration, in the Oracle WebLogic Server configuration, edit the data sources to match the new database host location.
Update the Oracle Data Integrator Standalone Agent Repository configuration using the following WLST offline commands:
cd ORACLE_HOME/odi/common/bin ./wlst.sh readDomain('DOMAIN_DIRECTORY') cd('/JdbcSystemResource/OdiMasterRepository/JdbcResource/OdiMasterRepository/JDBCDriverParams/NO_NAME_0'); set('URL','NEW_JDBC_URL_TO_RECOVERED_DB'); updateDomain(); exit();
To recover Oracle Data Integrator agents to a different host:
Restore Oracle Data Integrator JEE Agent by restoring the Managed Server, as described in Section 18.3.4.
Restore the Oracle Data Integrator Standalone system component, as described in Section 18.3.5
Use ODI Studio to edit each physical agent's configuration and provide the updated Host Name value and, if changed, the Port value.
Update Oracle Data Integrator Standalone Agent's host and port configuration using the following commands:
cd ORACLE_HOME/odi/common/bin ./wlst.sh readDomain('DOMAIN_HOME') cd('ODI/ODI_STANDALONE_AGENT_NAME') set("ServerListenAddress",'UPDATED_HOST_NAME'); set("ServerListenPort",'UPDATED_PORT'); updateDomain(); exit();
Restart the standalone agents and the Oracle Data Integrator applications deployed in Oracle WebLogic Server.
To recover Oracle WebCenter Content to a different host:
If the database must be restored to a different host, restore it, as described in Section 18.3.7.
Restore the domain, as described in Section 18.3.3.
If the Vault, WebLayout, or Search directories are not located in the domain directory, restore those directories, if necessary. For example, if the Vault directory is located on a shared drive in /net/home/vault, restore it from backup:
cd /net/home/vault tar -xf vault_backup_042012.tar
Edit the following file:
DOMAIN_HOME/ucm_domain/ucm/cs/config/config.cfg
In the file, change the HttpServerAddress setting to specify the new host. For example:
HttpServerAddress=hostname:port_number
Note that you should restore the database and the shared file system at the same time. If you cannot do that, you can use the IDCAnalyse utility to determine if there are any inconsistencies between the database and the shared file system. If there are, you can perform a manual recovery using IDCAnalyse.
Depending on the entity that you are recovering, you may need to take additional actions after loss of host. The sections about each entity may require you to follow one or more of the following procedures. If so, that is noted in the section describing how to recover the entity.
The following topics describe the actions you may need to take:
To recover Fusion Middleware Control to a different host, update properties using the System MBean Browser:
In Fusion Middleware Control, from the WebLogic Domain menu, select System MBean Browser.
In the System MBean Browser pane, expand Application-Defined MBeans, then emoms.props, then Server: AdminServer, then Application: em, and then Properties.
Click emoms.properties.
In the Attributes pane, select the Operations tab and click setProperty.
Change the value of the following properties to the new host name:
oracle.sysman.emSDK.svlt.ConsoleServerHost
oracle.sysman.emSDK.svlt.ConsoleServerName
For example, for Key, enter oracle.sysman.emSDK.svlt.ConsoleServerHost. Then, for value, enter host.example.com:7001_Management_Service.
Click Invoke.
When you recover an Administration Server or a Managed Server to a different host and your environment includes Oracle HTTP Server, you must modify the following file on the new host:
(UNIX) DOMAIN_HOME/config/fmwconfig/components/OHS/ohs_name/mod_wl_ohs.conf (Windows) DOMAIN_HOME\config\fmwconfig\components\OHS\ohs_name\mod_wl_ohs.conf
Note that with Oracle HTTP Server in a WebLogic Server domain, this directory is in the Domain home of the Administration Server. With Oracle HTTP Server in a standalone domain, this directory is the Domain home of Oracle HTTP Server.
Modify all of the instances of the host name, port, and clusters (elements such as WebLogicHost, WebLogicPort, and WebLogicCluster) entries in that file. For example:
<Location /console> SetHandler weblogic-handler WebLogicHost Admin_Host WeblogicPort Admin_Port WLProxySSL ON WLProxySSLPassThrough ON </Location> . . . <Location /soa-infra> SetHandler weblogic-handler WebLogicCluster SOAHOST1VHN2:8001,*SOAHOST2VHN1*:*8001* WLProxySSL ON WLProxySSLPassThrough ON </Location>
If the Administration Server has a Listen address, you must create a new machine with the new host name before you start the Administration Server:
Take the following steps:
Create a new machine with the new host name. Use the following WLST commands, in offline mode:
readDomain('DOMAIN_HOME') machine = create('newhostname', 'Machine') cd('/Machine/newhostname') nm = create('newhostname', 'NodeManager') cd('/Machine/newhostname/NodeManager/newhostname') set('ListenAddress', 'newhostname') updateDomain()
For the Administration Server, set the machine with the new host name, using the following WLST command, in offline mode:
readDomain('DOMAIN_HOME') cd ('/Machine/newhostname') machine = cmo cd ('/Server/AdminServer') set('Machine', machine) updateDomain()
Set the listen port for the Administration Server, using WLST:
readDomain('DOMAIN_HOME')
cd('/Server/AdminServer')
cmo.setListenPort(8001)
updateDomain()
If required, update the Administration Server listen address, using WLST:
readDomain('DOMAIN_HOME') cd('/Server/AdminServer') cmo.getListenAddress() cmo.setListenAddress('newhostname') updateDomain() exit()
For many components, when you recover to a different host, as in the case of loss of host, you must update the Oracle inventory. To do so, execute the following script:
(UNIX) ORACLE_HOME/oui/bin/attachHome.sh (Windows) ORACLE_HOME\oui\bin\attachHome.cmd
When you recover any component to a different host on Windows, as in the case of loss of host, you must import any Windows Registry keys related to Oracle Fusion Middleware to the new host. (You exported the Registry keys in Section 17.3.3.)
Recover the following Registry key.
HKEY_LOCAL_MACHINE\Software\Oracle
In addition, recover each node that begins with Oracle within the following registry keys:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services
To import a key that you have previously exported, use the following command:
regedit /I FileName
For example:
regedit /I C:\oracleregistry.reg
You can also use the Registry Editor to import the key. See the Registry Editor Help for more information.
For information about recovering your database, see Section 18.2.9.