Re: can not identify file when Rman duplicate standby database

Jesse wrote:
> Be nice now... ;-) Having just gone through this, I can understand
> Yoke's confusion, even if he had read the manual (he doesn't state
> whether or not he has, but given the detail of his post, he must have
> read something). As Holger's quote from the manual states, "make sure
> that all backups...are remotely accessible from the duplicate host."
> This leads me to believe that simply mapping/mounting the drive/path
> from the duplicate would be sufficient (i.e. make backup path look the
> same as it does on target DB). This isn't always the case.

Well, the backdoor for the ones writing the documentation clearly is that making the backups accessible doesn't mean that you make it look like it's accessible, but to make it accessible ;-)
>
> I know that Yoke isn't using Windows for his target DB, but we do
> (Win2k3 Server EE) and trying to duplicate using a mapped drive (on our
> target DB, the backups are stored on R:\....) fails in RMAN (similar
> message to what Yoke received; i.e. couldn't find file). Instead it
> requires that you change the RMAN config for the target DB to use UNC
> paths instead of drive letters. This is only necessary if you use a

Plus IIRC the Oracle Service for the instance will need to be an account that has access to an UNC path, in other words something different than LocalSystem. Oh yeah, I've burned my fingers on that, too.

> remote drive though (meaning, remote to the duplicate host). I was
> able to get around this by installing a second HD on the duplicate
> node, assigning it R:, and copying the backup sets (and archive logs)
> as needed to the duplicate node's R: drive. Note: This was preferable
> over changing the RMAN config for the target DB for two reasons.
> First, the target DB was in production and we were just setting up a
> duplicate node for development/testing (couldn't afford the restart).
> Second, UNC can often-times be slower than using drive letters in
> Windows. Anyway, I have various scripts/jobs running to copy and
> cleanup the backup sets as needed.
>
> Again, I know Yoke isn't using Windows for his target DB, but my point
> is that there are often undocumented "features" that may cause
> unexpected results (even when you believe that you've
> understood/followed the docs). In short, copying the files to standby
> node may be his best bet (it''ll work easiest if he can mimic the path
> used by the target DB).
>
> Jesse
>

Believe me, if Yoke's post had included an effort to show that he has read the manual and wasn't sure on how to go on or if he had used Windows my answer would have been much more understanding. But he hadn't, so it wasn't.

You know what my first thought was? How the hell can he come up with all the steps to create an auxiliary database, set up a catalog, have automatic channel allocation configured etc. but miss the easiest step (his question actually was: " Must I copy the backup file from primary node to standby node manually?"). If you've come sofar, it really isn't hard to try that one for yourself, especially if you suspect what might be the cause. And if you don't want to try it because, say you don't want to copy several hundred GB in vain, then it really is time to read the manual. So I'm back to my first conclusion. What Yoke missed was reading the manual.

Sorry.

Holger

PS: And where would this NG go if there wasn't the regular ReadTheFineManual thrown at people asking questions (that are answered there)? ;-) Received on Wed Apr 13 2005 - 02:04:47 CDT