Pat & others, For your information something that I hope is helpful.
To add a point we discovered the hard way - RMAN doesn't so much backup blocks containing data but rather it backs up blocks that have ever contained data. To quote from Metalink note 105208.1: "RMAN will not back up NEVER USED blocks, but will back up blocks that were used once, even if they are not in use now." This can be a problem if you're not using uniform extent sizes and you temporarily get (say) large indexes. In our case we worked around this at the time by rebuilding indexes to a new tablespace, resizing the original tablespace to a smaller value and then moving them back. Our longer term "fix" has been to move to LMTs with uniform extent sizes. Regards, Bruce Reardon -----Original Message----- Sent: Friday, 8 March 2002 9:32 Bill ; I am just in the process of implementing RMAN at our shop. We decided to go with RMAN for the following reasons : * Reason1 RMAN manages what backups are required to perform the restore and where the backup are located (will get the files off tape). * Reason 2 The ability to perform HOT backups without the "ALTER TABLESPACE ..BEGIN/END" commands. This will reduce the amount of REDO that is generated during the backup. IE: You get HOT backups with out the adverse impact of the volume of redo. Since a datafile does not have to be placed in backup mode - there is no risk of the database going down during a hot backup and asking for media recovery. * Reason 3 The ability to only backup "used" Oracle blocks. This greatly reduces the amount of data that needs to be backed up. BACKUP SETS - Will only copy database blocks containing data. This saves on IO by not copying empty blocks. * Reason 4 The ability to detect database block corruption. Because RMAN uses Server Processes to perform its backup reads - it will raise the same error a SQL statement will raise upon detection of something amiss inside a database block. * Reason 5 The ability to perform incremental backups and restores. This greatly reduces the amount of data that needs to be backed up (block level backups). LEVEL 0 - Will copy all database blocks containing data (FULL). This saves on IO by not copying empty blocks. LEVEL 1 - Will copy database blocks that have changed since the most recent level0 bkup. This further reduces IO. LEVEL 2 - Will copy database blocks that have changed since the most recent level1 bkup. This further reduces IO. * Reason 6 A Enterprise Centralized Backup and Recovery solution. _________________________ Patrick J. Howe Oracle DBA Illuminet Inc. (Carrier Division of Verisign) 4501 Intelco Loop SE Olympia, WA 98507 Email : [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Reardon, Bruce (CALBBAY) 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).
