Oracle® Application Server Administrator's Guide 10g Release 3 (10.1.3.2.0) Part Number B32196-01 |
|
|
View PDF |
This chapter describes the Oracle Application Server backup strategy and procedures.
It contains the following topics:
This section describes the recommended backup strategy for Oracle Application Server. Using this strategy ensures that you can perform the recovery procedures described in this book.
The backup strategy is as follows:
Task 1: Perform a Complete Cold Backup of Your Oracle Application Server Environment
Task 3: Perform a New Complete Environment Backup After a Major Change
Task 4: Perform Instance Backups on a Regular Basis (Return to Task 2)
The flow chart in Figure 17-1 provides an overview of how to decide which type of backup is appropriate for a given circumstance.
Figure 17-1 Deciding the Type of Backup Needed
Task 1: Perform a Complete Cold Backup of Your Oracle Application Server Environment
The first backup you perform should be an image backup, which includes all of the files in your environment. You should also create a record of your environment.
Perform a complete Oracle Application Server environment backup.
This will serve as the baseline for all subsequent instance backups.
Refer to Section 17.2.3, "Performing a Complete Oracle Application Server Environment Backup".
Create a record of your Oracle Application Server environment.
In the event you need to reconstruct your environment, you can refer to this record.
Refer to Section 17.2.1, "Creating a Record of Your Oracle Application Server Configuration".
Task 2: Perform Instance Backups on a Regular Basis
After every administrative change, or, if this is not possible, on a regular basis, perform an instance backup of your Oracle Application Server environment.
See Also:
Appendix E, "Examples of Administrative Changes" to learn more about administrative changesRefer to Section 17.2.2, "Performing an Oracle Application Server Instance Backup from the Command Line".
Task 3: Perform a New Complete Environment Backup After a Major Change
If you make a major change to your Oracle Application Server environment, you must perform a new image backup of your Oracle Application Server environment. This backup serves as the basis for subsequent instance backups. You should also update the record of your environment with any new configuration information.
Perform a new image backup after:
An operating system software upgrade
An Oracle Application Server software upgrade or patch application
To do so:
Update the record of your Oracle Application Server environment.
Refer to Section 17.2.1, "Creating a Record of Your Oracle Application Server Configuration".
Perform a complete Oracle Application Server environment backup.
Refer to Section 17.2.3, "Performing a Complete Oracle Application Server Environment Backup".
Task 4: Perform Instance Backups on a Regular Basis (Return to Task 2)
After you establish a new complete Oracle Application Server environment backup, return to Task 2 and continue to perform instance backups on a regular basis.
Task 5: Perform Portlet Producer Backup
If your application contains remote portlet producers, you must back up the portlet producer customization and personalization data.
Additional Tips:
Create a backup of the JRE/JDK on your system. This is not an Oracle product, but it is utilized by Oracle Application Server and, if accidentally lost or corrupted, would need to be restored in order for Oracle Application Server to function. This issue only applies to HP-UX, HP Tru64, and IBM AIX systems.
Ensure that your backups are valid by routinely verifying that they can be restored.
This section describes the backup procedures in detail. To maintain configuration data consistency, you should back up each of your Oracle Application Server instances at the same time. While backing up one Oracle Application Server instance, ensure that no configuration changes are made in any of the other instances.
This section contains the following topics:
Creating a Record of Your Oracle Application Server Configuration
Performing an Oracle Application Server Instance Backup from the Command Line
Performing a Complete Oracle Application Server Environment Backup
In the event you need to restore and recover your Oracle Application Server environment, it is important to have all the necessary information at your disposal. This is especially true in the event of a hardware loss that requires you to reconstruct all or part of your Oracle Application Server environment on a new disk or host.
You should maintain an up-to-date record of your Oracle Application Server environment that includes the information listed in this section. You should keep this information both in hardcopy and electronic form. The electronic form should be stored on a host or e-mail system that is completely separate from your Oracle Application Server environment.
Your Oracle Application Server hardware and software configuration record should include:
The following information for each host in your environment:
Hostname
Virtual hostname (if any)
Domain name
IP address
Hardware platform
Operating system release level and patch information
The following information for each Oracle Application Server installation in your environment:
Host on which the installation resides
User name, userid number, group name, groupid number, environment profile, and type of shell for the operating system user that owns the Oracle home (/etc/passwd
and /etc/group
entries)
Directory structure, mount points, and full path for ORACLE_HOME
Amount of disk space used by the installation
Port numbers used by the installation
Note:
Useopmnctl status -l
to determine the ports in use.This section describes how to perform various Oracle Application Server instance backups from the command line. An instance-level backup backs up all the required components in an application server instance: configuration files, repositories for the middle tier.
Once you have performed a complete Oracle Application Server environment backup, you should perform subsequent instance-level backups after every administrative change, or, if this is not possible, on a regular basis.
Performing a Cold Backup of an Oracle Application Server Instance
Use the following command to perform a cold backup of an Oracle Application Server instance:
bkp_restore.sh -m backup_instance_cold bkp_restore.bat -m backup_instance_cold
Performing an Incremental Cold Backup of an Oracle Application Server Instance
Use the following command to perform an incremental cold backup of an Oracle Application Server instance:
bkp_restore.sh -m backup_instance_cold_incr bkp_restore.bat -m backup_instance_cold_incr
Performing an Online Backup of an Oracle Application Server Instance
Use the following command to perform an online backup of an Oracle Application Server instance:
bkp_restore.sh -m backup_instance_online bkp_restore.bat -m backup_instance_online
Performing an Incremental Online Backup of an Oracle Application Server Instance
Use the following command to perform an incremental online backup of an Oracle Application Server instance:
bkp_restore.sh -m backup_instance_online_incr -l level bkp_restore.bat -m backup_instance_online_incr -l level
This section describes how to perform a complete Oracle Application Server environment backup. You should back up the node after installation or after an upgrade. Perform the following tasks for each instance on the host:
Configuration Backup of the Node
Run the following command to create a backup of the node configuration:
On UNIX:
bkp_restore.sh -m configure
On Windows:
bkp_restore.bat -m configure
Node Backup Preparation
Run the following command to prepare a node for backup:
On UNIX:
bkp_restore.sh -m node_backup -o prepare
On Windows:
bkp_restore.bat -m node_backup -o prepare
Creating an Image Backup of the Instance
This task creates an archive of an instance that includes the Oracle home, oratab, central inventory, Windows registries and so forth. On UNIX, the command must be run from root. Run the following command to create an image backup of the instance:
On UNIX:
bkp_restore.sh -m node_backup -o image_backup -P archive path
On Windows:
bkp_restore.bat -m node_backup -o image_backup -P archive path
After the command completes, the backup is placed in the directory specified in archive path
.
To completely back up and recover an application containing remote portlet producers, you must back up and recover two additional items:
The portlet producer Web application itself. The producer's application is backed up and recovered as part of the overall Oracle Application Server backup and recovery. If the portlet producer runs on a remote Oracle Application Server installation, that application server must also be backed up.
The producer's preference store, which contains portlet personalization and customization data. You must use a preference store migration utility to back up the preference store.
Using the Predeployment tool, you can use the -backup
option to specify the location of the Oracle Metadata Services (OMS) repository when configuring OMS. This allows the Recovery Manager to backup the OMS repository by adding the location to the config_misc_files.inp
file.
Note:
Portlet preferences can be stored either in a relational database or in a file system. For more information on configuring the portlet preference store, refer to Oracle WebCenter Framework Developer's Guide.Note:
For information on disaster backup and recovery, refer to the Disaster Recovery section of the Oracle Application Server High Availability Guide.To back up your portlet producer preference store, you can use the JPS and PDK-Java preference store migration utilities.
To back up your JPS preference store, perform the following steps:
Stop the OC4J instance on which the portlet container runs.
Run the migration tool to back up data from the source preference store to the destination (backup) store. For example:
java -classpath wsrp-container.jar:cache.jar:saaj-api.jar:orasaaj.jar:ojdbc14.jar oracle.portlet.server.containerimpl.PersistenceMigrationTool -sourceType db -destType file -sourceDatabase portaldb.mycompany.com:1521:orcl -sourceUsername p1 -sourcePassword p1 -destPath /tmp/portletbkp
Start the OC4J instance on which the portlet container runs.
PersistenceMigrationTool Syntax
The syntax of the PersistenceMigrationTool
is:
java oracle.webdb.wsrp.server.PersistenceMigrationTool -sourceType file | db -destType file | db {-sourcePath dir | -sourceUsername username -sourcePassword password -sourceDatabase db} {-destPath dir | destUsername username -destPassword password -destDatabase db} [-debug]
where:
sourceType
indicates whether the source store is in a file or database. You may have source and destination stores of the same type. Hence, you can migrate from one database to another or one file system to another.
destType
indicates whether the destination store is in a file or database. You may have source and destination stores of the same type. Hence, you can migrate from one database to another or from one file system to another.
sourcePath
is the location of a file-based preference store. This argument is required when sourceType
is file
.
sourceUsername
is the database user name for a preference store database. This argument is required when sourceType
is db
.
sourcePassword
is the database password for a preference store database. This argument is required when sourceType
is db
.
sourceDatabase
is the name of a preference store database. This argument is required when sourceType
is db
.
destPath
is the location of a file-based preference store. This argument is required when destType
is file
.
destUsername
is the database user name for a preference store database. This argument is required when destType
is db
.
destPassword
is the database password for a preference store database. This argument is required when destType
is db
.
destDatabase
is the name of a preference store database. This argument is required when destType
is db
.
debug
turns on full logging through standard output to allow users to diagnose issues that arise when the tool runs.
Note:
You can also obtain this syntax from the command line by entering the following command:java -classpath ORACLE_HOME/j2ee/OC4J_WebCenter/shared-lib/oracle.wsrp/1.0/ wsrp-container.jar: ORACLE_HOME/javacache/lib/cache.jar: ORACLE_HOME/j2ee/OC4J_WebCenter/webservices/lib/saaj-api.jar: ORACLE_HOME/j2ee/OC4J_WebCenter/webservices/lib/orasaaj.jar: ORACLE_HOME/j2ee/OC4J_WebCenter/jdbc/lib/ojdbc14.jar oracle.portlet.server.containerimpl.PersistenceMigrationTool
Preference Store Specification Example
To discover the type of a WSRP producer's preference store, review its web.xml
file (Example 17-1).
Example 17-1 The persistentStore and fileStoreRoot Variables in the web.xml File
<env-entry>
<env-entry-name>oracle/portal/wsrp/server/persistentStore</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>File</env-entry-value>
</env-entry>
<env-entry>
<env-entry-name>oracle/portal/wsrp/server/fileStoreRoot</env-entry-name>
<env-entry-type>java.lang.String</env-entry/type>
<env-entry-value>portletdata</env-entry-value>
</env-entry>
For more information about the JPS portlet migration utility, refer to Oracle WebCenter Framework Developer's Guide.
To back up your PDK-Java preference store, perform the following steps:
Stop the OC4J instance on which the portlet container runs.
Run the migration tool to back up data from the source preference store to the destination (backup) store. For example:
java -classpath $ORACLE_HOME/portal/jlib/pdkjava.jar oracle.portal.provider.v2.preference.MigrationTool -mode dbtofile -remap locale -countries AR,MX -pref1UseHashing true -pref1User portlet_prefs -pref1Password portlet_prefs -pref1URL jdbc:oracle:thin:@myserver.mydomain.com:1521:mysid -pref2RootDirectory /tmp/portletbkp
Start the OC4J instance on which the portlet container runs.
Migration Tool Syntax
The syntax of the migration utility is:
java -classpath $ORACLE_HOME/portal/jlib/pdkjava.jar oracle.portal.provider.v2.preference.MigrationTool -mode [file | db | filetodb | dbtofile | dbtodb] [-remap language | locale] [-countries iso_country_code] [-pref1UseHashing true | false] {-pref1RootDirectory directory | -pref1User username -pref1Password password -pref1URL url} [-pref1UseHashing true | false] {-pref2RootDirectory directory | -pref2User username -pref2Password password -pref2URL url} [-upfixwpi filename]
where:
-mode
is the mode in which you want to run the Preference Store Migration and Upgrade Utility.
file
or db
indicates that you want to run in upgrade mode.
filetodb
, dbtofile
, or dbtodb
indicates that you want to run in migration mode.
-remap
is the localePersonalizationLevel
(language
or locale
). Note that you only need to use this option if you want to change localePersonalizationLevel
as part of your upgrade or migration.
-countries
specifies a prioritized list of ISO country codes, indicating your order of preference in case of a collision between remapped preferences for different countries. -countries
is only meaningful if you also specified the -remap
option.
-pref1UseHashing
indicates whether or not you want to employ hashing on the source for this operation.
-pref1RootDirectory
is the path of a source file system, for example, j2ee/home/applications/jpdk/jpdk/WEB-INF/providers/sample
.
-pref1User
is the user name for a source database.
-pref1Password
is the password for a source database.
-pref1URL
is the URL to a source database, for example, jdbc:oracle:thin:@myserver.mydomain.com:1521:mysid
.
-pref2UseHashing
indicates whether or not you want to employ hashing on the destination for this operation.
-pref2RootDirectory
is the path of a destination file system, for example, j2ee/home/applications/jpdk/jpdk/WEB-INF/providers/sample
.
-pref2User
is the user name for a destination database.
-pref2Password
is the password for a destination database.
-pref2URL
is the URL to a destination database, for example, jdbc:oracle:thin:@myserver.mydomain.com:1521:mysid
.
-upfixwpi
indicates a log file for the operation.
Note:
You can also obtain this syntax from the command line by entering the following command:java -classpath C:\JDEV_HOME\adfp\lib\pdkjava.jar; C:\jdev_10132_wcs_4007\adfp\lib\ptlshare.jar oracle.portal.provider.v2.preference.MigrationTool
Preference Store Specification Example
To discover the type of a PDK-Java producer's preference store, review its provider.xml
file (Example 17-2).
Example 17-2
<provider class="oracle.portal.provider.v2.DefaultProviderDefinition">
<localePersonalizationLevel>none</localePersonalizationLevel>
<session>true</session>
<defaultLocale>en</defaultLocale>
<preferenceStore
class="oracle.portal.provider.v2.preference.FilePreferenceStore">
<name>prefStore1</name>
</preferenceStore>
<portlet
class="oracle.portal.sample.v2.devguide.prefstore.GuestBookPortletDefinition">
<id>1</id>
<name>GuestBook</name>
<title>Guest Book Portlet</title>
<shortTitle>Guest Book</shortTitle>
<description>Demonstration of using a Preference Store to drive
portlet content</description>
<timeout>100</timeout>
<timeoutMessage>Guest Book Portlet timed out</timeoutMessage>
<renderer class="oracle.portal.provider.v2.render.RenderManager">
<showPage>/htdocs/prefstore/guest_book.jsp</showPage>
<editPage>/htdocs/prefstore/store_comment.jsp</editPage>
</renderer>
</portlet>
</provider>
For more information on the PDK-Java migration and upgrade utility, refer to Oracle WebCenter Framework Developer's Guide.
OracleAS Recovery Manager provides an automated procedure to take a full backup of the instances on one host and restore them to a new host after losing the original operating environment.
Loss of Host Automation (LOHA) automates the tasks necessary for the Oracle Application Server administrator to migrate Oracle Application Server instances from one host to another. The new host can be a different host running the same operating system or the same host after system re-imaging. LOHA provides a solution for a loss of host when you want to restore the original instances to a new environment without having to reinstall the instances and preserve the application data.
LOHA supports all middle-tier installations, and the new host's name can be the same or different from the original host. For different host names, some manual work is required.
LOHA can move all the Oracle Application Server instances from one host to a new host if the new host does not have any other Oracle Application Server instances already running. You can restore a subset of the instances to the new host if the subset does not have any dependencies on the instances remaining on the old host. You cannot restore instances from multiple hosts to a single host.
LOHA can also be used to recover a corrupted instance on a host without affecting other instances on the same host.
This section contains the following topics:
The Loss of Host Automation service is installed as part of OracleAS Recovery Manager. It is installed into the following directory:
On UNIX:
ORACLE_HOME/backup_restore/loha
On Windows:
ORACLE_HOME\backup_restore\loha
To use the Loss of Host Automation service, you must configure OracleAS Recovery Manager as described in Chapter 16, "Oracle Application Server Recovery Manager".
The Loss of Host service has the following prerequisites:
The new host must have the same version of operating system and the same level of patches as required by Oracle Application Server.
In the config.inp
file, the orainst_loc_path
field must be changed only if the instance is installed with the -invPtrLoc
installer command line option. It must be changed to reflect the nonstandard location of oraInst.loc
.
For Windows platforms, Windows Support Files (WSF) must be installed. You can obtain WSF from the Oracle Application Server installation CDROM. For instructions on installing Windows system files, see Oracle Application Server Installation Guide.
For Windows platforms, the Microsoft service utility sc.exe
must be installed on both the original host and the new host. According to Microsoft, it is part of the NT ResourceKit. For Windows XP, the utility is part of the installation. For Windows 2000 platforms, it must be installed. Ensure that it is in the execution path.
For UNIX platforms, ensure that the ORACLE_HOME environment variable does not have a trailing forward slash (/).
On the new host, jar
(Windows) or tar
(Unix) must be available to unpack the node archive. If your system has its own tar program, use it instead of GNU tar.
The user must have administrative privileges on the system such that system or root-level tasks can be performed.
There should not be any other Oracle products installed on the new host. For example, if there are some Oracle Application Server instances on this new host, they must be shutdown and uninstalled cleanly.
The user/group ID on the new host must match that on the original host.
Check port usage on the new host. Make sure there are no processes using the same ports as any of the Oracle Application Server instances you are restoring. If any processes are using the same ports, reconfigure the processes to use different ports before restoring any Oracle Application Server instance.
After completing the restore, the same mount point and full path as the original middle-tier Oracle home are preserved. Ensure that the Oracle home parent directory is on a file system with enough space to hold the middle-tier installation, and that the directory is owned by the same user and group as on the original host.
The following tasks must be performed, for each instance on the original host, to enable the Loss of Host Automation service:
Configuration Backup of the Node
You should back up the node after installation or after an upgrade. Run the following command to create a backup of the node configuration:
On UNIX:
bkp_restore.sh -m configure
On Windows:
bkp_restore.bat -m configure
Node Backup Preparation
During node backup preparation, the Loss of Host Automation service determines the following information about the current host:
Operating system
Host name
IP address
User/group ID
Install type
Central inventory location
Oracle home locations
Windows registry and all Windows services created for all Oracle homes
The service also creates an instance backup with this operation.
Run the following command to prepare a node for backup:
On UNIX:
bkp_restore.sh -m node_backup -o prepare
On Windows:
bkp_restore.bat -m node_backup -o prepare
Creating an Image Backup of the Original Host
This task creates an archive of an instance that includes the original Oracle home, oratab, central inventory, Windows registries and so forth. On UNIX, the command must be run from root
. Run the following command to create an image backup of the original instance:
On UNIX:
bkp_restore.sh -m node_backup -o image_backup -P archive path
On Windows:
bkp_restore.bat -m node_backup -o image_backup -P archive path
After the command completes, the backup is placed in the directory specified in archive path
.
The commands in this section restore a node on a new host after a loss of host. Before performing the following steps, ensure that all the prerequisites in Section 17.3.1, "Preparing to Use Loss of Host Automation" are fulfilled.
The following commands must be run in order.
Unpack the backup archive of the old node:
On UNIX, login as root:
cd /
tar -xvpf archive_name
On Windows:
jar -xvf archive_name
The following command restores Oracle Universal Installer related metadata such as oratab (UNIX), Windows registries, and central inventory on the new host. If multiple instances are to be restored, this operation should be performed only for the first instance. The command must be run as root
on UNIX.
On UNIX:
bkp_restore.sh -m node_restore -o sys_init
On Windows:
bkp_restore.bat -m node_restore -o sys_init
The following command registers the instance with oratab and the central inventory; it also sets up daemon start/stop script by running root.sh
on UNIX, or, on Windows, it creates Windows services. The command must be run as root
on UNIX.
On UNIX:
bkp_restore.sh -m node_restore -o inst_register
On Windows:
bkp_restore.bat -m node_restore -o inst_register
This command reconfigures the instance on the new host. This includes IP changing, config backup restore and so forth, depending on the install type. Prior to running the command, run opmnctl shutdown
to ensure that opmn and Enterprise Manager processes are not using ports required by the reconfigure process. For Infrastructure and metadata repository installations on Windows, the flashback_recovery_area must be manually created before running the command. The command must be run as the owner of the instance. The path to the instance backups must be valid.
On UNIX:
bkp_restore.sh -m node_restore -o inst_reconfigure -t config_bkp_timestamp
On Windows:
bkp_restore.bat -m node_restore -o inst_reconfigure -t config_bkp_timestamp
Without a timestamp argument, this command shows all the available instance backups. For a successful completion of this operation, ensure that all the other required services are started if they do not belong to this instance.
LOHA will not detect port conflicts on the new host. It is recommended that you do not run other applications using the same TCP ports that are to be used by the restored instance. Any port conflict will cause this operation to fail.
If an Oracle_Home/backup_restore/config/config_misc_files.inp_<time_stamp>
file exists and is more recent than the existing config_misc_files.inp
file, overwrite the config_misc_files.inp
file with the most recent config_misc_files.inp_<time_stamp>
file.
For each component plug-in file in the Oracle_Home/backup_restore/plugin_config
directory, check to see if there is a timestamped version that is more recent than the config_component_name_plugin.inp
file. If there is a more recent version, overwrite the config_component_name_plugin.inp
file with the most recent timestamped version.
When an instance of Oracle Application Server requires an image restore to correct a problem, you can use LOHA to recover the instance. Perform the following steps to recover the instance:
Completely shutdown the instance.
Perform step 1 of Section 17.3.3, "Restoring a Node on a New Host" to unpack the latest image backup of the instance.
Perform steps 3, 4 and 5 of Section 17.3.3, "Restoring a Node on a New Host" to register and configure the instance.
If the instance has any dependencies on other instances of Oracle Application Server, the other instances must be up and running.