Re: Automation: DG Broker

From: Neil Chandler <>
Date: Thu, 22 Aug 2019 18:20:33 +0000
Message-ID: <DB7PR10MB20904FACBB124FA98259BB9B85A50_at_DB7PR10MB2090.EURPRD10.PROD.OUTLOOK.COM>

You appear to be confusing capability with performance.

You posted a throw-away comment that it wasn't possible: "After a fail-over you have to rebuild because fail-over does resetlogs.". That is incorrect. You do not have to rebuild if you have flashback switched on. You've been able to do this since Oracle 11.

You also said "automated fail-over is a terrible ide." (sic) - I don't agree with that at all. If you have solid infrastructure, and high uptime requirement and an application layer which is multi-site, can run from any site, and can connect to any of the DB's seamlessly (and this is not hard to achieve, it just needs to be well designed and implemented)

"Such claims need to be proven."
OK. Think I've done that.

"I dislike switching to the personal level" - me to, but throwaway comments and glib assertions are not helpful. I may be being somewhat of a curmugeon, and I'll apologise for that, but I don't apologise for correcting the incorrect.



From: Mladen Gogala <> Sent: 22 August 2019 19:06
To: Neil Chandler <>; <> Subject: Re: Automation: DG Broker

Comments in-line.

On 8/22/19 1:32 PM, Neil Chandler wrote: Mladen,

With all due respect, what has that got to do with giving incorrect advice?

I didn't give incorrect advice. As a matter of fact you did, quoting "Oracle recommendation". Turning on flashback should be done very, very carefully and only after a careful consideration and performance testing. Sometimes, the consequences can be quite drastic, as I've explained in my post. Furthermore, saying that I gave an incorrect advice doesn't make it so. Such claims need to be proven.

You were wrong, and so have changed the subject, so lets go with that.

I dislike switching to the personal level, even when it comes from an Oracle ACE. Maybe if you had the string "(ret)" added to the title? This discussion is over, here and now.

Received on Thu Aug 22 2019 - 20:20:33 CEST

Original text of this message