New Rman features in 9i make it even nicer... Recover specific blocks, while the database and the datafile is still available. Automatic channel allocation. retention policies. restartable backups and restores. backing up database and archivelog files in one operation run command isn't needed in most places anymore...
Also Rman is FREE, unlike some of the other backup/recovery tools out there... :-) I do know that one major software supplier of backup and recovery tools is reworking their product so that it's just a front end to Rman.... RF Robert G. Freeman - Oracle8i OCP Oracle DBA Technical Lead CSX Midtier Database Administration The Cigarette Smoking Man: Anyone who can appease a man's conscience can take his freedom away from him. -----Original Message----- [mailto:[EMAIL PROTECTED]] Sent: Monday, March 11, 2002 11:28 PM To: Multiple recipients of list ORACLE-L 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Freeman, Robert 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).
