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. FinnOn Thu, Nov 27, 2008 at 9:21 AM, Yechiel Adar <adar666@xxxxxxxxxxxx <mailto:adar666@xxxxxxxxxxxx>> 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
