Brian, brian:

Like I said. Give me a few more hours, and you shall have your blanket
recommendation verbatim.

It's in the training documentation.

And yes, quite likely, your doctor does mean don't bother having one wart
burnt off: it's a painful and expensive procedure, and isn't worth his, her
or your time, unless the need is drastic (ie, you've got lots of them).

Be patient. The quote will come.

;-o


"Brian Peasland" <oracle_dba (AT) remove_spam (DOT) peasland.com> wrote

k.htm#442214),

At least you found some docs to back up your statements. I don't
necessarily agree with what you have quoted though. And what you have
quoted, and what you now say are not necessarily the same thing. Your
latest statement is "unless your backup requirements are complex, we
SUGGEST you run without a catalog." which is different than your
original statement of "Oracle is recommending running without a catalog
database these days". It may be semantics......


As I stated in my first post to this thread "What did 9i introduce that
does away with the benefits of a Recovery Catalog?" About the closest
one can come to answering this question is that 9i introduced the
ability to configure some more defaults like channels. But what about
storing scripts? I don't agree with your statements with regards to
stored config params "Therefore they don't need to be specified at
run-time, and therefore there is no need for long-winded scripts. One of
the major reasons for having a catalog was to permit the storage of
scripts. If scripts are no longer needed, you don't need a catalog."
This assumes that the whole reason for storing scripts was due to the
configuration parameters like channels. There are other reasons to store
scripts. It also assumes that the only benefit of the Recovery Catalog
was stored scripts.

So I ask again, what did 9i introduce that does away with the benefits
of a Recovery Catalog? How can you restore to a previous incarnation of
the database without a Recovery Catalog? What mechanism addresses this
issue? Even according to the Oracle docs, "Without a catalog, you must
first restore a control file
backup that lists the correct set of database files." Granted this is
not that difficult, but it does add one more step to restoring before
recovery. A Recovery Catalog can simplify this process. How do you list
the database schema from a previous point in time? The Recovery Catalog
can tell you this. Without a Recovery Catalog, one needs to make sure
that the CONTROL_FILE_RECORD_KEEP_TIME paramater is much greater than
the default of 7 days in order to make sure that the control file can
keep a history long enough.

There are valid reasons to use a Recovery Catalog. And, there are valid
reasons to not use a Recovery Catalog. And that's my whole point. One
needs to weigh the pros and cons of Recovery Catalogs when deciding to
use RMAN. Just like one needs to weigh the pros and cons of even using
RMAN itself, catalog or no catalog!

Cheers,
Brian



Arcangelo wrote:
--
================================================== =================

Brian Peasland
oracle_dba (AT) remove_spam (DOT) peasland.com

Remove the "remove_spam." from the email address to email me.


"I can give it to you cheap, quick, and good. Now pick two out of
the three"

Brian Peasland <oracle_dba (AT) remove_spam (DOT) peasland.com> wrote

I think it is. Suggest - Recommend. Amounts to the same thing. I
thought I'd included the reference to 'complex' backup requirements in
the first place, but I see now I didn't, and I should have. It was
certainly meant to be there.

No.. it assumes that there are rather few other benefits!

I will happily agree that if the only store for RMAN metadata is the
controlfile, there is a premium on configuring the controlfile
correctly. If you were about to put all your eggs in that particular
basket, I would certainly hope you'd thought about the
CONTROL_FILE_RECORD_KEEP_TIME.

But I won't sign up to the idea that setting a database back to a
previous incarnation is a compelling argument for a catalog. How many
times do you actually do that a year??! Is it utterly impossible to
do without a catalog? No. So on those rare occasions when you need to
do something like that, a bit of extra hassle is probably worth it, if
in the mean time it's saved you another database, another set of
backup and recovery concerns, another splurge of disk space and memory
requirements and so on. I would have thought.

To answer your specific question ('what did 9i introduce'), the
controlfile autobackup, which embeds a controlfile backup in each
backup piece is specifically designed to address the problem of
needing to supply old controlfiles for these sorts of scenarios.

I never meant to suggest there weren't (but as I also mentioned above,
the qualification of 'unless your requirements are complex' was in my
head but not typed, so I accept I may have given that impression).

Goes without saying. Oracle recommends all sorts of things I wouldn't
want to see near any of my databases. But everything depends, of
course.

But the 'suggestion' is still there in print. Which is all I meant to
imply.

So we agree and can put the matter to rest.

;-)