RMAN 10g

RMAN RMAN becomes more powerful with a redesigned incremental backup scheme, offline recovery of incremental backups, previewing restore, recovering through reset logs, file compression, and much more Most people would agree that RMAN is the de facto tool of choice for Oracle database backup. But as powerful as they were, early versions of RMAN left something to be desired. Like many DBAs, I had pet peeves about the absence of what I consider to be must-have features. Fortunately, Oracle Database 10g addresses many of these issues by incorporating many desirable features, making RMAN an even more powerful and useful tool. Let's take a look. Incremental Backups Revisited RMAN includes an option for incremental backups. But truthfully, how often do you use it? Probably occasionally, or possibly even never. This option instructs the tool to back up blocks that have changed since the last incremental backup at the same level or below. For instance, a full backup (level_0) is taken on day 1 and two incrementals of level_1 are taken on days 2 and 3. The latter two merely back up the changed blocks between days 1 and 2 and days 2 and 3, not across the entire backup time. This strategy reduces backup size, requiring less space, and narrows the backup window, reducing the amount of data moving across the network. The most important reason for doing incremental backups is associated with data warehouse environments, where many operations are done in NOLOGGING mode and data changes do not go to the archived log fileshence, no media recovery is possible. Considering the massive size of data warehouses today, and the fact that most of the data in them does not change, full backups are neither desirable nor practical. Rather, doing incremental backups in RMAN is an ideal alternative. So why do many DBAs do incremental backups only rarely? One reason is that in Oracle9i and below, RMAN scans all the data blocks to identify candidates for backup. This process puts so much stress on the system that doing incrementals becomes impractical. Oracle Database 10g RMAN implements incremental backups in a manner that disposes of that objection. It uses a file, analogous to journals in filesystems, to track the blocks that have changed since the last backup. RMAN reads this file to determine which blocks are to be backed up. You can enable this tracking mechanism by issuing the following command: SQL> alter database enable block change tracking using file '/rman_bkups/change.log'; This command creates a binary file called /rman_bkups/change.log for tracking purposes. Conversely, you can disable tracking with SQL> alter database disable block change tracking; To see whether change tracking is currently enabled, you can query:

SQL> select filename, status from v$block_change_tracking;

Flash Recovery Area

Flashback queries, introduced in Oracle9i, depend on undo tablespace to flash-back to a prior version, thereby limiting its ability go too far into the past. Flash recovery provided an alternative solution by creating flashback logs, which are similar to redo logs, to revert the database to a prior state. In summary, you create a flash recovery area for the database, specify its size, and place the database in flash recovery mode with the following SQL commands: alter system set db_recovery_file_dest = '/ora_flash_area'; alter system set db_recovery_file_dest_size = 2g; alter system set db_flashback_retention_target = 1440; alter database flashback on; The database must be in archive log mode to be flashback-enabled. That process creates Oracle Managed Files in the directory /ora_flash_area, with a total size of up to 2GB. The database changes are written to these files and can be used to quickly recover the database to a point in the past. By default, RMAN also uses /ora_flash_area to store backup files; thus, RMAN backups are stored on disk, not tape. For that reason, you have the ability to specify how many days you need to keep backups. After that period, the files are automatically deleted if more space is required. The flash recovery area needn't be a filesystem or a directory, howeveralternatively, it could be an Automatic Storage Management (ASM) diskgroup. In that case, the flash recovery area is specified by: alter system set db_recovery_file_dest = '+dskgrp1'; Consequently, using ASM and RMAN in combination, you can build a highly scaleable, faulttolerant storage system using cheap disks such as Serial ATA or SCSI drives, with no additional software required. (For more details about ASM, see the Week 8 installment in this series.) This approach not only makes the backup process much faster but also cheap enough to compete with the tape-based approach. An additional benefit is protection against user errors. Because ASM files are not true filesystems, they are less likely to be corrupted accidentally by DBAs and sysadmins. Incremental Merge Let's say you have the following backup schedule: Sunday - Level 0 (full), with tag level_0 Monday - Level 1 (incremental) with tag level_1_mon Tuesday - Level 1 (incremental) with tag level_1_tue and so on. If the database fails on Saturday, prior to 10g you would have had to restore the tag level_0 and then apply all six incrementals. It would have taken a long time, which is another reason many DBAs shun incremental backups. Oracle Database 10g RMAN radically changes that equation. Now, your incremental backup command looks like this:

RMAN> backup incremental level_1 for recover of copy with tag level_0 database; Here we have instructed RMAN to make an incremental level_1 backup and merge that with the full backup copy with the tag level_0. After this command, level_0 becomes a full backup of that day. So, on Tuesday, the backup with tag level_0, when merged with incremental level_1 backup, becomes identical to the full Tuesday backup. Similarly, the incremental taken on Saturday, when applied to the backup on disk, will be equivalent to a full level_0 Saturday backup. If the database fails on Saturday, you just need to restore the level_0 backup plus a few archive logs to bring the database into a consistent state; there is no need to apply additional incrementals. This approach cuts down recovery time dramatically, speeds backup, and eliminates the need to make a full database backup again. Compressed Files With disk-based backups in the flash recovery area, you still have a big limitation: disk space. Especially when going across a networkas is usually the caseit's advisable to create as small a backup set as possible. In Oracle Database 10g RMAN, you can compress files inside the backup command itself: RMAN> backup as compressed backupset incremental level 1 database; Note the use of the clause COMPRESSED. It compresses backup files with an important difference: while restoring, RMAN can read the files without uncompressing. To confirm compression, check for the following message in the output: channel ORA_DISK_1: starting compressed incremental level 1 datafile backupset Furthermore, you can verify that the backup was compressed by checking the RMAN list output: RMAN> list output; BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------3 Incr 1 2M DISK 00:00:00 26-FEB-04 BP Key: 3 Status: AVAILABLE Compressed: YES Tag: TAG20040226T100154 Piece Name: /ora_flash_area/SMILEY10/backupset/2004_02_26/o1_mf_ncsn1_TAG20040226T100154_0 3w2m3lr_.bkp Controlfile Included: Ckp SCN: 318556 Ckp time: 26-FEB-04 SPFILE Included: Modification time: 26-FEB-04 As with any compression process, this approach puts pressure on CPUs. As a tradeoff, you can keep more RMAN backups on disk that are readily available for restore-and-recover operations. Alternatively, you can make RMAN backups at the Physical Standby Database that can be used to recover the primary database. That approach will offload backup resourses to another host. Look Before You Leap: Recovery Preview In Oracle Database 10g, RMAN has gone one more step ahead by providing the ability to preview the backups required to perform a restore operation.

RMAN> restore database preview; Listing 1 shows the output of this operation. You can also preview specific restore operations; for example: restore tablespace users preview; Preview allows you to ensure the recovery readiness of your backup infrastructure by making periodic and regular checks. Resetlogs and Recovery Let's imagine that you have lost the current online redo log files and you have to perform an incomplete database recoverya rare but not unheard of situation. The biggest problem is resetlogs; after incomplete recovery you must open the database with the resetlogs clause, which sets the sequence number of the log threads to 1, making your earlier backups obsolete in RMAN and making the recovery operation more of a challenge. In Oracle9i and below, if you need to restore the database to a version prior to resetlogs, you have to restore to a different incarnation. In Oracle Database 10g, you don't have to do that. Thanks to additional infrastructure in the control file, RMAN can now readily use all backups, before and after a resetlogs operation, to recover the Oracle database. There is no need to shut down the database to make a backup. This new capability means that the database can be re-opened immediately for the user community after a resetlogs operation. Ready for RMAN The enhancements in Oracle Database 10g RMAN make it an even more compelling tool in your backup strategy. The improvements to the incremental backup process alone make RMAN tough to ignore.

What are RMAN 10g backup formats?

RMAN Backup Formats: Image Copies and Backup Sets RMAN backups can be stored in one of two formats: as image copies or as backup sets. Image Copies An image copy is a bit-for-bit duplicate of a database file, identical to a copy made with an operating system command. (RMAN-created image copies are, however, recorded in the RMAN repository, unlike operating system-level file copies.) In principle, RMAN is not needed to restore a datafile from an image copy. RMAN creates image copies when the AS COPY option is used with the BACKUP command. RMAN can create image copies of datafiles and datafile copies, control files and controlfile copies, archived redo logs, and backup pieces. RMAN supports creating image copies on disk, but not on media managers. Backup Sets RMAN can also store backup information in logical structures called backup sets. A backup set contains the data from one or more datafiles or archived redo logs, or control files or

SPFILE. (Datafiles and archivelogs cannot be mixed together in the same backup set.) You can also back up existing backup sets into another backup set. Only RMAN can create or restore from backup sets.When multiple files are backed up into the same backup set, they are read concurrently and their data is multiplexed together. A backup set consists of one or more files called backup pieces, files in an RMAN-specific format. By default, a backup set consists of one backup piece. For example, you can back up ten datafiles into a single backup set containing a single backup piece (that is, one backup piece will be produced as output, and the backup piece and the backup set that contains it will be recorded in the RMAN repository). A file cannot be split across backup sets. Backup sets are the only type of backup that RMAN supports on media manager devices such as tapes. Backup sets can also be created on disk. RMAN defaults to creating backups as backup sets on both disk and tape.

