Oracle® Beehive Administrator's Guide Release 1 (1.4) Part Number E13797-02 |
|
|
View PDF |
This module gives recommendations for backup and recovery strategies for your Oracle Beehive deployment. It includes the following sections:
An Oracle Beehive deployment can comprise of two or three tiers, depending on the deployment topology selected, and may include a Web tier running the application listener services, an Application tier running the application business logic, and a Database tier containing the Oracle Beehive data repository (including business data, application seed data and configuration data). Your backup and restore strategy should include each tier individually, while also insuring that after a recovery there are no synchronization issues between the various tiers.
This module provides recommendations. However, every Oracle Beehive deployment is unique, and your organization's requirements for availability, backup storage strategy, and recovery scenarios are also unique. You should use the recommendations in this module as a baseline for forming a comprehensive backup strategy that best suits your organization's needs. You should also consider writing a set of recovery procedures specific to your hardware and deployment, to ensure rapid and accurate restoration whenever a problem occurs.
See Also:
For more information about backing up and recovering Oracle Databases, see:Chapter 15, "Backup and Recovery", in Oracle Database 10g Concepts
Oracle Database 10g Backup and Recovery Advanced User's Guide
This section contains the following topic:
Your backup and recovery strategy should be prepared to handle hardware and software failures, as well as human errors. Human errors include accidental deletion of critical code or configuration files, dropping a table or tablespace, accidentally purging unarchived data, and so forth. If these errors occur while the system is in production use by live users, then damage control should be performed quickly by taking appropriate restore measures.
Sometimes incorrect configuration can trigger corruption of data to such an extent that the system can become unusable. Under such circumstances it becomes imperative to restore the system from a backup of the system taken before the symptoms of logical corruption began to manifest.
Because most of the Oracle Beehive data (business, seed and configuration) resides in the database and there is very little information which is persisted in the Applications tier file system, the frequency of database backups (both full and incremental) should be significantly higher than the Applications tier backups.
You should consider performing a backup under any of the following circumstances:
Create a Baseline backup:
Immediately after installation of Oracle Beehive
Immediately before installing any software patch or upgrade, to provide rollback capability should the upgrade cause a problem
Immediately after installing any software patch or upgrade, to create a snapshot prior to any post-installation configuration
Whenever you have already scheduled system downtime, you should use the opportunity to perform a full cold backup. See "Performing a Cold Backup of Oracle Beehive"
During minimum system usage times, on a regular schedule, perform hot database backups. Oracle recommends daily incremental backups, and weekly full backups, of a production Oracle Beehive database. See "Performing aHot Backup of Oracle Beehive Database"
This section describes some options for backing up your Oracle Beehive deployment. It contains the following topics:
During software product installations, you can perform a backup of the entire environment as a snapshot. The purpose of taking such a snapshot is to successfully recover to a "known good" baseline, if irrecoverable errors are made during the post-installation phase. This is sometimes referred to as a baseline install backup.
For example, after you complete the basic installation of Oracle Beehive, but before getting started with more advanced configurations such as setting up end-to-end SSL encryption/decryption or integrating with a third party LDAP user directory, you should consider making a baseline backup.
Oracle recommends taking complete backups after every major milestone of the installation. The Application tier and database backups need to be synchronized. You can also make use of a backup naming convention, so that the name includes both the timestamp and a brief description of the milestone.
A baseline backup of Oracle Beehive includes:
Creating a Baseline Backup of the Database Tier
Note:
If you have configured Transport Layer Security (TLS) with Oracle Wallet, as described in the Oracle Beehive install guide for your platform, you should also back up the files in the following location:<Oracle home>/Apache/Apache/conf/ssl.wlt/default
For more information, see "Configuring TLS with Oracle Wallet" in the Oracle Beehive Installation Guide for your platform.
Shutdown all Oracle Beehive Application tier processes and then backup the ORACLE_HOME and oraInventory for the Application tier installation using the archiving tool of your choice; tar, cpio, WinZip, or any other archiving tool. Backing up the oraInventory is important as it contains crucial information about the Application tier installation. To reduce the backup overhead you can exclude some of the following beehive log file directories from this backup:
$ORACLE_HOME/beehive/logs
$ORACLE_HOME/opmn/logs
$ORACLE_HOME/Apache/Apache/logs
$ORACLE_HOME/j2ee/home/log
$ORACLE_HOME/j2ee/oc4j_soa/log
$ORACLE_HOME/j2ee/OCSCORE/log
$ORACLE_HOME/j2ee/OCSMGMT/log
$ORACLE_HOME/j2ee/OCSAPP/log
On Windows systems, the above files are typically located in C:\Program Files\
. The remainder of the directory structure is identical. In addition, you should back up the following registry entries:
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Control\Session Manager\Environment HKLM\SOFTWARE\ORACLE HKLM\SYSTEM\CurrentControlSet\Services
Caution:
On UNIX and Linux platforms, if certain listener services in the Oracle Beehive installation are running on privileged port numbers (any port in the 0 - 1024) range, then you must perform the backup using super-user privileges. This is because under such circumstances, certain files have the set-uid set by the root user. If the archive is created by a user not having root privileges then during a restore operation, the set-uid will be lost and the file will lack appropriate privileges. This could prevent Oracle Beehive from making use of those privileged ports, until the problem is fixed.Backing up Oracle Beehive database repository is similar to backing up any other Oracle database. Various options are available for backing up Oracle databases. Database backup options include:
Oracle provided database backup tools like RMAN
Oracle database export utility
Third party backup tools
Custom shell or SQL scripts
You can perform two types of database backups:
Cold backup
A cold backup is taken by shutting down the database first, and then backing up all data, log and control files of the database. Because the database has to be shut down first, this is also referred to as offline backup. See Performing a Cold Backup of Oracle Beehive for example cold backup procedures.
Hot backup - A hot backup is preferred when the database needs to be available for read/write and can't be shut down. However, in order to take a hot backup, the database must be in ARCHIVELOG mode. Oracle Beehive requires the database to be in ARCHIVELOG mode., so a hot backup is a viable option.
By default Oracle uses the database control files to store information about backups. Normally it is better to set up an RMAN catalog database to store RMAN metadata in. Read the Oracle Backup and Recovery Guide before implementing any RMAN backups.
It is recommended to take a full cold backup of all mid-tiers before going into production. From that point onwards, a full cold backup should be taken after every Oracle Beehive patch is applied to the system. Also a full cold backup is recommended every time a change impacting connectivity to configuration data like change to database connect string, schema passwords etc. is implemented as this has the potential to hamper usability of older backups. Apart from that, if there are any scheduled outage windows, then a full cold backup of all mid-tiers should be performed too. Use archival tool of your choice like tar, cpio, zip to take the backup of the entire mid-tier ORACLE_HOME and the oraInventory.
Here is a very simple example demonstrating a cold backup of database:
Ensure all Oracle Beehive processes are shut down. You must shut down Oracle Beehive Application tiers before shutting down the Oracle Beehive database
Run the following queries to get a list of all files that need to be backed up:
select name from sys.v_$datafile; select member from sys.v_$logfile; select name from sys.v_$controlfile;
Shut down the Oracle Beehive database from SQLplus
Backup all files to disk or secondary storage (such as magnetic tape). Ensure that you backup all data files, all control files and all log files
When completed, restart the database, and then you may restart Oracle Beehive
Note:
Because the Oracle Beehive database is always in ARCHIVELOG mode, you can use archived log files to roll forward from a cold (offline) backup.A hot backup is preferred when the database needs to be available for read/write operations, and can't be shut down. In order to take a hot backup, the database must be in ARCHIVELOG mode. Oracle Beehive requires the database to be in ARCHIVELOG mode, so hot backup is a viable option.
You can use RMAN or custom scripts to schedule regular hot backups of the database. For live production installations, Oracle recommends that at least one full RMAN backup be scheduled every week in addition to daily incremental backups.
Note:
Do not run online "hot" database backups during peak processing periods. The Oracle database will write complete database blocks, instead of the normal deltas, to redo log files while in backup mode. This can lead to excessive database archiving and even database freezes if the database experiences heavy use while in backup mode.This section contains the following topics:
The following procedure is a simple example demonstrating a hot backup of the Oracle Beehive database:
One at a time, switch each database tablespace that needs to be backed up into backup mode:
ALTER TABLESPACE xyz BEGIN BACKUP;
Note:
It is better to backup tablespaces one at a time, rather than all tablespaces at once, because substantial overhead is incurred for each tablespace in backup mode.You can script the command for all tablespaces, dynamically accounting for changes to the physical structure of the database since the last backup.Copy the tablespace files into your backup directory or offline storage:
! cp xyzFile1 /backupDir/
When the copy is complete, disable the backup mode on the tablespace:
ALTER TABLESPACE xyz END BACKUP;
Repeat the procedure for every tablespace in the database
When you have finished backing up each tablespace, backup the control files:
ALTER SYSTEM SWITCH LOGFILE
This command forces log switch to update control file headers
ALTER DATABASE BACKUP CONTROLFILE TO '/backupDir/control.dbf';
RMAN can facilitate the task of taking, organizing, and managing database backups to a great extent and is preferred over traditional ways of taking database backups. The biggest advantage of RMAN is that it will only backup used space in the database. RMAN does not put tablespaces in backup mode, saving on redo generation overhead. RMAN will re-read database blocks until it gets a consistent image.
The following is an example of how to perform a hot backup of the Oracle Beehive database using RMAN:
rman target sys/*** nocatalog run { allocate channel t1 type disk; backup format '/app/oracle/db_backup/%d_t%t_s%s_p%p' ( database ); release channel t1; }
This section contains advice about recovering Oracle Beehive from backup. It contains the following topics:
A baseline backup of Oracle Beehive is usually a "known-good" backup, providing a restoration option that is sure to re-establish availability, at the possible expense of losing changes made to the system more recently.
A restore operation uses the same tool or utility which was used for taking the full backup. It is performed offline.
For the restore operation, first remove or move the existing ORACLE_HOME and oraInventory of the Oracle Beehive installation, and then restore them from the full backup. You should perform a corresponding database restore concurrently.
Database restore can be done using RMAN, import (if the backup was a logical backup taken using Oracle export utility), or flash recovery. The advantage of using RMAN or flash recovery is that you can restore the database to a specific date/time stamp.
The following is an example of restoring using an RMAN restore script:
rman target sys/*** nocatalog run { allocate channel t1 type disk; # set until time 'Aug 07 2000 :51'; restore tablespace users; recover tablespace users; release channel t1; }
You can recover the Application tier, without making any changes to the Oracle Beehive database.
To restore the Application tier, perform the following procedure:
Use the same tool which you used to take the Application tier backup to restore the ORACLE_HOME and oraInventory from the last known-good backup just before the failure occurred
On the Application tier, use the
command to synchronize the Application tier with the latest information from the Oracle Beehive repository:beectl
modify_local_configuration_files
beectl> modify_local_configuration_files
This command must be run on every Application tier affected by the service outage. The process may take a while to complete.
Note:
The Oracle Beehive data repository is used for storing all configuration data and is the final authority about a deployment configuration. Do not attempt to manually change configuration data on an Application tier.In case of a hardware failure, you can restore the database from RMAN catalog or use flash recovery to go to a point-in-time before the failure occurred. Though there is not much information which is persisted in the Application tier file system, an effective change control mechanism has to be in place to address any such deltas which might arise.
The following procedure is an example of how to restore a database which you have backed up using the tablespace-by-tablespace hot backup method:
Copy all applicable archive log files to the target database destination file system. Also, copy all data, index and redo log files to the target database's file system (all files from the HOT backup)
Alter trace file for new file locations and ensure the CREATE CONTROLFILE
statement specifies:
USING <source_sid> RESETLOGS ARCHIVELOG
Using the original (source) database ORACLE_SID value, startup the target database with the new init.ora (New control file locations, LEAVE DB_NAME=<source_sid>, dump_dest, and so forth)
Recover the database using the following command:
RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;
Run the following command:
ALTER DATABASE OPEN RESETLOGS;