yipeee!

[dba]

Re: yipeee!

Sigh,

So where are the benchmarks where RAC across 128 nodes scaled linearly
at anywhere near the scale factor of shared nothing? And where are the
references of RAC scaling to 128 nodes? And where are the references of
competitive takeouts of NCR and IBM shared nothing?

I'll still take the stocks and bonds.

DBA

Mark Townsend wrote:[color=blue]
> Sigh.
>
> Check out the #1 result at
> http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
> For RAC references go to
> http://www.oracle.com/ultrasearch/ww...=7&p_Query=RAC
>
>
> Did you actually even attempt to look for yourself ?
>
> dba wrote:
>[color=green]
>> Then where are the benchmarks and real customer references to prove
>> it? Where are the examples of this wonderful technology displacing NCR
>> and IBM shared nothing implementations because it scales better?
>>
>> I'll take the stocks and bonds.
>>
>> DBA
>>
>> Daniel Morgan wrote:
>>[color=darkred]
>>> Database Guy wrote:
>>>
>>>> Daniel seems to think otherwise. He clearly feels that Oracle's
>>>> allegedly faster recover from node failures outweighs its
>>>> less-than-half-speed RAC performance under BAU circumstances (i.e.
>>>> nodes working). I can't understand why Oracle nodes crash so much, but
>>>> it's not a product I know well. Hopefully someone else will explain.
>>>>
>>>>
>>>> DG
>>>
>>>
>>>
>>>
>>> I don't think nodes crash often: But all hardware, all operating
>>> systems, all platforms, and all software does have problems from
>>> time-to-time. Reading your post someone with little or no experience
>>> might be tempted to believe that somehow one vendor's RDBMS is more
>>> likely to cause a CPU to die than another's: Pure nonsense. All
>>> machines lose CPUs. All machines lose RAM. Computers are not
>>> perpetual motion
>>> machines. And downtime has a real cost in $.
>>>
>>> If you truly believe that hardware never crashes I presume you also
>>> don't do nightly backups. In other words ... thanks for the hyperbole.
>>>
>>> And if you truly believe that in the real-world RAC scaling at 128 nodes
>>> gives less than 50% of the performance of shared nothing scaling at 128
>>> nodes I have some stocks and bonds I'd like to sell you.
>>>[/color]
>>[/color]
>[/color]

[Mark Townsend]

Re: yipeee!

Mark A wrote:[color=blue]
> "Mark Townsend" <markbtownsend@ comcast.net> wrote in message
>[color=green]
>><snip>
>>Exactly. Note that Oracle does support COBOL ESQL, and both CIC's and
>>DRDA access via Gateways.
>>[/color]
>
> I think you mean CICS. I know that Oracle supports CICS on OS/390, but does
> it support CICS and COBOL on RS/6000 or other UNIX box that CICS may run on?[/color]

Yes. Sun, HP, IBM and Windows platforms. Possible also Linux but I would
need to confirm
[color=blue]
>
> The originator of this thread (Mike) is thinking of picking up the entire
> OS/390 application and running it on UNIX, probably converting the VSAM to
> an RDMS (at least as a first step), but keeping the COBOL and CICS. There is
> no DRDA access via a Gateway in such an architecture.[/color]

Right. No confusion here. Embedded SQL in the COBOL (Pro*COBOL). We
could also potentially pre-compile the VSAM sections directly into
embedded SQL (pretty much what SAP originally did when they migrated)
I'd have to understand how CICS is being used in the app to understand
what could be 'saved', but this is a pretty typical requirement, and
I've migrated a large number of such apps over the years (and even
managed to sausage machine some of the migrations).

For further reading

http://otn.oracle.com/products/gateways/pdf/am4cics.pdf

http://otn.oracle.com/pls/db10g/db10g.to_pdf?pathname=appdev.101%2Fa96109.pdf&remark=portal