What is block change tracking in RMAN Oracle 10g

Oracle Database 10g RMAN implements incremental backups in a manner that disposes of the objection " RMAN scans all the data blocks to identify candidates for backup. This process puts so much stress on the system that doing incrementals becomes impractical" . It uses a file, analogous to journals in filesystems, to track the blocks that have changed since the last backup. RMAN reads this file to determine which blocks are to be backed up. You can enable this tracking mechanism by issuing the following command: SQL> alter database enable block change tracking using file '/rman_bkups/change.log'; This command creates a binary file called /rman_bkups/change.log for tracking purposes. Conversely, you can disable tracking with SQL> alter database disable block change tracking; To see whether change tracking is currently enabled, you can query: SQL> select filename, status from v$block_change_tracking;

What are the different files that RMAN can backup?

Files That RMAN Can Back Up RMAN can back up all database files needed for efficient recovery in the event of a failure. RMAN's BACKUP command supports backing up these types of files: * Datafiles, and image copies of datafiles * Control files, and image copies of control files * Archived redo logs * The current server parameter file * Backup pieces, containing other backups created by RMAN Although the database depends on other types of files for operation, such as network configuration files, password files, and the contents of the Oracle home, these files cannot be backed up with RMAN. Use some non-RMAN backup solution for any files not in the preceding list.

What is Incremental Merge in RMAN 10g?

Let's say you have the following backup schedule: Sunday - Level 0 (full), with tag level_0 Monday - Level 1 (incremental) with tag level_1_mon Tuesday - Level 1 (incremental) with tag level_1_tue and so on. If the database fails on Saturday, prior to 10g you would have had to restore the tag level_0 and then apply all six incrementals. It would have taken a long time, which is another reason many DBAs shun incremental backups. Oracle Database 10g RMAN radically changes that equation. Now, your incremental backup command looks like this: RMAN> backup incremental level_1 for recover of copy with tag level_0 database; Here we have instructed RMAN to make an incremental level_1 backup and merge that with the full backup copy with the tag level_0. After this command, level_0 becomes a full backup of that day. So, on Tuesday, the backup with tag level_0, when merged with incremental level_1 backup, becomes identical to the full Tuesday backup. Similarly, the incremental taken on Saturday, when applied to the backup on disk, will be equivalent to a full level_0 Saturday backup. If the database fails on Saturday, you just need to restore the level_0 backup plus a few archive logs to bring the database into a consistent state; there is no need to apply additional incrementals. This approach cuts down recovery time dramatically, speeds backup, and eliminates the need to make a full database backup again.

Handling Errors During Backups: Example

Handling Errors During Backups: Example By default a checksum is calculated for every block read from a datafile and stored in the backup or image copy. If you use the NOCHECKSUM option, then checksums are not calculated. If the block already contains a checksum, however, then the checksum is validated and stored in the backup. If the validation fails, then the block is marked corrupt in the backup. The SET MAXCORRUPT FOR DATAFILE command sets how many corrupt blocks in a datafile that BACKUP will tolerate. If a datafile has more corrupt blocks than specified by the MAXCORRUPT parameter, the command terminates. If you specify the CHECK LOGICAL option, RMAN checks for logical and physical corruption. By default, the BACKUP command terminates when it cannot access a datafile. You can specify parameters to prevent termination, as listed in the following table. If you specify the option ... Then RMAN skips... SKIP INACCESSIBLE

Inaccessible datafiles. A datafile is only considered inaccessible if it cannot be read. Some offline datafiles can still be read because they exist on disk. Others have been deleted or moved and so cannot be read, making them inaccessible. SKIP OFFLINE

Offline datafiles.

SKIP READONLY

Datafiles in read-only tablespaces. The following example uses an automatic channel to back up the database, and sets the corruption level for the datafile in the SYSTEM tablespace so that up to 10 errors will be accepted: RMAN> RUN { SET MAXCORRUPT FOR DATAFILE 1 TO 10; BACKUP DATABASE SKIP INACCESSIBLE SKIP READONLY SKIP OFFLINE; }

Backup Validation with RMAN

Backup Validation with RMAN You can run the BACKUP ... VALIDATE command to check datafiles for physical and logical corruption, or to confirm that all database files exist in the correct locations. No backup is taken, but all specified files are scanned to verify that they can be backed up. Here is an example: BACKUP VALIDATE DATABASE ARCHIVELOG ALL; You cannot use the MAXCORRUPT or PROXY parameters with the VALIDATE option. You can use the VALIDATE keyword of the BACKUP command to do the following: * Check datafiles for physical and logical corruption * Confirm that all database files exist and are in the correct locations RMAN does not actually produce backup sets, but rather reads the specified files in their entirety, to determine whether they can be backed up and are not corrupted. In this sense, the BACKUP VALIDATE command is similar to the RESTORE VALIDATE command, except for backups rather than restore jobs. If the backup validation discovers corrupt blocks, then RMAN updates the V$DATABASE_BLOCK_CORRUPTION view with rows describing the corruptions. After a corrupt block is repaired, the row identifying this block is deleted from the view. For example, you can validate that all database files and archived redo logs can be backed up by running a command as follows: RMAN> BACKUP VALIDATE DATABASE ARCHIVELOG ALL; This form of the command would check for physical corruption. To check for logical corruption, RMAN> BACKUP VALIDATE CHECK LOGICAL DATABASE ARCHIVELOG ALL;

RMAN displays the same output that it would if it were really backing up the files. If RMAN cannot validate the backup of one or more of the files, then it displays an error message. For example, RMAN may show output similar to the following: RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of backup command at 08/29/2001 14:33:47 ORA-19625: error identifying file /oracle/oradata/trgt/arch/archive1_6.dbf ORA-27037: unable to obtain file status SVR4 Error: 2: No such file or directory Additional information: 3 You cannot use the MAXCORRUPT or PROXY parameters with the VALIDATE option.

Detection of Logical Block Corruption

Besides testing for media corruption, the database can also test data and index blocks for logical corruption, such as corruption of a row piece or index entry. If RMAN finds logical corruption, then it logs the block in the alert.log. If CHECK LOGICAL was used, the block is also logged in the server session trace file. By default, error checking for logical corruption is disabled. For BACKUP commands the MAXCORRUPT parameter sets the total number of physical and logical corruptions permitted in a file. If the sum of physical and logical corruptions for a file is less than its MAXCORRUPT setting, the RMAN command completes successfully. If MAXCORRUPT is exceeded, the command terminates and RMAN does not read the rest of the file. V$DATABASE_BLOCK_CORRUPTION is populated with corrupt block ranges if the command succeeds. Otherwise, you must set MAXCORRUPT higher and re-run the backup to find out the corrupt block ranges.

Detecting Physical and Logical Block Corruption

Because an database server session is performing the backups and has a great understanding of files being backed up or copied, the server session is able to detect many types of physically corrupt blocks during the backup process. Each new corrupt block not previously encountered in a backup is recorded in the control file and in the alert.log. By default, error checking for physical corruption is enabled. At the end of a backup, RMAN stores the corruption information in the recovery catalog and control file. Access this data using the V$DATABASE_BLOCK_CORRUPTION view. If the server session encounters a datafile block during a backup that has already been identified as corrupt by the database, then the server session copies the corrupt block into the backup and the corrupt block is recorded the control file as either a logical or media corruption. RMAN copies the block in case the user wants to try to salvage the contents of the block. If RMAN encounters a datafile block that has media corruption but that has not already been identified as corrupt by the database, then it writes the block to the backup with a reformatted header indicating that the block has media corruption.

Tests and Integrity Checks for Backups?

The database prevents operations that result in unusable backup files or corrupt restored datafiles. The database server automatically does the following: * Blocks access to datafiles while they are being restored or recovered * Allows only one restore operation for each datafile at a time * Ensures that incremental backups are applied in the correct order * Stores information in backup files to allow detection of corruption You can use the BACKUP VALIDATE and RESTORE VALIDATE commands to test backup and restore operations without creating output files. In this way, you can check your datafiles for possible problems. If you run RMAN with the following configuration, then it detects all types of corruption that are possible to detect: * In the initialization parameter file, set DB_BLOCK_CHECKSUM=TRUE * In the RMAN BACKUP and RESTORE commands, do not specify the MAXCORRUPT option, do not specify the NOCHECKSUM option, but do specify the CHECK LOGICAL option

When RMAN Performs Control File Autobackups

When RMAN Performs Control File Autobackups By default, control file autobackups are turned off, and no control file autobackups are performed. If CONFIGURE CONTROLFILE AUTOBACKUP is ON, then RMAN automatically backs up the control file and the current server parameter file (if used to start up the database) in one of two circumstances: when a successful backup must be recorded in the RMAN repository, and when a structural change to the database affects the contents of the control file which therefore must be backed up. Control File Autobackups After Backup Acivities This means that the control file is backed up in the following situations: * After every BACKUP command issued at the RMAN prompt. * At the end of a RUN block, if the last command in the block was BACKUP. * Whenever a BACKUP command within a RUN block is followed by a command that is not BACKUP. The first channel allocated during the backup job creates the autobackup and places it into its own backup set. The control file autobackup may be written to disk or tape. Control File Autobackups After Database Structural Changes The control file is also automatically backed up after database structural changes such as adding a new tablespace, altering the state of a tablespace or datafile (for example, bringing it online), adding a new online redo log, renaming a file, adding a new redo thread, and so on. Losing this information would compromise your ability to recover the database. This backup is performed by the server process itself, rather than one of the RMAN channels. This type of autobackup, unlike autobackups that occur after a successful backup, is always created on disk. You can use CONFIGURE CONTROLFILE AUTOBACKUP FOR DEVICE TYPE DISK to set the location for this disk based control file autobackup. Note that a failure of the automatic control file autobackup after a structural change never causes the associated structural change to fail. For example, if you add a datafile, and if the resulting control file autobackup fails, then the datafile addition is still successful.

