Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: General RMAN Configuration Recommendations

RE: General RMAN Configuration Recommendations

From: Orr, Steve <sorr_at_rightnow.com>
Date: Mon, 03 Jun 2002 12:53:53 -0800
Message-ID: <F001.00472BC9.20020603125353@fatcity.com>


> this way you are not writing unnecessary information to the RMAN
dictionary.
Isn't the data that goes to the RMAN repository so small that this is moot?

> take one step back and begin by configuring RMAN to backup to disk first.
I've used the sbttest utility that comes with Oracle to test the MML integration several times. Using sbttest is quick and easy and once it works then your tape backup scripts should work. I used to test the RMAN-to-disk technique first but now I find it unnecessary with sbttest. I also have a parameter driven script which I can toggle between tape and disk backups without modification. I find this quite handy. I can use the same script on lots of machines and I don't have to roll out new scripts for each RMAN implementation.

Steve Orr
It's a beautiful day in Bozeman, Montana...

-----Original Message-----
Sent: Monday, June 03, 2002 1:49 PM
To: Multiple recipients of list ORACLE-L

I have compiled a list of 'rman configuration recommendations' that I have based my RMAN deployment on.
I am sending this out to the list for general discussion. If you have anything to add let me know - I am learning as I go.

PS : Either CC me on all question responses or I will get back to you on Tuesday - I am currently in Oracle-L digest mode.

THANKS


Configuration Recommendation 1

Use BACKSETS instead of IMAGE COPIES.

PROS
BackupSets can be written to tape or disk. ImageCopies can only be written to disk.
BackupSets only backup used Oracle blocks. ImageCopies backup all blocks (used or unused).
BackupSets can use incremental backups. ImageCopies are always full database backups.

Both perform logical and physical block checking. With BackupSets logical and physical block checking is always performed. With ImageCopies you need to include the CHECK LOGIC option in the COPY command in order to detect logical corruption

CONS
Backupsets requires RMAN for recovery - backups are stored in an Oracle proprietary format.

Configuration Recommendation 2
Like everything else : Keep it simple!
Don't over complicate your backup and recovery strategy. If you can get away with it perform a FULL backup nightly. Don't get into incrementals unless the database dictates that it is required.

Configuration Recommendation 3
Use FULL instead of INCREMENTAL level 0 if you are not using an INCREMENTAL strategy.
A INCREMENTAL level 0 is identical to the FULL but it writes additional incremental info to the backup database set. Therefore if you are not using INCREMENTAL backups use the FULL - this way you are not writing unnecessary information to the RMAN dictionary.

Configuration Recommendation 4
Resync RMAN-Catalog and the Target-Database-Control-File at least once per day. I actually resync hourly.

Configuration Recommendation 5
As part of our backup schedule, perform an RMAN "restore database validate;" after each backup. This reads all of the files required to restore the database, and does everything except apply the data to disk. This is a major sanity check.

Configuration Recommendation 6
If you plan on routing your backups directly to tape - take one step back and begin by configuring RMAN to backup to disk first. Thus you will eliminate the (major) problems associated with configuring the tape interface. Once you have RMAN up and running on disk then implement the tape interface. ie; Don't bite off to much at a time.

Configuration Recommendation 7
Monitor the target database's alert.log for any ORA- error messages. Any corrupt blocks found during a backup are reported in the alert.log - therefore you want to know as soon as possible if there is a problem with your backup.



 Patrick J. Howe
 Oracle DBA
 VeriSign, Inc.
 4501 Intelco Loop SE
 Olympia, WA 98507
 Email : phowe_at_verisign.com
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Orr, Steve
  INET: sorr_at_rightnow.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
Received on Mon Jun 03 2002 - 15:53:53 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US