Re: Upgrades with no downtime
- From: LS Cheng <exriscer@xxxxxxxxx>
- To: "SHEEHAN, JEREMY" <JEREMY.SHEEHAN@xxxxxxxxxxxxxxxxx>
- Date: Tue, 27 Oct 2009 20:16:33 +0100
And exactly that was my point since it's going to replace Streams (or looks
like it)
Regards
--
LSC
On Tue, Oct 27, 2009 at 6:14 PM, SHEEHAN, JEREMY <
JEREMY.SHEEHAN@xxxxxxxxxxxxxxxxx> wrote:
> 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@xxxxxxxxxxxxx [mailto:
> oracle-l-bounce@xxxxxxxxxxxxx] *On Behalf Of *LS Cheng
> *Sent:* Tuesday, October 27, 2009 11:19 AM
> *To:* valpis@xxxxxxxxx
> *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@xxxxxxxxx> 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
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
Other related posts:
