Re: Any-one know how to eliminate PLANNED downtime with Oracle RAC?

From: Yechiel Adar <>
Date: Sun, 30 Nov 2008 08:30:33 +0200
Message-id: <>

Since it seems that the goal of no down time can not be achieved with the current technology I proposed a way that may be applied, depending on various dependencies, to shorten the down time. If we are talking about system wide local clients or jdbc thin clients, each with its own connection string, then this is one problem, while talking about web clients, all accessing 2-3 application servers is another thing.
Even with many local clients, you can bit by bit change the tnsnames to access the first database and if it is not available access the second database.
After you changed them all you can use the streams method.

To make this short, it is all depends, and may help in some situations.

It was never meant as a cover all mode of operations.

About forgetting, the advice that takes first place in this list is: TEST, TEST and TEST AGAIN.

Adar Yechiel
Rechovot, Israel

Finn Jorgensen wrote:
> Adar,
> The original request was for basically zero (planned) downtime. Your
> proposed solution would require "a few minutes" here and "a few
> minutes" there which quickly adds up so no instead of 100% uptime
> you're at 99.999% or less (which is still great, but not 100%). Then
> what happens if you "forgot" something and have to do it again?
> Testing the solution again introduces these "few minutes". It quickly
> adds up.
> Finn
> On Thu, Nov 27, 2008 at 9:21 AM, Yechiel Adar <
> <>> wrote:
> Hello Niall
> Of course there may be issues that do not allow for this solution.
> This is true for every general idea.
> I just want to point that there is no bi-directional replication.
> First the application works on server1 and replicate to server 2.
> Then the application works on server 2 and replicate to server 1.
> The idea of building bi-directional replication is that is helps
> to return to the original server.
> Adar Yechiel
> Rechovot, Israel

Received on Sun Nov 30 2008 - 00:30:33 CST

Original text of this message