For the OP. Given your description of your HA requirements, I'd
recommend you look at Oracle Database 10g Standard Edition. Use the
built in clusterware on AIX or Linux (without having to step up to the
HACMP cost), the automated storage management to give you automatic
striping and mirrored data protection, which when coupled with the built
in recovery area and flashback capabilities should be enough to give you
a very high level of local site protection of your data. Note that this
edition also includes RAC (Real Application Clusters) so that you can do
the hardware/software maintenance on the node you mentioned, plus you
get to use all of them for your app as required. And it's cheap - total
$60K max on 4 CPUs, or $300 per user (whichever is least)

http://otn.oracle.com/products/database/oracle10g/pdf/ds_general_oracle_database10g_se_0104.pdf

[color=blue]
>
> BTW, I may be getting a little ornery at Daniel's trolling on this forum,
> but I can assure you that I am not confused.
>
>[/color]

Obtuse then ?

[Mark Townsend]

Re: yipeee!

dba wrote:
[color=blue]
> Sigh,
>
> So where are the benchmarks where RAC across 128 nodes scaled linearly
> at anywhere near the scale factor of shared nothing?[/color]

Probably the same place as the IBM and NCR ones ? I can't find a single
128 node result from any vendor anywhere.
[color=blue]
> And where are the references of competitive takeouts of NCR and IBM shared nothing?[/color]

I don't have specific 'takeout' references for RAC replacing shared
nothing. For SMP replaceing shared nothing, well, thats a different
story. There is evidence of a trend in the platforms and software being
used for the worlds largest DSS VLDBs however, that indicate a move away
from shared nothing, often for price considerations, (at least,
according to the Wintercorp Survey (and possibly even Mark A, who
recently acknowledged in this very forum that 'strict' shared nothing
may no longer be the most optimal archiecture for a large scale data
warehouse)).


Anyhow - from the Wintercorp Surveys

1998 - the top 10 VDLB database/platform combos for DSS usage included 3
MMP boxes running Teradata, 2 SMP boxes running Oracle, 1 SMP and 1 MMP
box running Informix, and 2 SMP boxes running UDB. Oracle was #7 and #10
respectively.

2001 - the top 10 VDLB database/platform combos for DSS usage included 4
MMP boxes running Teradata, 2 SMP boxes running Oracle, 2 MMP boxes
running Informix, and two mainframes, one running UDB. Oracle was #8 and
#9 respectively

2003 - the top 10 VDLB database/platform combos for DSS usage included 3
SMP boxes running Oracle, 4 MMP boxes running Teradata, a cluster
running Sybase, and a cluster running IBM DB2. Oracle was #1, #5 and #7
respectively.

[Daniel Morgan]

Re: yipeee!

Mark A wrote:
[color=blue]
> BTW, I may be getting a little ornery at Daniel's trolling on this forum,
> but I can assure you that I am not confused.[/color]

Trolling? Hardly. Why don't you go back to the OP's original post.

My answer was on topic for what the OP asked. The fact that you are
seemingly awash in insecurity is not my problem. I didn't troll and I
didn't try to start a flame-war. I just addressed the specifics of what
the OP asked.

If you disagreed you could have presented to the OP your case
as to why a DB2 solution would have been better. Seems to me that would
have been a far better use of your keyboard.

The OP, seemingly smarter than all of us combined, is likely sitting
back quietly enjoying the show.

--
Daniel Morgan

http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp

http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp

damorgan@x.wash ington.edu
(replace 'x' with a 'u' to reply)

[Mark A]

Re: yipeee!

> Mark A wrote:[color=blue]
>[color=green]
> > BTW, I may be getting a little ornery at Daniel's trolling on this[/color][/color]
forum,[color=blue][color=green]
> > but I can assure you that I am not confused.[/color]
>
> Trolling? Hardly. Why don't you go back to the OP's original post.
>
> My answer was on topic for what the OP asked. The fact that you are
> seemingly awash in insecurity is not my problem. I didn't troll and I
> didn't try to start a flame-war. I just addressed the specifics of what
> the OP asked.
>
> If you disagreed you could have presented to the OP your case
> as to why a DB2 solution would have been better. Seems to me that would
> have been a far better use of your keyboard.
>
> The OP, seemingly smarter than all of us combined, is likely sitting
> back quietly enjoying the show.
>
> --
> Daniel Morgan[/color]

The fact that you are on a DB2 forum constantly talking about Oracle and how
much better it is than DB2, fits the definition of trolling to a "T".

