RE: Upgrades with no downtime

From: SHEEHAN, JEREMY <JEREMY.SHEEHAN_at_nexteraenergy.com>
Date: Tue, 27 Oct 2009 13:14:44 -0400
Message-ID: <C3F905167E081B418BFC63B8668D52FF0C30FD525E_at_GOXEXVS03.fplu.fpl.com>



GoldenGate was just purchased by Oracle.

Jeremy
P Consider the environment. Please don't print this e-mail unless you really need to.

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of LS Cheng Sent: Tuesday, October 27, 2009 11:19 AM To: valpis_at_gmail.com
Cc: Oracle Discussion List
Subject: Re: Upgrades with no downtime

Hi

You can probably have a look at GoldenGate, they have been claiming Zero Downtime is possible

--

LSC
On Tue, Oct 27, 2009 at 2:44 PM, Johan Eriksson <valpis_at_gmail.com<mailto:valpis_at_gmail.com>> wrote: Hi

We had an discussion about how we could solve the problem with no downtime during upgrades and I want to know if anyone of you have had an similiar problem before and if you could help me with some advice on how to solve this.

Our current setup is we have some application servers with most of the logic, and in the database we have some pl/sql logic and the data.

The problem we have is when we have an deployment of code or changes in the database we also need to take down the system since we can't make changes in the tables for example.

My first thought is that we should split the logic and data in the database into different schemas, and let the logicschema has views that points to the physical storage of the data in another schema. By doing this we could have several schemas with logic( and views) in the database and we could make changes on the tables without affecting the logic. (We rarely deletes any columns and if we do we have to face downtime). And by doing this we could make the changes to the tables and create a new schema with logic and then this is done we shift the application servers to the new schema, and if we also have changes in the code in the application servers we take down couple of the application servers and commit the changes, bring them up and make the run against the new schema and then we are done we take the rest of the application servers. We will not have perfectly smooth upgrades by doing this since we will loose connections when we switch, but we won't have an hour long downtime.

Don't like the idea on using views like this, this is only my first thought about it.

I don't think we are the first ones to hit this problem, but how has others solved them? I look forward to your suggestions and comments about this.

/johan
--

http://www.freelists.org/webpage/oracle-l

--

http://www.freelists.org/webpage/oracle-l Received on Tue Oct 27 2009 - 12:14:44 CDT

Original text of this message