Recovery Catalog vs Control File
ex...@chicagorsvp.com
I've read a lot about this concept, Recovery Catalog vs Control File.
I'm just looking for some real life experience comments.
I've always thought that using a recovery catalog only gives you yet
another instance to back up.
What are some of your experiences.......it'd help me make my
decision. Reading is not the same as getting real life comments......
Mark D Powell
If you have a single database (or maybe just two) I see no reason to
have a recovery catalog. As long as you backup the control file as
part of you backup set then in the event you lose the control file you
first recovery it then perform a recovery using a backup control
file. RMAN/Oracle will handle the rest.
A recovery catalog only provides two advantages over using the control
file. One is the ability to save scripts but you can save your
scripts in a directory and make sure that directory is part of the OS
level backups. I forget the other advantage as I do not consider
whatever it is as being that important or useful.
With multiple databases I can see the recovery catalog as potentially
being more beneficial as it can give you one place to look to check on
the status of your backups.
But unless you can place the recovery catalog on a different server
than your production databases you could end up in a situation where
you cannot start recovery of any of your databases till you restore
the recovery catalog database.
HTH -- Mark D Powell --
sybr...@hccnet.nl
The problem with your question is it doesn't mention the database
version you are using.
RMAN has been revised with every release of Oracle, amongst others
making the recovery catalog more and more optional.
If you are on 9i, you will need a recovery catalog to recover your
database through a resetlogs operation.
This is becaused all history in a controlfile is virtually wiped out
during a resetlogs and you don't have any info on the SCN of the last
resetlogs.
On 10g this is no longer required, as you can include the resetlogs
scn in the file specification of your archivelog.
So the key factor in answering this question is:
- What operations *require* a recovery catalog
- Am I planning to use those operations frequently.
Hth
--
Sybrand Bakker
Senior Oracle DBA
ex...@chicagorsvp.com
Always forget to include that. We are on 10g release 2.
From what I hear, as we have 1 database on this server, the control
file makes more sense.......
hpuxrac
Before 9i if you were using rman ( it was pretty darn unstable at best
in the 8x days anyways ) you pretty much had to use a recovery
catalog.
At 9i level it became somewhat more optional ( having a recovery
catalog or not ).
At 10g and above the recovery catalog concept may not make a lot of
sense unless you have a whole bunch of databases to manage ( whatever
a whole bunch means mileage may vary ) ...
That's my short summary.
There's a bunch of synchronization work needed at times in terms of
levels of the recovery catalog and levels of the databases you are
backing up and levels of the software to do the rman backups if you do
go the recovery catalog way.
joel garry
Mostly agree with this, except if you have some reason to need an old
archive log, it is quite a pain to do it without a catalog in 9i.
Those situations are (or should be!) very infrequent, but kind of
argues that infrequent operations mean you should use a catalog. I
was on the nocatalog side until I had to go through that for real,
wishing I had a catalog.
The OP says 10g now. The more I look at it the less sure I am about
which way I want to go with the catalog. I'll have a standby machine
eventually. I'm not convinced the default backup has enough
redundancy for my tastes.
jg
--
@home.com is bogus.
"just look at the bright side, at least she'll be able to teach us to
fish and hunt for our own food...after McCain sends our nation's
economy and markets into a sinkhole." - sdsane
ex...@chicagorsvp.com
What does this mean, and what is the purpose of the different control
file backup methods?
The RMAN behavior when the BACKUP command includes datafile 1 depends
on the CONFIGURE CONTROLFILE AUTOBACKUP setting. If control file
autobackups are ON and the backup includes datafile 1, RMAN writes the
control file and SPFILE to a separate autobackup backup set. If
control file autobackups are OFF and the backup includes datafile 1,
then RMAN includes the current control file and SPFILE in the same
backup set as the datafiles.
Palooka
PMFJI. I am being challenged on this, so would also be glad of comments.
IMHO, in an enterprise scenario, there is one big advantage to using a
recovery catalog (on a separate dedicated server of course):
It facilitates centralised monitoring/reporting of multiple database
backups on umpteen different instances on various boxes.
Another advantage is that backup information is retained far longer: If
I need to restore a backup from eight months ago to rerun some
year-end report or to satisfy the auditors, it is easy. Try that with
CONTROLFILE_RECORD_KEEP_TIME!
Palooka
hpuxrac
snip
> What does this mean, and what is the purpose of the different control
> file backup methods?
>
> The RMAN behavior when the BACKUP command includes datafile 1 depends
> on the CONFIGURE CONTROLFILE AUTOBACKUP setting. If control file
> autobackups are ON and the backup includes datafile 1, RMAN writes the
> control file and SPFILE to a separate autobackup backup set. If
> control file autobackups are OFF and the backup includes datafile 1,
> then RMAN includes the current control file and SPFILE in the same
> backup set as the datafiles.
Well it means what it says. Just read it a couple more times.
Just set it ON and leave it ON.
Data file 1 is the SYSTEM tablespace. In other words whenever you are
doing a backup that includes the SYSTEM tablespace you also get a
backup of the control file and the spfile ( if you are using an
spfile ).
The purpose of having it in a different backupset versus the same one
is for the most part not a big thing to worry about.
For normal sized databases ... backup the whole database at the same
time please.
sybr...@hccnet.nl
The controlfile autobackup is stored in a file including the dbid of
the database, the date in the format yyyymmdd and a piece number.
It can be restored seperately and it pretty much replaces the ...
recovery catalog.
If you know the dbid and controlfile autobackup is on, you can always
restore the database.
hpuxrac
snip
> The controlfile autobackup is stored in a file including the dbid of
> the database, the date in the format yyyymmdd and a piece number.
> It can be restored seperately and it pretty much replaces the ...
> recovery catalog.
>
> If you know the dbid and controlfile autobackup is on, you can always
> restore the database.
Probably trying to say you should always record or have available your
database id. With that knowledge and being able to identify the tape/
media ( perhaps from logs from your tape/media backup system or from
rman output ) that a controlfile backup is stored on ... you can
restore the database.
You might have to restore the control file first (not usually ) then
do the database restore.
sybr...@hccnet.nl
Not quite.
If you don't have a recovery catalog and you don't have autobackup
controlfile on, and you lost all your controlfiles, how does RMAN know
which controlfile to restore?
Apart from that: is this the controlfile containing the correct backup
info?
So controlfile autobackup comes in.
It has a fixed filename format (the %F modifier is mandatory)
and using
set dbid .....
and
restore controlfile from autobackup
using several other parameters it will go back until it finds a viable
backup. So this doesn't need to be the most recent.
This is why I consider the controlfile autobackup to function as a
replacement for the recovery catalog.