How RMAN Performs Control File Autobackups?

How RMAN Performs Control File Autobackups The first channel allocated during the backup job creates the autobackup and places it into its own backup set; for autobackups after database structural changes, the default disk channel makes the backup. If a server parameter file is used, it is backed up in the same backup set as the control file during a control file autobackup. After the control file autobackup completes, the database writes a message containing the complete path of the backup piece and the device type to the alert log. The RMAN behavior when the BACKUP command includes datafile 1 depends on the CONFIGURE CONTROLFILE AUTOBACKUP setting. If control file autobackups are ON and the backup includes datafile 1, RMAN writes the control file and SPFILE to a separate autobackup backup set. If control file autobackups are OFF and the backup includes datafile 1, then RMAN includes the current control file and SPFILE in the same backup set as the datafiles. The control file autobackup filename has a default format of %F for all device types, so that RMAN can guess the file location and restore it without a repository. The substitution variable %F is defined in the description of the CONFIGURE command in Oracle Database Backup and Recovery Basics. You can specify a different format with the CONFIGURE CONTROLFILE AUTOBACKUP FORMAT command. All autobackup formats must include the %F variable. The SET CONTROLFILE AUTOBACKUP FORMAT command, which you can specify either within a RUN block or at the RMAN prompt, overrides the configured autobackup format in the session only. The order of precedence is: 1. SET within a RUN block 2. SET at RMAN prompt 3. CONFIGURE CONTROLFILE AUTOBACKUP FORMAT You can configure the autobackup format even when CONFIGURE CONTROLFILE AUTOBACKUP is set to OFF, but RMAN does not generate autobackups in this case. For RMAN to make autobackups, you must set CONFIGURE CONTROLFILE AUTOBACKUP to ON.

what command do you execute to ensure that the control file is automatically backed up using Recovery Manager (RMAN)?
what command do you execute to ensure that the control file is automatically backed up using Recovery Manager? The automatic backup of the control file occurs independently of any backup of the current control file explicitly requested as part of your backup command. You can turn the autobackup feature on or off by running the following commands: CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE CONTROLFILE AUTOBACKUP OFF;

Oracle 10 RMAN Views

Oracle 10g includes additional V$ views making the reporting of backup operations more transparent. * V$RMAN_OUTPUT - This is an in-memory view of the messages reported by RMAN holding a maximum of 32767 rows. Since this information is not recorded in the controlfile it is lost on instance restart. * V$RMAN_STATUS - This view displays progress and status information for in-progress and complete RMAN jobs. The information for the in-progress jobs is memory only, while the complete job information comes from the controlfile. * V$BACKUP_FILES - This view display information about RMAN image copies, backupsets and archived logs, similar to the information listed by the RMAN commands LIST BACKUP and LIST COPY. This view relies on the DBMS_RCVMAN.SETDATABASE procedure being run to set the database. The V$RMAN_CONFIGURATION view from Oracle 9i is still available in Oracle 10g.

Automatic Instance Creation for RMAN TSPITR

Automatic Instance Creation for RMAN TSPITR If a tablespace point-in-time recovery (TSPITR) is initiated with no reference to an auxillary instance RMAN now automatically creates an one. The auxillary instance configuration is based on that of the target database. As a result, any channels required for the restore operations must be present in the target database so they are configured correctly in the auxillary instance. The location of the datafiles for the auxillary instance are specified using the AUXILIARY DESTINATION clause shown below. RECOVER TABLESPACE users UNTIL LOGSEQ 2400 THREAD 1 AUXILIARY DESTINATION '/u01/oradata/auxdest'; The tablespace is taken offline, restored from a backup, recovered to the specified point-intime in the auxillary instance and re-imported into the target database. The tablespace in the target database should then be backed up and the tablespace brought back online. BACKUP TABLESPACE users; SQL "ALTER TABLESPACE users ONLINE"; On successful completion the auxillary instance will be cleaned up automatically. In the event of errors the auxillary instance is left intact to aid troubleshooting.

What is Oracle Secure Backup (OSB)?

What is Oracle Secure Backup (OSB)? Oracle Secure Backup is a centralized tape backup management software providing secure data protection for heterogeneous file systems and the Oracle Database. Why switch to Oracle Secure Backup? Oracle Secure Backup delivers reliable, high performance tape backup for your entire IT environment including UNIX/Linux/Windows/NAS file systems and the Oracle database at the lowest-cost. The single component, per tape drive, pricing model is lower-cost and significantly reduces license management as compared to other media management products, which generally charge a premium for advanced functionality.

Oracle Secure Backup provides key benefits: Fastest Oracle database backup to tape Single technical resource for entire backup environment Dynamic tape drive sharing between NAS / UNIX / Linux / Windows servers Policy-based backup management: o Backup encryption o Vaulting (rotation of tapes between multiple locations) o Tape duplication o Migration from virtual tapes to physical tapes Is Oracle Secure Backup a separate product from the Oracle database? Yes. Oracle Secure Backup is a separate product with independent release schedule and versioning from that of the database. What Oracle database versions does Oracle Secure Backup 10.2 support? Oracle Secure Backup 10.2 is tightly integrated with Recovery Manager (RMAN) supporting Oracle9i to Oracle Database 11g.

What is Oracle Secure Backup Express (OSB-XE)? Bundled with the Oracle database, Oracle Secure Backup Express is free and provides single-server tape backup management for one database server directly attached to one tape drive. Oracle Secure Backup documentation is applicable for OSB-XE with the exception of advanced functionality only available with the OSB edition. You can leverage advanced media management features by upgrading OSB-XE licensing to OSB edition. Please refer to the OSB 10.2 Licensing Documentation for feature restrictions in OSB-XE. How difficult is upgrading from OSB 10.1 to OSB 10.2? Upgrading from OSB 10.1 to 10.2 is relatively easy. The backup catalog is retained (unless explicitly deleted by user) during the upgrade maintaining all backup metadata and backwards compatibility of tapes (tapes written using OSB 10.1 are fully compatible with OSB 10.2 environments). Where can I find compatibility matrixes for Oracle Secure Backup? Platform, Web browser and NAS support is listed on Certify at metaling.oracle.com Tape device matrix is available at otn.oracle.com/technology/products/securebackup/tape_devices.pdf If a tape device is not listed on the compatibility matrix, does OSB support it? No. A tape device must be listed on the compatibility matrix to be supported. To request support for a tape device, log a Service Request (SR) through Oracle support requesting an enhancement request be filed on your behalf. Which network protocols does Oracle Secure Backup support? Oracle Secure Backup leverages NDMP for data transport over TCP/IP supporting backup, restore and other file access through NFSA and CIFS; host name resolution through NIS and DNS. How does backup encryption differ between Oracle Secure Backup 10.1 and 10.2? Oracle Secure Backup 10.2 provides backup encryption for file systems and Oracle9i forward. In OSB 10.2, policy based encryption is available at the global, server or backup job level.

Encryption keys may be generated transparently (randomly) or with a user-defined passphrase. In OSB 10.1, backup encryption to tape leveraged RMAN backup encryption only. What is the difference between RMAN backup encryption and OSB 10.2 database backup encryption? While both RMAN and Oracle Secure Backup 10.2 backup encryption leverage the same underlying Oracle encryption library, RMAN backup encryption is performed within the database and Oracle Secure Backup encryption occurs on the database server (outside of database). OSB 10.2 backup encryption supports Oracle9i forward while RMAN backup encryption is supports Oracle Database 10gR2 forward. Encryption key management differs as following: Oracle Secure Backup encryption keys are managed by OSB and stored on the OSB Administrative Server RMAN backup encryption keys are managed by the Oracle database Does Oracle Secure Backup support disk-based backups? No. However, Oracle Secure Backup supports virtual tape libraries (VTL). VTLs are disk appliances, which emulated tape drives and libraries. Oracle databases have always supported disk-based backups via RMAN. With Oracle Database 10g, the Flash Recovery Area was introduced to manage Oracle recovery related files. The Flash Recovery may be backed up to tape using Oracle Secure Backup. More information on the Flash Recovery Area is here. Does OSB vaulting support Iron Mountain FTP format? Yes. Oracle Secure Backup vaulting reports may be generated in Iron Mountain FTP format. Is Oracle Secure Backup integrated with 3rd-party backup tools such as Veritas NetBackup or Tivoli Storage Manager? No, Oracle Secure Backup is not integrated with any 3rd-party backup tools. Oracle Secure Backup is an alternative to these products offering centralized backup management for both database data, in conjunction with Recovery Manager (RMAN), and non-database data stored in file systems. Does Oracle Secure Backup support online backups of 3rd-party databases? No, Oracle Secure Backup does not provide native plug-ins of non-Oracle databases. NonOracle databases may be backed up offline (closed/consistent) as part of a file system backup. Consult with your vendor on best practices of backing up and recovering applications. Can Oracle Secure Backup share a server and/or tape resources with other backup applications? It is not recommended to install two backup applications on the same server or share tape hardware due to potential contention of resources. Overlapping background processes may be problematic causing unusual behavior for one or both backup applications. However, a partitioned library may be successfully shared between two applications.

