Oracle vs DB2 on heavy OLTP loads

7 views
Skip to first unread message

dbgu...@yahoo.com

unread,
May 16, 2005, 6:35:53 PM5/16/05
to
We're almost ready to give up on DB2 v8 and consider migration to
Oracle (the reason is DB2 v8 being unstable). The main question is -
how good and stable properly configured Oracle is under heavy OLTP load
(10M+ transactions/day)? DB2 v7 handles such loads nicely, but v8 even
w/FP7 is a disaster (instance crashes as well as other errors), and
with supported life of v7 coming to the end, we are pressured to look
for alternatives (with the only real one being Oracle).

So - does anybody has an experience (good or bad) with running heavily
loaded OLTP systems on Oracle?

dbgu...@yahoo.com

unread,
May 16, 2005, 6:41:48 PM5/16/05
to
Clarification - we're running DB2/Win2003-32, and would like to hear
about experiences with Oracle on any platform/OS (with preference going
towards Itanium-based ones).

HansF

unread,
May 16, 2005, 6:48:39 PM5/16/05
to
On Mon, 16 May 2005 15:35:53 -0700, dbguy456 interested us by writing:

Oracle has a number of nifty things to help out with such a load,
especially related to space pre-alocation.

IN addition, zero-to-minimal change to application needed to get RAC
working - RAC being the *database* 'clustering' solution allowing more
physical machines to coordinate on one database.

Based on one of my former customers (previous company) being able to feed
data at roughly 4500 records per minute without the systems breaking out
in a sweat during testing 4 years ago, I'd say you will probably not run
into an issue.

--
Hans Forbrich
Canada-wide Oracle training and consulting
mailto: Fuzzy.GreyBeard_at_gmail.com

dbgu...@yahoo.com

unread,
May 16, 2005, 7:13:39 PM5/16/05
to
Thanks, but...

- re. "number of nifty things" - DB2 has them either, and option for
space pre-allocation is standard for any
database-pretending-to-be-somwhat-serious.

- re. RACs - DB2 has somewhat similar thing but it is not really needed
for any conceivable OLTP loads; in general, we're pretty sure that DB2
and Oracle are more or less equivalent in OLTP performance department.

- re. 4500 records/minute - it was just a test, and what we need is
real-life experience. DB2 v8 will also work Ok in several-hour testing;
it fails just once a few days or weeks which is still not good enough.

Thanks anyway

HansF

unread,
May 16, 2005, 7:25:14 PM5/16/05
to
On Mon, 16 May 2005 16:13:39 -0700, dbguy456 interested us by writing:


I agree with your response to the 'nifty things'. Just want you to be
sure that Oracle has 'em too. Some others that profess to be
industry-strength do not.

The RAC is optional, but a hell of an easy way to save money by not
needing to go to big SMB boxes. (Less what is required for the RAC
licenses ... all my environments still save. YMMV)

DB2's clustering is NOT the same. Has other advantages and disadvantages.
Equate the two only at risk of proving your lack of understanding.

The customer put it into service 24x7x265 under a MUCH higher load. Sadly
I can not discuss that part as I left under NDA.

HansF

unread,
May 16, 2005, 7:45:48 PM5/16/05
to
On Mon, 16 May 2005 23:25:14 +0000, HansF mistyped:


> The customer put it into service 24x7x265 under a MUCH higher load. Sadly
> I can not discuss that part as I left under NDA.

Typo ... s.b. 24x365 (not 265)

dbgu...@yahoo.com

unread,
May 16, 2005, 8:16:34 PM5/16/05
to
> Some others that profess to be industry-strength do not.
Are there any others besides Oracle and DB2? :-)

> The RAC is optional, but a hell of an easy way to save money by not
needing to go to big SMB boxes.

C'm on, properly designed OLTP app in most cases can get 100M
transactions/day (or 200000/minute assuming even distribution over
8-hour workday) on a single 4-CPU box; and 100M/day is a huuuuuge
number, which is more than NYSE and NASDAQ transaction numbers
combined.

> DB2's clustering is NOT the same. Has other advantages and
disadvantages.

I know, but as we're not interested in either one, it becomes a moot
issue.

> The customer put it into service 24x7x265 under a MUCH higher load.
Sadly
I can not discuss that part as I left under NDA.

As usual, just as it started to become interesting - it's all over :-(.

Noons

unread,
May 16, 2005, 8:51:27 PM5/16/05
to
dbguy...@yahoo.com wrote:
> So - does anybody has an experience (good or bad) with running
heavily
> loaded OLTP systems on Oracle?

Dunno what you call heavily loaded, but does 5000 users
with 30Mrow/day classify? If so, that was the load
on the system I looked at >5 years ago with Oracle 8.0.
I'd expect 9ir2 on modern hardware to be up to that or
much more without breaking a sweat. In fact, we now do
churn throgh around 50Gb/day on 9ir2 and RHAS. But that is
NOT an OLTP system. 10g should be even better.

I'm quite sure IBM would be able to fix your instability
problems given time and resources. Is it worth going
through all the hassles of change because of a less
than daily spike? Just asking.

Now, the bad: you can get nasty one-off bugs in Oracle as
well. And the options are the same: wait for a patch or
work around the problem. Or both. In some environments
I think you'll find it doesn't matter the maker, things
are very similar. On the whole I've found Oracle is quite
good at fixing the glaring holes. This is not to say there
aren't any left!

