Database Journal
MS SQL Oracle DB2 Access MySQL PostgreSQL Sybase PHP SQL Etc SQL Scripts & Samples Links Database Forum

» Database Journal Home
» Database Articles
» Database Tutorials
MS SQL
Oracle
DB2
MS Access
MySQL
» RESOURCES
Database Tools
SQL Scripts & Samples
Links
» Database Forum
» Sitemap
Free Newsletters:
DatabaseDaily  
News Via RSS Feed


follow us on Twitter
Database Journal |DBA Support |SQLCourse |SQLCourse2
 

Featured Database Articles

Oracle

Posted Nov 24, 2004

Oracle 10g Availability Enhancements, Part 1: Backup and Recovery Improvements

By Jim Czuprynski

Synopsis. Oracle 10g offers significant enhancements that help insure the high availability of any Oracle database, especially in the arena of disaster recovery. This article - the first in a series - concentrates on several new features available for backup, restoration, and recovery of Oracle databases, especially when using Oracle Recovery Manager (RMAN).

If you have read my earlier article about setting up disaster recovery for Oracle databases, you already know that I sincerely enjoy experimenting with the myriad robust features of Oracle Recovery Manager (RMAN). I am willing to bet that any seasoned Oracle DBA sighs knowingly and thankfully when she thinks of a potentially disastrous loss of data that has been averted by a well-planned backup and recovery strategy that incorporates RMAN.

Oracle 10g expands significantly the RMAN backup, restoration, and recovery features that I have grown to appreciate. Flash Backup and Recovery appears to be the most exciting improvement, and I will cover that in greater detail in the next article in this series, but for now, this article will focus on numerous significant features that beg for illustration.

Backup Enhancements

Expanded Image Copying Features. A standard RMAN backup set contains one or more backup pieces, and each of these pieces consists of the data blocks for a particular datafile stored in a special compressed format. When a datafile needs to be restored, therefore, the entire datafile essentially needs to be recreated from the blocks present in the backup piece.

An image copy of a datafile, on the other hand, is much faster to restore because the physical structure of the datafile already exists. Oracle 10g now permits image copies to be created at the database, tablespace, or datafile level through the new RMAN directive BACKUP AS COPY. For example, here is a command script to create image copies for all datafiles in the entire database:

RUN {
# Set the default channel configuration. Note the use of the 
# %U directive to insure unique file names for the image copies
ALLOCATE CHANNEL dbkp1 DEVICE TYPE DISK FORMAT 'c:\oracle\rmanbkup\U%';

# Create an image copy of all datafiles in the database
BACKUP AS COPY DATABASE;
}

See Listing 1.1 for additional RMAN script examples of this new feature.

Incrementally Updated Backups. As I explained in the previous section, it is now much simpler to create image copy backups of the database. Another new Oracle 10g feature, incrementally updated backups, allows me to apply incremental database changes to the corresponding image copy backup - also known as rolling forward the datafile image copy -- of any datafile in the database. Since image copy backups are much faster to restore in a media recovery situation, this new feature gives me the option to have updated image copies ready for restoration without having to recreate the image copies on a regular basis.

To utilize this feature, I will need to use the new BACKUP ... FOR RECOVER OF COPY command to create the incremental level 1 backups to roll forward the changes to the image copy of the datafiles, and use the new RMAN RECOVER COPY OF DATABASE command to apply the incremental backup to the image copies of the datafiles. Note that the TAG directive becomes extremely important to this implementation, as it is used to identify to which image copies the changes are to be rolled forward.

Here is a script that illustrates a daily cycle of creation and application of the incrementally updated backups. This would be appropriate for a database that has sufficient disk space for storage of image copies, and has a relatively high need for quick restoration of media:

RUN {
# Roll forward any available changes to image copy files
# from the previous set of incremental Level 1 backups
RECOVER 
COPY OF DATABASE 
WITH TAG 'img_cpy_upd';

# Create incremental level 1 backup of all datafiles in the database
# for roll-forward application against image copies
BACKUP
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG 'img_cpy_upd'
DATABASE;
}

