New Features of RMAN
| As indicated before, RMAN was introduced in Oracle 8 and has grown in functionality and stability through Oracle 8i and Oracle 9i. Oracle Database 10g continues that tradition and provides a number of new, especially useful features. These are listed in the various sections that follow. Use of Flash Recovery AreaThe ability to flash back, or go back in time, was introduced in Oracle 9i. Oracle Database 10g has introduced a slew of new features in this area as detailed in Chapter 17. What is interesting is that a new command, FLASHBACK DATABASE, can be used to reset the whole database back in time without resorting to a Point-In-Time-Recovery (PITR) using a backup of the database. A particular table can also be restored to a previous point in time, even if it was dropped. Use of such features can sometimes obviate the need for a RMAN or user-managed recovery from backup. All this information is stored in the flash recovery area as determined by the DB_RECOVERY_FILE_DEST parameter and bounded by both the DB_RECOVERY_FILE_DEST_SIZE and DB_FLASHBACK_RETENTION_TARGET parameters for size and retention time respectively. Notice that the latter is just a target; the size parameter along with other internal adjustments may decide the actual amount of data retained for flashback purposes. Note that flashback needs to be specifically enabled, and that you can use RMAN regardless of whether flashback is enabled or not. The flash recovery area is actually a directory or file system dedicated to storing all recovery-related data such as copies of multiplexed online redo logs and control files, archive logs, flashback logs, and finally RMAN backups as seen in Listing 9.2. In Oracle Database 10g, the flash recovery area can also be an Automatic Storage Management (ASM) disk group. Using a well-protected ASM disk group ensures that this important portion of the database is provided the right amount of protection from disaster. ASM was discussed in detail in Chapter 4, "Setting Up Automatic Storage Management."
RMAN can back up directly to the disk rather than to tape, specifically to the flash recovery area by default as you saw earlier. By configuring a large bunch of low-cost disks such as SATA (Serial ATA) to function as the flash recovery area, many organizations are trying to provide online backups using disk technology rather than tape technology. The advantages of using disk-based backup are many, including performance and shrinking time windows for backup and most importantly restoration, longevity of technology, avoidance of environmental issues that result in tape read and tape head problems, and so on. RMAN with Oracle Database 10g is poised to provide you with the ability to do this easily. As with any other backup medium, you will have to define retention periods for backups, and RMAN will automatically manage the expiration of backups and files. This is another advantage of using the flash recovery area for backups. Fast Incremental BackupsRMAN allows for incremental backups that can be used to back up only the blocks that were changed since the last full backup. Formerly, this was done by recording the SCN (System Change Number) at the last full backup and scanning all the data files for any block whose SCN was later than the previously recorded SCN. Although incremental backups saved backup storage space at the expense of some administrative work during a restore, all data files still had to be scanned, and this overhead made incremental backups impractical in most situations. Now, however, RMAN can perform incremental backups quickly using a new feature called block change tracking. Block change tracking records the list of blocks in each data file that have changed in a change-tracking file. RMAN uses the change-tracking file to identify changed blocks for incremental backup quickly and directly, thus avoiding the need to scan every block in the data file during an incremental backup. After enabling change tracking, the first level 0 incremental backup still has to scan the entire data file, because 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. There is no need to change any of the commands that were previously used to perform incremental backup; RMAN automatically uses the change-tracking files once this is configured.
Because change tracking has some minimal performance overhead on your database during normal operations, it is disabled by default. 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. Alternatively, you can specify the name and location of the block change-tracking file. The size of the change-tracking file is proportional to the size of the database and the number of enabled threads of redo, rather than to the amount or frequency of updates to the database. For databases up to 1TB, a 10MB change-tracking file is sufficient, with sizes doubling every TB. The command to create a change-tracking file is shown in Listing 9.3. Once created, the V$BLOCK_CHANGE_TRACKING view is populated as seen in Listing 9.3. Listing 9.3. Creating a Change-Tracking FileSQL> alter database enable block change tracking 2; SQL> SQL> alter database enable block change tracking using file 2 '/u04/app/oracle/product/10.1.0/db_1/oradata/TS10G/rman_chg_track.f'; Database altered. SQL> select status, bytes, filename from v$block_change_tracking; STATUS BYTES ---------- ---------- FILENAME -------------------------------------------------------------------------------- ENABLED 11599872 /u04/app/oracle/product/10.1.0/db_1/oradata/TS10G/rman_chg_track.f MetaLink Note #262853.1, titled "10G RMAN Fast Incremental Backups," provides a quick overview of this useful feature.
Incrementally Updated BackupsAlso known as backup merging, RMAN in Oracle Database 10g supports the merging of backup incrementals to previously created data file image copies so as to roll them forward to a specified point in time. Using these incrementally updated backups, you can reduce recovery time by applying incrementals specifically to data file image copies and avoid taking a full data file image copy. This backup method is possible only when using data file image copies, rather than backup sets, and these data file image copies are retained on disk rather than tape. This is an incredibly powerful feature that can drastically reduce backup and recovery times. The command to create and maintain such a backup is shown in Listing 9.4. Listing 9.4. Creating an Incrementally Updated Backup RUN { RECOVER COPY OF DATABASE WITH TAG 'TS10G_INCR_UPDATE'; BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'TS10G_INCR_UPDATE' DATABASE; } The simple example in Listing 9.4 shows how a RMAN command script can be created. Assuming this has not been run before, the first command, RECOVER COPY, will fail with error messages such as no copy of datafile 1 found to recover for those data file image copies that do not yet exist. However, the second BACKUP INCREMENTAL command with FOR RECOVER OF COPY would create a level 0 backup of all the data files in the database with the specified tag for such data files. In the second and all subsequent runs, it will produce level 1 incremental backups of all the data files in the database. If a cataloged data file image copy exists, all incremental data changes are placed in a separate backup set piece that can now be applied to the level 0 copy of the specific data file image copy. This is clear from Listing 9.5, which is the output produced by the BACKUP command in Listing 9.4. You can see from the first set of bold lines that a level 0 image copy of data file 3 (sysaux01.dbf) was not present and hence it was created in the flash recovery area under the aptly named datafile directory. Similarly, an image copy for data file 1 (system01.dbf) was also not found and hence was created. A comparison of file sizes at the operating system showed that the sizes of the physical data files and their image copies are exactly the same. The next bold section shows that an incremental level 1 data file backup set was created for the example01.dbf, undotbs01.dbf, and users01.dbf files. This backup set piece file, of course, was created in the backupset/2005_05_09 subdirectory. Finally, the control file and SPFILE were backed up into a separate backup set piece. Listing 9.5. Log of Incrementally Updated Backup[View full width] Starting backup at 09-MAY-05 using channel ORA_DISK_1 no parent backup or copy of datafile 1 found no parent backup or copy of datafile 3 found channel ORA_DISK_1: starting datafile copy input datafile fno=00003 name=/u04/app/oracle/product/10.1.0/db_1/oradata/TS10G/sysaux01 Subsequent incremental executions of the command script would create additional backup set pieces that contain changed blocks that can be used to roll forward the previous level 0 data file image copies. Note that this roll-forward recovery merging can be performed only via RMAN, because the changes are held in a backup set piece. Recovery Through RESETLOGSThe loss of all control files, or the loss of all copies of an online redo log file, will always force incomplete recovery whether the database was recovered via RMAN or from the traditional hot backup. One of the prerequesites before the database is opened is to perform an ALTER DATABASE OPEN RESETLOGS. In this case, the online redo logs are reset by initialization of both contents and the numbering scheme. As a result, going forward from that point in time, you will not be able to use previous backup sets, also known to RMAN as incarnations. Hence, you will have to immediately create another full backup of the database after you have opened the database with the RESETLOGS operation. With RMAN in Oracle Database 10g, this is no longer required. The procedure to restore a database is as easy and transparent as recovering a backup from the same incarnation. Also, the ALTER DATABASE OPEN RESETLOGS statement has now been modified so that the database archives the current online redo logs (if possible) before clearing the logs. This is an unexpected but welcome side effect! The only caveat is that you cannot restore a data file from a previous incarnation; you will have to perform complete database recovery. RMAN TuningCurrent enterprise-level databases are usually 24x7, and are employed throughout by users all around the globe. RMAN now allows for additional tuning via the use of the RATE parameter, which can be used to throttle down the I/O in case backup periods affect other online users. You can also use the COMPRESSED keyword with any BACKUP command to compress the backup. This can save backup I/O and disk space at the expense of some CPU on the backup client, and can also relieve network congestion by reducing the amount of backup traffic. The BACKUP command with the DURATION option lets you specify limited time windows for backup activities and minimize load imposed by backup activities during those backup windows. When a backup runs beyond the specified time, it is aborted. An optional PARTIAL parameter can be added to display which files could not be backed up. You can also use the MINIMIZE TIME or MINIMIZE LOAD parameters with the DURATION option to ensure that backups use all available resources in the first instance or throttle the resources so that the backup window is fully utilized in the latter instance. As well, RMAN can adjust its backup parameters dynamically using the disk topology APIs. This can influence which files are multiplexed, the level of multiplexing, as well as the number and size of buffers used for input and output disk buffers. Note that these buffers are allocated out of the LARGE_POOL_SIZE and this parameter needs to be configured properly. Other RMAN ImprovementsRMAN has introduced a slew of new features too numerous to list in detail. Briefly, they include the following:
There are many other small improvements that when considered together make a very strong case to move to the new version of RMAN. |
.dbf
EAN: 2147483647
Pages: 214