If you decide to move, pay special attention to your IO
configuration hardware-wise. For the kind of volumes
you talking about, you can't put up with "feature *blah* is
supported in version x.y.z, patch 89893243" and other crap
like that. Do your ground work in selecting the h/w and OS you're
gonna run on and life will be a lot easier. Yes, there is a
difference. No matter how much marketroids might want you to
believe everything is the same in db/os-land.

Better yet: get an eval copy of Oracle for your intended platform,
get access to Metaclick and start pouring through the list
of problems/bugs/white papers. It will be the best spent
$$ and time of your life.

HTH

HansF

unread,
May 16, 2005, 9:23:54 PM5/16/05
to
On Mon, 16 May 2005 17:16:34 -0700, dbguy456 interested us by writing:

>
>> The RAC is optional, but a hell of an easy way to save money by not
> needing to go to big SMB boxes.
> C'm on, properly designed OLTP app in most cases can get 100M
> transactions/day (or 200000/minute assuming even distribution over
> 8-hour workday) on a single 4-CPU box; and 100M/day is a huuuuuge
> number, which is more than NYSE and NASDAQ transaction numbers
> combined.

You saying you achieve the above in DB2? So why worry about it.

Every published benchmark around Oracle and IBM show that they leapfrog
each other. If you can do it with DB2, you know you can do it with Oracle
under roughly the same horsepower. (And that's about all benchmarks prove.)

You sure don't need RAC for a single 4-CPU box. (Not even Enterprise
Edition, unless you need Enterprise features if required by design.)

Just make sure you read Tom Kyte's "Effective Oracle by Design" so you
understand the difference in design pattern.

>> The customer put it into service 24x7x265 under a MUCH higher load.
>Sadly I can not discuss that part as I left under NDA.
>As usual, just as it started to become interesting - it's all over :-(.

Talk to Oracle. Ask for references. This customer is a reference. Yes,
they'll be selected but you do get a chance to talk.

Unless, of course, you don't trust your ears and eyes in a reference
situation. Then again, asking on this list is just as likely to give
biased info and it's even less trustworthy than a reference call in which
you have the name of the company and the company's representative.

I can with significant confidence tell you that issues you will encounter
are generally NOT Oracle issues. They will likely be issues of the
selected OS and especially the IO subsystem and disk configuration.

DA Morgan

unread,
May 16, 2005, 9:28:30 PM5/16/05
to

Very very heavy loads? Well lets see ... the FBI, Homeland Security,
CIA, NSA, MasterCard, Visa, American Express, Bank of America,
Washington Mutual Bank, Cingular Wireless, T-Mobile Wireless, Western
Wireless, Amazon.com. Will that do?

My personal best ... (and I am so ashamed) ... American Idol TV show ...
20K+ inserts/second.
--
Daniel A. Morgan
http://www.psoug.org
damo...@x.washington.edu
(replace x with u to respond)

DA Morgan

unread,
May 16, 2005, 9:30:05 PM5/16/05
to

My preference would be to drop Windows as a platform for any serious
database work and to drop Itanium if going 64bit: It is overpriced
garbage.

If Linux I'd look at Opteron and if going P5 I'd look at Apple G5s.

DA Morgan

unread,
May 16, 2005, 9:36:33 PM5/16/05
to
dbgu...@yahoo.com wrote:
>
> - re. RACs - DB2 has somewhat similar thing but it is not really needed
> for any conceivable OLTP loads; in general, we're pretty sure that DB2
> and Oracle are more or less equivalent in OLTP performance department.

RAC is not "needed" for OLTP but it will provide you with a few things
you can not get from DB2.

1. Failover
2. No need to federate data

> - re. 4500 records/minute - it was just a test, and what we need is
> real-life experience. DB2 v8 will also work Ok in several-hour testing;
> it fails just once a few days or weeks which is still not good enough.
>
> Thanks anyway

I have, in production, run as I said before 20K+ inserts per second.
That is real-life experience and I can put you in touch, off-line,
with the Oracle employee that worked with me on the project to verify
it.

DA Morgan

unread,
May 16, 2005, 9:47:52 PM5/16/05
to
Noons wrote:

> Now, the bad:

The knock on the door you hear is Mark Townsend. ;-)

Noons

unread,
May 17, 2005, 1:16:26 AM5/17/05
to
DA Morgan wrote:
> Noons wrote:
>
> > Now, the bad:
>
> The knock on the door you hear is Mark Townsend. ;-)
>

:D
you mean he threw that brick through the window?
<d&r>

DA Morgan

unread,
May 17, 2005, 1:28:37 AM5/17/05
to

I'm seeing him Friday ... I'll ask. ;-)

anton_v...@nl.ibm.com

unread,
May 17, 2005, 6:27:41 AM5/17/05
to
Daniel, you shouldn't say things that aren't true.
DB2 has failover via either partitioned databases (long before Oracle
had RAC) or via the new HADR support, which is very easy to set up by
the way.

Anton Versteeg

dbgu...@yahoo.com

unread,
May 17, 2005, 5:40:12 PM5/17/05
to
> My preference would be to drop Windows as a platform for any serious
database work
We would prefer to select database first, and platform for it second
(for DB2 Power5/AIX is a natural choice, for Oracle it is not that
obvious, as Sparc CPUs cannot really compete with either Power5/Itanium
now).

