Yechiel - Excellent point. Even better, burn the exports on a CD, making several copies. We have started doing that for special year-end reports that need to be retained for long periods of time. Much cheaper than tapes as well.
� Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> -----Original Message----- Sent: Thursday, September 19, 2002 10:54 AM To: Multiple recipients of list ORACLE-L I want to add another point. After 7 years your tapes can be unreadable. If you use exports you can periodically restore them and backup them to a new tape. Yechiel Adar Mehish ----- Original Message ----- To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> Sent: Thursday, September 19, 2002 4:28 PM Sean Yes, remember that the real reason you keep the RMAN catalog on another system is not for disaster recovery, but for normal recoveries. The worst situation is where you keep the catalog in the instance you are backing up. The second worst situation is where the recovery catalog is in a separate instance that shares some disks with the instance it is backing up. Lose a disk and you can't recover. Again, this isn't designed for disaster recovery, but for normal recoveries. I agree with Jay, the best procedure is to take an export of your RMAN catalog and FTP it to the server being backed up so it gets on the backup tape. RMAN is not the easiest to test a disaster recovery situation. The one factor that makes things easier is that even though you use a catalog, RMAN also writes its information to the control file. You can perform a disaster recovery with the control file alone. Several of us have done it. There is a parameter that controls how long the RMAN information will stay in the control file. I would suggest leaving that alone. I agree with Jay, that over a 7 year period you should consider exports as being less vulnerable to change. After 7 years, is this data still in your production database, or has it been deleted? For example, we have data that old in some of our databases, but we don't apply extraordinary measures to ensure it doesn't get deleted. For example, if a user deleted some old data, it might not be known immediately. You might consider regular audits to ensure the old data is intact. Anyway, I don't think this has anything to do with RMAN. I suppose you could maintain backup records that far back, but it would be cumbersome. One product you may want to look at is Princeton Softech Active Archiving. If I had an absolute requirement for 7 year retention, that is what I would use. RMAN is a strange product in that it works differently than you would assume and it takes awhile to get your head around how it works. A book that really helped me get started is Oracle Backup and Recovery 101. Robert Freeman who participates on this list has one coming out soon. Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> -----Original Message----- Sent: Thursday, September 19, 2002 5:08 AM To: Multiple recipients of list ORACLE-L Hi Folks, We're planning to implement RMAN as part of our B&R solution and by extenstion also as part of our DR solution. I've been trying to locate information on how best to configure RMAN across our organisation. For example it's advised you place catalog on separate server to production server. So server A might house catalog for server B and vice versa. But in a DR scenario where both servers could be destroyed there are I 'suspect' potential implementations on overall MTTR depending on configuration. Is it then perhaps better to locate all catalogs on a dedicated server which ideally would be replicated somehow to eliminate it as a singal point of failure. Also we have a requirment to be able to potentially recover data as far back as 7 years. These are currently comprised of monthly backups taken out of regular cycle and archived off site. I'm thinking it might be an idea to set up a two catalogs, one for regular monthly cycle and another to record these monthly archives as the maintenace of the catalog might be cumbersome trying to ensure the montlhy archive data records do not get accidentally deleted. I've had a trawl across the Web courtesy of Google but did not find any papers which appear to deal with these type of issues. The RMAN User's Guide and Reference does not appear to address them either. Your feedback/comments or references to papers would be much appeciated!. Oracle 7.3.3, 8.0.5, 8.1.7 NT4, W2K ------------------------- Se�n O' Neill Organon (Ireland) Ltd. [subscribed: digest mode] -------------------------------------------------------------------- This message, including attached files, may contain confidential information and is intended only for the use by the individual and/or the entity to which it is addressed. Any unauthorized use, dissemination of, or copying of the information contained herein is not allowed and may lead to irreparable harm and damage for which you may be held liable. If you receive this message in error or if it is intended for someone else please notify the sender by returning this e-mail immediately and delete the message. -------------------------------------------------------------------- -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: O'Neill, Sean INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- 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: DENNIS WILLIAMS INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- 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: Yechiel Adar INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- 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: DENNIS WILLIAMS INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- 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).
