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 <niall.litchfield@xxxxxxxxx> wrote:> On 12/16/06, Dhimant Patel <drp4kri@xxxxxxxxx> 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> http://www.orawin.info>>