Though this appears a bit counter-intuitive at first, here is an explanation of what happens during the initial run of this script:

  • The RECOVER command actually has no effect, because it cannot find any incremental backups with a tag of img_cpy_upd.
  • However, the BACKUP command will create a new Incremental Level 0 backup that is labeled with a tag of img_cpy_upd because no backups have been created yet with this tag.

And during the second run of this script:

  • The RECOVER command still will have no effect, because it cannot find any Level 1 incremental backups with a tag of img_cpy_upd.
  • The BACKUP command will create its first Incremental Level 1 backup that is labeled with a tag of img_cpy_upd.

But during the third and subsequent runs of this script:

  • The RECOVER command finds the incremental level 1 image copy backups from the previous night's run tagged as img_cpy_upd, and applies them to the existing datafile image copies.
  • The BACKUP command will create the next Incremental Level 1 backup that is labeled with a tag of img_cpy_upd.

After the third run of this script, RMAN would then choose the following files during a media recovery scenario: the image copy of the database for tag img_cpy_upd from the previous night, the most recent incremental level 1 backup, and all archived redo logs since the image copy was taken. This strategy offers a potentially quick and flexible recovery, since the datafile image copies will be relatively quick to restore, and the incremental level 1 backup plus all archived redo logs can be used to perform either a point-in-time or a complete recovery.

See Listing 1.2 for an example of how this new feature could be implemented for a weekly backup strategy.

Improved Incremental Backup Performance With Change Tracking. Another new Oracle 10g optional feature, change tracking, promises to improve the performance of incremental backup creation significantly. When an incremental backup was being taken prior to 10g, all the blocks in each datafile being backed up needed to be scanned to determine if the block had changed since the last incremental backup to determine if it needed to be included in the new incremental backup.

With the new change tracking feature enabled, however, now only the first Level 0 incremental backup needs to be completely scanned, and the IDs of any changed blocks are written instead to a change tracking file. All subsequent incremental backups will query the change tracking file to determine if there are any changed blocks that need to be backed up. Oracle automatically stores enough incremental backup metadata to insure that any of the eight most recent incremental backups can be used as the "parent" of a new incremental backup.

Each Oracle database has only one change tracking file, and if the database has been configured for Oracle Managed Files (OMF) it will be automatically created based on the specification for DB_CREATE_FILE_DEST. However, if OMF is not enabled for the database, the location of the change tracking file can be specified manually. The initial size of the change tracking file is 10MB, and it grows in 10MB increments, but Oracle notes that the 10MB initial extent should be sufficient to store change tracking information for any database up to one terabyte in size.

If the location needs to be moved, change tracking can be disabled, and a new change tracking file can be created, but this causes the database to lose all change tracking information. Moreover, unfortunately the change tracking file cannot be moved without shutting down the database, moving it with the appropriate ALTER DATABASE RENAME FILE <filename> command, and then restarting the database.

Oracle does recommend that this feature be activated for any database whose disaster recovery plan utilizes incremental backups of differing levels. Oracle also notes that theirs is a small performance hit during normal operations, but that hit should be discounted against the need to avoid scans of datafiles during restoration and recovery operations.

See Listing 1.3 for more extensive RMAN script examples of this new feature.



Oracle Archives

Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 




Latest Forum Threads
Oracle Forum
Topic By Replies Updated
Oracle Data Mining: Classification jan.hasller 0 July 5th, 07:19 AM
Find duplicates - Unique IDs Lava 5 July 2nd, 08:30 AM
no matching unique or primary key rcanter 1 April 25th, 12:32 PM
Update values of one table based on condition of values in other table using Trigger Gladiator 3 February 29th, 06:01 PM


















Thanks for your registration, follow us on our social networks to keep up-to-date