Veritas NetBackup™ for Oracle Administrator's Guide
- Introduction
- NetBackup for Oracle QuickStart
- Installing NetBackup for Oracle
- About linking Oracle RMAN with NetBackup for UNIX
- Oracle policy configuration
- Preparing for NetBackup for Oracle configuration
- Instance management for an Oracle Intelligent Policy
- About Oracle Intelligent Policies (OIP)
- About script- or template-based Oracle policies
- About adding backup selections to an Oracle policy
- About configuring the run-time environment
- About creating templates and shell scripts
- About creating RMAN scripts manually
- Performing backups and restores of Oracle
- About NetBackup for Oracle backups
- About NetBackup for Oracle restores
- Using NetBackup for Oracle in a Microsoft Windows cluster environment
- Guided Recovery
- Troubleshooting Guided Recovery
- NetBackup for Oracle with Snapshot Client
- About NetBackup for Oracle with Snapshot Client
- How NetBackup for Oracle with Snapshot Client works
- About configuring Snapshot Client with NetBackup for Oracle
- Restoring NetBackup for Oracle from a snapshot backup
- About configuring NetBackup for Oracle block-level incremental backups on UNIX
- About Snapshot Client effects
- About Oracle support for Replication Director
- Troubleshooting
- Troubleshooting RMAN backup or restore errors
- Appendix A. Real Application Clusters
- Appendix B. Best practices for protecting Oracle RAC with NetBackup
- Appendix C. Deduplication best practices
- Appendix D. Snapshot Client support of SFRAC
- Appendix E. Script-based block-level incremental (BLI) backups without RMAN on UNIX and Linux systems
- Verifying installation requirements for BLI backups without RMAN
- Creating NetBackup policies for script-based BLI backup
- Creating notify scripts for BLI backups
- Performing backups and restores
- About troubleshooting backup or restore errors
- Appendix F. XML Archiver
- NetBackup for Oracle XML export and XML import
- About XML export templates and shell scripts
- Performing an XML export archive
- Restoring an XML export archive
- Troubleshooting XML export or XML import errors
- Appendix G. Register authorized locations
Example RAC configuration: Failover name is not available and backup is not load balanced
In this configuration, VIP names or host names allow connections to the respective hosts in the cluster. You need a special configuration to ensure that the backup script executes on at least one of the hosts but not on both hosts. Otherwise, a backup may not occur if the specified instance is down, or a redundant backup occurs if both of the specified instances are active.
For ease of discussion, the term primary refers to the instance on which the backup normally occurs. The term secondary refers to the other instance which may be used if the primary is unavailable. In addition, because the backup may occur on either host, the backup images have the potential to be stored under both client names. The image storage name is dependent on which host is active at the time of the backup. The configuration is as follows:
The policy specifies client names for both hosts, either hostname1 and hostname2, or vipname1 and vipname2. The specification of client name ensures that the backup is attempted on a host which is currently operational.
The backup script must be accessible to both hosts in the cluster, the clustered file system makes a good location.
The backup script should be customized so that it starts RMAN on exactly one of the clients. If the script is executed on the primary, then start RMAN and perform the backup. If the script is executed on the secondary and the primary is up, then exit with status 0 so the NetBackup scheduler doesn't retry this client. If the script is executed on the secondary and the primary is down, then start RMAN and perform the backup. You can build the script customization around a tnsping to the primary or even a query of the database. Use this customization to see if the other instance is open and able to perform the backup.
$ select INST_ID, STATUS, STARTUP_TIME, HOST_NAME from gv$instance; INST_ID STATUS STARTUP_T HOST_NAM ---------- ------------ --------- --------- 1 OPEN 13-JAN-09 vipname1 2 OPEN 13-JAN-09 vipname2
Each user-directed backup request must use a client name which allows the NetBackup media server to connect back to the correct host for the data transfer. By default, the backup uses the CLIENT_NAME from the bp.conf file which is distinct for each host. A better solution is to configure RMAN to provide the appropriate client name from the policy as follows:
SEND 'NB_ORA_CLIENT=$NB_ORA_CLIENT';
Configure the NetBackup master server to give the physical host names access to all of the backup images.
cd /usr/openv/netbackup/db/altnames echo "hostname1" >> hostname1 echo "vipname1" >> hostname1 echo "hostname2" >> hostname1 echo "vipname2" >> hostname1 cp hostname1 hostname2
You can use Preferred Network or another means to force NetBackup to use the IP addresses associated with the VIP names for outbound user-directed requests. If you use this method then you must allow the VIP names to access all of the backup images.
cd /usr/openv/netbackup/db/altnames cp hostname1 vipname1 cp hostname1 vipname2
Either client can initiate a restore. RMAN must be configured with 'SET AUTOLOCATE ON;' to request the backup set pieces from the appropriate instance or host that performed the backup. Alternatively, you can restore from either host or instance if you configure each restore request to include the correct client name. This client name is the one that is used at the time the backup set piece was transferred to storage.
SEND 'NB_ORA_CLIENT=client_name_used_by_backup'