Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Oracle 24x7 shops and Patches-Upgrades.

Re: Oracle 24x7 shops and Patches-Upgrades.

From: Dhimant Patel <>
Date: Tue, 19 Dec 2006 10:30:31 -0500
Message-ID: <>


Thanks for continuing to provide ideas and inputs.

Dennis & August:

    I couldn't agree more about your suggestions - need to find a     way now!


    Are you referring Oracle installation on IBM or VMS?     I usually come across many links for VMS on metalink but couldn't     imagine oracle is capable of "hot" upgrades/migration on these     platforms. Please enlighten me here, I haven't worked on these     systems.


    Yes, we are running on option # 2. But I don't see why we can't     have planned downtime and do upgrades. As I already mentioned, it's     getting difficult to convince here.


    You are right but even if I'm getting a staging server, I still     have to have planned downtime on production, until as Niall put     down that 11g might support rolling upgrades.


    Interesting, so is this entire database is duplicated with     advanced replication? This needs admiration as well as a     good hardware for keeping these databases in sync.

    Could you please provide some sketchy details about the kind of     hardware requirements? Certainly you can't have these on age     old machines! And also a high speed fiber link between the servers     could be a requirement.

Thanks again!

On 12/18/06, Carel-Jan Engel <> wrote:
> One of my CT's sites has the perfect solution.
> This is transaction clearing for POS terminals. They have a context switch
> loadbalancing between two storage/server/db/application stacks. Both are
> normally in service (in two locations 20M apart). One site can serve all the
> load. If one site needs maintenance, the context switch is simply pointed to
> the other site in stead of load balancing.
> Both databases sync the transactions to each other, using Advanced
> Replication (Asynchronous). Normally the backlog won't be more than 5-10
> minutes, in extreme conditions 30 minutes. Losing one server implies a worst
> case of losing half of half an hour of transactions. (Actually it can be
> worse, when the other site is in maintenance at the loss). Half an hour of
> transactions simply does not justify a huge RAC and whatever full stack
> investment. If they lose the transactions they can easlily survive that. And
> this works for some years alreay, so the ROI is supporting the overall
> profitability nicely. No Data Guard, no RAC, just (a lot of) common sense,
> no CYA, but knowledgeable thrustworthy programmers/SA's/DBA's, no
> 'damagement', but entrepreneurs, that can identify well skilled staff. (I
> should not that I got innvolved here AFTER this thing was designed an
> implemented. No credits to me, I just like the elegant solution a LOT).
> Needless to say that the concept of designing an HA stack makes it all
> much better maintainable, allows for real 24x7, rolling upgrades and so on.
> Making som crippled stack HA afterwards is a challenge. You might get close,
> but will hardly meet the requirements, and still spend a lot of time, effor
> and money (blood sweat and tears).
> Best regards,
> Carel-Jan Engel
> ===
> If you think education is expensive, try ignorance. (Derek Bok)
> ===
> On Mon, 2006-12-18 at 19:02 +0000, Niall Litchfield wrote:
> Oh yes. I once asked a consultant "How long from when you arrived onsite until you were allowed to bounce a 24/7 system?" It was measuredin hours.
> On 12/18/06, Niall Litchfield <> wrote:> On 12/16/06, Dhimant Patel <> wrote:> >> > Hi Gurus,> >> >> > This seems very common issue but I am confronted with a requirement where> > we need to have 24x7 availability, no exceptions.> > There is no way we can have staging server (for patch testing before> > deploying on the production.) and we need to accommodate> > software upgrades without a planned downtime.>>> You *might* just possibly be able to upgrade your own in-house written> software without downtime. You *cannot* maintain Oracle software without> downtime - 11g promises the actual shipping of 'rolling upgrades' just about> 1/2 a decade after Larry first mentioned them. Until then (and it would be a> brave person who relied on that particular feature in it's first release)> then you cannot achieve 24*7 without either>> 1) redefining 24*7 to 100% availability within service hours. or possibly> 2) never upgrading any part of the system again.>> Both options 1 and 2 are perfectly acceptable and professional approaches of> course.>> I'm also wondering how shops having 24x7 availability addresses such issues?> >> > Since I'm focused solely on Oracle, I'm not aware if any database server> > allow patching/upgrading without bringing down the server?> > Is any mainstream database server offer such solution?> >> >> >> >> > Thanks,> > DP.> >>>>> --> Niall Litchfield> Oracle DBA>>>

Received on Tue Dec 19 2006 - 09:30:31 CST

Original text of this message