| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: RMAN implementation strategy
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.
dwilliams_at_lifetouch.com <mailto:dwilliams_at_lifetouch.com>
-----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
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: 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).
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: 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 Thu Sep 19 2002 - 09:28:29 CDT
 |
 |