Yes I just went through my backup scripts and changed them to only connect to catalog and resync after a backup completes. One too many backups failing because of a network hiccup to the catalog (one is too many). So my backups can run as scheduled if it goes down. The resync would fail obviously but the next resync would catch it up. We also have a dataguard setup so there is some extra value in having the catalog there, as well as doing any sort of non-active duplication. But for the most part I don't like depending on the catalog as just my personal preference. But there are times when it has been nice to get the history. On Tue, Dec 10, 2013 at 4:13 PM, Andy Klock <andy@xxxxxxxxxxxxxxx> wrote: > This is a good thread. What I don't like about catalogs is that your > production backups may rely on some other database to be up for the > duration of the backup. > > However, there are some other nice benefits to them apart from > recoverability. To answer questions like, how long do my backups > take?How long did they take 6 months ago? Are we generating more redo > then before? When did the #$@!# backup schedule change? Stuff like > that which can be nice sometimes. > > Andy > > On Tue, Dec 10, 2013 at 4:42 PM, Norman Dunbar <oracle@xxxxxxxxxxxxxxx> > wrote: > > Hey Rich, > > > > Just wondering. Given that you have "all" that work to do recatalogging > when > > you have to do a restore and recovery, that's what you would be doing if > > your catalog was a SPOF and was lost, surely? > > > > I know you'd have some details in the control file, and could recatalog > the > > remainder, but i would tend to disagree that the catalog is actually a > SPOF. > > > > Your mileage, as they say, may vary. > > > > I hadn't used a catalog until recently, but I can see how useful one can > be, > > in addition to whatever is stored away in the control files. But I > obviously > > cannot speak for everyone. > > > > Cheers, > > Norm. > > > -- > //www.freelists.org/webpage/oracle-l > > > -- Don Seiler http://www.seiler.us