| Oracle® Fusion Middleware Administrator's Guide 11g Release 1 (11.1.1) E10105-01 |
|
 Previous |
 Next |
| Oracle® Fusion Middleware Administrator's Guide 11g Release 1 (11.1.1) E10105-01 |
|
Previous |
Next |
This chapter provides an introduction to backing up and recovering Oracle Fusion Middleware.
This chapter includes the following topics:
An Oracle Fusion Middleware environment can consist of different components and configurations. A typical Oracle Fusion Middleware environment contains an Oracle WebLogic Server domain with Java components, such as Oracle SOA Suite, and an Oracle WebLogic Server domain with Identity Management components. It can also include one or more Oracle instances.
The installations of an Oracle Fusion Middleware environment are interdependent in that they contain configuration information, applications, and data that are kept in synchronization. For example, when you perform a configuration change, you might update configuration files in the installation. When you deploy an application, you might deploy it to all Managed Servers in a domain or cluster.
It is, therefore, important to consider your entire Oracle Fusion Middleware environment when performing backup and recovery. You should back up your entire Oracle Fusion Middleware environment at once, then periodically. If a loss occurs, you can restore your environment to a consistent state.
The following topics describe concepts that are important to understanding backup and recovery:
|
See Also:
|
The failure of an Administration Server does not affect the operation of Managed Servers in the domain but it does prevent you from changing the domain's configuration. If an Administration Server fails because of a hardware or software failure on its host computer, other server instances on the same computer may be similarly affected.
If an Administration Server for a domain becomes unavailable while the server instances it manages—clustered or otherwise—are running, those Managed Servers continue to run. Periodically, these Managed Servers attempt to reconnect to the Administration Server. For clustered Managed Server instances, the load balancing and failover capabilities supported by the domain configuration continue to remain available.
When you first start a Managed Server, it must be able to connect to the Administration Server to retrieve a copy of the configuration. Then, you can start a Managed Server even if the Administration Server is not running. In this case, the Managed Server uses a local copy of the domain's configuration files for its starting configuration and then periodically attempts to connect with the Administration Server. When it does connect, it synchronizes its configuration state with that of the Administration Server.
Managed Servers maintain a local copy of the domain configuration. When a Managed Server starts, it contacts its Administration Server to retrieve any changes to the domain configuration that were made since the Managed Server was last shut down. If a Managed Server cannot connect to the Administration Server during startup, it can use its locally cached configuration information—this is the configuration that was current at the time of the Managed Server's most recent shutdown. A Managed Server that starts without contacting its Administration Server to check for configuration updates is running in Managed Server Independence (MSI) mode. By default, MSI mode is enabled. However a Managed Server cannot be started even in MSI mode for the first time if the Administration Server is down due to non-availability of the cached configuration.
Configuration changes are updated in a Managed Server during the following events:
On each Managed Server restart, the latest configuration is pulled from the Administration Server. This happens even when the Node Manager is down on the node where the Managed Server is running. If the Administration Server is unavailable during the Managed Server restart and if the MSI (Managed Server Independence) mode is enabled in the Managed Server, it starts by reading its local copy of the configuration and synchronizes with the Administration Server when it is available. By default MSI mode is enabled.
Upon activating every administrative change like configuration changes, deploy or redeploy of applications, and topology changes, the Administration Server pushes the latest configuration to the Managed Server. If the Managed Server is not running, the Administration Server pushes the latest version of the configuration to the Managed Server when it does start.
The following shows a simplified view of the Oracle Fusion Middleware directory structure:
To back up your Oracle Fusion Middleware environment, you can use:
File copy utilities such as copy, xcopy, or jar.
For example, for online backups on Windows, use copy; for offline backups on Windows, use copy, xcopy, or jar. Do not use Winzip because it does not work with long filenames or extensions.
For example, for Linux and UNIX, use tar.
Ensure that the tool you are using preserves the permissions of the files.
Oracle Recovery Manager (RMAN) to back up database-based metadata repositories.
Oracle WebLogic Server Pack and Unpack Utility
The pack command creates a template archive (.jar) file that contains a snapshot of either an entire domain or a subset of a domain. You can use a template that contains a subset of a domain to create a Managed Server domain directory hierarchy on a remote computer.
Alternatively, you can use a template that contains an entire domain to create the the domain on a remote computer.
|
See Also: Oracle Fusion Middleware Creating Templates and Domains Using the Pack and Unpack Commands |
If you want to retain your backups for a longer duration, you may want to back up to tape, for example using Oracle Secure Backup.
You can also configure Oracle WebLogic Server to make backup copies of the configuration files. This facilitates recovery in cases where configuration changes need to be reversed or in the unlikely case that configuration files become corrupted. When the Administration Server starts, it saves a JAR file named config-booted.jar that contains the configuration files. When you make changes to the configuration files, the old files are saved in the configArchive directory under the domain directory, in a JAR file with a sequentially numbered name such as config-1.jar. However, the configuration archive is always local to the Administration Server host. It is a best practice to back up the archives to an external location.
You can backup your Oracle Fusion Middleware environment offline or online:
An offline backup means that you must shut down the environment before backing up the files. When you perform an offline backup, the Administration Server, all Managed Servers in the domain, and all system components in the Oracle instances should be shut down.
Back up the environment offline immediately after installation and after applying any patches or upgrades.
An online backup means that you do not shut down the environment before backing up the files. 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 3.4.2.
You can perform backups on your full Oracle Fusion Middleware environment, or on the run-time artifacts, those files that change frequently.
To perform a full backup, you should back up the static files and directories, as well as run-time artifacts.
Static files and directories are those that do not change frequently. These include:
The Middleware home (MW_HOME). MW_HOME consists of an Oracle home and a WebLogic Server home. It can also contain the user_projects directories, which contains Oracle WebLogic Server domains, and an Oracle instance home, which are not static files.
OraInventory
OraInst.loc and oratab files, which are located in the following directory:
/etc
The beahomelist file, which is located at:
(UNIX) user_home/bea/beahomelist
(Windows) C:\bea\beahomelist
On Windows, the following registry key:
HKEY_LOCAL_MACHINE\Software\oracle
In addition, for system components, such as Oracle Web Cache, you must back up the following Windows Registry key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
Run-time artifacts are those files that change frequently. Back up these files when you perform a full backup and on a regular basis. Run-time artifacts include:
Domain directories of the Administration Server and the Managed Servers (by default, a domain directory resides in MW_HOME, but it can be configured by the user to point to a different location)
In most cases, you do not need to back up Managed Server domain directories separately because the Administration Server contains information about all of the Managed Servers in its domain.
All Oracle instance homes, which reside, by default, in the MW_HOME but can be configured to be in a different location
Application artifacts, such as .ear or .war files
You do not need to backup application artifacts in a Managed Server domain because they can be pulled from the Administration Server during Managed Server startup.
Database artifacts such as the MDS repository
Any database-based metadata repositories used by Oracle Fusion Middleware. You use Oracle Recovery Manager (RMAN) to back up an Oracle database.
Persistent stores, such as JMS Providers and transaction logs, which reside, by default in the user_projects directory, but can be configured in a different location. However, note the limitation described in Section 14.2.
This section outlines the recommended strategy for performing backups. Using this strategy ensures that you can perform the recovery procedures in this book.
Perform a full offline backup: This involves backing up the entities described in Section 13.3.1. Perform an offline full backup at the following times:
Immediately after you install Oracle Fusion Middleware.
Immediately after an operating system software upgrade.
Perform an online backup of run-time artifacts: This involves backing up the run-time artifacts described in Section 13.3.1. Backing up the run-time artifacts enables you to restore your environment to a consistent state as of the time of your most recent configuration and metadata backup. To avoid an inconsistent backup, do not make any configuration changes until backup completes. Perform an online backup of run-time artifacts at the following times:
On a regular basis. Oracle recommends that you back up run-time artifacts nightly.
Prior to making configuration changes to a component or cluster.
After making configuration changes to a component or cluster.
Prior to deploying a custom Java EE application to a Managed Server or cluster.
After a major change to the deployment architecture, such as creating servers or clusters.
Perform an offline backup of static files and directories: This involves backing up the static files and directories described in Section 13.3.1. Perform an offline backup of static files and directories at the following times:
After patching your Oracle Fusion Middleware environment. This backup serves as the basis for subsequent online backups.
After upgrading your Oracle Fusion Middleware environment. This backup serves as the basis for subsequent online backups.
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
Metadata Repository files
Oracle system files
Windows Registry key
Application artifacts
You can recover your Oracle Fusion Middleware environment while Oracle Fusion Middleware is offline.
To recover your Oracle Fusion Middleware environment, you can use:
File copy utilities such as copy, xcopy or tar.
When you restore the files, use your preferred tool to extract the compressed files.
For example, for online recovery on Windows, use copy; for offline recovery on Windows, use copy, xcopy, or jar. Do not use Winzip because it does not work with long filenames or extensions.
For example, for Linux and UNIX, use tar.
Oracle Recovery Manager (RMAN) to recover database-based metadata repositories.
You can recover your Oracle Fusion Middleware environment in part or in full. You can recover the following:
A domain
The WebLogic Administration Server
A Managed Server
The Middleware home
An Oracle instance home
A component, such as Oracle HTTP Server or Oracle Web Cache
A cluster
Deployed applications
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 an Oracle instance home or a component, 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.
The following sections describe backup and recovery recommendations for specific Oracle Fusion Middleware components:
Backup and Recovery Recommendations for Oracle Identity Management
Backup and Recovery Recommendations for Oracle JRF Installations
Backup and Recovery Recommendations for Web Tier Installations
For the steps you take to back up your environment, see Section 14.3. For the steps you take to recover a component, see Chapter 15.
The following sections describe backup and recovery recommendations for Oracle SOA Suite:
Backup and Recovery Recommendations for Oracle BPEL Process Manager
Backup and Recovery Recommendations for Oracle Business Activity Monitoring
Backup and Recovery Recommendations for Oracle Business Rules
Backup and Recovery Recommendations for Oracle WebLogic Server JMS
You can configure Oracle SOA Suite so that the Administration Server is on a separate host from the Managed Servers. You do this by using the ant-soa-util.xml script that is provided. In this case, the domain is an Administration Server-only domain and no Managed Servers share the domain directory with the Administration Server. For example, a domain contains two Managed Servers, one of which contains Oracle SOA Suite, but neither of the Managed Server's directories are on the same host as the Administration Server.
In this case, you must back up the Administration Server domain as well as the following directory for all Managed Servers:
DOMAIN_HOME/config/soa-infra
For the steps you need to take to recover components, see Section 15.2.6 and Section 15.3.3. For the steps specific to recovering from loss of host, see Section 15.3.3.5.
This section describes the Oracle BPEL Process Manager data that must be backed up and restored.
For the steps you need to take to recover components, see Section 15.2.6 and Section 15.3.3. For the steps specific to recovering from loss of host, see Section 15.3.3.5.
Configuration Files
Configuration files are stored in the database.
Database Repository Dependencies
Process definition and configuration files are stored in the MDS schema. The dehydration store is stored in the BPEL schema.
Backup Recommendations
Back up the database after any configuration changes, including changes to global fault policies, callback classes for workflows and resource bundles that can potentially be outside the suitcase). Also back up the database after deploying a new composite or redeploying a composite.
If this is an Administration Server-only domain, as described in Section 13.5.1, back up the following directory:
DOMAIN_HOME/config/soa-infra
Recovery Recommendations
Recover the database to the most recent point in time, if needed. Point-in-time recovery ensures that the latest process definitions and in-flight instances are restored. However, this may result in reexecution of the process steps. Oracle recommends that you strive for idempotent Oracle BPEL Process Manager processes. If the system contains processes that are not idempotent, you must clean them up from the dehydration store before starting Oracle Fusion Middleware. See Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite for more information.
Because instances obtain the process definition and artifacts entirely from the database, there is no configuration recovery needed after the database is recovered to the most current state; instances should continue to function correctly.
For redeployed composites, a database recovery ensures consistency between the dehydrated in-flight processes and their corresponding definition since the process definition is stored in database repository where dehydrated instances get stored as well.
This section describes the Oracle Business Activity Monitoring data that must be backed up and restored.
For the steps you need to take to recover components, see Section 15.2.6 and Section 15.3.3. For the steps specific to recovering from loss of host, see Section 15.3.3.5.
Configuration Files
MW_HOME/SOA_ORACLE_HOME/bam DOMAIN_HOME/config/fmwconfig/servers/AdminServer/adml/server-oracle_bamweb-11.0.xml DOMAIN_HOME/config/fmwconfig/servers/AdminServer/adml/server-oracle_bamserver-11.0.xml DOMAIN_HOME/config/fmwconfig/servers/bam-server-name/adml/server-oracle_bamweb-11.0.xml DOMAIN_HOME/config/fmwconfig/servers/bam-server-name/adml/server-oracle_bamserver-11.0.xml
Database Repository Dependencies
ORABAM schema.
Backup Recommendations
Back up the Middleware home, the domain and the database containing the ORABAM schema.
If this is an Administration Server-only domain, as described in Section 13.5.1, back up the following directory:
DOMAIN_HOMEconfig/soa-infra
Recovery Recommendations
Recover the Managed Server or the Middleware home, or both, depending on the extent of failure.
Recover the database to the most recent point in time, if needed.
This section describes the Oracle B2B data that must be backed up and restored.
For the steps you need to take to recover components, see Section 15.2.6 and Section 15.3.3. For the steps specific to recovering from loss of host, see Section 15.3.3.5.
Configuration Files
DOMAIN_HOME/config/soa-infra/configuration/b2b-config.xml
Database Repository Dependencies
MDS schema.
Backup Recommendations
Back up the Administration Server domain, the Oracle home if changes are made to the Oracle B2B configuration file, and the database containing the MDS schema.
If this is an Administration Server-only domain, as described in Section 13.5.1, back up the following directory:
DOMAIN_HOME/config/soa-infra
Recovery Recommendations
Recover the Managed Server where the soa-infra application is deployed.
Recover the database to the most recent point in time, if needed.
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
This section describes the Oracle Business Rules data that must be backed up and restored.
For the steps you need to take to recover components, see Section 15.2.6 and Section 15.3.3. For the steps specific to recovering from loss of host, see Section 15.3.3.5.
Configuration Files
DOMAIN_HOME/config/soa-infra/configuration/businessrules-config.xml
Database Repository Dependencies
MDS schema.
Backup Recommendations
Back up the Administration Server domain and the database containing the MDS schema.
If this is an Administration Server-only domain, as described in Section 13.5.1, back up the following directory:
DOMAIN_HOME/config/soa-infra
Recovery Recommendations
Recover the Managed Server where the soa-infra application is deployed.
Recover the database to the most recent point in time, if needed.
This section describes the Oracle WebLogic Server JMS data that must be backed up and restored.
For the steps you need to take to recover components, see Section 15.2.6 and Section 15.3.3.
Configuration Files
DOMAIN_HOME/config/jms
If a JMS uses a file-system accessible stores, the default file-system store is either in a user-configured location that is specified in config.xml, or in this location:
DOMAIN_HOME/servers/server_name/data/store/default
Database Repository Dependencies
If a JMS uses a JDBC accessible store, back up the database.
Backup Recommendations
Back up the domain and the JMS file persistent store if it is not located within the domain.
Back up the schema in the database if JDBC-based persistent store is configured. Note the following:
Always try to keep JMS data as current as possible. This can be achieved by using the point-in-time recovery capabilities of Oracle Database (in the case of database- based persistence) or using a highly available RAID backed storage device (for example, SAN/NAS).
If, for whatever reason, you need to restore JMS data to previous point in time, there are potential implications. Restoring the system state to a prior point in time not only can cause duplicate messages, but can also cause lost messages. The lost messages are messages that were enqueued before or after the system restore point time, but never processed. If the persistent store is a custom store that is dedicated to JMS use, then you can delete the entire store.
Use the following procedure before recovery to drain messages in the JMS queue after persistent-store recovery to avoid processing duplicate messages:
Log into the Oracle WebLogic Server Administration Console.
Before recovery, configure JMS server to pause Production, Insertion, and consumption operations at boot-time to ensure that no new messages are produced or inserted into the destination or consumed from the destination before you drain stale messages. To do this:
Expand Services, then Messaging, and then JMS Servers.
On the Summary of JMS Servers page, click the JMS server you want to configure for message pausing.
On the Configuration: General page, click Advanced to define the message pausing options. Select Insertion Paused At Startup, Production Paused At Startup, and Consumption Paused At Startup.
Click Save.
To activate these changes, in the Change Center of the Administration Console, click Activate Changes.
Use the following procedure after recovery:
After recovering the persistent store, start the Managed Servers.
Drain the stale messages from JMS destinations, by taking the following steps:
Expand Services, then Messaging, and then JMS Modules.
Select a JMS module, then select a destination.
Select Monitoring, then Show Messages
Click Delete All.
Resume operations, by taking the following steps:
Expand Services, then Messaging, and then JMS Servers.
On the Summary of JMS Servers page, click the JMS server you want to configure for message pausing.
On the Configuration: General page, click Advanced. Select Insertion Paused At Startup, Production Paused At Startup, and Consumption Paused At Startup.
Click Save.
To activate these changes, in the Change Center of the Administration Console, click Activate Changes.
If the store is not dedicated to JMS use, use the Oracle WebLogic Server JMS message management administrative tooling. This tooling can perform import, export, move, and delete from the Administration Console, MBeans, and WLST.
For applications that use publish and subscribe in addition to queuing, you should manipulate topic subscriptions in addition to queues.
All JMS data should be backed up continuously and synchronously. Do not use asynchronous snapshots:
For Oracle Database-based persistence, use RMAN for backups.
For file-based persistence, if you are using a SAN/NAS device, then use snapshot mechanism to take a consistent JMS data backup.
If you are using a storage device that does not support block-level snapshot capabilities, then you must shutdown the JMS server to be able to take a consistent backup. This is to ensure that the persistence store is not being written to while the copy operation is being performed. In a clustered environment, you can do so by shutting down one server at time, backing it up and restarting it. You also can create a script to perform these operations using WLST.
Recovery Recommendations
Recover the domain.
If the JMS file persistent store is file-based, recover it from backup. If the JMS file persistent store is database-based, recover the database to the most recent point in time, if needed.
The following sections describe backup and recovery recommendations for Oracle WebCenter:
Backup and Recovery Recommendations for Oracle WebCenter Portlets
Backup and Recovery Recommendations for Oracle WebCenter Discussions Server
Backup and Recovery Recommendations for Oracle WebCenter Wiki and Blog Server
This section describes the Oracle WebCenter data that must be backed up and restored.
For the steps you need to take to recover components, see Section 15.2.6 and Section 15.3.3. For the steps specific to recovering from loss of host, see Section 15.3.3.7.
Configuration Files
All configuration files are bundled in the EAR file, which is located in the domain.
Database Repository Dependencies
WEBCENTER and MDS schemas
Backup Recommendations
Back up the domain and the database containing the WEBCENTER and MDS schemas.
Recovery Recommendations
Recover the Oracle WebCenter domain.
Recover the database containing the WEBCENTER and MDS schemas to the most recent point in time, if needed.
This section describes the Oracle WebCenter Portlets data that must be backed up and restored.
For the steps you need to take to recover components, see Section 15.2.6 and Section 15.3.3. For the steps specific to recovering from loss of host, see Section 15.3.3.7.
Configuration Files
All configuration files are bundled in the EAR file, which is located in the domain.
Database Repository Dependencies
PORTLET
Backup Recommendations
Back up the Oracle WebCenter domain and the database containing the PORTLET schema.
Recovery Recommendations
Recover the Oracle WebCenter domain.
Recover the database to the most recent point in time, if needed.
This section describes the Oracle WebCenter Discussions server data that must be backed up and restored.
For the steps you need to take to recover components, see Section 15.2.6 and Section 15.3.3. For the steps specific to recovering from loss of host, see Section 15.3.3.7.
Configuration Files
Some configuration files are either bundled in the EAR file, which is located in the domain or the files are located elsewhere in the domain. Other configuration files are located in:
DOMAIN_HOME/fmwconfig/server/<server_name>/owc_discussions
Database Repository Dependencies
JIVE schema.
Backup Recommendations
Back up the Oracle WebCenter domain and the database containing the JIVE schema.
Recovery Recommendations
Recover the Oracle WebCenter domain.
Recover the database to the most recent point in time, if needed.
This section describes the Oracle WebCenter Wiki and Blog Server data that must be backed up and restored.
For the steps you need to take to recover components, see Section 15.2.6 and Section 15.3.3. For the steps specific to recovering from loss of host, see Section 15.3.3.7.
Configuration Files
Configuration files are bundled in the WAR file, which is located in the domain.
Database Repository Dependencies
WIKI schema.
Backup Recommendations
Back up the Oracle WebCenter domain and the database containing the WIKI schema.
Recovery Recommendations
Recover the Oracle WebCenter domain.
Recover the database to the most recent point in time, if needed.
For information about backing up and recovering Oracle Content Server, see Getting Started with Content Server which is available at:
http://download.oracle.com/docs/cd/E10316_01/owc.htm
Database Repository Dependencies
OCSERVER schema.
The following sections describe backup and recovery recommendations for Oracle Identity Management:
Backup and Recovery Recommendations for Oracle Internet Directory
Backup and Recovery Recommendations for Oracle Virtual Directory
Backup and Recovery Recommendations for Oracle Directory Integration Platform
Backup and Recovery Recommendations for Oracle Directory Services Manager
Backup and Recovery Recommendations for Oracle Identity Federation
This section describes the Oracle Internet Directory data that must be backed up and restored.
For the steps you need to take to recover components, see Section 15.2.6 and Section 15.3.3. For the steps specific to recovering from loss of host, see Section 15.3.3.9.1.
Configuration Files
ORACLE_INSTANCE/config/tnsnames.ora ORACLE_INSTANCE/OID/admin ORACLE_INSTANCE/OID/ldap/server/plugin ORACLE_INSTANCE/OID/component_name ORACLE_INSTANCE/config/OID/component_name
Database Repository Dependencies
ODS and ODSSM schemas.
Backup Recommendations
Back up the Oracle Internet Directory component directory and Oracle Internet Directory's configuration files from the Oracle instance home. Back up the database containing the ODS and ODSSM schemas.
Recovery Recommendations
Recover the Oracle Internet Directory specific files into Oracle Internet Directory's component directory of the restored Oracle instance home.
Recover the database to the most recent point in time, if needed.
This section describes the Oracle Virtual Directory data that must be backed up and restored.
For the steps you need to take to recover components, see Section 15.2.6 and Section 15.3.3. For the steps specific to recovering from loss of host, see Section 15.3.3.9.2.
Configuration Files
ORACLE_INSTANCE/OVD/component_name ORACLE_INSTANCE/config/OVD/component_name ORACLE_INSTANCE/diagnostics/logs/OVD/component_name
Database Repository Dependencies
None.
Backup Recommendations
Back up the Oracle Virtual Directory component directory and Oracle Virtual Directory's configuration files from the Oracle instance home.
Recovery Recommendations
Restore the Oracle Virtual Directory's configuration files into the Oracle Virtual Directory component directory of the restored Oracle instance home.
This section describes the Oracle Directory Integration Platform data that must be backed up and restored.
For the steps you need to take to recover components, see Section 15.2.6 and Section 15.3.3. For the steps specific to recovering from loss of host, see Section 15.3.3.9.3.
Configuration Files
dip-config.xml, which is part of the Oracle Directory Integration Platform application. It is backed up when you back up the Administration Server domain.
Database Repository Dependencies
ODSSM schema, used by Oracle Internet Directory.
Backup Recommendations
Back up the Administration Server domain and Oracle Internet Directory and its dependencies.
Recovery Recommendations
Recover the Managed Server where the Oracle Directory Integration Platform application is deployed.
Recover Oracle Internet Directory.
This section describes the Oracle Directory Services Manager data that must be backed up and restored.
For the steps you need to take to recover components, see Section 15.2.6 and Section 15.3.3. For the steps specific to recovering from loss of host, see Section 15.3.3.9.4.
Configuration Files
Oracle Directory Services Manager, which is the graphical user interface for Oracle Internet Directory and Oracle Virtual Directory, does not have configuration files, but keeps track of host and port information of Oracle Internet Directory and Oracle Virtual Directory in serverlist.txt, which is part of the application .ear:
MW_HOME/user_projects/domains/domain_name/servers/server_name/tmp/_WL_user/odsm_11.1.1.0.0/nx1i7i/war/WEB-INF/serverlist.txt
Database Repository Dependencies
None.
Backup Recommendations
Back up the domain.
Recovery Recommendations
To restore Oracle Directory Services Manager, enter the user name and password to connect to Oracle Internet Directory or Oracle Virtual Directory.
This section describes the Oracle Identity Federation data that must be backed up and restored.
For the steps you need to take to recover components, see Section 15.2.6 and Section 15.3.3. For the steps specific to recovering from loss of host, see Section 15.3.3.9.5.
Configuration Files
DOMAIN_HOME/servers/server_name/stage/OIF/11.1.1.0.0/OIF/configuration
Database Repository Dependencies
OIF schema.
Backup Recommendations
Back up the Administration Server domain and the database containing the OIF schema.
Recovery Recommendations
Recover the Managed Server where the Oracle Identity Federation application is deployed.
Recover the database to the most recent point in time, if needed.
The following topics describe backup and recovery recommendations for components that are installed with more than one type of installation:
Backup and Recovery Recommendations for Oracle Web Services Manager
Backup and Recovery Recommendations for Oracle Platform Security Services
This section describes the Oracle Web Services Manager data that must be backed up and restored.
For the steps you need to take to recover components, see Section 15.2.6 and Section 15.3.3.
Configuration Files
DOMAIN_HOME/config/fmwconfig/policy-accessor-config.xml
Database Repository Dependencies
If a database-based MDS repository is used, Oracle Web Services Manager uses a partition in the MDS schema.
Backup Recommendations
Back up Oracle Web Services Manager configuration files.
If Oracle Web Services Manager uses a file-based MDS repository, back it up using a file copy mechanism. If it uses a database-based MDS repository, back up the database using RMAN.
Recovery Recommendations
Restore Oracle Web Services Manager configuration files.
If Oracle Web Services Manager uses a file-based MDS repository, restore it from the backup. If it uses a database-based MDS repository, recover the database to the most recent point in time, if needed.
This section describes the Oracle Platform Security Services data that must be backed up and restored.
For the steps you need to take to recover components, see Section 15.2.6 and Section 15.3.3. For the steps specific to recovering from loss of host, see Section 15.3.3.9.1.
Configuration Files
DOMAIN_HOME/config/fmwconfig/jps-config.xml
Database Repository Dependencies
None.
Backup Recommendations
Back up the Administration Server domain.
Recovery Recommendations
Restore the jps-config.xml file.
The following sections describe backup and recovery recommendations for Web Tier installations:
This section describes the Oracle HTTP Server data that must be backed up and restored.
For the steps you need to take to recover components, see Section 15.2.6 and Section 15.3.3. For the steps specific to recovering from loss of host, see Section 15.3.3.8.1.
Configuration Files
ORACLE_INSTANCE/config/OHS/component_name ORACLE_INSTANCE/diagnostics/logs/OHS/component_name
Database Repository Dependencies
None.
Backup Recommendations
Back up the Oracle HTTP Server Oracle instance home.
Recovery Recommendations
Restore the Oracle HTTP Server-specific files into its Oracle instance home.
This section describes the Oracle Web Cache data that must be backed up and restored.
For the steps you need to take to recover components, see Section 15.2.6 and Section 15.3.3. For the steps specific to recovering from loss of host, see Section 15.3.3.8.2.
Configuration Files
ORACLE_INSTANCE/config/WebCache/component_name ORACLE_INSTANCE/diagnostics/logs/WebCache/component_name
Database Repository Dependencies
None.
Backup Recommendations
Back up the Oracle Web Cache Oracle instance home.
Recovery Recommendations
Restore the Oracle Web Cache-specific files into its Oracle instance home.
The following sections describe backup and recovery recommendations for these components:
Backup and Recovery Recommendations for Oracle Forms Services
Backup and Recovery Recommendations for Oracle Business Intelligence Discoverer
This section describes the Oracle Portal data that must be backed up and restored.
For the steps you need to take to recover components, see Section 15.2.6 and Section 15.3.3. For the steps specific to recovering from loss of host, see Section 15.3.3.10.1.
Configuration Files
MW_HOME/user_projects/domains/domain_name/servers/server_name/stage/portal/portal/configuration/appConfig.xml MW_HOME/user_projects/domains/domain_name/servers/server_name/stage/portal/portal/configuration/portal_dads.conf MW_HOME/user_projects/domains/domain_name/servers/server_name/stage/portal/portal/configuration/portal_plsql.conf MW_HOME/user_projects/domains/domain_name/servers/server_name/stage/portal/portal/configuration/portal_cache.conf
Database Repository Dependencies
PORTAL, PORTAL_DEMO, PORTAL_APP, PORTAL_PUBLIC, AND PORTAL_APPROVAL schemas.
Backup Recommendations
Back up the WebLogic Server domain and the Oracle instance containing Oracle Portal, as well as the database containing the schemas.
Recovery Recommendations
Recover the WebLogic Server domain and the Oracle instance containing Oracle Portal, as well as the database containing the schemas.
Recover the database to the most recent point in time, if needed.
This section describes the Oracle Forms Services data that must be backed up and restored.
For the steps you need to take to recover components, see Section 15.2.6 and Section 15.3.3. For the steps specific to recovering from loss of host, see Section 15.3.3.10.4.
Configuration Files
Forms Component:
ORACLE_INSTANCE/config/Forms/forms ORACLE_INSTANCE/Forms/forms
Forms Common Component:
ORACLE_INSTANCE/config/Forms/frcommon ORACLE_INSTANCE/Forms/frcommon
Forms Java EE application and external files:
wls_managed_server/stage/formsapp
Database Repository Dependencies
Any user-configured database for Oracle Forms Services applications.
Backup Recommendations
Back up the Oracle instance home where Oracle Forms Services is located.
Recovery Recommendations
Restore the configuration files.
This section describes the Oracle Reports data that must be backed up and restored.
For the steps you need to take to recover components, see Section 15.2.6 and Section 15.3.3. For the steps specific to recovering from loss of host, see Section 15.3.3.10.3.
Configuration Files
For Reports Server:
ORACLE_INSTANCE/config/ReportsServer/server_name/rwserver.conf ORACLE_INSTANCE/config/ReportsServer/server_name/jdbcpds.conf ORACLE_INSTANCE/config/ReportsServer/server_name/xmlpds.conf ORACLE_INSTANCE/config/ReportsServer/server_name/textpds.conf ORACLE_INSTANCE/config/ReportsServer/server_name/rwnetwork.conf ORACLE_INSTANCE/config/ReportsServer/server_name/pcscomponent.conf ORACLE_INSTANCE/config/ReportsServer/server_name/component-logs.xml ORACLE_INSTANCE/config/ReportsServer/server_name/logging.xml
For Oracle Reports Servlet:
DOMAIN_HOME/servers/server_namestage/reports/reports/configuration/cgimd.dat DOMAIN_HOME/servers/server_namestage/reports/reports/configuration/rwservlet.properties DOMAIN_HOME/servers/server_namestage/reports/reports/configuration/rwserver.conf DOMAIN_HOME/servers/server_namestage/reports/reports/configuration/jdbcpds.conf DOMAIN_HOME/servers/server_namestage/reports/reports/configuration/xmlpds.conf DOMAIN_HOME/servers/server_namestage/reports/reports/configuration/textpds.conf DOMAIN_HOME/servers/server_namestage/reports/reports/configuration/rwnetwork.conf DOMAIN_HOME/servers/server_namestage/reports/reports/configuration/logging.xml DOMAIN_HOME/servers/server_namestage/reports/reports/configuration/logmetadata.xml
For Oracle Reports Bridge:
ORACLE_INSTANCE/config/ReportsBridge/bridge_name/rwbridge.conf ORACLE_INSTANCE/config/ReportsBridge/bridge_name/rwnetwork.comf ORACLE_INSTANCE/config/ReportsBridge/bridge_name/component-logs.xml ORACLE_INSTANCE/config/ReportsBridge/bridge_name/loggin.xml ORACLE_INSTANCE/config/ReportsBridge/bridge_name/pcscomponent.xml
For Oracle Reports Tool:
ORACLE_INSTANCE/config/ReportsTools/rwbuilder.conf ORACLE_INSTANCE/config/ReportsTools/rwnetwork.conf ORACLE_INSTANCE/config/ReportsTools/jdbcpds.conf ORACLE_INSTANCE/config/ReportsTools/xmlpds.conf ORACLE_INSTANCE/config/ReportsTools/textpds.conf ORACLE_INSTANCE/config/ReportsTools/pcscomponent.xml ORACLE_INSTANCE/config/ReportsTools/rwservlet.properties ORACLE_INSTANCE/config/ReportsTools/cgicmd.dat ORACLE_INSTANCE/config/ReportsTools/component-logs.xml ORACLE_INSTANCE/config/ReportsTools/logging.xml
Other directories and files:
ORACLE_INSTANCE/reports/server/*.dat ORACLE_INSTANCE/reports/cache/ ORACLE_INSTANCE/reports/fonts/ ORACLE_INSTANCE/reports/plugins/resource ORACLE_INSTANCE/diagnostics/logs/reports/ReportsServer ORACLE_INSTANCE/diagnostics/logs/reports/ReportsBridge ORACLE_INSTANCE/diagnostics/logs/reports/ReportsTools (UNIX) ORACLE_INSTANCE/config/reports/bin/rw*.sh (Windows) ORACLE_INSTANCE\config\reports\bin\rw*.bat (UNIX) ORACLE_INSTANCE/config/reports/bin/reports.sh (Windows) ORACLE_INSTANCE\config\reports\bin\reports.bat (UNIX) ORACLE_INSTANCE/config/reports/bin/namingservice.sh (Windows) ORACLE_INSTANCE\config\reports\bin\namingservice.bat
Database Repository Dependencies
You can configure Oracle Reports to store job-related information, such as scheduled job data, past job data, or job status data in a database.
Backup Recommendations
Back up the Oracle instance home where Oracle Reports is located.
If a database is configured for Oracle Reports, back up the database.
Recovery Recommendations
Restore the configuration files.
If a database is configured for Oracle Reports, recover the database to most recent point in time, if needed.
This section describes the Oracle Business Intelligence Discoverer data that must be backed up and restored.
For the steps you need to take to recover components, see Section 15.2.6 and Section 15.3.3. For the steps specific to recovering from loss of host, see Section 15.3.3.10.2.
Configuration Files
ORACLE_INSTANCE/config/PreferenceServer/disco-comp-name/pref.txt ORACLE_INSTANCE/config/PreferenceServer/disco-comp-name/.reg_key.dc DOMAIN_HOME/servers/server_name/stage/discoverer/discoverer/configuration/configuration.xml DOMAIN_HOME/config/config.xml DOMAIN_HOME/config/fmwconfig/servers/server_name/logging.xml ORACLE_INSTANCE/diagnostics/logs/PreferenceServer/Discoverer_instance_name/console* ORACLE_INSTANCE/diagnostics/logs/PreferenceServer/Discoverer_instance_name/log* DOMAIN_HOME/servers/server_name/logs/discoverer/diagnostic-*.xml DOMAIN_HOME/servers/server_name/logs/discoverer/diagnostics*.xml DOMAIN_HOME/servers/server_name/logs/discoverer/WLS_DISCO-diagnostic-*.xml
Database Repository Dependencies
DISCOVERER and DISCOVERER_PS schemas
Backup Recommendations
Back up the Oracle BI Discoverer Oracle instance home and the database containing the DISCOVERER and DISCOVERER_PS schemas.
Recovery Recommendations
Restore the configuration files to the Oracle BI Discoverer Oracle instance home.
Recover the database to the most recent point in time, if needed.
The following assumptions and restrictions apply to the backup and recovery procedures in this book. Also see the restrictions listed in Section 14.2.
File systems and files can only be restored as of the last "good" backup. There is no support for roll forward recovery to the current point in time.
All of the files required for recovery are maintained within the Middleware home, Oracle instance home, and Oracle Inventory (for loss of host use cases) directories. Generally, as long as no administration changes, such as configuration changes, deployments, redeployments, or patching, have been done since the last backup, it is always safe to restore the file system pertaining to a particular component to a previous point in time using the last "good" backup. Thus, new backups must always performed after any administration changes.
Only the user who installs the product or a user who has access privileges to the directories where Oracle Fusion Middleware has been installed should be able to execute backup and recovery operations.
If a single Managed Server and Administration Server are running in different hosts and the Managed Server is not in a cluster, you must use the pack and unpack commands on the Managed Server to pick up the correct configuration.
If you have multiple Managed Servers running on different hosts (not in a cluster), the domain should be configured to use an external LDAP for policy store instead of using file-base policy store.
If the Administration Server is on a different host than the Managed Servers, the domain should be configured to use an external LDAP for policy store instead of using file-base policy store.
|
See Also: If you are using Cold Failover Cluster or Disaster Recovery, refer to the Oracle Fusion Middleware High Availability Guide for additional information. |