Backup Scripts When Few Data Blocks Change

Backup Scripts When Few Data Blocks Change If most data blocks do not change each day, incremental backups will be small and you can plan your strategy around daily incremental backups. Initial Setup

The minimum recommended flash recovery area size on disk is dependent on the how frequent the backups are taken and retention policy used. If your configured retention policy is REDUNDANCY X and you plan to take a backup every Y days, then the formula for the recommended flash recovery area disk quota is: Disk Quota = Size of X copies of database + Size of one copy of incremental backups + Size of (Y+1) days of archived logs If you configure your retention policy to a recovery window of X days and execute your backup script once in Y days then you can calculate your required disk quota by one of two formulas. If X>=Y then the formula for the recommended flash recovery area disk quota is: Disk Quota = Size of one copy of database + Size of (floor(X/Y) + 1) copies of incremental backups + Size of (X * ceil(X/Y) +1) days of archived logs where ceil(X/Y) is the smallest integer greater than or equal to X/Y and floor(X/Y) is the largest integer less than or equal to X/Y. If X Disk Quota = Size of one copy of database + Size of 2 copies of incremental backups + Size of (Y +1) days of archived logs Size your flash recovery area according to the applicable formula. For this example, assume that the retention policy is REDUNDANCY 1: RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 1; Also assume that backups will be performed daily. Daily Script The daily backup script would look like this: RMAN> RECOVER COPY OF DATABASE WITH TAG "whole_db_cpy"; # Make an incremental backup of the database to the flash recovery area. RMAN> BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG "whole_db_copy" DATABASE; Assume that there are no backups tagged "whole_db_copy" as of the first day of this backup scheme. The results of running this script daily are as follows: * On the first day, the RECOVER statement would have no effect, and the BACKUP... FOR RECOVER OF COPY would create the initial level 0 database copy. * On the second day, the RECOVER statement still has no effect, as there is no level 1 incremental backup to be applied to the level 0 incremental database copy. The BACKUP command creates the first incremental level 1 backup. * Each day after that, the incremental level 1 from the previous day is applied over the level 0

database copy, rolling it forward to the time of the incremental level 1 of the previous day, and a new incremental level 1 is created, containing all changes since the level 1 incremental backup of the previous day.

Improving Incremental Backup Performance: Change Tracking

Improving Incremental Backup Performance: Change Tracking RMAN's change tracking feature for incremental backups improves incremental backup performance by recording changed blocks in each datafile in a change tracking file. If change tracking is enabled, RMAN uses the change tracking file to identify changed blocks for incremental backup, thus avoiding the need to scan every block in the datafile. After enabling change tracking, the first level 0 incremental backup still has to scan the entire datafile, as the change tracking file does not yet reflect the status of the blocks. Subsequent incremental backup that use this level 0 as parent will take advantage of the change tracking file. Using change tracking in no way changes the commands used to perform incremental backups, and the change tracking files themselves generally require little maintenance after initial configuration. Change tracking is disabled by default, because it does introduce some minimal performance overhead on your database during normal operations. However, the benefits of avoiding full datafile scans during backup are considerable, especially if only a small percentage of data blocks are changed between backups. If your backup strategy involves incremental backups, then you should enable change tracking. One block change tracking file is created for the whole database. By default, the block change tracking file is created as an Oracle managed file in DB_CREATE_FILE_DEST. You can also specify the name of the block change tracking file, placing it in any location you choose. Oracle saves enough change-tracking information to enable incremental backups to be taken using any of the 8 most recent incremental backups as its parent. Although RMAN does not support backup and recovery of the change-tracking file itself, if the whole database or a subset needs to be restored and recovered, then recovery has no uservisible effect on change tracking. After the restore and recovery, the change tracking file is cleared, and starts recording block changes again. The next incremental backup after any recovery is able to use change-tracking data. The size of the change tracking file is proportional to the size of the database and the number of enabled threads of redo. The size is not related to the frequency of updates to the database. The space required for block change tracking is approximately 1/30,000 the size of the data blocks to be tracked. However, to avoid overhead of allocating space as your database grows, the change tracking file size starts at 10MB, and new space is allocated in 10MB incremenents. Thus, for any database up to approximately 1TB the file size is 10MB, for up to 2TB the file size is 20MB, and so on. Enabling and Disabling Change Tracking You can enable or disable change tracking when the database is either open or mounted. To alter the change tracking setting, you must use SQL*Plus to connect to the target database with administrator privileges. To store the change tracking file in the database area, set DB_CREATE_FILE_DEST in the

target database. Then issue the following SQL statement to enable change tracking: SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING; You can also create the change tracking file in a location you choose yourself, using the following SQL statement: SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/mydir/rman_change_track.f' REUSE; The REUSE option tells Oracle to overwrite any existing file with the specified name. To disable change tracking, use this SQL statement: SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING; If the change tracking file was stored in the database area, then it is deleted when you disable change tracking. Checking Whether Change Tracking is Enabled From SQL*Plus, you can query V$BLOCK_CHANGE_TRACKING.STATUS to determine whether change tracking is enabled, and if it is, query V$BLOCK_CHANGE_TRACKING.FILENAME to display the filename. Moving the Change Tracking File If you need to move the change tracking file, the ALTER DATABASE RENAME FILE command updates the control file to refer to the new location. The process outlined in this section describes how to change the location of the change tracking file while preserving its contents. To relocate the block change tracking file: 1. If necessary, determine the current name of the change tracking file: SELECT filename FROM V$BLOCK_CHANGE_TRACKING; 2. Shut down the database. For example: SHUTDOWN IMMEDIATE 3. Using host operating system commands, move the change tracking file to its new location. 4. Mount the database and move the change tracking file to a location that has more space. For example: ALTER DATABASE RENAME FILE 'ora_home/dbs/change_trk.f' TO '/new_disk/change_ trk.f'; 5. Open the database: ALTER DATABASE OPEN; If you cannot shut down the database, then you must disable change tracking and re-enable it at the new location, as in the following example:

ALTER DATABASE DISABLE BLOCK CHANGE TRACKING; ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE 'new_location'; If you choose this method, you will lose the contents of the change tracking file. Until the next time you complete a level 0 incremental backup, RMAN will have to scan the entire file.

Incrementally Updated Backups: A One Week Example

