Re: RMAN sample script for Linux

Brian Peasland <oracle_dba_at_remove_spam.peasland.com> wrote in message news:<3EFA1921.41DA811A_at_remove_spam.peasland.com>...
> 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......

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.

>
> 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.

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

>
> 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.

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.

>
> There are valid reasons to use a Recovery Catalog.

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).

>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!

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.

;-)

>
> Cheers,
> Brian
>
>
>
> Arcangelo wrote:
> >
> > Actually, Brian, I found the reference rather quicker than expected.
> >
> > 9i New Features, chapter 4, page 59 :
> >
> > "All that is necessary to use RMAN is start the RMAN executable and connect
> > to the target database. If neither CATALOG or NOCATALOG is specified, then
> > RMAN automatically begins using the control file as the backup repository.
> > Actually, NOCATALOG mode is suggested now unless your backup needs are
> > extremely complex".
> >
> > OK, they use the word 'suggested' rather than 'recommended'.
> >
> > But that last sentence is pretty unambiguous: unless your backup
> > requirements are complex, we SUGGEST you run without a catalog.
> >
> > Together with the phrase I quoted before, "Hence, unless you manage a
> > network of databases, you may choose to avoid the overhead and use the
> > control file as the exclusive repository of metadata", I think the nature of
> > their general 'suggestion' is pretty clear.
> >
> > ;-)
> >
> > "Brian Peasland" <oracle_dba_at_remove_spam.peasland.com> wrote in message
> > news:3EF9B2FC.3ABC2079_at_remove_spam.peasland.com...
> > > > "In general, Oracle Corporation advises using a catalog when you manage
> > > > multiple databases."
> > > >
> > > > Which can also be read to mean 'we don't advise it for a single
> database'.
> > >
> > > I don't read it that way at all. That's your interpretation of the
> > > sentence. Let me give you a counter example.....A doctor tells you that
> > > if you have multiple warts, you should get them burned off. Does this
> > > mean that if you have a single wart, you should not get it burned off?
> > > Or, using a more mathematical approach, "A implies B" does not equate to
> > > "NOT A implies NOT B". In fact, is it highly possible that "NOT A
> > > implies B".
> > >
> > > > And then, later, explicity they say:
> > > >
> > > > "Hence, unless you manage a network of databases, you may choose to
> avoid
> > > > the overhead and use the control file as the exclusive repository of
> > > > metadata"
> > >
> > > Notice that your exact quote includes "...you *may* choose...". It does
> > > not say something like "...we recommend...". Even if you manage a
> > > network of databases, you may choose to avoid the overhead and use the
> > > control files as the exclusive repositories of metadata.
> > >
> > > I really doubt that you will find any documentation that matches your
> > > blanket statement, "And, since this is 9i RMAN, Oracle is recommending
> > > running without a catalog database these days". Whether or not you use a
> > > Recovery Catalog is dictated by many factors. As can be seen from the 9i
> > > documentation
> > >
> > (http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96566/rcmquic
> > k.htm#442214),
> > > they include a section titled "Deciding Whether to Use RMAN with a
> > > Recovery Catalog". If your statement was true, then this section would
> > > be very short and say that they don't recommend using a Recovery
> > > Catalog. Instead, this section goes into detail on when it is a good
> > > idea to use a Recovery Catalog.
> > >
> > > [quote from the docs]
> > > Benefits of Using the Recovery Catalog as the RMAN Repository
> > > When you use a recovery catalog, RMAN can perform a wider variety of
> > > automated backup and recovery functions than when you use the control
> > > file in the target database as the sole repository of metadata. The
> > > following features are available only with a catalog:
> > >
> > > You can store metadata about multiple target databases in a single
> > > catalog.
> > > You can store metadata about multiple incarnations of a single target
> > > database in the catalog. Hence, you can restore backups from any
> > > incarnation.
> > > Resynchronizing the recovery catalog at intervals less than the
> > > CONTROL_FILE_RECORD_KEEP_TIME setting, you can keep historical metadata.
> > > You can report the target database schema at a noncurrent time.
> > > You can store RMAN scripts in the recovery catalog.
> > > When restoring and recovering to a time when the database files that
> > > exist in the database are different from the files recorded in the
> > > mounted control file, the recovery catalog specifies which files that
> > > are needed. Without a catalog, you must first restore a control file
> > > backup that lists the correct set of database files.
> > > If the control file is lost and must be restored from backup, and if
> > > persistent configurations have been made to automate the tape channel
> > > allocation, these configurations are still available when the database
> > > is not mounted.
> > > [/quote from the docs]
> > >
> > > The docs go further to say
> > >
> > > [quote from the docs]
> > > When you use a control file as the RMAN repository, RMAN still functions
> > > effectively. If you do not use a catalog, read the section "Managing the
> > > RMAN Repository Without a Recovery Catalog". Specifically, make sure
> > > you:
> > >
> > > Consider the costs of not using a recovery catalog, as described in
> > > "Understanding Catalog-Only Command Restrictions"
> > > Develop a strategy for backing up the repository, as described in
> > > "Backing Up and Restoring the Control File"
> > > [/quote from the docs]
> > >
> > >
> > >
> > > The way I read the docs, it sounds to me like using a Recovery Catalog
> > > has its pros and cons and the DBA should be weigh each when making their
> > > configuration decisions. Blanket statements like "And, since this is 9i
> > > RMAN, Oracle is recommending running without a catalog database these
> > > days" are simply not true.
> > >
> > > Cheers,
> > > Brian
> > >
> > > --
> > > ===================================================================
> > >
> > > Brian Peasland
> > > oracle_dba_at_remove_spam.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.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"
Received on Thu Jun 26 2003 - 01:05:40 CDT