[Niall Litchfield]

Re: yipeee!

"Database Guy" <dbguy101@hotma il.com> wrote in message
news:7fdee71c.0 402051346.5c0fa 32d@posting.goo gle.com...[color=blue]
> I can't understand why Oracle nodes crash so much, but
> it's not a product I know well. Hopefully someone else will explain.[/color]

They don't.


--
Niall Litchfield
Oracle DBA
Audit Commission UK

[Noons]

Re: yipeee!

"Niall Litchfield" <n-litchfield@audi t-commission.gov. uk> wrote in message
news:402366cb$0 $7067$ed9e5944@ reading.news.pi pex.net...[color=blue]
> "Database Guy" <dbguy101@hotma il.com> wrote in message
> news:7fdee71c.0 402051346.5c0fa 32d@posting.goo gle.com...[color=green]
> > I can't understand why Oracle nodes crash so much, but
> > it's not a product I know well. Hopefully someone else will explain.[/color]
>
> They don't.[/color]



Easy to "confuse" hardware with software...

--
Cheers
Nuno Souto
wizofoz2k@yahoo .com.au.nospam

[Serge Rielau]

Re: yipeee!

Mark Townsend wrote:
[color=blue]
> Sigh.
>
> Check out the #1 result at
> http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
> For RAC references go to
> http://www.oracle.com/ultrasearch/ww...=7&p_Query=RAC
>
>
> Did you actually even attempt to look for yourself ?
>[/color]
Ok, I looked.
I fimd three pages of references. Two references to 2 nodes (!), one
reference talking about "either of the nodes" (I take it that means 2,
else it would be any, right?). there is one vendor that states 10 nodes
tested in house but customers use "much smaller configurations" all
other references don't state the number of nodes (at least I couldn't
find them in my quick browse through).
One of the main advertised attractions of RAC for scaleout is that when
one node goes down the load is _shared_ amongst the other nodes.
If the other nodes is one node only, this is no different than failing
over a DB2 MPP system to another active node, doubling that nodes load.
I liked the reference by the Ellis Island customer: They brought the
database utilization doen to 10%-15%. Is that what workload balancing is
all about? 85% idle-time?

Oracle was kind to also offer a non-clustered TPC-C result on the same
infrastructure (10g, HP same box, Linux). Scalability: 58%.

Other than Daniel and Oracle at Openworld I don't see references of 128
nodes anywhere. DB2 with three digit number of nodes runs since years at
an american insurance company.
Oracle themselves stated that more than 8 nodes are really unchartered
territory with Oracle 9. Oracle 10 is not yet out long enough that
anyone can tell me its in production anywhere with a three digit nodes
commitment to RAC without solid proof.

Cheers
Serge

PS: no-one posting in this newsgroup speaks _for_ their company. Please
don't paraphrase what any IBMer states here as "IBM:". You know better
than that. Showing ourselves with our true affiliation is a courtesy to
others, not a promotion to spokes-persons.

--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab

[Mark Townsend]

Re: yipeee!

>. DB2 with three digit number of nodes runs since years at[color=blue]
> an american insurance company.[/color]


You and I both know that the insurance company's data is parititioned by
branch, that each node in question manages the data and the user access
for a given (set of) branch(s) only, and that there is very little
requirements in this particular app for the data from one branch to be
accessed by another branch. So yes, a great example of 'consolidated
federation'. And if thats what the OP wants to do, then they should
definately look at UDB (although SQLServer would be a little cheaper for
this type of architecture)

[Blair Adamache]

Re: yipeee!

Mark Townsend wrote:
[color=blue]
> Sigh.
>
> Check out the #1 result at
> http://www.tpc.org/tpcc/results/tpcc_perf_results.asp[/color]

Double sigh -

Mark B. Townsend (Mark.Townsend@ oracle.com) also wrote:
Subject: Re: What's the fastest database on IBM's fastest computer?

Newsgroups: comp.databases. ibm-db2
Date: 2001-06-22 14:14:01 PST
....
I would contend that TPC-C on a un-clustered SMP environment is a better
indication of database and hardware capabilities than a clustered
result. The real challenge with clusters is not to run larger and faster
TPC-C's, but instead to make them work in typical OLTP environments -
where data cannot be easily partitioned.