dbgu...@yahoo.com

unread,
May 17, 2005, 5:56:42 PM5/17/05
to
> Dunno what you call heavily loaded, but does 5000 users with
30Mrow/day classify?
Sure it does, thanks. But Oracle 8 doesn't really qualify as a 100%
relevant experience (as I've already told, DB2 v7 was rock-solid, but
v8 is quite unstable, to be polite - and how can I be sure it's not the
case with Oracle 8 / 10g? ).

> I'm quite sure IBM would be able to fix your instability problems
given time and resources.

First of all, it's not 'our' instability problems, it's 'their'
instability problems. :-)

> Is it worth going through all the hassles of change because of a less
than daily spike? Just asking.

It is already FP9, and it is still unstable as hell. Things are getting
better, but at this rate we're risking to wait for sufficient stability
for v8 until v9 will be released and v8 will be out of support :-(.

> If you decide to move, pay special attention to your IO configuration
hardware-wise.

Sure we will (and as you probably guessed, we already did pay attention
to it in current configuration :-) ).

> Do your ground work in selecting the h/w and OS you're gonna run on
and life will be a lot easier.

Ok, and what would YOU recommend for this kind of load for Oracle
(note: I don't think SPARC is a good choice for us due to lower per-CPU
power than competition - and per-CPU is essential for us, but all other
options are open; price is not that important either).

dbgu...@yahoo.com

unread,
May 17, 2005, 5:44:30 PM5/17/05
to
> If you can do it with DB2, you know you can do it with Oracle
under roughly the same horsepower.
I'm pretty sure about it too, the question is stability.

> Talk to Oracle. Ask for references.

We will, but IMO it is different from asking here - those are 2 sources
of information, and I don't see reasons to ignore each one of them.

Niall Litchfield

unread,
May 17, 2005, 5:55:02 PM5/17/05
to
and I was going to ask abut the lack of weekend working...


--
Niall Litchfield
Oracle DBA
http://www.niall.litchfield.dial.pipex.com
"HansF" <News...@telus.net> wrote in message
news:pan.2005.05.16....@telus.net...

DA Morgan

unread,
May 17, 2005, 4:31:26 PM5/17/05
to

DB2 has no technology equivalent to RAC. Yes they both have features
for high availability. But a federated database, lacking transparent
fail-over does not contain anything that does what RAC does.

If you wish to debate this feel free to do so. But point to specific
DB2 functionality that you think is equivalent to TAF.

PS: Who got anywhere first is irrelevant. Whose is there now with
currently supported versions is relevant.

dbgu...@yahoo.com

unread,
May 17, 2005, 6:02:37 PM5/17/05
to
> I have, in production, run as I said before 20K+ inserts per second.
For how long? Once again - I'm pretty sure it's possible with Oracle to
handle heavy loads, the question is how stable is it while handling
it? Also - what platform do you run it on?

Niall Litchfield

unread,
May 17, 2005, 5:57:56 PM5/17/05
to
"DA Morgan" <damo...@psoug.org> wrote in message
news:1116361649.927612@yasure...

> If you wish to debate this feel free to do so. But point to specific
> DB2 functionality that you think is equivalent to TAF.

You originally stated that DB2 didn't do 'failover', not TAF. If you mean
that DB2 won't failover and retry select statements on another node, then
that is a mite different.

dbgu...@yahoo.com

unread,
May 17, 2005, 6:00:33 PM5/17/05
to
: Will that do?
No, unless you'll tell where this information came from (if, for
example, it's from list of Oracle customers, it doesn't mean that those
organizations perform any critical OLTP processing on Oracle - 99% of
them are also IBM customers and MS customers or even MySQL customers,
but this doesn't mean they're processing critical data in MSSQL or
MySQL).

Noons

unread,
May 17, 2005, 7:18:45 PM5/17/05
to
dbguy...@yahoo.com wrote:

> Sure it does, thanks. But Oracle 8 doesn't really qualify as a 100%
> relevant experience (as I've already told, DB2 v7 was rock-solid, but
> v8 is quite unstable, to be polite - and how can I be sure it's not
the
> case with Oracle 8 / 10g? ).

You can't be sure. Other than ask online and/or pour through
Metaclick,
like I suggested. And the answer has been given already: 9ir2 is
stable. 10g dunno, but Mark Townsend will have my doolies for
saying so.

And Daniel will tell you that all is roses in 10g-land.
<g,d&r>

> > I'm quite sure IBM would be able to fix your instability problems
> given time and resources.
> First of all, it's not 'our' instability problems, it's 'their'
> instability problems. :-)

You got a good point there! ;)

