SEO

Intermittently our RMAN full backup fails to a remote network share.

Oracle 8.1.7.4.1 Target DB, 8.1.7.4.1 Catalog (and 8.1.7.4.1 RMAN
executable) - all on MS Windows.

The following is the error in the RMAN log:

RMAN-00571: ================================================== =========
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS
===============
RMAN-00571: ================================================== =========
RMAN-03007: retryable error occurred during execution of command:
backup
RMAN-07004: unhandled exception during command execution on channel d1
RMAN-10035: exception raised in RPC: ORA-19504: failed to create file
"r:\HR83PRD\HR83PRD_DB_l4fpk3cv_1_1.bak"
ORA-27044: unable to write the header block of file
OSD-04008: WriteFile() failure, unable to write to file
O/S-Error: (OS 64) The specified network name is no longer available.
RMAN-10031: ORA-19624 occurred during call to
DBMS_BACKUP_RESTORE.BACKUPPIECECREATE

Recovery Manager complete.

Metalink has very few hits on this message, probably because it is
actaully an OS error rather than an RMAN error.

However I did see one recommendation that setting DISABLE_OOB to ON in
the client side sqlnet.ora can help in this scenario.

This would mean changing this parameter on the PROD DB server...

Anyone know of any issues with disabling out of band breaks (either
performance or Dead Connection Detection related).

Metalink was also pretty vague on this parameter as was the Net 8
Admin Guide.

Thanks in advance.

Matt

On 30 Jun 2004 04:08:50 -0700, mccmx@hotmail.com (Matt) wrote:

>Metalink has very few hits on this message, probably because it is
>actaully an OS error rather than an RMAN error.

Metalink has very few hits, because Oracle doesn't support writing to
a networked drive. Not on Windows, not on Unix.
This means you will be pretty much on your own, if you proceed.


--
Sybrand Bakker, Senior Oracle DBA

> >Metalink has very few hits on this message, probably because it is
> >actaully an OS error rather than an RMAN error.
>
> Metalink has very few hits, because Oracle doesn't support writing to
> a networked drive. Not on Windows, not on Unix.
> This means you will be pretty much on your own, if you proceed.

True.. But I've been running on this config for over 2 years with no
problems. I have done hundreds of clones with RMAN duplicate commands
and the backups have proved to be OK. I think the network failure is
due to the increase in the size of our database.

I have tried the DISABLE_OOB parameter (it is a client side setting)
and I haven't had a failure since.

I can understand Metalink being vague about RMAN remote backups but I
expected to see some info on DISABLE_OOB (but there is very littel
anywhere).

Thanks for the feedback.

Matt

mccmx@hotmail.com (Matt) wrote in message news:<cfee5bcf.0406302321.6f653e94@posting.google. com>...
> > >Metalink has very few hits on this message, probably because it is
> > >actaully an OS error rather than an RMAN error.
> >
> > Metalink has very few hits, because Oracle doesn't support writing to
> > a networked drive. Not on Windows, not on Unix.
> > This means you will be pretty much on your own, if you proceed.
>
> True.. But I've been running on this config for over 2 years with no
> problems. I have done hundreds of clones with RMAN duplicate commands
> and the backups have proved to be OK. I think the network failure is
> due to the increase in the size of our database.
>
> I have tried the DISABLE_OOB parameter (it is a client side setting)
> and I haven't had a failure since.
>
> I can understand Metalink being vague about RMAN remote backups but I
> expected to see some info on DISABLE_OOB (but there is very littel
> anywhere).

This is wild speculation, but I've seen similar scaling problems with
other network configurations. I think something similar to
http://metalink.oracle.com/metalink/... p_id=68059.1
is happening, that is, at some point the protocol is sending
out-of-band udm and the receiving end is not handling it correctly.
So setting DISABLE_OOB overrides the problem. But you don't want to
disable oob in case something in the data looks just like udm when the
network starts garbaging.

Using unsupportable backup procedures is not a very good idea.

>
> Thanks for the feedback.
>
> Matt

jg
--
@home.com is bogus. The circuit board of Genie garage door openers
have a failure mode where the door opens at a random time, ignores the
stop switch, jams the door open so hard the emergency release becomes
unworkable, then blows the internal circuit breaker. So much for
rolling security codes.

> This is wild speculation, but I've seen similar scaling problems with
> other network configurations. I think something similar to
> http://metalink.oracle.com/metalink/... p_id=68059.1
> is happening, that is, at some point the protocol is sending
> out-of-band udm and the receiving end is not handling it correctly.
> So setting DISABLE_OOB overrides the problem. But you don't want to
> disable oob in case something in the data looks just like udm when the
> network starts garbaging.
>
> Using unsupportable backup procedures is not a very good idea.

I guess the underlying issue is the fact that I am backing up to a
network drive and at the end of the day if I encounter problems then
Oracle will offer little help since it is unsupported.

The problem is that the way we have it configured means that I can
clone the PROD database to any other server which has access to my
network share without having to copy the backup sets locally first.
Since we are cloning the database nearly every day this is a big
saving for us.

I think I will take you advice and not use the DISABLE_OOB parameter
and instead look at why the backups have been failing more often
recently...

I suspect that keeping the datafiles smaller than 2 Gb each may help
the situation.

Matt