We've had an open TAR on a corrupt archive logs on dataguard issue with
Oracle for two years. The last update to the TAR just a week ago said
that Oracle development could reproduce and solve the problem by setting
filesystemio_options = setall or directio instead of asynch. Only
problem with that is you must create ALL of your original data files
with directio in the first place, so we are stuck.

The problems we see are much more subtle, just a message about a corrupt
log on the standby. The standby eventually recovers, but the result is
that many archive logs must be shipped to the standby multiple times.
That just makes things worse and slower. At one point we could reproduce
on test equipment 100% of the time. We were clobbered with this issue
after an SLES8 kernel upgrade and an Oracle upgrade so we stopped
upgrading.

We have given up trying to solve the issue and we'll stick with what
we've got until our next hardware refresh as we have reached an
"understanding" with our hardware and software combinations. Sad really.

Best of luck solving this issue.

Andy

> -----Original Message-----
> From: Alexei_Roudnev [mailto:Alexei_Roudnev@(protected)]
> Sent: Monday, April 16, 2007 10:25 PM
> To: suse-oracle@(protected)
> Cc: Arun Singh
> Subject: Re: [suse-oracle] Strange error on log transport /
> data guard, SLES10
>
> I tested connection - works pretty well, FTP speed is
> 35MB/second in both
> directions (then limited by the File System).
>
> It can be UL4.4 problem (on receiving side), but it looks
> more likely as
> Async IO problem in SLES10 - Oracle 10.2.0.3 uses
> async io when sending logs in SYNC mode (I run MAx
> Availiability mode + Fast
> Failover in the lab), and somethinh runs out of the limits.
>
> Will retest on SLES9 <->SLES9 in a short time.
>
snip

--
To unsubscribe, email: suse-oracle-unsubscribe@(protected)
For additional commands, email: suse-oracle-help@(protected)
Please see http://www.suse.com/oracle/ before posting