Re: RMAN sample script for Linux

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:
>
> 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"