| 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 duplicate dbid? AND rman catalog config options
Pat - I think you've pretty well covered the pros/cons from what I
understand. I haven't implemented in production, so hopefully some people
with some experience of living with RMAN will respond. How about it guys?
One point bothered me. You didn't explicitly say that you were keeping your RMAN catalog on a system separate from the production system it is backing up. The nightmare situation is where you have only one system and you store the RMAN tablespace on the same disk as some production tables. Then the disk goes bad and you can't use RMAN to recover the tables. That is the sort of thing that has you waking up in the middle of the night in a cold sweat.
You were probably considering this, but I just thought I should bring it out explicitly.
We have gone back and forth on this issue. At first, I was going to use our test system so I could use RMAN to back up all production systems. The system administrator didn't like that idea. He preferred a valuable production resource to reside on a production system. I have put the RMAN catalog on a production system we don't plan to use RMAN to back up.
I have heard some people cross-mount their RMAN catalogs. Say you have two production systems, A and B. Put the RMAN catalog for A on system B, and the RMAN catalog for B on system A.
Oh yeah, I don't mind you mis-spelling my name, but let's just keep the gender consistent. It's Dennis, not Denise.
And have a good weekend.
Dennis Williams
DBA
Lifetouch, Inc.
dwilliams_at_lifetouch.com
-----Original Message-----
Sent: Friday, May 31, 2002 11:49 AM
To: Multiple recipients of list ORACLE-L
Bill :
I have currently been wrestling with the same issues as you are : How best
to configure RMAN.
I have put together an 'RMAN Configuration Doc' with 'PROs and CONs' from
information that I have scrapped together from this list, papers and books.
Like anything in Oracle - no one configuration is right for all situations -
you have to look at your system needs and choose the best approach.
Hopefully this paper will help you in arriving at the right configuration
for your company.
Denise :
I have incorporated your thoughts into a document I have been assembling on
RMAN configuration.
I originally was leaning towards going with OPTION1 just for the KISS law
(keep it simple stupid) - but a lot of what you said made sense and the PROs
list is growing for OPTION2.
Since I am still just playing around with the product I have the option of
going with what ever path I see fit.
All :
If anyone has anything to add - I would be glad to hear from you - this is a
work in progress.
Thanks
RMAN CATALOG CONFIGURATION OPTIONS
>From a RMAN catalog perspective we have many configuration options ;
Configuration OPTION 1
Create one RMAN database with one RMAN catalog for all the databases that
you are backing up.
IE; If you had two databases "PROD and DEV" then create one RMAN database
with one RMAN Catalog in one RMAN tablespace to manage all database recovery
info.
PROS
- Simple to setup and to Simple to understand
CONS
- When using SQL to query the RMAN catalog views you will have to isolate
the database (join db key).
- You will need to manually backup (script-backup) the RMAN database.
Configuration OPTION 2
Create one RMAN database with one RMAN catalog per database that you are
backing up.
IE: If you had two databases "PROD and DEV" then setup one RMAN database
with an RMAN-PROD catalog and an RMAN-DEV catalog in the same RMAN
tablespace to manage each database's recovery info.
PROS
- When using SQL to query the RMAN catalog views you do not have to isolate
the database (join dbkey) because in this configuration each RMAN schema
(catalog) will only contain one database.
- Along the same lines as the above point ; If you have perform RMAN Catalog
maintenance (clean out some records), it would be easier to focus on an RMAN
catalog that contains one database rather then multiple database.
- Easier to maintain the RMAN catalog if you are dropping a database - Just
drop the RMAN schema owner.
- This configuration adds a level of security by always matching the TARGET
you are on to the RMAN repository you are signing on to. ie; If you were on
TARGET PROD then you would have to signon to the RMAN-PROD schema owner.
- If you need to upgrade the target database, you can do that without
affecting the other databases. For example, if the upgrade requires a change
to the RMAN catalog schema, you can just change it for that database without
worrying about it affecting the other databases.
- If the RMAN catalog for one of your databases gets corrupted, you minimize
the damage to a single schema/target database.
- You may decide to relocate the catalog for a database to another instance
and/or host. Separate catalogs give you this flexibility.
- If you like the philosophy of a backup tape(s) containing everything you
need to recreate the system. You can run the backup to disk, export the RMAN
catalog schema and FTP it over to the target system before tape backup
starts, so everything winds up on a single tape.
CONS
- Multiple RMAN catalogs will consume more physical space (their own set of
tables) on the RMAN
database.
- You will need to manually backup (script-backup) the RMAN database.
Configuration OPTION 3
Create an RMAN database for each version of database that you are backing
up.
IE: If you had to maintain two 8.1.7 databases and three 9.1 databases then
setup a RMAN817 database and a RMAN910 database (same box) to maintain the
two different versions of Oracle databases.
PROS
- I saw this option posted on a previous discussion thread, but I was unable
to see the advantage to this configuration.
CONS
- This is not technically necessary. Lower levels of RMAN work with higher
levels of the RMAN catalog.
- You will need to manually backup (script-backup) the RMAN database.
Configuration OPTION 4
Split up your RMAN catalogs by physical location.
IE: If you maintained a west coast set of databases and an east cost set of
databases then setup a RMAN-WEST database and an RMAN-EAST database
(different RMAN boxes in two physically different locals).
PROS
- Keeping the catalogs on independent hardware prevents a single point of
failure. RMAN West can backup RMAN East and visa-versa.
CONS
- Costly (2 boxes).
-- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Pat Howe INET: phowe_at_Illuminet.com 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: 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: DENNIS WILLIAMS INET: DWILLIAMS_at_LIFETOUCH.COM 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: 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 Fri May 31 2002 - 13:11:32 CDT
 |
 |