Re: Problem with Oracle standby database (automatic transfer of archived logs)

From: joel garry <>
Date: Mon, 4 Feb 2008 15:47:42 -0800 (PST)
Message-ID: <>

On Feb 4, 11:39 am, wrote:
> I am on HP UNIX 11 and still on Oracle (cannot move to another
> version). I setup a standby database and am using Oracle's automatic
> mechanism to transfer archived logs from primary to standby  database
> by setting:
> log_archive_dest_2='SERVICE=kdcsb OPTIONAL REOPEN=60'
> Before moving to production, I did testing of this setup for several
> months by manually switching an archived log every 15 minutes and
> everything ran fine. Now, I have moved to production and am finding
> this setup is not working:
> 1.      Oracle sometimes only partial archived log causing recovery to fail
> on standby.
> 2.      Oracle sometimes does not transfer archived logs at all, so standby
> database has some logs missing, i.e., logxxx92, logxxx94, logxxx95,
> logxxx97. There is no pattern here.
> I am in production now and I want this problem to be fixed quickly.
> Are there any options in log_archive_dest, which can be set to remove/
> reduce this kind of error? Appreciate, any help.

If you can get to the right people in Oracle support, they may be able to help you. My experience, on the other hand, was they were very knowledgeable and helpful, but unfortunately these sorts of bugs aren't fixed until later versions. So I moved away from the automatic mechanism and went back to the "older ways." There're probably still scripts floating about on the superduperinterweb, mine aren't really useful beyond the specific site I use them at. It isn't particularly hard to write such scripts if you don't need a lot of variety.

There was one particular nasty RFS bug that blew back into production, is why the customer felt strongly about it, even staying away from managed in O9.

Also see metalink Note:120855.1.


-- is bogus.
I don't know what happened at C$erve, but my homepage is finally back
as mysteriously as it left.
Received on Mon Feb 04 2008 - 17:47:42 CST

Original text of this message