Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

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

Re: Oracle 24x7 shops and Patches-Upgrades.

From: Carel-Jan Engel <cjpengel.dbalert_at_xs4all.nl>
Date: Tue, 19 Dec 2006 22:54:36 +0100
Message-Id: <1166565276.23075.4.camel@dbalert099.dbalert.eu>


On Tue, 2006-12-19 at 10:30 -0500, Dhimant Patel wrote:

> All,
>
> Thanks for continuing to provide ideas and inputs.
> Carel-Jan:
> 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.

Admiration, yes ;-) Administration, no, not that much.

Mind that actually only transactions (payments) get inserted. No updates, cleanup locally. Processing of transactions is offloaded to backoffice.
The rest of the tables is just lookup, hardly any changes. Yes, adding new cards. Just a regular (local) batch. All the 'unimportant' stuff isn't replicated, just maintained locally at both sites.

> 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.

Just a couple of commodity servers (Intel Xeon, 4 CPU's), network < 4 Mb.

>
>
>
> Thanks again!
> -Dhimant
>
>
> On 12/18/06, Carel-Jan Engel <cjpengel.dbalert_at_xs4all.nl> 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 on
> > site until you were allowed to bounce a 24/7 system?" It was measured
> > in hours.
> >
> > On 12/18/06, Niall Litchfield <niall.litchfield_at_gmail.com> wrote:
> > > On 12/16/06, Dhimant Patel <drp4kri_at_gmail.com> 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
> > >
> > >
> >
>
>
>
>
>
>

===
If you think education is expensive, try ignorance. (Derek Bok) ===

DBA!ert, Independent Oracle consultancy Kastanjelaan 61C
2743 BX Waddinxveen
The Netherlands
tel. +31 (0) 182 64 04 28
fax +31 (0) 182 64 04 29
e-mail careljan_at_dbalert.eu

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Dec 19 2006 - 15:54:36 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US