| 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: RE : RMAN Repository
I do a cold backup of my repository daily.
Replication of it is not a bad idea, as Arup mentioned, though I haven't tried it myself.
Speaking of backing up the RMAN repository, does anyone back them up hot?
Seems to me that would not be a good idea.
Jared
"Ruth Gramolini" <rgramolini_at_tax.state.vt.us>
Sent by: root_at_fatcity.com
01/09/2003 11:04 AM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
cc:
Subject: Re: RE : RMAN Repository
The earlly versions of rman suggested that you put a 2nd recovery catalog
in one of the databases you are using the "real" recovery catalog for.
Then
you use this to record the backups of the recovery catalog database. I
never headed this advice, altho I do use a recovery catalog for all
production, developement, and test databases that I back up.
Ruth
----- Original Message -----
To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com>
Sent: Thursday, January 09, 2003 1:44 PM
RE: RE : RMAN Repository>If I need a database to backup a database then do
I
need another database to backup the database that backed up the original
database?
Exactly my thoughts.
Igor Neyman, OCP DBA
ineyman_at_perceptron.com
Yeah but do you have to pay for another Veritas NetBackup license and server to backup the catalog? If just have one database server and one database license why should I have to buy another license and install another 1-2GB of Oracle software on another server? The only answer I can think of is so Larry can spend more money on yachts, planes, and cars.
Contrary to Oracle Corporate aspirations, not all data in the universe
really needs to be stored in Oracle databases, especially backup
information
about Oracle databases I want to backup. If I need a database to backup a
database then do I need another database to backup the database that
backed
up the original database? ;-) Seems the simple solution to this silliness
is
just to remove the requirement of having a database to backup a database.
Steve Orr
-----Original Message-----
From: Jared.Still_at_radisys.com [mailto:Jared.Still_at_radisys.com]
Sent: Thursday, January 09, 2003 10:50 AM
To: ORACLE-L_at_fatcity.com
Cc: Orr, Steve
Subject: RE: RE : RMAN Repository
Importance: High
> The overhead of the repository database is more. With the initial
releases of RMAN (EBU) Oracle was rightly
> criticized for the fact that you had to backup the database that holds
information about the database you want to backup.
> Getting rid of this silliness seems reasonable to me.
Why silly?
It isn't any more silly than making a separate backup of the Veritas Netbackup catalog.
It's just a different level of abstraction.
Jared
"Orr, Steve" <sorr_at_rightnow.com>
Sent by: root_at_fatcity.com
01/09/2003 08:45 AM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
cc:
Subject: RE: RE : RMAN Repository
If you aren't using a repository all you have to do is make sure control
file backups are part of the routine. There are 2 ways to backup the
backup metadata: 1) the RMAN repository database; 2) backup
controlfiles.
Functionally and operationally they're pretty much the same. The only
things you can't do with controlfile RMAN/database metadata is: 1) use
previous "incarnations" of the database for recovery; 2) use database
stored scripts. No big deal as far as I'm concerned.
When RMAN first came out a separate repository database was a
requirement.
Subsequent releases added some functionality for using controlfiles. The
vulnerability of losing the repository or losing the backup controlfile
is
about equivalent. The overhead of the repository database is more. With
the initial releases of RMAN (EBU) Oracle was rightly criticized for the
fact that you had to backup the database that holds information about
the
database you want to backup. Getting rid of this silliness seems
reasonable to me.
Steve Orr-man for RMAN,
Bozeman, Montana
-----Original Message-----
From: Jared.Still_at_radisys.com [mailto:Jared.Still_at_radisys.com]
Sent: Wednesday, January 08, 2003 2:14 PM
To: Multiple recipients of list ORACLE-L
Subject: RE : RMAN Repository
Importance: High
And how does one go about restoring a database when all control files
are lost, and the only recovery data is stored in the control file?
This doesn't sound very reasonable.
Jared
"Deshpande, Kirti" <kirti.deshpande_at_verizon.com>
Sent by: root_at_fatcity.com
01/08/2003 11:44 AM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
cc:
Subject: RE : RMAN Repository
Joe,
-- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Ruth Gramolini INET: rgramolini_at_tax.state.vt.us 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: INET: Jared.Still_at_radisys.com 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 Jan 09 2003 - 14:30:22 CST
 |
 |