VERITAS Education INSTRUCTOR ARTICLES APRIL 2003 1. Selecting an Oracle Backup Solution Part 3: Hot Backups with the NetBackup for Oracle Advanced BLI Agent 2. Using a Volume Snapshot to Recover a Lost Object SELECTING AN ORACLE BACKUP SOLUTION PART 3: HOT BACKUPS WITH THE NETBACKUP FOR ORACLE ADVANCED BLI AGENT The last Oracle newsletter discussed the advantages and configuration of the NetBackup for Oracle agent. This month, we will discuss the NetBackup for Oracle Advanced BLI Agent (NBUO BLI), which also provides for hot database backups written directly to tape, but offers the additional functionality of performing faster incremental backups and reducing the impact of backup processing on the Oracle server. NBUO BLI achieves faster incremental backups by performing block-level incremental backups, which, unlike RMAN directed incremental backups, do not have to examine each block of a data file to determine changes. Block-level incremental backups use the Storage Checkpoint facility of VERITAS File System (available through Database Edition) to track changed data blocks of Oracle database files. A storage checkpoint is a disk- and I/Oefficient snapshot of a file system that provides a consistent view of the file system at the point in time when it is snapped or checkpointed. Instead of making a physically separate copy of the file system, a storage checkpoint tracks only changed blocks; a more efficient method that reduces I/O and CPU overhead on the Oracle server while the snapshot is maintained. During incremental backups, NetBackup uses storage checkpoints to identify all the changed blocks, saving time and reducing CPU overhead during the backup, as well. NBUO BLI uses a feature called Proxy Copy to reduce the impact of backup processing on the Oracle server. Proxy Copy is an extension to the API provided with the NBUO BLI installation that allows the NetBackup Media Manager software to manage the entire backup process of the Oracle data files, not just the actual writing of the data to the backup devices. When a backup using the Proxy Copy feature is initiated, RMAN provides a list of files to be backed up to the NetBackup Media Manager software, which then assumes control of all backup processing. CPU and network overhead are greatly reduced or even eliminated on the Oracle server while the backup is in progress. Currently, Oracle does not support proxy backups of database control files and archived redo logs, so whole database backups consist of proxy backups of data files and RMAN-directed backups of the control file and archived redo logs. The NBUO BLI agent can be configured for use with or without integration with RMAN (this newsletter focuses on using the NBUO BLI agent with RMAN). The agent is available to users of Database Edition for Oracle for Solaris, HP and AIX (AIX is available with 4.5 FP3 or MP3) and can be used with Oracle8i and later. VERITAS Software Requirements: NetBackup VERITAS Database Edition for Oracle NetBackup for Oracle Advanced BLI agent (separately licensed) Oracle 8i or later 1
Advantages: Disadvantages: * Makes the database accessible to users during backups * Makes use of standard RMAN commands * Writes the data directly to tape. * Provides faster incremental backups * Performs tape management using NetBackup Media Manager software * Offers a significant reduction in CPU and network overhead during backups * Configuration requires some understanding of RMAN and NetBackup concepts. * Hot backups require recovery after the restore. Configuration overview: 1. Install the NBUO BLI agent on the client. 2. Link NBUO BLI with Oracle. 3. Prepare NBUO BLI scripts. 4. Configure an Oracle backup policy. STEP 1: INSTALL THE NBUO BLI AGENT. The NBUO BLI software is installed after the NetBackup client software installation. Both installations are performed on the system housing the target database you wish to back up. You can install the NBUO BLI software locally using the installation CD, or install it remotely by first installing the software on the NetBackup Master server and then pushing the software to the Oracle client. The remote installation is useful when you have multiple Oracle clients to install, but it requires a trusting client. STEP 2: LINK NETBACKUP FOR ORACLE API WITH ORACLE. The install of the NBUO BLI software copies a media management API library to the Oracle client. This API must be linked with RMAN in order to write to sequential devices such as a robotic tape drive. You can perform the linking process manually or run a script called oracle_link that is also copied to the client during the install. The linking process differs for hardware platforms and Oracle Server release levels, so even if you have performed previous installs of the NBUO agent, you should check the detailed instructions provided in the VERITAS NetBackup 4.5 for Oracle Advanced BLI Agent System Administrator s Guide. You can also search the knowledge base in the VERITAS Support Web site at http://support.veritas.com for Technote 233482 to review the latest information about the linking process. STEP 3: PREPARE THE NBUO BLI SCRIPTS. NBUO BLI templates or scripts contain RMAN commands invoked during NBUO BLI backup and restore jobs. Sample scripts are provided during the install and may be modified to meet individual requirements. Modifying the scripts requires little knowledge of RMAN and usually takes only a few minutes, even for a new NBUO BLI user. NBUO BLI provides sample scripts for both backups and restores. You can also use the NetBackup for Oracle Wizard to initiate backups or restores. The wizard prompts for required information to create backup or restore templates and initiates the backup or restore job immediately, if desired. The templates are useful for restores and unscheduled backups, but can also be used to create an NBUO BLI script using a utility called bpdbsbora. This is the same wizard discussed in the NBUO newsletter last 2
month. There are additional prompts you select and configure when performing proxy/bli backups. NBUO BLI scripts are required for scheduled backups. The full path and name of the script replaces the file list in an Oracle policy. STEP 4: CONFIGURE AN ORACLE BACKUP POLICY. The next section describes differences between an Oracle policy and a standard backup policy. Configuration of an Oracle policy for NBUO BLI is very similar to configuration of a policy for NBUO (discussed last month). Attributes: Policy type: Select Oracle from the policy type list. Storage unit: Select the storage unit for the backup here (or in the schedule). Volume pool: Select the volume pool for the Oracle backups here (or in the schedule). Keyword phrase: This is not allowed with an Oracle policy (it is ignored). Block level incremental: Select this option. Schedules: Oracle policies require two types of schedules: application backup schedules and automatic backup schedules. As previously noted, Oracle does not currently support proxy backups for control files or archived redo logs. Therefore, to perform a whole database proxy backup you must configure an automatic backup schedule to perform proxy BLI backups of the data files and an application backup schedule to back up the control file and the archived redo logs. Application backup schedule An application backup schedule named Default-Application-Backup is automatically created when you select Oracle as the policy type in the Attributes section. It is important not to delete the schedule, because it is required for non-proxy backups. This schedule behaves in a similar way to a user backup schedule and initiates the request for the RMAN backups of the control file and archived redo logs. This schedule needs to be modified. Schedule window: The start window must encompass all of the periods during which RMAN is able to start non-proxy backup jobs. Typically, start windows are configured to be open 24 hours per day, seven days per week. This ensures your NBUO BLI operations are never locked out due to a closed window. Retention period: The retention period in this schedule type determines how long the non-proxy backups that are performed remain in the NetBackup catalogs. When a backup image expires based on the retention period set here, it is deleted only from the NetBackup catalogs; references to the backup are not deleted from the RMAN repository. You must use RMAN commands to delete references to the expired backups when you allow NetBackup to manage expiration of backups in this manner. You may prefer to manage the expiration and deletion of backup images through RMAN. When a request is issued to delete a backup file from an RMAN repository, RMAN sends a request to NBUO to delete the corresponding image from the NetBackup catalogs. To manage backup images using RMAN repository commands, set the retention period in the application backup schedule to infinity to prevent the expiration of backup images from the NetBackup catalogs until commands are initiated through RMAN utilities. Storage units and volume pools: These can be set in this schedule type and they override settings in the Attributes component of the policy. 3
Frequency or calendar schedule settings: Neither frequency nor calendar dates can be set for this schedule type. Frequency is always configured in the automatic backup schedule, discussed in the following section. Automatic backup schedule Automatic backup schedules are used to specify automatic proxy BLI backups initiated by the NetBackup scheduler. Storage units: Are not set in this schedule type; storage units are set in the application backup schedule Volume pools: Are also not set in this schedule type Frequency or calendar schedule settings: Are set in this schedule type Retention period: The retention period for an automatic backup schedule determines how long NetBackup keeps records of when scheduled backups have occurred. The NetBackup scheduler process requires these records to determine the start time for the next automatic backup. It is important to ensure that the retention period in this schedule type is greater than the frequency setting (also set in this schedule type). If the retention period is less than the frequency setting, backup scheduling can be unpredictable. Type of Backup: The type of backup is set in this schedule type. Three types are allowed for NBUO BLI. Automatic full backup Automatic differential backup Automatic cumulative backup The schedule type is passed to the script to ensure the correct backup type is invoked. Multiplexing: Multiplexing settings are configured in this schedule type. Note: Multiplexing must also be configured for the selected storage unit. File List: The file list has a different meaning than the file list in other policies. Normally, in a standard policy, you list files and directories to be backed up. However, because you are now configuring an Oracle policy, you list templates (created using the Oracle wizards) or scripts. If you are using a script, specify the full pathname of the Oracle script on the clients to be backed up. For example: /oracle/scripts/cold_database_backup.sh If you are using a template, you need only specify the name of the template. For example: weekly_full_backup.tpl Client List: The client list should contain only the Oracle clients to be backed up at the same time using the specified script or template in the file list. You can test the finished policy configuration by performing a manual backup through the backup policy interface. Database users can also initiate backups on the client system, either by initiating a manual backup using jnbsa (provided on the client during the NBUO BLI installation) or by performing a user-directed backup from the command line or from the Oracle wizard. 4
Sample restore scripts are provided to simplify the restore and recovery process. Edit them as you would a sample backup script and invoke them by running them from the command line. You may prefer to use the Oracle Restore Wizard as an alternative. For more information on Oracle backup and restores using the NBUO BLI agent, see the NetBackup 4.5 for Oracle Advanced BLI Agent System Administration Guide. -- Lisa Childress, Senior Instructor, VERITAS Education USING A VOLUME SNAPSHOT TO RECOVER A LOST OBJECT Released with Database Edition 3.5, VERITAS Database FlashSnap is a separately licensed set of utilities specifically designed to create recoverable, point-in-time snapshot images of a database. The Oracle administrator can then use these copies as backups, or as a duplicate database for decision support analysis and reporting or application testing and training. One important advantage of these point-in-time copies is that they provide the Oracle administrator with the ability to create an exact clone of a database instance and then use that clone to recover from logical errors, such as the inadvertent loss of a table or other database object, committed by database users or applications. The alternative requires a full restoration from tape or other backup. The steps to create a point-in-time clone of an Oracle database are as follows: 1. Log in to the host as the Oracle administrator. 2. Create and validate the snapshot plan. 3. Create a volume snapshot of the database. 4. Create the clone database and recover the lost object. 5. Destroy the clone database. CREATING AND VALIDATING A SNAPSHOT PLAN Database FlashSnap requires database and storage information, such as primary and secondary host name, ORACLE_SID, ORACLE_HOME, or primary and secondary disk group, to successfully create a snapshot image of a database, tablespace, or tables. The snapshot plan specifies snapshot scenarios, such as online or offline, and database, tablespace, or tables. You can create and validate the snapshot plan using the dbed_vmchecksnap command. The snapshot plan also serves as a blueprint for the clone database. When you first run dbed_vmchecksnap with the -o setdefaults option, the command creates a snapshot plan template with a number of default variables and values. You can edit the snapshot plan file manually using a text editor to set the variables for different snapshot scenarios. $ dbed_vmchecksnap -S ORCL -H /oracle -f ORCLplan \ -o setdefaults -t train01 Once a snapshot plan is created, you must validate the information in the plan. The dbed_vmchecksnap command with the o validate option validates the snapshot plan. It verifies that the snapshot plexes and their associated data change object (DCO) logs are on different disks from the original plexes and are configured correctly, and it checks the mode of the snapshot, the archive log mode, and the archive log destinations. $ dbed_vmchecksnap -S ORCL -H /oracle -f ORCLplan -o validate 5
The dbed_vmchecksnap command must be executed by the database administrator (DBA). CREATING A VOLUME SNAPSHOT OF THE DATABASE After the snapshot plan is created and validated, you are ready to create a volume snapshot. Begin by ensuring that the storage is properly configured for Database FlashSnap. Then use the dbed_vmsnap command to create the snapshot. $ dbed_vmsnap -S ORCL -f ORCLplan \ -o snapshot dbed_vmsnap started at 2002-11-04 16:19:24 The dbed_vmsnap command must be executed by the database administrator. The snapshot image created by dbed_vmsnap is a frozen image of an Oracle database's datafiles. You can choose whether or not to include archive log volumes in the snapshot. The command dbed_vmsnap ensures that a backup control file is created (in the VxDBA repository) along with the snapshot, which allows for complete data recovery, if needed. The dbed_vmsnap command places the tablespaces in backup mode when it creates the snapshot. CREATING THE CLONE DATABASE After the snapshot image is created, it represents the consistent backup copy of the database. The same snapshots can be used for database backup and recovery or to create a duplicate database on the same host or on a different host. To create a clone from one of these snapshot images, use the dbed_vmclonedb command. $ dbed_vmclonedb -S ORCL -g SNAP_oradg \ -o recoverdb,new_sid=clone -r /snapdb As with all Database FlashSnap commands, the dbed_vmclonedb command must be executed by the database administrator. The dbed_vmclonedb command creates a clone database from the snapshot image of a database created by the dbed_vmsnap command. This clone can be created either on the same host or on another host. When the clone is created on another host, the dbed_vmclonedb command uses the VxDBA repository to import the snapshot disk group, mount the file system (mount points to be precreated) on the snapshot volumes, and start a clone database after completing necessary recovery procedures, if required. When used on the primary host, the dbed_vmclonedb command creates a clone database on it; the option -r relocate_path is required so that the clone database's file systems use different mount points from those used by the primary database. The -o recoverdb option is used in case the user requires that the clone database be recovered automatically, using all available archive logs; a manual point-in-time recovery can be performed if the -o recoverdb option is not used with dbed_vmclonedb command. The dbed_vmclonedb command runs without interaction from the user. After the clone is online and mounted, you can export the lost object from the clone and then import it into the production database with no interruption of availability. At this point, the database administrator has a number of choices for the disposition of the database clone. The database may be used for a variety of tasks, including decision support and analysis, testing, or training. Alternatively, the DBA may choose to use the clone to perform off-host processing. The database administrator 6
may then use Database FlashSnap tools to resynchronize the clone with the primary database. The database administrator also has the option to destroy the clone. DESTROYING THE CLONE DATABASE To destroy the online copy of the database, simply shut down the clone and unmount the file system. This can be performed in one step using the dbed_vmclonedb command with the o umount option. $ dbed_vmclonedb -o umount,new_sid= CLONE VERITAS Database FlashSnap provides a powerful and flexible storage management solution for database administrators. By creating point-in-time copies of the database, Database FlashSnap allows administrators to perform resource-intensive processes such as backups, decision support, and reporting without disrupting the performance of production systems. In addition, these point-in-time copies can also serve as on-disk backup images for protecting and recovering mission-critical data. To learn more about VERITAS Database FlashSnap, and all the VERITAS Database Editions features, attend the VERITAS Database Edition 3.5 for Oracle for Solaris course now available from VERITAS Education. -- Jane Richter, Technical Course Developer, VERITAS Education 7