> It is already FP9, and it is still unstable as hell. Things are
getting
> better, but at this rate we're risking to wait for sufficient
stability
> for v8 until v9 will be released and v8 will be out of support :-(.

Nice... Just what you need, eh?

> Ok, and what would YOU recommend for this kind of load for Oracle
> (note: I don't think SPARC is a good choice for us due to lower
per-CPU
> power than competition - and per-CPU is essential for us, but all
other
> options are open; price is not that important either).

I don't think SPARC is a good choice for ANYONE!
But don't quote me on that...

At the risk of ruffling the feathers of many here:

- HPUX11+9ir2, with raw disk devices. Pick your hardware level.
- AIX5L+9ir2, with JFS2. Pick your hardware level.
- If you got the guts: RHAS with ext2, RAC 10g, OCFS. Dell is a
good one. (those 4xXeons in one of our db servers kick major ass!).

Disk-wise? EMC or equivalent SAN/NAS. The sky is the limit there,
how deep is your pocket? Look at Veritas' file system as well, it's
sometimes very surprising.

And that's about it, I'm afraid. Fujitsu/Siemens might have something
as well but I've lost track of their h/w and they don't talk much
online so it's hard to figure out what's going on.

As is I'll probably get crucified for excluding SPARC but that's
the lay of the land: Sun can't spend their time dumping on Oracle
and expect dbas to support them indefinitely. Fact is: their
hardware is crap. And software is not that far behind.

HansF

unread,
May 17, 2005, 7:41:39 PM5/17/05
to
On Tue, 17 May 2005 22:55:02 +0100, Niall Litchfield interested us by
writing:

> and I was going to ask abut the lack of weekend working...

Union shop. OS works to rule ...

dbgu...@yahoo.com

unread,
May 17, 2005, 7:45:35 PM5/17/05
to
Thanks!


> - HPUX11+9ir2, with raw disk devices. Pick your hardware level.

You mean 'Itanium 2' here, right? What do you think of rx4640-8
w/MSA1500+MSA30 for storage?

> - AIX5L+9ir2, with JFS2. Pick your hardware level.

What do you think of p5-570 w/FastT900+EXP700 for storage? Also - do
you know of anybody in real world running 'heavily loaded' OLTP on
Oracle under AIX?

> - If you got the guts: RHAS with ext2, RAC 10g, OCFS. Dell is a
good one. (those 4xXeons in one of our db servers kick major ass!).

No I don't. Not on Dell at any rate; HP DL585 could be a choice for
some secondary databases though.

In general, IBM solution is going to be 2-3 times more expensive than
equivalent HP one, but could be worth it.

Obviously, exact configurations heavily depend on load etc., but as a
general idea it should look either like 'Ok, may do', or like 'No way'.


BTW, why did you mention 9ir2 rather than 10g for HPUX and AIX?

HansF

unread,
May 17, 2005, 8:18:28 PM5/17/05
to
On Tue, 17 May 2005 16:45:35 -0700, dbguy456 interested us by writing:

>
> In general, IBM solution is going to be 2-3 times more expensive than
> equivalent HP one, but could be worth it.

Though you aren't interested, just want to point out that this is EXACTLY
the thought process that Oracle RAC was created to handle.

ie: Why go for multi-CPU machines? Or at least the expensive ones with
more than 2 CPU?

Instead, get the same number of CPU across easily swapped boxes. And add
boxes as load requires, when load requires, instead of getting a big
backplane up front. And each box has access to ALL the data, as compared
to a typical federated / partitioned environment.

(And I'd seriously look at NetApp to handle the shared storage.)

DA Morgan

unread,
May 17, 2005, 9:05:01 PM5/17/05
to
dbgu...@yahoo.com wrote:
>>Dunno what you call heavily loaded, but does 5000 users with
>
> 30Mrow/day classify?
> Sure it does, thanks. But Oracle 8 doesn't really qualify as a 100%
> relevant experience (as I've already told, DB2 v7 was rock-solid, but
> v8 is quite unstable, to be polite - and how can I be sure it's not the
> case with Oracle 8 / 10g? ).

Simply put cause of database instability is incompetent SysAdmins and
DBAs so I am hesitant to give you a simplistic answer. But I can tell
you that I have not seen a well managed 9i or 10g database go down
except by intent of its owner.

DA Morgan

unread,
May 17, 2005, 9:08:15 PM5/17/05
to

I don't know ... how long has American Idol been on TV?

Generic Dell hardware with a NetApp Filer Head.

I'm not sure why you are so paranoid about this. Oracle Corp., for
years, has eaten its own dogfood. Ask your Oracle rep. what is in
Oracle's own data centers. The answer AFAIK is Dell, Apple, EMC, and
NetApp.

DA Morgan

unread,
May 17, 2005, 9:06:02 PM5/17/05
to
Niall Litchfield wrote:
> "DA Morgan" <damo...@psoug.org> wrote in message
> news:1116361649.927612@yasure...
>
>>If you wish to debate this feel free to do so. But point to specific
>>DB2 functionality that you think is equivalent to TAF.
>
>
> You originally stated that DB2 didn't do 'failover', not TAF. If you mean
> that DB2 won't failover and retry select statements on another node, then
> that is a mite different.

If the conversation is RAC, and it was, then the conversation is TAF.

If we were talking DataGuard there are several options but RAC = TAF
when failover is being discussed.

DA Morgan

unread,
May 17, 2005, 9:00:42 PM5/17/05
to

There is little question that the best CPU on the market for 64bit
Oracle is the P5. That leaves you a choice of two vendors.

And I would disagree with your characteriztion about Oracle and AIX.
It is a very powerful combination: And has been since 5L.

Noons

unread,
May 17, 2005, 9:44:27 PM5/17/05
to
dbguy...@yahoo.com wrote:

> > - HPUX11+9ir2, with raw disk devices. Pick your hardware level.
> You mean 'Itanium 2' here, right?

Very much so. The rest, not familiar with. Watch out for patch levels
on the OS: check carefully which ones you need. There are a LOT of
dependencies if you running a SAN, Oracle, Vxfs and HPUX11.

> you know of anybody in real world running 'heavily loaded' OLTP on
> Oracle under AIX?

Yes. Mixed DSS and OLTP. Superannuation ( retirement stuff)
system. And it runs darn stable.

> No I don't. Not on Dell at any rate; HP DL585 could be a choice for
> some secondary databases though.

Well, the Linux solution has one thing going for it: it is cheap.
And quite fine for secondary stuff, I'd say. Mind you: we're running
it 24x7x365, collecting and churning bulk logs from many search
engines and quite frankly, it hasn't missed a beat. Hardware
glitches excepted. But I don't know what it'd be like for a pure
OLTP.

> In general, IBM solution is going to be 2-3 times more expensive than
> equivalent HP one, but could be worth it.

Nothing wrong with AIX, I reckon. And the hardware to run it.
Although Unix purists like to dump on the combo. Once again,
check out the SP levels: it's very important with IBM software
as you are I'm sure aware.

> BTW, why did you mention 9ir2 rather than 10g for HPUX and AIX?

Because it's the one I'm familiar with. 10g is still very much
embryonic in Australia for critical online sites. Regardless
of what Oracle might say. Hey, you asked for "real experience",
didn't you? ;)

Having said that, there is a lot of yummy stuff in 10g PL/SQL
I'd give my right arm to get in 9i... Heck, maybe next year
we'll upgrade!

Mark Townsend

unread,
May 17, 2005, 10:52:15 PM5/17/05
to dbgu...@yahoo.com
There are a few common misconceptions in this thread.

1. 99% of Oracle customers are also running IBM, MS SQLServer and MySQL.
They aren't. The numbers are much smaller. If you would like to contact
me offline I can provide some more realistic numbers. I would be fully
prepared to accept that the reverse is true however :-)

2. DB2 is a natural choice for IBM hardware/storage. It's not. If you
would like to contact me offline I can provide some reasons why.

3. Oracle is a natural choice for Sun harwdare/storage. It is, but it's
not the only natural choice. If you would like to contact me offline I
can provide some other choices.

3. There are no mission critical applications running on Oracle Database
10g. There are. Even in Australia. If you would like to contact me
offline I can provide some examples.

4. I throw rocks and covet Noons' doolies (whatever those are). I don't.
I do throw a good party, and I do have some very staunch friends in
Bondi that owe me a favor or three. Noons can decide for himself if this
is an invitation or a threat. No need to contact me offline or online
for this one.

5. Last but not least I do work for Oracle (although the Oracle people
will tell you that's probably the biggest misconception of all). Working
out how to contact me offline is not too hard to do.

DA Morgan

unread,
May 18, 2005, 12:31:33 AM5/18/05
to

I'm bringing that bottle of scotch I promised. I may not always be
right: But I am always enjoying life.

anton_v...@nl.ibm.com

unread,
May 18, 2005, 5:21:35 AM5/18/05
to
I debated that DB2 does have failover technology.
I never said it was equivalent to RAC, which has its pro's and con's.

Anton Versteeg

Billy

unread,
May 18, 2005, 7:03:34 AM5/18/05
to
anton_v...@nl.ibm.com wrote:
> I debated that DB2 does have failover technology.
> I never said it was equivalent to RAC, which has its pro's and con's.

Pro's. It is friggen great.

Con's. It is friggen great (which means less time being bored in the
office and surfing www.wickedweasel.com).

Seriously though, show me any other RDBMS architecture that can
outscale RAC. And not the theoretical stuff, but practically - doing
real work in the real world dealing with real world budget constraints
and the like.

--
Billy

dbgu...@yahoo.com

unread,
May 18, 2005, 7:28:10 AM5/18/05
to
> Why go for multi-CPU machines? Or at least the expensive ones with
more than 2 CPU?
The answer is simple: KISS aka 'Keep It Simple, Student'. Extra level
of complexity (and a huge one) is not a thing I want to see in such
demanding environments. As for server pricing - optimum
CPU-price-performance-wise are 2CPU boxes, but the difference
(especially considering current pricing for decent storage), is not
that large to compensate for extra complexity (which means more time to
support, more risks etc. - plus RAC itself should have certain price
too) Starting from 4CPU ones upwards pricing tend to be more or less
linear one (with other factors coming into play); also it is quite
common model when 8CPU box is assembled from 2 4CPU chassis.

dbgu...@yahoo.com

unread,
May 18, 2005, 7:30:29 AM5/18/05
to
Thanks

dbgu...@yahoo.com

unread,
May 18, 2005, 7:46:13 AM5/18/05
to
> 99% of Oracle customers are also running IBM, MS SQLServer and MySQL.

It is not what I originally stated. But I'm pretty sure that for BIG
ones it is true - just because they're BIG (I'm pretty sure that
somewhere, in some department of Homeland Security they're even using
MS Access and Excel to handle the data - which doesn't have anything to
do with processing OLTP data on it).

