> 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  : [EMAIL PROTECTED]  

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Orr, Steve
  INET: [EMAIL PROTECTED]

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: [EMAIL PROTECTED] (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).

Reply via email to