Incrementally Updated Backups: A One Week Example The basic example can be extended to provide fast recoverability to a window greater than 24 hours. Alter the RECOVER COPY... WITH TAG to perform incomplete recovery of the datafile copies to the point in time in the past where you want your window of recoverability to begin. This example shows how to maintain a seven day window: RUN { RECOVER COPY OF DATABASE WITH TAG 'incr_update' UNTIL TIME 'SYSDATE - 7'; BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_update' DATABASE; } The effect of the script is as follows: * On the first night the RECOVER COPY... UNTIL TIME statement has no effect, and the BACKUP INCREMENTAL... FOR RECOVER OF COPY statement creates the incremental level 0 copy. * On the second through seventh nights, the RECOVER COPY... UNTIL TIME statement has no effect because TIME 'SYSDATE - 7' is still a time in the future. The BACKUP INCREMENTAL... FOR RECOVER OF COPY statement creates differetial incremental level 1 backups containing the block changes for the previous day. * On the eighth and all subsequent nights night, the RECOVER COPY... UNTIL TIME statement applies the level 1 incremental from seven days ago to the copy of the database. The BACKUP INCREMENTAL... FOR RECOVER OF COPY statement creates an incremental backup containing the changes for the previous day. As with the basic example, you have fast recoverability to any point in time between the SCN of the datafile copies and the present, using block changes from the incremental backups and individual changes from the redo logs. Because you have the daily level 1 incrementals, you still never need to apply more than one day of redo.

Basic Incremental Backup Strategy

Basic Incremental Backup Strategy Choose a backup scheme according to an acceptable MTTR (mean time to recover). For example, you can implement a three-level backup scheme so that a full or level 0 backup is taken monthly, a cumulative level 1 is taken weekly, and a differential level 1 is taken daily. In this scheme, you never have to apply more than a day's worth of redo for complete recovery. When deciding how often to take full or level 0 backups, a good rule of thumb is to take a new level 0 whenever 50% or more of the data has changed. If the rate of change to your database is predictable, then you can observe the size of your incremental backups to determine when a new level 0 is appropriate. The following query displays the number of

blocks written to a backup set for each datafile with at least 50% of its blocks backed up: SELECT FILE#, INCREMENTAL_LEVEL, COMPLETION_TIME, BLOCKS, DATAFILE_BLOCKS FROM V$BACKUP_DATAFILE WHERE INCREMENTAL_LEVEL > 0 AND BLOCKS / DATAFILE_BLOCKS > .5 ORDER BY COMPLETION_TIME; Compare the number of blocks in differential or cumulative backups to a base level 0 backup. For example, if you only create level 1 cumulative backups, then when the most recent level 1 backup is about half of the size of the base level 0 backup, take a new level 0. Making Incremental Backups: BACKUP INCREMENTAL After starting RMAN, run the BACKUP INCREMENTAL command at the RMAN prompt. This example makes a level 0 incrementnal backup of the database: BACKUP INCREMENTAL LEVEL 0 DATABASE; This example makes a differential level 1 backup of the SYSTEM tablespace and datafile tools01.dbf. It will only back up those data blocks changed since the most recent level 1 or level 0 backup: BACKUP INCREMENTAL LEVEL 1 TABLESPACE SYSTEM DATAFILE 'ora_home/oradata/trgt/tools01.dbf'; This example makes a cumulative level 1 backup of the tablespace users, backing up all blocks changed since the most recent level 0 backup. BACKUP INCREMENTAL LEVEL = 1 CUMULATIVE TABLESPACE users; Incrementally Updated Backups: Rolling Forward Image Copy Backups Oracle's Incrementally Updated Backups feature lets you create an image copy of a datafile, then regularly create incremental backups of your database and apply them to that image copy. The image copy is updated with all changes up through the SCN at which the incremental backup was taken. RMAN can use the resulting updated datafile in media recovery just as it would use a full image copy taken at that SCN, without the overhead of performing a full image copy of the database every day. A backup strategy based on incrementally updated backups can help minimize time required for media recovery of your database. If you run scripts to implement this strategy daily, then at recovery time, you never have more than one day of redo to apply. Incrementally Updated Backups: A Basic Example To create incremental backups for use in an incrementally updated backups strategy, you must use the BACKUP... FOR RECOVER OF COPY WITH TAG form of the BACKUP command. How the command works is best understood in the context of an example script that would implement the strategy. This script, run on a regular basis, is all that is required to implement a strategy based on incrementally updated backups: RUN {

RECOVER COPY OF DATABASE WITH TAG 'incr_update'; BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_update' DATABASE; } The syntax used in the script does not, however, make it clear how the strategy works. To understand the script and the strategy, it is necessary to understand the effects of these two commands when no datafile copies or incremental backups exist. * The BACKUP INCREMENTAL LEVEL 1... FOR RECOVER OF COPY WITH TAG... command does not always create a level 1 incremental backup. If there is no incremental level 0 backup of an individual datafile to use with this level 1 backup, then executing this command creates a level 0 backup of the datafile with the specified tag. Therefore, the first time the script runs, it creates the level 0 backup of the datafile needed to begin the cycle of incremental updates. In the second run and all subsequent runs, it produces level 1 incremental backups of the datafile. * The RECOVER COPY OF DATABASE WITH TAG... command causes RMAN to apply any incremental level 1 backups to a set of datafile copies with the same tag. If there is no incremental backup or no datafile copy, the command generates a message but does not generate an error. The first time the script runs, this command has no effect, because there is neither a datafile copy nor a level 1 incremental backup. The second time the script runs, there is a datafile copy (created by the first BACKUP command), but no incremental level 1 backup, so again, the command has no effect. On the third run and all subsequent runs, there is a datafile copy and a level 1 incremental from the previous run, so the level 1 incremental is applied to the datafile copy, bringing the datafile copy up to the checkpoint SCN of the level 1 incremental. Note also the following details about how this example works: * Each time a datafile is added to the database, an image copy of the new datafile is created the next time the script runs. The time after that, the first level 1 incremental for that datafile is created, and on all subsequent runs the new datafile is processed like any other datafile. * Tags must be used to identify the incremental backups and datafile copies created for use in this strategy, so that they do not interfere with other backup strategies you implement. (If you have multiple incremental backup strategies in effect, RMAN cannot unambiguously select incremental level 0 and level 1 backups for use in incremental backup and recover operations, unless they are tagged.) In practice, you would schedule the example script to run once each day, possibly at midnight. On a typical night (that is, after the first two nights), when the script completed the following files would be available for a point-in-time recovery: * An image copy of the database, as of the checkpoint SCN of the preceding run of the script, 24 hours earlier * An incremental backup for the changes since the preceding run * Archived redo logs including all changes between the checkpoint SCN of the image copy and the current time If, at some point during the following 24 hours, you need to restore and recover your database from this backup, for either complete or point-in-time recovery, you can restore the datafiles from the incrementally updated datafile copies, and apply changes from the most recent

incremental level 1 and the redo logs to reach the desired SCN. At most, you will have 24 hours of redo to apply, which limits how long point-in-time recovery will take.

Cumulative Incremental Backups

Cumulative Incremental Backups In a cumulative level 1 backup, RMAN backs up all the blocks used since the most recent level 0 incremental backup. Cumulative incremental backups reduce the work needed for a restore by ensuring that you only need one incremental backup from any particular level. Cumulative backups require more space and time than differential backups, however, because they duplicate the work done by previous backups at the same level.

Differential Incremental Backups

Differential Incremental Backups In a differential level 1 backup, RMAN backs up all blocks that have changed since the most recent cumulative or differental incremental backup, whether at level 1 or level 0. RMAN determines which level 1 backup occurred most recently and backs up all blocks modified after that backup. If no level 1 is available, RMAN copies all blocks changed since the level 0 backup. If no level 0 backup is available, then the behavior depends upon the compatibility mode setting. If compatibility is >=10.0.0, RMAN copies all blocks changed since the file was created, and stores the results as a level 1 backup. In other words, the SCN at the time the incremental backup is taken is the file creation SCN. If compatibility <10.0.0, RMAN generates a level 0 backup, to be consistent with the behavior in previous releases.

Level 0 and Level 1 Incremental Backups

Level 0 and Level 1 Incremental Backups Incremental backups can be either level 0 or level 1. A level 0 incremental backup, which is the base for subsequent incremental backups, copies all blocks containing data, backing the datafile up into a backup set just as a full backup would. The only difference between a level 0 incremental backup and a full backup is that a full backup is never included in an incremental strategy. A level 1 incremental backup can be either of the following types: * A differential backup, which backs up all blocks changed after the most recent incremental backup at level 1 or 0 * A cumulative backup, which backs up all blocks changed after the most recent incremental backup at level 0 Incremental backups are differential by default. Note: Cumulative backups are preferable to differential backups when recovery time is more important than disk space, because during recovery each differential backup must be applied in succession. Use cumulative incremental backups instead of differential, if enough disk space is available to store cumulative incremental backups.

The size of the backup file depends solely upon the number of blocks modified and the incremental backup level.

RMAN Incremental Backups

RMAN Incremental Backups You can make incremental backups of databases, individual tablespaces or datafiles. As with other backups, if you are in ARCHIVELOG mode, you can make incremental backups if the database is open; if the database is in NOARCHIVELOG mode, then you can only make incremental backups when the database is closed. The goal of an incremental backup is to back up only those data blocks that have changed since a previous backup. The primary reasons for making incremental backups part of your strategy are: * For use in a strategy based on incrementally updated backups, where these incremental backups will be used to roll forward an image copy of the database * To reduce the amount of time needed for daily backups * To save network bandwidth when backing up over a network * To get adequate backup performance when the aggregate tape bandwidth available for tape write I/Os is much less than the aggregate disk bandwidth for disk read I/Os * To be able to recover changes to objects created with the NOLOGGING option. For example, direct load inserts do not create redo log entries and their changes cannot be reproduced with media recovery. They do, however, change data blocks and so are captured by incremental backups. * To reduce backup sizes for NOARCHIVELOG databases. Instead of making a whole database backup every time, you can make incremental backups. Note that incremental backups of a NOARCHIVELOG database are only legal after a consistent shutdown. One effective strategy is to make incremental backups to disk, and then back up these image copies to a media manager with BACKUP AS BACKUPSET. This avoids the problem of keeping the tape streaming that can occur when making incremental backups directly to tape. Because incremental backups are not as big as full backups, you can create them on disk more easily. Incremental Backup Algorithm Each data block in a datafile contains a system change number (SCN), which is the SCN at which the most recent change was made to the block. During an incremental backup, RMAN reads the SCN of each data block in the input file and compares it to the checkpoint SCN of the parent incremental backup. If the SCN in the input data block is greater than or equal to the checkpoint SCN of the parent, then RMAN copies the block. Note that if you enable the block change tracking feature, RMAN can refer to the change tracking file to identify changed blocks in datafiles without scanning the full contents of the datafile. Once enabled, block change tracking does not alter how you take or use incremental backups, other than offering increased performance. See "Improving Incremental Backup Performance: Change Tracking" for more details about enabling block change tracking.

Using Compressed Backupsets

Using Compressed Backupsets For any use of the BACKUP command that creates backupsets, you can take advantage of RMAN's support for binary compression of backupsets, by using the AS COMPRESSED BACKUPSET option to the BACKUP command. The resulting backupsets are compressed using an algorithm optimized for efficient compression of Oracle database files. No extra uncompression steps are required during recovery if you use RMAN's integrated compression. This example backs up the entire database and archived logs to the configured default backup destination (disk or tape), producing compressed backupsets: BACKUP AS COMPRESSED BACKUPSET DATABASE PLUS ARCHIVELOG; This example backups up several datafiles to the default device, using binary compression: BACKUP AS COMPRESSED BACKUPSET DATAFILE 1,2,4; Predictably, creating compressed backupsets imposes some extra CPU overhead during backup and restore, which can slow the backup process. The performance penalty can be worth paying, however, in a number of circumstances: * If you are using disk-based backups and disk space in your flash recovery area or other disk-based backup destination is limited * If you are performing your backups to some device over a network and reduced network bandwidth is more important than CPU usage * If you are using some archival backup media such as CD or DVD, where reducing backup sizes saves on media costs and archival storage Note that performance while creating compressed backupsets is CPU bound. If you have more than one CPU, you can use increased parallelism to run jobs on multiple CPUs and thus improve performance.

Backing Up Archived Redo Logs with RMAN

Backing Up Archived Redo Logs with RMAN Archived redo logs are the key to successful media recovery. Back them up regularly. You can back up logs with BACKUP ARCHIVELOG, or back up logs while backing up datafiles and control files by specifying BACKUP ... PLUS ARCHIVELOG. Backing Up Archived Redo Log Files with BACKUP ARCHIVELOG To back up archived redo logs, use the BACKUP ARCHIVELOG command at the RMAN prompt. This example uses a configured disk or sbt channel to back up one copy of each log sequence number for all archived redo logs: BACKUP ARCHIVELOG ALL; Even if your redo logs are being archived to multiple destinations and you use RMAN to back up archived redo logs, RMAN selects only one copy of the archived redo log file to include in the backup set. (Since logs with the same log sequence number are identical, there is no need to include more than one copy.) You can also specify a range of archived redo logs by time, SCN, or log sequence number, as in the following example:

BACKUP ARCHIVELOG FROM TIME 'SYSDATE-30' UNTIL TIME 'SYSDATE-7'; Automatic Online Redo Log Switches During Backups of Archived Logs When taking a backup of archived redo logs that includes the most recent log (that is, a BACKUP ... ARCHIVELOG command is run without the UNTIL or SEQUENCE option) if the database is open, then before beginning the backup, RMAN will switch out of the current online redo log group, and all online redo logs that have not yet been archived, up to and including the redo log group that was current when the commadn was issued. This ensures that the backup contains all redo that was generated prior to the start of the command. Using BACKUP ARCHIVELOG with DELETE INPUT or DELETE ALL INPUT You can specify the DELETE INPUT or DELETE ALL INPUT clauses for the BACKUP ARCHIVELOG command to delete archived logs after they are backed up, eliminating the separate step of manually deleting the archived redo logs. With DELETE INPUT, RMAN only deletes the specific copy of the archived redo log chosen for the backup set. With DELETE ALL INPUT, RMAN will delete each backed-up archived redo log file from all log archiving destinations. For example, assume that you archive to /arc_dest1, /arc_dest2, and /arc_dest3, and you run the following command: BACKUP DEVICE TYPE sbt ARCHIVELOG ALL DELETE ALL INPUT; In this case RMAN backs up only one copy of each log sequence number in these directories, and then deletes all copies of any log that it backed up from the archiving destinations. If you had specified DELETE INPUT rather than DELETE ALL INPUT, then RMAN would only delete the specific archived redo log files that it backed up (for example, it would delete the archived redo log files in /arc_dest1 if those were the files used as the source of the backup, but it would leave the contents of the /arc_dest2 and /arc_dest3 intact) . If you issue BACKUP ARCHIVELOG ALL or BACKUP ARCHIVELOG LIKE '...', and there are no archived redo log files to back up, then RMAN does not signal an error. Backing Up Logs with BACKUP ... PLUS ARCHIVELOG You can add archived redo logs to a backup of other files by using the BACKUP ... PLUS ARCHIVELOG clause. Adding BACKUP ... PLUS ARCHIVELOG causes RMAN to do the following: 1. Runs the ALTER SYSTEM ARCHIVE LOG CURRENT command. 2. Runs BACKUP ARCHIVELOG ALL. Note that if backup optimization is enabled, then RMAN skips logs that it has already backed up to the specified device. 3. Backs up the rest of the files specified in BACKUP command. 4. Runs the ALTER SYSTEM ARCHIVE LOG CURRENT command. 5. Backs up any remaining archived logs generated during the backup. This guarantees that datafile backups taken during the command are recoverable to a consistent state. To back up archived redo logs with BACKUP ... PLUS ARCHIVELOG: After starting RMAN, run the BACKUP ... PLUS ARCHIVELOG command at the RMAN

prompt . This example backs up the database and all archived logs: BACKUP DEVICE TYPE sbt DATABASE PLUS ARCHIVELOG; \

Backing Up Server Parameter Files with RMAN

Backing Up Server Parameter Files with RMAN As explained in "Backing Up Control Files with RMAN", RMAN automatically backs up the current server parameter file in certain cases. The BACKUP SPFILE command backs up the parameter file explicitly. For example: BACKUP DEVICE TYPE sbt SPFILE; The SPFILE that is backed up is the one currently in use by the instance. If the instance is started with a client-side initialization parameter file, then RMAN does not back up anything when this command is used.

Backing Up Control Files with RMAN

Backing Up Control Files with RMAN You can back up the control file when the database is mounted or open. RMAN uses a snapshot control file to ensure a read-consistent version. If CONFIGURE CONTROLFILE AUTOBACKUP is ON (by default it is OFF), then RMAN automatically backs up the control file and server parameter file after every backup and after database structural changes. The control file autobackup contains metadata about the previous backup, which is crucial for disaster recovery. If the autobackup feature is not set, then you must manually back up the control file in one of the following ways: * Run BACKUP CURRENT CONTROLFILE * Include a backup of the control file within any backup by using the INCLUDE CURRENT CONTROLFILE option of the BACKUP command * Back up datafile 1, because RMAN automatically includes the control file and SPFILE in backups of datafile 1 A manual backup of the control file is not the same as a control file autobackup. In manual backups, only RMAN repository data for backups within the current RMAN session is in the control file backup, and a manually backed-up control file cannot be automatically restored. Backing Up the Current Control File Manually After starting RMAN, run the BACKUP CURRENT CONTROLFILE command. This example backs up the current control file to the default disk device and assigns a tag: BACKUP CURRENT CONTROLFILE TAG = mondaypmbackup; If the autobackup feature is enabled, then RMAN makes two control file backups in this example: the explicit control file backup (BACKUP CURRENT CONTROLFILE) and the autobackup of the control file and server parameter file.

Including the Current Control File in a Backup Set To include the current control file in a backup set, specify the INCLUDE CURRENT CONTROLFILE option after specifying the backup object. In this example, the default configured channel is to an sbt device. This command backs up tablespace users to tape and includes the current control file in the backup: BACKUP DEVICE TYPE sbt TABLESPACE users INCLUDE CURRENT CONTROLFILE; If the autobackup feature is enabled, then RMAN also creates an autobackup of the control file after the BACKUP TABLESPACE command completes. Backing Up a Control File Copy This example creates a control file backup with the BACKUP CONTROLFILECOPY command. To back up a control file copy: After starting RMAN, run the BACKUP CONTROLFILECOPY command at the RMAN prompt. This example creates the control file copy '/tmp/control01.ctl' on disk and then backs it up to tape: BACKUP AS COPY CURRENT CONTROLFILE FORMAT '/tmp/control01.ctl'; BACKUP DEVICE TYPE sbt CONTROLFILECOPY '/tmp/control01.ctl';

Backing Up Datafiles and Datafile Copies with RMAN

Backing Up Datafiles and Datafile Copies with RMAN You can back up datafiles and datafile copies when the database is mounted or open. Backing Up Datafiles Use the BACKUP DATAFILE command to back up individual datafiles. You can specify the datafiles by name or number. To back up a datafile: After starting RMAN and connecting to the target database, run the BACKUP DATAFILE command at the RMAN prompt. This example uses an sbt channel to back up datafiles 1-4 as well as a datafile copy: BACKUP DEVICE TYPE sbt DATAFILE 1,2,3,4 DATAFILECOPY '/tmp/system01.dbf'; If CONFIGURE CONTROLFILE AUTOBACKUP is ON, then RMAN writes the current control file and SPFILE to a separate autobackup piece. Otherwise, these files are automatically included in the backup set that contains datafile 1. Backing Up Datafile Copies Use the BACKUP DATAFILECOPY command to back up datafile copies. Datafile copies exist on disk only. To back up a datafile copy:

While connected to the target database, run the BACKUP DATAFILECOPY command at the RMAN prompt. This example backs up datafile /tmp/system01.dbf to tape: BACKUP DEVICE TYPE sbt DATAFILECOPY '/tmp/system01.dbf';

Backing Up Individual Tablespaces with RMAN

Backing Up Individual Tablespaces with RMAN You can backup one or more individual tablespaces with the BACKUP TABLESPACE command. You can use this command when the database is mounted or open. To back up a tablespace: After starting RMAN, run the BACKUP TABLESPACE command at the RMAN prompt. This example backs up the users and tools tablespaces to tape, using the MAXSETSIZE parameter to specify that no backup set should be greater than 10 MB: BACKUP DEVICE TYPE sbt MAXSETSIZE = 10M TABLESPACE users, tools; Oracle translates the tablespace name internally into a list of datafiles.

Making Whole Database Backups with RMAN

Making Whole Database Backups with RMAN You can perform whole database backups with the database mounted or open. To perform a whole database backup, from the RMAN prompt, use the BACKUP DATABASE command. The following example backs up all the datafiles as well as the control file and server parameter file (if used) to the default configured device (in this example, disk). The backup will be stored in the default backup destination with an automatically generated filename. The default is determined as follows: * If a format is configured for the disk channel, RMAN uses the format as the default for backup storage. * Otherwise, if a flash recovery area is in use, RMAN uses the flash recovery area as the default for backup storage.. * If there is neither a format for the disk channel nor a flash recovery area, the default location and filename format are platform-specific. This example shows the procedure for taking a whole database backup to the default destination: RMAN> BACKUP DATABASE; # uses automatic channels to make backup RMAN> SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT'; # switches logs and archives all logs By archiving the logs immediately after the backup, you ensure that you have a full set of archived logs through the time of the backup. This guarantees that you can perform media recovery after restoring this backup. The FORMAT parameter to the BACKUP DATABASE command lets you specify a different destination for backups and control the filename for the backup. For example, enter:

RMAN> BACKUP DATABASE FORMAT '/tmp/%U'; # %U generates a unique filename You can also use the FORMAT argument to name an ASM disk group as backup destination, as shown in this example: RMAN> BACKUP DATABASE FORMAT '+dgroup1'; # sets an ASM disk group Optionally, use the TAG parameter to specify a backup tag. For example, enter: RMAN> BACKUP DATABASE TAG = 'weekly_backup'; # gives the backup a tag identifier RMAN assigns a default tag to backups.

Making Consistent and Inconsistent Backups with RMAN

Making Consistent and Inconsistent Backups with RMAN Consistent backups can be restored without recovery. To make a consistent backup, the database must be mounted and must not have suffered an instance failure or closed with SHUTDOWN ABORT the last time it was open. If these conditions are not met, then the backup is inconsistent. An inconsistent backup requires media recovery when it is restored, but is otherwise just as valid as a consistent backup. You can use SQL*Plus or RMAN to start up and shut down the database. The following example connects to the target database, shuts it down cleanly, and then mounts it in preparation for a backup: % rman TARGET / RMAN> SHUTDOWN IMMEDIATE # closes database consistently RMAN> STARTUP MOUNT # uses SPFILE

RMAN Backups and Tags

RMAN Backups and Tags RMAN supports attaching a tag to a backup as a way of identifying that backup. Tags can be unique for a particular backup or set of backups taken at a given time, such as 2003_year_end, or they can be re-used over time to identify a backup as being part of a series of backups, such as weekly_incremental. Many forms of the BACKUP command let you associate a tag with a backup, and many RESTORE and RECOVER commands let you specify which backups to use in the restore or recover operation by means of the tag provided when the backup was created. In practice, tags are frequently used to distinguishing backups created in different strategies, especially incremental backup strategies.

Full and Incremental Datafile Backups

Full and Incremental Datafile Backups A full datafile backup is a backup that includes every used data block in the file. If the backup

is created as a backupset, then unused block compression will cause unused blocks to be omitted. For an image copy, the entire file contents are reproduced exactly. Note: A full backup is different from a whole database backup, which is a backup of all datafiles and the current control file.

Incremental backups can only be created for datafiles. Incremental backups of datafiles capture datafile changes on a block-by-block basis, rather than requiring the backup of all used blocks in a datafile. The resulting backup sets are generally smaller than full datafile backups, unless every block in the datafile is changed. During media recovery, RMAN examines the restored files to determine whether it can recover them with an incremental backup. When possible, RMAN chooses incremental backups over archived logs, because applying all changes to a block at once is faster than reapplying individual changes to the block from the redo logs.

Unused Block Compression and Binary Compression of Backup Sets

Unused Block Compression in Backup Sets Never-used data blocks in datafiles are never copied into backup sets, saving storage space and overhead during the backup process. Unused block compression is fundamental to how RMAN writes datafiles into backup pieces, and cannot be disabled. Binary Compression of Backup Sets When storage space is more important to you than backup and restore times, you can use binary compression to reduce the size of your backup sets. The compression algorithm built into the Oracle server is tuned specifically for efficient compression of Oracle archived logs and datafiles, and will generally yield better compression than general-purpose compression utilities not tuned for Oracle database files. Further, because it is integrated into Oracle, compressing backups requires only that you add the AS COMPRESSED BACKUPSET argument to your BACKUP command. Restoring from compressed backups requires no special action whatever. Oracle Corporation recommends that you use RMAN's integrated binary compression instead of external compression utilities when you need to make compressed backups. For more on performance considerations when using binary compression of backup sets, see the description of the AS COMPRESSED BACKUPSET option of the BACKUP command, in Oracle Database Recovery Manager Reference.

Oracle RMAN 11g - New Features

New Features in Oracle Database 11g Data Recovery Advisor The Data Recovery Advisor is a new tool aimed at reducing a users time spent analyzing and formulating a suitable recovery plan for a given failure. A failure in the context of the DRA can be a missing, inaccessible, or wrong version of a file (e.g. control file, data file), physical corruptions resulting from I/O errors, or logical block inconsistency. After identifying all current failures, the DRA then recommends the optimal, feasible recovery plan, and if the user

desires, automatically executes a selected recovery plan. All DRA functions can be accessed via EM or RMANs command-line interface. Multisection Backups RMAN can back up or restore a single file in parallel by dividing the work among multiple channels. Each channel backs up one file section, which is a contiguous range of blocks. This speeds up overall backup and restore performance, and particularly for bigfile tablespaces, in which a data file can be sized upwards of several hundred GB to TB's. Fast Backup Compression In addition to the Oracle Database 10g backup compression algorithm (BZIP2), RMAN now supports the ZLIB algorithm, which offers 40% better performance, with a trade-off of < 20% lower compression ratio, versus BZIP2. Network-enabled Database Duplication A clone database on a remote site can now be easily created directly over the network with the enhanced DUPLICATE command, without the need for existing backups. Virtual Private Catalog A recovery catalog administrator can grant visibility of a subset of registered databases in the catalog to specific RMAN users. Integration with Windows Volume Shadow Copy Services (VSS) The Oracle database can participate in the VSS infrastructure on Windows platforms, with compatible backup management applications and storage systems. This feature allows VSSenabled backup management applications to snapshot the Oracle database and restore at the datafile, tablespace, or database level. Refer to the Backup and Recovery User's Guide for a complete list of new features. New Features in Oracle Database 10g Release 2 Backup Set Encryption Backup security is vital to the well-being of any company. Backups should only be able to be opened and read by their creators. With Oracle Database 10gR2, backup sets made to disk can now be encrypted, for the whole database or particular tablespaces, using the new CONFIGURE ENCRYPTION FOR [DATABASE | TABLESPACE ] option. Unused Block Compression With unused block compression (enabled by default), only the currently used blocks are read and written during a full backup. This speeds up backups and reduces backup size. In previous releases, blocks that are currently unused, but had been used at some point in the past, were required to continue to be backed up. Also, blocks that have never been used are never backed up. Dynamic Channel Allocation for RAC Environments By configuring the PARALLELISM parameter, RMAN will dynamically allocate the specified number of channels across all active RAC nodes, to perform the backup or restore operation. RMAN utilizes Oracle Clusterware (formerly known as Cluster Ready Services) to allocate channels to the least loaded nodes, to perform the operations. In this way, the overall backup or restore workload can be distributed across the RAC nodes more efficiently. Enterprise Manager Enhancements Oracle Enterprise Manager, a single, integrated solution for administering and monitoring systems and applications based on the Oracle technology stack, is further enhanced for managing and monitoring backup jobs.

Database Control allows DBAs to view all backup jobs by date range and backup type (e.g. full, datafile, archive log), along with their status (e.g. "completed", "completed with warnings"), input and output sizes, and output rate. Each backup job can be further drilled down to review input files and output backup sets/image copies, their sizes, and compression ratio (if enabled). Grid Control offers several enhancements to manage backups across the enterprise. Backup jobs can be viewed across all target databases, and a failed job can be easily restarted without having to resubmit the job again. In case a backup job fails, the DBA can be notified immediately via email. In addition, user-defined RMAN scripts can be created as jobs and applied to any number of target databases. The recovery wizard has also been enhanced to allow restore and recovery to a different Oracle home, in the event that the original Oracle home or database is lost.

Can one restore RMAN backups without a CONTROLFILE and RECOVERY CATALOG?
Can one restore RMAN backups without a CONTROLFILE and RECOVERY CATALOG? Details of RMAN backups are stored in the database control files and optionally a Recovery Catalog. If both these are gone, RMAN cannot restore the database. In such a situation one must extract a control file (or other files) from the backup pieces written out when the last backup was taken. Let's look at an example: Let's take a backup (partial in our case for ilustrative purposes): $ rman target / nocatalog Recovery Manager: Release 10.1.0.2.0 - 64bit Production Copyright (c) 1995, 2004, Oracle. All rights reserved. connected to target database: ORCL (DBID=1046662649) using target database controlfile instead of recovery catalog RMAN> backup datafile 1; Starting backup at 20-AUG-04 allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=146 devtype=DISK channel ORA_DISK_1: starting full datafile backupset channel ORA_DISK_1: specifying datafile(s) in backupset input datafile fno=00001 name=/oradata/orcl/system01.dbf channel ORA_DISK_1: starting piece 1 at 20-AUG-04 channel ORA_DISK_1: finished piece 1 at 20-AUG-04 piece handle= /flash_recovery_area/ORCL/backupset/2004_08_20/o1_mf_nnndf_TAG20040820T153256_0l czd9tf_.bkp comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:45 channel ORA_DISK_1: starting full datafile backupset channel ORA_DISK_1: specifying datafile(s) in backupset including current controlfile in backupset including current SPFILE in backupset channel ORA_DISK_1: starting piece 1 at 20-AUG-04 channel ORA_DISK_1: finished piece 1 at 20-AUG-04 piece handle=

/flash_recovery_area/ORCL/backupset/2004_08_20/o1_mf_ncsnf_TAG20040820T153256_0l czfrx8_.bkp comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:04 Finished backup at 20-AUG-04[/code] Now, let's destroy one of the control files: SQL> show parameters CONTROL_FILES NAME TYPE VALUE ------------------------------------ ----------- -----------------------------control_files string /oradata/orcl/control01.ctl, /oradata/orcl/control02.ctl, /oradata/orcl/control03.ctl SQL> shutdown abort; ORACLE instance shut down. SQL> ! mv /oradata/orcl/control01.ctl /tmp/control01.ctl Now, let's see if we can restore it. First we need to start the databaase in NOMOUNT mode: SQL> startup NOMOUNT ORACLE instance started. Total System Global Area 289406976 bytes Fixed Size 1301536 bytes Variable Size 262677472 bytes Database Buffers 25165824 bytes Redo Buffers 262144 bytes Now, from SQL*Plus, run the following PL/SQL block to restore the file: DECLARE v_devtype VARCHAR2(100); v_done BOOLEAN; v_maxPieces NUMBER; TYPE t_pieceName IS TABLE OF varchar2(255) INDEX BY binary_integer; v_pieceName t_pieceName; BEGIN -- Define the backup pieces... (names from the RMAN Log file) v_pieceName(1) := '/flash_recovery_area/ORCL/backupset/2004_08_20/o1_mf_ncsnf_TAG20040820T153256_0 lczfrx8_.bkp'; v_pieceName(2) := '/flash_recovery_area/ORCL/backupset/2004_08_20/o1_mf_nnndf_TAG20040820T153256_0 lczd9tf_.bkp'; v_maxPieces := 2; -- Allocate a channel... (Use type=>null for DISK, type=>'sbt_tape' for TAPE) v_devtype := DBMS_BACKUP_RESTORE.deviceAllocate(type=>NULL, ident=>'d1'); -- Restore the first Control File... DBMS_BACKUP_RESTORE.restoreSetDataFile; -- CFNAME mist be the exact path and filename of a controlfile taht was backed-up DBMS_BACKUP_RESTORE.restoreControlFileTo(cfname=>'/app/oracle/oradata/orcl/control 01.ctl');

dbms_output.put_line('Start restoring '||v_maxPieces||' pieces.'); FOR i IN 1..v_maxPieces LOOP dbms_output.put_line('Restoring from piece '||v_pieceName(i)); DBMS_BACKUP_RESTORE.restoreBackupPiece(handle=>v_pieceName(i), done=>v_done, params=>null); exit when v_done; END LOOP; -- Deallocate the channel... DBMS_BACKUP_RESTORE.deviceDeAllocate('d1'); EXCEPTION WHEN OTHERS THEN DBMS_BACKUP_RESTORE.deviceDeAllocate; RAISE; END; / Let's see if the controlfile was restored: SQL> ! ls -l /oradata/orcl/control01.ctl -rw-r----- 1 oracle dba 3096576 Aug 20 16:45 /oradata/orcl/control01.ctl[/code] We should now be able to MOUNT the database and continue recovery... SQL> ! cp /oradata/orcl/control01.ctl /oradata/orcl/control02.ctl SQL> ! cp /oradata/orcl/control01.ctl /oradata/orcl/control03.ctl SQL> alter database mount; SQL> recover database using backup controlfile; ORA-00279: change 7917452 generated at 08/20/2004 16:40:59 needed for thread 1 ORA-00289: suggestion : /flash_recovery_area/ORCL/archivelog/2004_08_20/o1_mf_1_671_%u_.arc ORA-00280: change 7917452 for thread 1 is in sequence #671 Specify log: {=suggested | filename | AUTO | CANCEL} /oradata/orcl/redo02.log Log applied. Media recovery complete. Database altered. SQL> alter database open resetlogs; Database altered.

How does one clone/duplicate a database with RMAN?

How does one clone/duplicate a database with RMAN? The first step to clone or duplicate a database with RMAN is to create a new INIT.ORA and password file (use the orapwd utility) on the machine you need to clone the database to. Review all parameters and make the required changed. For example, set the DB_NAME parameter to the new database's name.

Secondly, you need to change your environment variables, and do a STARTUP NOMOUNT from sqlplus. This database is referred to as the AUXILIARY in the script below. Lastly, write a RMAN script like this to do the cloning, and call it with "rman cmdfile dupdb.rcv": connect target sys/secure@origdb connect catalog rman/rman@catdb connect auxiliary / run { set newname for datafile 1 to '/ORADATA/u01/system01.dbf'; set newname for datafile 2 to '/ORADATA/u02/undotbs01.dbf'; set newname for datafile 3 to '/ORADATA/u03/users01.dbf'; set newname for datafile 4 to '/ORADATA/u03/indx01.dbf'; set newname for datafile 5 to '/ORADATA/u02/example01.dbf'; allocate auxiliary channel dupdb1 type disk; set until sequence 2 thread 1; duplicate target database to dupdb logfile GROUP 1 ('/ORADATA/u02/redo01.log') SIZE 200k REUSE, GROUP 2 ('/ORADATA/u03/redo02.log') SIZE 200k REUSE; } The above script will connect to the "target" (database that will be cloned), the recovery catalog (to get backup info), and the auxiliary database (new duplicate DB). Previous backups will be restored and the database recovered to the "set until time" specified in the script. Notes: the "set newname" commands are only required if your datafile names will different from the target database. The newly cloned DB will have its own unique DBID.

How does one integrate RMAN with third-party Media Managers?

How does one integrate RMAN with third-party Media Managers? The following Media Management Software Vendors have integrated their media management software with RMAN (Oracle Recovery Manager): * Veritas NetBackup - http://www.veritas.com/ * EMC Data Manager (EDM) - http://www.emc.com/ * HP OMNIBack/ DataProtector - http://www.hp.com/ * IBM's Tivoli Storage Manager (formerly ADSM) - http://www.tivoli.com/storage/ * EMC Networker - http://www.emc.com/ * BrightStor ARCserve Backup - http://www.ca.com/us/data-loss-prevention.aspx * Sterling Software's SAMS:Alexandria (formerly from Spectralogic) http://www.sterling.com/sams/ * SUN's Solstice Backup - http://www.sun.com/software/whitepapers/backup-n-storage/ * CommVault Galaxy - http://www.commvault.com/ * etc...

The above Media Management Vendors will provide first line technical support (and installation guides) for their respective products. A complete list of supported Media Management Vendors can be found at: http://www.oracle.com/technology/deploy/availability/htdocs/bsp.htm When allocating channels one can specify Media Management spesific parameters. Here are some examples: Netbackup on Solaris: allocate channel t1 type 'SBT_TAPE' PARMS='SBT_LIBRARY=/usr/openv/netbackup/bin/libobk.so.1'; Netbackup on Windows: allocate channel t1 type 'SBT_TAPE' send "NB_ORA_CLIENT=client_machine_name"; Omniback/ DataProtector on HP-UX: allocate channel t1 type 'SBT_TAPE' PARMS='SBT_LIBRARY= /opt/omni/lib/libob2oracle8_64bit.sl'; or: allocate channel 'dev_1' type 'sbt_tape' parms 'ENV=OB2BARTYPE=Oracle8,OB2APPNAME=orcl,OB2BARLIST=machinename_orcl_archl ogs)';

How does one backup and restore archived log files?

How does one backup and restore archived log files? One can backup archived log files using RMAN or any operating system backup utility. Remember to delete files after backing them up to prevent the archive log directory from filling up. If the archive log directory becomes full, your database will hang! Look at this simple RMAN backup scripts: RMAN> run { 2> allocate channel dev1 type disk; 3> backup 4> format '/app/oracle/archback/log_%t_%sp%p' 5> (archivelog all delete input); 6> release channel dev1; 7> } The "delete input" clause will delete the archived logs as they as backed-up. List all archivelog backups for the past 24 hours: RMAN> LIST BACKUP OF ARCHIVELOG FROM TIME 'sysdate-1'; Here is a restore example: RMAN> run {

2> allocate channel dev1 type disk; 3> restore (archivelog low logseq 78311 high logseq 78340 thread 1 all); 4> release channel dev1; 5> }