My experience in the 8i timeframe was that any combination of options
in log_archive_dest_n still allowed problems with the standby to blow
back to production. That is why any customer that ever got burned by
that would get rid of managed recovery and go back to the old way of
automating shipping with scripts. Unfortunately I didn't save the tars
that explained it in detail, although I did post some, google cdos for
RFS with joel garry as author. I think searching metalink for RFS also
is informative, but metalink search doesn't seem to be working for me
just now.

jg
--
@home.com is bogus.
https://metalink.oracle.com/metalink...580312.999,1,1

Yeah, managed recovery ain't gonna fly for me - the whole point of the
exercise is to have a reporting database, rather than recovery or
failover - so it'd be in read-only mode the vast majority of the time.
Scheduled manual recoveries are the best option.

I ain't no shell script guru; thankfully, after I verbosely explained
what I needed in the AIX group, and asked for pointers to similar
sample scripts, some kind soul hacked out three lines of shell code
that would fit the bill nicely - check dest1 for files, check dest2 for
missing files, copy and rename from dest1 to dest2 as required. Easy
peasy.

So I'll give that a run for awhile. It'd be _far_ easier on me if we
were at 10g right now, but that is gonna have to wait for our server
consolidation project to kick off later in the year.

BD wrote:
I'm sure the kind soul did this, but I'll say it anyways - check that
dest2 has complete files. Partial files (corrupted in transit or just
not finished writing yet) will, predictably, stop recovery cold. It
can also help to have error messages that junior people can understand
available where they can see them should things go wrong. I keep error
logs and mail an uh-oh message.

jg
--
@home.com is bogus.
http://www.signonsandiego.com/news/m...1protest4.html

My requirements have changed a bit; I'd forgotten how we do things in
Prod, and it's a little different:

Every hour, to conserve disk space, we take log files that are over 10
minutes old, zip them up, and move them to a different directory. So
the full log stream includes the compressed files, plus the most
recent, uncompressed ones.

What I will try to do is alter the routine that does this, to rcp each
log file to /dest2 before it is compressed and relocated. This may
result in some files being overwritten, but I do not think that is a
problem in this case, as it's simply a duplicate log stream anyway -
and, it will all but guarantee that I won't have a gap in the log
sequence at the recovery end.

I will also attempt to create a routine that does a checksum before the
files are rcp'd, and verify that checksum at the other end.

Once each recovery process completes, I'll remove all log files from
/dest2, as they will no longer be needed.

That _should_ work. There's obviously a few ways to skin this
particular cat, but I agree that verification of any file copies is
very wise.

BD

BD wrote:

If you are doing a remote copy, don't you think it would be easier on
the network to copy the compressed files? My experience has been that
results in faster throughput (at least with my abused and slow WAN).
Then I compare file sizes after uncompression, seems to catch all the
transmission-based problems in my configuration. I originally intended
to do a checksum, but this seems good enough, any noise inserted will
make the uncompress the wrong size. Over the last couple years, it's
caught a few, vs. ~3 failures/month with 8i options. Network has been
upgraded, but still, shipping an order of magnitude fewer bytes means
that much less opportunity for collisions/retransmits and other
transient network problems.

I don't know the details of your system, but this is a red flag to me.
Unless you are checking to be sure "old" logs during slow times are not
active?

jg
--
@home.com is bogus.
I remember McMartin. http://catless.ncl.ac.uk/Risks/24.27.html#subj1