> DB2 is a natural choice for IBM hardware/storage. It's not. If you
would like to contact me offline I can provide some reasons why.

Again, it is not what was originally stated. What was stated is that
IBM hardware and AIX are natural choices for DB2.

dbgu...@yahoo.com

unread,
May 18, 2005, 8:02:03 AM5/18/05
to
> cause of database instability is incompetent SysAdmins and DBAs
That's what support wants us to think. I have quite different point of
view though - no incompetence on the side of SysAdmin/DBA should be an
excuse for DB instance crash, period. Poor performance? Sure. Invalid
results? Could be. Diagnostic log full of error messages? Sure.
Instance crash? No way.

HansF

unread,
May 18, 2005, 8:44:44 AM5/18/05
to
On Wed, 18 May 2005 04:28:10 -0700, dbguy456 interested us by writing:

>
> The answer is simple: KISS aka 'Keep It Simple, Student'. Extra level
> of complexity (and a huge one) is not a thing I want to see in such

I totally agree with the KISS. I do not agree that a 4 (or 64) CPU
backplane fits in the definition of KISS.

But it's all experience and perspective ... Having been around Oracle
technology since 1984, I do understand a bit about it's operation and do
find RAC easier, and simpler, and more reliable, than a hardware solution.
(Note that I am an electrical engineer by training).

