I was on vacation last week.

 

Our DBA solved the problem she was having here.

 

It was the incorrect values for variable NB_ORA_CLIENT in the crosscheck
script which used the real hostname instead of the backup LAN hostname
which the backup/restore scripts use.

 

For most of our hosts we have a separate backup LAN.   To distinguish
path over the backup LAN as opposed to the primary LAN we typically
suffix the hostname with a "b".  So if we had a server named tiger (used
for primary LAN) we would do backups/restores using tigerb (backup LAN).
In her issue the crosscheck script had "tiger" and when she changed it
to "tigerb" which is what was in the backup/restore scripts then it
worked properly.

 

 

________________________________

From: veritas-bu-boun...@mailman.eng.auburn.edu
[mailto:veritas-bu-boun...@mailman.eng.auburn.edu] On Behalf Of Jared
Still
Sent: Tuesday, May 25, 2010 8:32 PM
To: Dean
Cc: veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] RMAN crosscheck

 

On Tue, May 25, 2010 at 4:54 PM, Dean <dean.de...@gmail.com> wrote:

Are you sure RMAN actually knows about the tape an image is on? If it
does, that is just silly. It should just ask for a backupid, then NBU
will give it the correct tape, regardless of whether it's a duped or
vault copy or whatever. I've always been sure that that's the way it
worked (Although, I'm not a DBA and don't know that much about RMAN). 

 

I think you're right, it just keeps the Media ID.

It's been a few months since I have looked closely at it.

 

Regarding vaulted tapes:  RMAN will not know that a tape has been
vaulted,

so it will have the wrong media ID for requesting the tape.

 

If the tapes are restored into the NBU catalog, RMAN will then ask for
the 

correct backup pieces by name.

 

This not an issue with RMAN, as the API has that capability, at least 

according to the docs.

 

It just has not been implemented by Veritas.

 

This would bear further investigation, as that situation may have
changed 

since I last looked into it.

 

        Does RMAN also track disk STUs? I know in our environment, we
write all our Oracle archive log backups to a DSSU, then they get moved
out to tape and deleted from the DSSU within a day or so. We restore
regularly (to development), and it always works fine, regardless of
whether the archive log backups are still on disk or have been moved to
tape. Does that mean RMAN is aware of the destage process? I highly
doubt it.

 

There is a way for RMAN in later version to track backups that are
staged to disk and

then backed up on to tape.

 

I have never used it, and don't know any details about it.

 

Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist
Oracle Blog: http://jkstill.blogspot.com
Home Page: http://jaredstill.com
 
Proud partner. Susan G. Komen for the Cure.
 
Please consider our environment before printing this e-mail or attachments.
----------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential 
information and is for the sole use of the intended recipient(s). If you are 
not the intended recipient, any disclosure, copying, distribution, or use of 
the contents of this information is prohibited and may be unlawful. If you have 
received this electronic transmission in error, please reply immediately to the 
sender that you have received the message in error, and delete it. Thank you.
----------------------------------
_______________________________________________
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Reply via email to