| Oracle® Beehive Administrator's Guide Release 2 (2.0.1.8) Part Number E16648-07 |
|
|
PDF · Mobi · ePub |
| Oracle® Beehive Administrator's Guide Release 2 (2.0.1.8) Part Number E16648-07 |
|
|
PDF · Mobi · ePub |
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 closed (cold) backup. See "Performing an Offline (Cold) Backup of Oracle Beehive"
During minimum system usage times, on a regular schedule, perform online (hot) database backups. Oracle recommends daily incremental backups, and weekly full backups, of a production Oracle Beehive database. See "Performing an Online (Hot) 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:
Offline (cold) backup
An offline 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 an Offline (Cold) Backup of Oracle Beehive for example closed backup procedures.
Online (hot) backup - An online 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 online backup, the database must be in ARCHIVELOG mode.
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.
Oracle recommends taking a full offline (cold) backup of all Application tiers before going into production. From that point onwards, you should take a full closed backup taken after every Oracle Beehive patch is applied to the system. Additionally, a full offline backup is recommended every time a change impacting connectivity to configuration data, such as a change to the database connect string, schema passwords, and so forth is implemented, as this has the potential to hamper usability of older backups. Apart from that, whenever you have a scheduled outage window, take the opportunity to perform a full offline backup of all Application tiers.
Use an archival tool of your choice such as tar, cpio, or zip to take the backup of the entire Application tier ORACLE_HOME, and the oraInventory.
The following is a simple example demonstrating an offline backup of the 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 SQL*Plus
Back up 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 closed (cold) backup.An online (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 an online backup, the database must be in ARCHIVELOG mode. Oracle Beehive requires the database to be in ARCHIVELOG mode, so online backup is a viable option.
You can use RMAN or custom scripts to schedule regular online 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 an online 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 an online 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 flashing back the database (if flashback database is enabled). The advantage of using RMAN or flashback database is that you can restore the database to a specific point in time.
See Also:
For detailed information and examples, see Chapter 16, "Performing Flashback and Database Point-in-Time Recovery," in the Oracle Database Backup and Recovery User's Guide.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 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, such as from patches.
The following procedure is an example of how to restore a database which you have backed up using the tablespace-by-tablespace online (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 online 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;
Beginning in Oracle Beehive 2.0, you can use beectl to export e-mail for a specified user to an external archive file. This utility serves two main purposes:
Simplifying the process of transporting an account from one Oracle Beehive deployment to another
Periodic backup of selected user account data for emergency recovery purposes
You can selectively and periodically export certain users' e-mail accounts and store the exported files on the file system. Each export serves as a single-user backup. The export file captures the snapshot of the entire e-mail account, including the folder hierarchy, folder names, message received date, message flags and read status, as well as message payload in its original MIME form. All e-mail messages in all "regular" folders will be exported. A "regular" folder is a folder subscribable from an IMAP client. E-mail messages in the workspace Trash are not exported.
The file is stored in a proprietary format. It is not encrypted.
Because of the highly individualized approach, e-mail export is not suitable for entire system backup for any sizable user population. The mechanism is not incremental and not parallelized. Use the system-wide backup strategies described earlier in this chapter for such purposes.
When importing e-mail data, you should specify an empty folder in the specified user's personal workspace. Subfolders will be created corresponding to the subfolders that were archived.
If exported e-mails already exist in the target folder, they will be duplicated. If a subfolder with the same name already exists in the target folder, the import will fail.
To export e-mail, use the beectl export_email_data command:
beectl> export_email_data --user_name <user name> --file <file name>
Specify the user_name using the user's Primary Principal.
Specify the file name in either relative path (to the current working directory where beectl is invoked), or absolute path, to save the export file.
To import e-mail, use the beectl import_email_data command:
beectl> import_email_data --user_name <user name> --folder <folder name> --file <file name>
Specify the user_name using the user's Primary Principal.
Specify the file name in either relative path (to the current working directory where beectl is invoked), or absolute path, from which to read the export file.
Specify the relative folder path under which the file content should be imported. The folder path should begin at the workspace level and use "/" as delimiter.
The following examples show appropriate syntax:
beectl> export_email_data --user_name john.doe@example.com --file /backup/10-JAN-2009/john_doe.bkp beectl> import_email_data --user_name john.doe@example.com --folder INBOX/Restore_10_Jan_2009 --file /backup/10-JAN-2009/john_doe.bkp
|
 Copyright © 2008, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|