So you and I will stand here and argue the opposite sides of this problem
forever - and use exactly the same agruments to bolster our viewpoint. The
only way to counter that is to test and benchmark.

dbgu...@yahoo.com

unread,
May 18, 2005, 9:52:08 AM5/18/05
to
> But it's all experience and perspective ...
Exactly. From my experience, hardware crashes (except for problems
related to moving parts like HDDs) are extremely rare (and a few
additional orders of magnitude less rare if we won't count drivers as
part of the hardware), and as you probably noticed, my experience with
DB software wasn't that good.

Serge Rielau

unread,
May 18, 2005, 10:01:55 AM5/18/05
to
dbgu...@yahoo.com wrote:
>>cause of database instability is incompetent SysAdmins and DBAs
>
> That's what support wants us to think. I have quite different point of
> view though - no incompetence on the side of SysAdmin/DBA should be an
> excuse for DB instance crash, period. Poor performance? Sure.
> Invalid results? Could be.
Don't agree. Wrong results are even worse than a crash. At least a crash
can't be missed.

> Diagnostic log full of error messages? Sure.
> Instance crash? No way.
>
Agreed. No ifs no buts.

Let me make a couple of simple comments. As you see from the posts the
standard recommendation is O9R2 which is a stable release (no function
being added for a long time).
It's noted that O10gR2 requires "guts" and I'm sure Mark T. can give you
the current level of penetration of O10g.
DB2 V7.2 matches O9R2 in terms of release cycle (one backlevel)
DB2 V8.2 matches O10gR2 (latest drop).
The same shared customers (I know it first hand from briefings) who
don't want to go to DB2 V8 for LUW also don't want to go to O10g.
IBM's biggest mistake is/was to push customers to the current release by
announcing end of regular support (You can run V7 supported and many
customers do!) before Vnext shipped (unlike what Oracle did with O8i).
You state you are affraid that DB2 V8 may not be stable before Vnext
ships and then the cycle starts again.
If IBM yanks support for DB2 V8.2 before V8.2 + 2 is shipped and Vnext
is stabilized similarly as V7.2 is stabalized, that would mean they/we
have learned nothing.
That would be very poor indeed and I'd reconsider my employment options
myself should that happen.

DB2 for LUW has grown a lot with V8. As part of this IBM needs to grow
up its delivery strategy and I'm confident they will. After all DB2 V7
for zOS is supported and will be for a long time. No magic trick to it.

Cheers
Serge

PS: 24x7x365? Talk of wrong results .... ;-)
--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab

HansF

unread,
May 18, 2005, 10:33:12 AM5/18/05
to
On Wed, 18 May 2005 06:52:08 -0700, dbguy456 interested us by writing:

And my experience - ranging back to early days of SMP and the SMP-MPP
battles, to more recent, indicates that the hardware and related software
workarounds to SMP with anything more than 2 CPU is questionable.

On that note, I drop the thread as it has become purely religious - you
don't want to look at something I know works because you have little
faith, and I don't like what you want because I have little faith.

dbgu...@yahoo.com

unread,
May 18, 2005, 12:00:41 PM5/18/05
to
> Wrong results are even worse than a crash. At least a crash can't be
missed.
Sure they are worse. But my point here was that while incompetent DBA
can be blamed for invlaid results (well, at least in some cases), but
it is wrong to blame him for instance crash.

dbgu...@yahoo.com

unread,
May 18, 2005, 12:03:01 PM5/18/05
to
> hardware and related software workarounds to SMP with anything more
than 2 CPU is questionable.
In terms of stability or in terms of performance/scalability?

DA Morgan

unread,
May 18, 2005, 2:38:37 PM5/18/05
to
Billy wrote:

> office and surfing www.wickedweasel.com).

One caution ... a lot of people, at least in the US, work in
environments where clicking on that link could potentially cost
them their job. Be sure to indicate the appropriateness of such
a link so that someone doesn't click on it when the cubefarm troll
is walking by.

DA Morgan

unread,
May 18, 2005, 2:42:49 PM5/18/05
to

There is nothing complex about maintaining RAC clusters if you learn
how.

And the cost savings on hardware with RAC is huge and more than
compensates for the cost of the RAC licenses. Consider the following
scenario:

1. Same hardware in dev, test, and prod
2. Production will, one-to-two years from now, need an 8CPU machine.

Your choice ... price out 3 x 8CPU servers or price out 6 x 2CPU
commodity hardware knowing that you can add nodes to prod on demand
when required.

Oh did I forget the need for a duplicate of prod. for failover? Sorry.
Increase the cost by buying another 8CPU machine: Completely unnecessary
with RAC.