[Blair Adamache]

Re: yipeee!

Mark Townsend wrote:
[color=blue]
> I understand perfectly. I am not confused. I know exactly what each
> product is capable off, down to the nth degree. It's my job to know, and
> I'm very,very good at my job.[/color]

Daniel Morgan wrote:
[color=blue]
> Perhaps you need to come take the class I teach on RAC.[/color]

Benchmarks on OLTP and DSS are great - but is TPC working on a benchmark
that measures tpmC? (X of Conceitful transactions in a newsgroup thread)?

[Mark A]

Re: yipeee!

> >. DB2 with three digit number of nodes runs since years at[color=blue][color=green]
> > an american insurance company.[/color]
>
>
> You and I both know that the insurance company's data is parititioned by
> branch, that each node in question manages the data and the user access
> for a given (set of) branch(s) only, and that there is very little
> requirements in this particular app for the data from one branch to be
> accessed by another branch. So yes, a great example of 'consolidated
> federation'. And if thats what the OP wants to do, then they should
> definately look at UDB (although SQLServer would be a little cheaper for
> this type of architecture)
>[/color]
DB2 for LUW and Teradata use hash partitioning, not range partiitoning, so
they don't partition by branch. I don't know why you think insurance
companies access decesion support data by branch anyway, becasue that is not
true. Decsion support queries typcially look at all the data. OLTP systems
may look at data by branch.

[Blair Adamache]

Re: yipeee!

Mike want to consider MQSeries instead of CICS on AIX.

Mark A wrote:
[color=blue]
> "Mark Townsend" <markbtownsend@ comcast.net> wrote in message
>[color=green]
>><snip>
>>Exactly. Note that Oracle does support COBOL ESQL, and both CIC's and
>>DRDA access via Gateways.
>>[/color]
>
> I think you mean CICS. I know that Oracle supports CICS on OS/390, but does
> it support CICS and COBOL on RS/6000 or other UNIX box that CICS may run on?
>
> The originator of this thread (Mike) is thinking of picking up the entire
> OS/390 application and running it on UNIX, probably converting the VSAM to
> an RDMS (at least as a first step), but keeping the COBOL and CICS. There is
> no DRDA access via a Gateway in such an architecture.
>
> BTW, I may be getting a little ornery at Daniel's trolling on this forum,
> but I can assure you that I am not confused.
>
>[/color]

[Mark A]

Re: yipeee!

"Blair Adamache" <badamache@2muc hspam.yahoo.com > wrote in message
news:c00m6m$t3b $1@hanover.toro lab.ibm.com...[color=blue]
> Mike want to consider MQSeries instead of CICS on AIX.
>[/color]
Is that a suggestion, or what Mike said?

I think the issue is that all the application screens are written in CICS
and they initially may want to move the application to RS/6000 without a
major rewrite (except maybe change VSAM to DB2). MQSeries handles messages,
but not user interface.

[Mark Townsend]

Re: yipeee!

I think you will find that the insurance company that Serge is putting
forward is put forward as a clustered OLTP reference, not as clustered
DSS reference.

Mark A wrote:
[color=blue][color=green][color=darkred]
>>>. DB2 with three digit number of nodes runs since years at
>>>an american insurance company.
>>>
>>>[/color]
>>You and I both know that the insurance company's data is parititioned by
>>branch, that each node in question manages the data and the user access
>>for a given (set of) branch(s) only, and that there is very little
>>requirement s in this particular app for the data from one branch to be
>>accessed by another branch. So yes, a great example of 'consolidated
>>federation' . And if thats what the OP wants to do, then they should
>>definately look at UDB (although SQLServer would be a little cheaper for
>>this type of architecture)
>>
>>
>>[/color]
>DB2 for LUW and Teradata use hash partitioning, not range partiitoning, so
>they don't partition by branch. I don't know why you think insurance
>companies access decesion support data by branch anyway, becasue that is not
>true. Decsion support queries typcially look at all the data. OLTP systems
>may look at data by branch.
>
>
>
>[/color]