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 load balanced, one policy with custom script
A load-balanced backup without a failover name must overcome the combined challenges of the preceding configurations. Because a failover name does not exist, the NetBackup scheduler must attempt to execute the backup script on both hosts. In this case, the script must start RMAN on only one of the hosts. Because RMAN may allocate channels on both instances, the user-directed requests must present host specific names. The requirement is that the connect-back from the NetBackup media server must be able to retrieve the data from the correct host.
The policy should specify both client names, either hostname1 and hostname2 or vipname1 and vipname2. The specification of client names is to ensure that the backup script is executed on at least one 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 backup script is executed on the primary, then start RMAN and perform the backup. If the backup script is executed on the secondary and the primary is up, then exit with status 0 so that the NetBackup scheduler doesn't retry this client. If the backup script is executed on the secondary and the primary is down, then start RMAN and perform the backup. The script customization can be built 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
The backup script must not be configured to send a single value for NB_ORA_CLIENT. This configuration is because the NetBackup media server needs to connect back to the correct host depending on which host originated the user-directed backup request.
Configure the backup to provide a host-specific client name with each backup request using one of the following three options:
Configure RMAN to bind specific channels to specific instances and provide the associated client names on each channel for backup image storage. Also, configure RMAN for connect-back to the requesting host for the data transfer.
ALLOCATE CHANNEL 1 ... PARMS='ENV=(NB_ORA_CLIENT=vipname1)' CONNECT='sys/passwd@vipname1'; ALLOCATE CHANNEL 2 ... PARMS='ENV=(NB_ORA_CLIENT=vipname2)' CONNECT='sys/passwd@vipname2'; ALLOCATE CHANNEL 3 ... PARMS='ENV=(NB_ORA_CLIENT=vipname1)' CONNECT='sys/passwd@vipname1'; ALLOCATE CHANNEL 4 ... PARMS='ENV=(NB_ORA_CLIENT=vipname2)' CONNECT='sys/passwd@vipname2';
Note:
If one or more of these nodes are down, these allocation operations fail which causes the backup to fail.
Alternatively, configure Oracle to bind specific channels to specific hosts.
CONFIGURE CHANNEL 1 DEVICE TYPE 'SBT_TAPE' CONNECT 'sys/passwd@vipname1' PARMS "ENV=(NB_ORA_CLIENT=vipname1)"; CONFIGURE CHANNEL 2 DEVICE TYPE 'SBT_TAPE' CONNECT 'sys/passwd@vipname2' PARMS "ENV=(NB_ORA_CLIENT=vipname2)"; CONFIGURE CHANNEL 3 DEVICE TYPE 'SBT_TAPE' CONNECT 'sys/passwd@vipname1' PARMS "ENV=(NB_ORA_CLIENT=vipname1)"; CONFIGURE CHANNEL 4 DEVICE TYPE 'SBT_TAPE' CONNECT 'sys/passwd@vipname2' PARMS "ENV=(NB_ORA_CLIENT=vipname2)";
Alternatively by default, the backup uses the client names which should be distinct for each host and is typically the physical host name.
Configure the NetBackup master server to allow the physical host names access to all of the backup images.
cd /usr/opnv/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
The net result is that the backup script runs on all of the currently active hosts but only starts RMAN on one host. RMAN allocates channels across the hosts for load balancing. The user-directed backup requests include a NB_ORA_CLIENT or CLIENT_NAME specific to the requesting host and which matches the policy. The connect-back for data transfer and the backup image are stored under that name.
Either client can initiate a restore. RMAN must be configured with 'SET AUTOLOCATE ON;' to request the backup pieces from the appropriate instance-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 name is the client name used at the time the backup piece was transferred to storage.
SEND 'NB_ORA_CLIENT=client_name_used_by_backup';