BTW: The cost of storage is irrelevant to the conversation. Either way
Apple, EMC, IBM, or NetApp is likely getting a large check for disk.

DA Morgan

unread,
May 18, 2005, 2:46:00 PM5/18/05
to

Not a chance you are correct. I would venture, with confidence, that
80% of all major crashes can be equated with SysAdmins and DBAs that
don't know what they need to know to be truly competent. In spite of
your overabundance of confidence I doubt your DBA team would survive
intact a serious screening. Want to find out?

When was the last time your DBAs actually read the Net Services manual?
Which version of Oracle was current? My guess 7.3.

DA Morgan

unread,
May 18, 2005, 2:51:09 PM5/18/05
to
Serge Rielau wrote:

> It's noted that O10gR2 requires "guts" and I'm sure Mark T. can give you
> the current level of penetration of O10g.

What Mark T. would probably say is that 10gR2 is still Beta and has
yet to be released.

> DB2 V8.2 matches O10gR2 (latest drop).

Assuming you actually meant R1 the difference is that 10gR1 was as or
more stable as 9iR2 the day it was released. DB2 8.2 appears to be an
untreated inflammation if the posters at c.d.ibm-db2 are to be believed.

> Cheers
> Serge

DA Morgan

unread,
May 18, 2005, 2:58:07 PM5/18/05
to

Sorry but I'm not buying that. Instance crashes are most often caused
by DBAs. And unless you are looking at ORA-00600 I'm sticking to it. ;-)

Serge Rielau

unread,
May 18, 2005, 3:21:20 PM5/18/05
to
DA Morgan wrote:
> dbgu...@yahoo.com wrote:
>
>>> Wrong results are even worse than a crash. At least a crash can't be
>>
>>
>> missed.
>> Sure they are worse. But my point here was that while incompetent DBA
>> can be blamed for invlaid results (well, at least in some cases), but
>> it is wrong to blame him for instance crash.
>
>
> Sorry but I'm not buying that. Instance crashes are most often caused
> by DBAs. And unless you are looking at ORA-00600 I'm sticking to it. ;-)
Perhaps DB2 DBAs have different expectations then.

Cheers
Serge

DA Morgan

unread,
May 18, 2005, 6:33:07 PM5/18/05
to
Serge Rielau wrote:
> DA Morgan wrote:
>
>> dbgu...@yahoo.com wrote:
>>
>>>> Wrong results are even worse than a crash. At least a crash can't be
>>>
>>>
>>>
>>> missed.
>>> Sure they are worse. But my point here was that while incompetent DBA
>>> can be blamed for invlaid results (well, at least in some cases), but
>>> it is wrong to blame him for instance crash.
>>
>>
>>
>> Sorry but I'm not buying that. Instance crashes are most often caused
>> by DBAs. And unless you are looking at ORA-00600 I'm sticking to it. ;-)
>
> Perhaps DB2 DBAs have different expectations then.
>
> Cheers
> Serge

You mean buggy product releases?

I don't think so. Seems to be a new "feature" with 8.2. Did you guys
hire some dev managers from Microsoft?

Serge Rielau

unread,
May 18, 2005, 6:51:37 PM5/18/05
to
DA Morgan wrote:
> Serge Rielau wrote:
>
>> DA Morgan wrote:
>>
>>> dbgu...@yahoo.com wrote:
>>>
>>>>> Wrong results are even worse than a crash. At least a crash can't be
>>>> missed.
>>>> Sure they are worse. But my point here was that while incompetent DBA
>>>> can be blamed for invlaid results (well, at least in some cases), but
>>>> it is wrong to blame him for instance crash.
>>> Sorry but I'm not buying that. Instance crashes are most often caused
>>> by DBAs. And unless you are looking at ORA-00600 I'm sticking to it. ;-)
>> Perhaps DB2 DBAs have different expectations then.
> You mean buggy product releases?
> I don't think so. Seems to be a new "feature" with 8.2.
If the new feature is to accept a downed instance as a bug no matter
what the poster did short of actual sabotage,
then yes. That would actually be an old feature and I'll wear that badge
with stride.
Playing the blame game with a customer, happy or not, is always a bad idea.

Noons

unread,
May 18, 2005, 8:11:32 PM5/18/05
to
Serge Rielau wrote:
>
> PS: 24x7x365? Talk of wrong results .... ;-)
> --

Awright, awright, stop beating up the blind...
:D

Noons

unread,
May 18, 2005, 8:32:13 PM5/18/05
to
Mark Townsend wrote:
> 4. I throw rocks and covet Noons' doolies (whatever those are). I
don't.

Never heard of the "oohmedoolies" bird?

> I do throw a good party, and I do have some very staunch friends in

> Bondi that owe me a favor or three. Noons can decide for himself if
this
> is an invitation or a threat. No need to contact me offline or online

> for this one.

Bondi? That's the tourist "surf beach" in Mexico, ain't it? You
gotta go to the real Sydney surf hangouts. Like North Narrabeen.
<d&r>

Noons

unread,
May 18, 2005, 8:52:05 PM5/18/05
to
Serge Rielau wrote:
> It's noted that O10gR2 requires "guts" and I'm sure Mark T. can give
you
> the current level of penetration of O10g.

