Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: RMAN and two LOG_ARCHIVE_DEST_<n>

Re: RMAN and two LOG_ARCHIVE_DEST_<n>

From: Howard J. Rogers <howardjr2000_at_yahoo.com.au>
Date: Mon, 2 Dec 2002 18:50:39 +1100
Message-ID: <D8EG9.88325$g9.248191@newsfeeds.bigpond.com>

"s.kapitza" <skapitza_at_volcanomail.com> wrote in message news:26703915.0212012344.6e61b2d_at_posting.google.com...
> Hi howard,
>
> i'm a little bit irritated (to take it bluntly:)
>

Lighten up a bit, then.

> what do you mean by "not working".
>
> (as i'm a newby DBA this makes me nervous)
>
> I'm using rman (8.1.7) on w$dows2k (with legato).
> the only thing i found was, that using
> the default name for the archives doesn't work if
> the instance names are different.
>
> Could you shed some light on "not working" ?

I think you just have.

Sybrand's posted a script that works. Sort of. The point I was trying to make was that you have to be instance-aware when using RMAN. You have to have convoluted scripts that make specific connections to specific instances and make specific requests to back up specific files. All of which is, I guess fine, if the configuration of your cluster doesn't change from one year to the next. Add another node, however, and all your RMAN scripts are toast.

Regards
HJR
>
> regards
>
> s.kapitza
>
> "Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in message
news:<IJsG9.87856$g9.247249_at_newsfeeds.bigpond.com>...
> > Marc,
> >
> > To put it bluntly: RMAN doesn't work in a Parallel Server environment.
> >
> > Full stop. Period.
> >
> > You're doing nothing wrong, but merely encountering the reason why an
> > upgrade to 9i would be recommended, because in 9i, RMAN works perfectly
with
> > RAC.
> >
> > I know, I know... that's out of the question. In which case: get another
> > backup strategy, 'cos RMAN isn't reliable in OPS.
> >
> > Regards
> > HJR
> >
> > "Marc Blum" <marc_at_marcblum.de> wrote in message
> > news:pspjuukohpbcc3qv6pd2dffouuvcvsq33n_at_4ax.com...
> > > Hi everybody,
> > >
> > > situation:
> > > Oracle Parallel Server 8.1.6 (test, produktion will be 8.1.7, I have
no
> > > possibility to upgrade the test DBs)
> > >
> > > each instance archives into LOG_ARCHIVE_DEST_1 and LOG_ARCHIVE_DEST_2
on
> > shared
> > > directories, so I have two complete sets of archived redologs
> > >
> > > backups are performed with RMAN and catalog db, media manager is
Legato
> > > Networker
> > >
> > >
> > > requierement:
> > > two separate RMANs, each with it's own Catalog DB, backup one distinct
set
> > of
> > > archived redologs on tape
> > >
> > >
> > > problem:
> > > the option DELETE INPUT within BACKUP raises this behaviour:
> > >
> > > - instance 1 generates arcs a, b, c
> > >
> > > - instance 2 generates arcs 1, 2, 3
> > >
> > > - LOG_ARCHIVE_DEST_1 contains: 1,2,3,a,b,c
> > >
> > > - LOG_ARCHIVE_DEST_2 cantains: 1,2,3,a,b,c
> > >
> > > - RMAN1 backupos ars with DELETE INPUT, one copy of the arcs is
deleted,
> > > everythings fine!
> > >
> > > - LOG_ARCHIVE_DEST_1 now contains: 1,2,3
> > >
> > > - LOG_ARCHIVE_DEST_2 now contains: a,b,c
> > >
> > > - RMAN1 backups again with DELETE INPUT, now the remaining set of arcs
is
> > > written to tape and deleted
> > >
> > > - LOG_ARCHIVE_DEST_1 now contains:
> > >
> > > - LOG_ARCHIVE_DEST_2 now contains:
> > >
> > > - RMAN2 is unable to backup his arcs!
> > >
> > >
> > > question:
> > > why doesn't RMAN1 recognise the already backuped arcs? Is it a bug or
> > well-known
> > > behaviour?
> > >
> > > many thanks in advance
> > >
> > >
> > > (I found a workaround by opening two channels and assigning each
channel
> > to a
> > > distinct LOG_ARCHIVE_DEST_<n>, but I would prefer a solution, where I
> > don't have
> > > to tell RMAN the LOG_ARCHIVE_DEST explicitely)
> > >
> > >
> > > Marc Blum
> > > mailto:marc_at_marcblum.de
> > > http://www.marcblum.de
Received on Mon Dec 02 2002 - 01:50:39 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US