Ahem. It wasn't noted at all. And Mark would have extreme difficulty
in providing any penetration stories for 10gr2: it ain't out yet.

What was noted was that 10g+RAC -or 9ir2+RAC and Linux would require
guts to go for a critical OLTP system: you'd probably want to get
Oracle professional services involved, or a very close first line
support number. Not because it's unworkable but because there are
quite a few gotchas and not all of them are clearly documented.
Particularly for someone changing database software as well as
hardware.

> DB2 V8.2 matches O10gR2 (latest drop).

Doubt it, given that 10gr2 hasn't been released yet!
Although I'm quite sure some marketroid at IBM will have the
authoritative "advantages" white-paper ready for the release date...
:D

> DB2 for LUW has grown a lot with V8. As part of this IBM needs to
grow
> up its delivery strategy and I'm confident they will. After all DB2
V7
> for zOS is supported and will be for a long time. No magic trick to
it.

<jab>
Same code bases for all, I'm sure. Wonder what that does
for stability...
</jab>

Seriously: you'd have noted as well I did my best to
dissuade the punter from moving. It sounds like too
critical a system for major continental drifts and I'm sure
your folks will fix the problems at some stage soon.
Of course Mark or one of his Bondi tourists will be all
over him - but that's their job.

Noons

unread,
May 18, 2005, 8:54:20 PM5/18/05
to
DA Morgan wrote:
> intact a serious screening. Want to find out?
>
> When was the last time your DBAs actually read the Net Services
manual?
> Which version of Oracle was current? My guess 7.3.


You know what, Daniel? You got a major point there...

Serge Rielau

unread,
May 18, 2005, 11:38:11 PM5/18/05
to
Duly noted and appreciated.

Cheers
Serge

DA Morgan

unread,
May 19, 2005, 12:58:13 AM5/19/05
to
Serge Rielau wrote:

> Playing the blame game with a customer, happy or not, is always a bad idea.
>
> Cheers
> Serge

If I were a former or current Oracle employee. Or had ever personally
accepted a single dollar from Oracle I would agree. As that is not the
case I am still covered by the immunity clause and can say whatever I
wish until the government takes away the First Amendment (and lets not
go there ... ok?). If ever my situation changes I will publicly announce
it and start behaving myself accordingly. Right now I can openly say
that that vast majority of DBAs in any major RDBMS are technically
incapable of plying their trade.

Which is not a fault/blame game: Just a fact. The number of companies
willing to step up to the plate and keep their people trained is
minimal. The number of trainers that can do more than read PowerPoint
slides ... I'll let you draw your own conclusion.

But truly I think DBAs need to take more responsibility for themselves
and their profession just as did other professionals in the previous
century. Until they (we) are willing to self-police it will not change.

rkusenet

unread,
May 19, 2005, 5:43:41 PM5/19/05
to

"DA Morgan" <damo...@psoug.org> wrote

>> We're almost ready to give up on DB2 v8 and consider migration to
>> Oracle (the reason is DB2 v8 being unstable). The main question is -
>> how good and stable properly configured Oracle is under heavy OLTP load
>> (10M+ transactions/day)? DB2 v7 handles such loads nicely, but v8 even
>> w/FP7 is a disaster (instance crashes as well as other errors), and
>> with supported life of v7 coming to the end, we are pressured to look
>> for alternatives (with the only real one being Oracle).
>>
>> So - does anybody has an experience (good or bad) with running heavily
>> loaded OLTP systems on Oracle?
>
> Very very heavy loads? Well lets see ... the FBI, Homeland Security,
> CIA, NSA, MasterCard, Visa, American Express, Bank of America,

You can remove VISA from this list. I asked a friend of mine who works
there and they use DB2 for its *most* intense OLTP application.


> Washington Mutual Bank, Cingular Wireless, T-Mobile Wireless, Western
> Wireless, Amazon.com. Will that do?

Joel Garry

unread,
May 19, 2005, 7:24:36 PM5/19/05
to

Serge Rielau wrote:
> dbgu...@yahoo.com wrote:
> >>cause of database instability is incompetent SysAdmins and DBAs
> >
> > That's what support wants us to think. I have quite different point
of
> > view though - no incompetence on the side of SysAdmin/DBA should be
an
> > excuse for DB instance crash, period. Poor performance? Sure.
> > Invalid results? Could be.
> Don't agree. Wrong results are even worse than a crash. At least a
crash
> can't be missed.

Agree that wrong results are even worse than a crash.

Don't agree that a crash can't be missed. Have seen several cases
where either the db was isolated from the app (ie, blame the Net), or
crash happened off-hours and was auto-fixed (ie, power outage runs out
ups or crash happened before normal auto-restart), and no one bothered
to check. (Except me, of course, but I don't count, since I come into
the picture much later and find these sorts of things as I poke
around.) Also seen non-IS people given keys to kingdom, who restart
crashed db and don't tell anyone (or crash and start for silly
reasons).

jg
--
@home.com is bogus.
See you at Oracle Conclave 2006!

Mark Townsend

unread,
May 19, 2005, 8:38:53 PM5/19/05
to rkusenet
rkusenet wrote:

>
>
> You can remove VISA from this list. I asked a friend of mine who works
> there and they use DB2 for its *most* intense OLTP application.
>
>

I think you will find that that's DB2 on the Mainframe, not DB2 LUWser

rkusenet

unread,
May 19, 2005, 9:11:05 PM5/19/05