what's "share-nothing archtecture"?

[Hardy]

I'm pretty new in this field. when reading some 70x material, I met with
this term but cannot catch its accurate meaning. who can help me? thanks in
advance:)~

[Mark A]

"Hardy" <yh********@hotmail.com> wrote in message
news:cc***********@mail.cn99.com...

I'm pretty new in this field. when reading some 70x material, I met with
this term but cannot catch its accurate meaning. who can help me? thanks in advance:)~

Share-nothing architecture refers to parallel processing where a table is
divided into multiple partitions so that the database can work
simultaneously on each partition in parallel. For best results and the most
scalability, each partition would not share hardware resources with other
nodes. These hardware resources include memory, disk drives, disk
controllers, processors, etc. Hence the term, share-nothing.

In a true share-nothing architecture, each database partition is on a
separate computer (physical node) with a high-speed interconnect between
them. This architecture was invented by Teradata, which used multiple Intel
386 PC's and a proprietary operating system in the early 1980's.

Today, with the advent of SMP (Symmetrical Multi-Processing) machines, a
single computer can have multiple CPU's, multiple disks and controllers, and
OS which can effective share memory and other resources among multiple
processes running on a single computer at the same time. However
share-nothing still provides the ability to have linear scalability to very
large databases, whereas the scalability of SMP is not quite linear and
reaches a saturation point at some level.

Most parallel implementations with DB2 are a hybrid of share-nothing and
SMP, where there are multiple physical nodes, but each one is SMP machine.
So in this case, you might have 6 nodes (computers) each with 4 CPU's, and a
total of 24 database partitions (4 per node). True share-nothing would be
one database partition per physical node.

Share-nothing is also used to distinguish DB2 and Teradata from other
parallel implementations such as Oracle, which is not capable of true
share-nothing, even if you had one partition per node, because of the way
the Oracle parallel database works internally. Even though Oracle is not
capable of true share-nothing, it works well for moderate sized parallel
processing of data warehouses, but not quite as good as DB2 and Teradata.
Oracle multiple node implementations, because they are not true
share-nothing, actually enhances its ability to implement failover
capability, expressly because of its lack of a true share-nothing
architecture.

[Data Goob]

Hardy wrote:

I'm pretty new in this field. when reading some 70x material, I met with
this term but cannot catch its accurate meaning. who can help me? thanks in
advance:)~

did you try google? It amazes me how people don't use google.

http://www.google.com

Put in the word "shared-nothing"

http://db.cs.berkeley.edu/papers/hpts85-nothing.pdf

[Daniel Morgan]

Mark A wrote:

Share-nothing is also used to distinguish DB2 and Teradata from other
parallel implementations such as Oracle, which is not capable of true
share-nothing, even if you had one partition per node, because of the way
the Oracle parallel database works internally. Even though Oracle is not
capable of true share-nothing, it works well for moderate sized parallel
processing of data warehouses, but not quite as good as DB2 and Teradata.
Oracle multiple node implementations, because they are not true
share-nothing, actually enhances its ability to implement failover
capability, expressly because of its lack of a true share-nothing
architecture.

I was going to ignore this until I got to this paragraph. Oracle is
not 'incapable of true shared-nothing' ... it is designed with an
entirely different architecture and has no interest in trying shared
nothing.

Well actually Oracle was shared-nothing through version 5 or 6 but
rejected it because of the very issues we have beaten to death multiple
times so I'll no belabor the point again.

Suffice it to say that Oracle, like DB2 on mainframes, is a
shared-everything architecture by intent and no-one I am aware of with
experience with shared-everything has indicated any desire to return
to the bad old days.

--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.washington.edu
(replace 'x' with a 'u' to reply)

[Mark A]

"Daniel Morgan" <da******@x.washington.edu> wrote in message
news:1089044573.775113@yasure...

I was going to ignore this until I got to this paragraph. Oracle is
not 'incapable of true shared-nothing' ... it is designed with an
entirely different architecture and has no interest in trying shared
nothing.

Well actually Oracle was shared-nothing through version 5 or 6 but
rejected it because of the very issues we have beaten to death multiple
times so I'll no belabor the point again.

Suffice it to say that Oracle, like DB2 on mainframes, is a
shared-everything architecture by intent and no-one I am aware of with
experience with shared-everything has indicated any desire to return
to the bad old days.

--
Daniel Morgan

Well, aside from the fact that you quoted me incorrectly, I will say that
apparently Oracle could not make share-nothing work based on the existing
product they already had.

Share-nothing works best for large scalable data warehouses. Share
everything works best for 24x7 applications where failover and zero downtime
is extremely important. But even with share-nothing, most systems can be
brought back up in a few minutes, and their failover capabilities are
steadily improving. But in the end, one has chose which is more
important--scalability or failover.

I did say that Oracle's lack of share nothing did help it with failover
capabilities, but I think that DB2 is quickly catching up even with their
share-nothing architecture.

[Daniel Morgan]

Mark A wrote:

"Daniel Morgan" <da******@x.washington.edu> wrote in message
news:1089044573.775113@yasure...

I was going to ignore this until I got to this paragraph. Oracle is
not 'incapable of true shared-nothing' ... it is designed with an
entirely different architecture and has no interest in trying shared
nothing.

Well actually Oracle was shared-nothing through version 5 or 6 but
rejected it because of the very issues we have beaten to death multiple
times so I'll no belabor the point again.

Suffice it to say that Oracle, like DB2 on mainframes, is a
shared-everything architecture by intent and no-one I am aware of with
experience with shared-everything has indicated any desire to return
to the bad old days.

--
Daniel Morgan

Well, aside from the fact that you quoted me incorrectly, I will say that
apparently Oracle could not make share-nothing work based on the existing
product they already had.

An incorrect assumption. I didn't work in an environment where there was
a desire to have multiversion read consistency ... the ability to have
reads not block writes and writes not block reads. And it has far too
much overhead, in human hours, when adding or removing nodes. And it
decreases mean time between failure.

Don't try to invent reasons ... the reasons have been known and
published for more than a decade.
I did say that Oracle's lack of share nothing did help it with failover
capabilities, but I think that DB2 is quickly catching up even with their
share-nothing architecture.

We shall see. So far what I have seen still involves a parent or master
node that, if lost, causes a loss of service.

I have nothing against shared-nothing when implemented appropriately. My
problem was with what I interpreted as your statement that Oracle
couldn't implement it. Oracle did. Then threw it away.
--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.washington.edu
(replace 'x' with a 'u' to reply)

[Data Goob]

Daniel Morgan wrote:

Mark A wrote:

"Daniel Morgan" <da******@x.washington.edu> wrote in message
news:1089044573.775113@yasure...

I was going to ignore this until I got to this paragraph. Oracle is
not 'incapable of true shared-nothing' ... it is designed with an
entirely different architecture and has no interest in trying shared
nothing.

Well actually Oracle was shared-nothing through version 5 or 6 but
rejected it because of the very issues we have beaten to death multiple
times so I'll no belabor the point again.

I'd love to hear the reasons.
Suffice it to say that Oracle, like DB2 on mainframes, is a
shared-everything architecture by intent and no-one I am aware of with
experience with shared-everything has indicated any desire to return
to the bad old days.

Oracle is shared-everything? I thought it was just shared-disk.
--
Daniel Morgan
Well, aside from the fact that you quoted me incorrectly, I will say that
apparently Oracle could not make share-nothing work based on the existing
product they already had.

Not surprising.

An incorrect assumption. I didn't work in an environment where there was
a desire to have multiversion read consistency ... the ability to have
reads not block writes and writes not block reads. And it has far too
much overhead, in human hours, when adding or removing nodes. And it
decreases mean time between failure.

So it has nothing to do with the Oracle distributed lock manager?

Don't try to invent reasons ... the reasons have been known and
published for more than a decade.
And they are???

I did say that Oracle's lack of share nothing did help it with failover
capabilities, but I think that DB2 is quickly catching up even with their
share-nothing architecture.

We shall see. So far what I have seen still involves a parent or master
node that, if lost, causes a loss of service.

Have you used anything but Oracle?
I have nothing against shared-nothing when implemented appropriately. My
problem was with what I interpreted as your statement that Oracle
couldn't implement it. Oracle did. Then threw it away.

Hee-hee! :o)

I guess Oracle figured there was no need to scale beyond what, 8 servers
in a cluster?

[Daniel Morgan]

Data Goob wrote:

Oracle is shared-everything? I thought it was just shared-disk.
Then you thought 'wrong'.

Don't try to invent reasons ... the reasons have been known and
published for more than a decade.

And they are???

http://otn.oracle.com. Surely you don't need to be spoon fed.
Have you used anything but Oracle?
DB2, Informix, Sybase, Ingres, Teradata, COBOL, and Fortran on
punchcards.
I guess Oracle figured there was no need to scale beyond what, 8 servers
in a cluster?

10g scales to 128. The only place I can remember having an 8 node
limitation is on Solaris with Veritas. And the limitation is Veritas
not Oracle. Oracle scales to more nodes when Veritas is not used.

--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.washington.edu
(replace 'x' with a 'u' to reply)

[Larry]

Come on Daniel ... he means in reality. Don't quote theoreticals. How
many referenceable 128-node implementations of shared-everything,
shared-disk or whatever you want to call it ... does Oracle have?

Larry Edelstein

Daniel Morgan wrote:

Data Goob wrote:

Oracle is shared-everything? I thought it was just shared-disk.

Then you thought 'wrong'.

Don't try to invent reasons ... the reasons have been known and
published for more than a decade.

And they are???

http://otn.oracle.com. Surely you don't need to be spoon fed.

Have you used anything but Oracle?

DB2, Informix, Sybase, Ingres, Teradata, COBOL, and Fortran on
punchcards.

I guess Oracle figured there was no need to scale beyond what, 8
servers in a cluster?

10g scales to 128. The only place I can remember having an 8 node
limitation is on Solaris with Veritas. And the limitation is Veritas
not Oracle. Oracle scales to more nodes when Veritas is not used.

[Data Goob]

Daniel Morgan wrote:

Data Goob wrote:

Oracle is shared-everything? I thought it was just shared-disk.

Then you thought 'wrong'.

OK on Sun Starfire UE 10000 it's shared-everything, but is that on
all platforms? I think not--or would be very surprised if Oracle
on a typical 4-cpu or 8-cpu system could even work as shared-
everything. And my knowledge of Starfire is from a few years ago,
with Oracle 7 and 8. Intel is different hardware, and it is
questionable if Intel CPUs are even capable of the high-bandwidth
required to make SE work at the same levels as the Starfire--it's
not going to even approximate SE without the wheels coming off.
But I could be wrong...maybe it could work today. But big iron
systems are still very expensive, and a lot of shops can instead
cluster lower-end hardware and still get remarkable performance--to
wit the Opteron 2-cpu systems that DB2 can be clustered on with
shared-nothing.

Don't try to invent reasons ... the reasons have been known and
published for more than a decade.

And they are???

http://otn.oracle.com.

....
Surely you don't need to be spoon fed.

Can't argue with that. But I think it's important to note that
Oracle is not the same beast on all platforms, it cannot be exactly
the same on the Starfire as it would be on an Intel system, it
would simply not function the same.

Have you used anything but Oracle?

DB2, Informix, Sybase, Ingres, Teradata, COBOL, and Fortran on
punchcards.

I guess Oracle figured there was no need to scale beyond what, 8
servers in a cluster?

10g scales to 128. The only place I can remember having an 8 node
limitation is on Solaris with Veritas. And the limitation is Veritas
not Oracle. Oracle scales to more nodes when Veritas is not used.

Hmmmm, not what I read. Every time I hear about Oracle it's their
distributed lock manager that degrades over N servers. The more servers
the more complicated it gets.

[Daniel Morgan]

Data Goob wrote:

Daniel Morgan wrote:

Data Goob wrote:

Oracle is shared-everything? I thought it was just shared-disk.
Then you thought 'wrong'.

OK on Sun Starfire UE 10000 it's shared-everything, but is that on
all platforms?

Yes. Because unlike some other RDBMS products there is only a single
code base specificatin. There is no difference in any regard between
running Oracle on any compatible operating system.

I think not--or would be very surprised if Oracle on a typical 4-cpu or 8-cpu system could even work as shared-
everything.

Then be surprised.

Don't try to invent reasons ... the reasons have been known and
published for more than a decade.

And they are???

http://otn.oracle.com.

...

>Surely you don't need to be spoon fed.

Can't argue with that. But I think it's important to note that
Oracle is not the same beast on all platforms, it cannot be exactly
the same on the Starfire as it would be on an Intel system, it
would simply not function the same.

Nonsense. Sorry but nonsense. I can not think of a single SQL or PL/SQL
command or built-in package or function or functionality that is not
identical on every platform and operating system.

Have you used anything but Oracle?

DB2, Informix, Sybase, Ingres, Teradata, COBOL, and Fortran on
punchcards.

I guess Oracle figured there was no need to scale beyond what, 8
servers in a cluster?

10g scales to 128. The only place I can remember having an 8 node
limitation is on Solaris with Veritas. And the limitation is Veritas
not Oracle. Oracle scales to more nodes when Veritas is not used.

Hmmmm, not what I read. Every time I hear about Oracle it's their
distributed lock manager that degrades over N servers. The more servers
the more complicated it gets.

Well if that is true then you need to explain that to those nice folks
at amazon.com who somehow managed to miss that. You'll also have to
explain it to Boeing, and to numerous other firms of which I am
knowledgeable.

The reason I am so focused on Oracle these days, even though in the past
I worked on many RDBMS products is that, quite simply, that is where the
demand is here in the Pacific Northwest. You either work on SQL Server
or Oracle (with very few exceptions) and SQL Server is not something
that I feel particularly good about except for department level apps.
--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.washington.edu
(replace 'x' with a 'u' to reply)

[datab0y]

Daniel Morgan <da******@x.washington.edu> wrote in message news:<1089044573.775113@yasure>...

Well actually Oracle was shared-nothing through version 5 or 6 but
rejected it because of the very issues we have beaten to death multiple
times so I'll no belabor the point again.

Suffice it to say that Oracle, like DB2 on mainframes, is a
shared-everything architecture by intent and no-one I am aware of with
experience with shared-everything has indicated any desire to return
to the bad old days.

Two questions:

1. Why do you bother haunting a db2 forum? You neither ask questions
nor offer advice within a db2 context. You only shill for oracle.
What's the deal? Are you on their dime, or are you damaged in some
way?

2. Last I looked (about two years ago) the Meta Group (or was it
Gartner) cited Oracle as a high-risk at the 5+ terabyte data warehouse
size. Only Teradata & DB2 were considered low-risk options at that
size. Was this due to Oracle's rejection of shared-nothing? Perhaps
due to licensing costs? Perhaps due to the nature of Oracle
partitioning (which is excellent at economizing hardware for small
rolling-windows of data, but stinks when you want all partitions)?
Unfortunately, the analyst article that I read didn't state the nature
of Oracle's limitation at the highest scalability limits. Perhaps I
need to see if the analysts think that somehow 10g's failover
capabilities help out in the scalability arena...

just wondering...

[Mark A]

> Two questions:

1. Why do you bother haunting a db2 forum? You neither ask questions
nor offer advice within a db2 context. You only shill for oracle.
What's the deal? Are you on their dime, or are you damaged in some
way?

just wondering...

1. Daniel is a troll and a menace to society. Everyone else comes to this
forum to ask questions or to provide help to others who have questions or
problems. Daniel has never helped anyone on this forum. He does like to
advertise his services with his web links, but I doubt that anyone who has
read all his posts would listen to his advice, much less pay for it.

[Daniel Morgan]

Comments in-line.

da*****@yahoo.com wrote:

Daniel Morgan <da******@x.washington.edu> wrote in message news:<1089044573.775113@yasure>...

Well actually Oracle was shared-nothing through version 5 or 6 but
rejected it because of the very issues we have beaten to death multiple
times so I'll no belabor the point again.

Suffice it to say that Oracle, like DB2 on mainframes, is a
shared-everything architecture by intent and no-one I am aware of with
experience with shared-everything has indicated any desire to return
to the bad old days.

Two questions:

1. Why do you bother haunting a db2 forum? You neither ask questions
nor offer advice within a db2 context. You only shill for oracle.
What's the deal? Are you on their dime, or are you damaged in some
way?

I don't own a share of stock in any software company that would be a
conflict of interest for my teaching at the University of Washington.
Nor do I take money from any for any reason whatsoever.

I visit all of the c.d. forum regularly because:

1. It helps me with my teaching.
2. It keeps me current with the topics of discussion in the industry
3. I have every one of these products installed on a machine and keep
my skill set reasonably current for projects involving system
migration.
2. Last I looked (about two years ago) the Meta Group (or was it
Gartner) cited Oracle as a high-risk at the 5+ terabyte data warehouse
size. Only Teradata & DB2 were considered low-risk options at that
size. Was this due to Oracle's rejection of shared-nothing? Perhaps
due to licensing costs? Perhaps due to the nature of Oracle
partitioning (which is excellent at economizing hardware for small
rolling-windows of data, but stinks when you want all partitions)?
Unfortunately, the analyst article that I read didn't state the nature
of Oracle's limitation at the highest scalability limits. Perhaps I
need to see if the analysts think that somehow 10g's failover
capabilities help out in the scalability arena...

just wondering...

The two largest Oracle databases of which I am aware ... there may well
be larger ... is 1.5 peta. I haven't worked on more than a handful of
databases in the last two years that were less than terabyte size.
Without knowing the author's name(s) and affiliation(s) it is impossible
to tell on what basis or for what purpose a statement may have been
made.

If there are limitations at 5TB ... once again ... that will be news to
the fine people at amazon.com and Boeing. When I was at Boeing working
on DCAC we were putting data warehouses into Teradata: These days they
stay in Oracle.

Failover and scalability are two entirely different things and I can't
imagine how they end up in the same sentence. But all of my personal
uses of Oracle partitioning such as range partitions with hash
subpartitions has always involved large GB or TB. Not once have I ever
seen them used for "small rolling windows of data" to quote you. But
rather for performance and maintainability on very very large quantities
of data.

--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.washington.edu
(replace 'x' with a 'u' to reply)

[Daniel Morgan]

Mark A wrote:

Two questions:

1. Why do you bother haunting a db2 forum? You neither ask questions
nor offer advice within a db2 context. You only shill for oracle.
What's the deal? Are you on their dime, or are you damaged in some
way?

just wondering...

1. Daniel is a troll and a menace to society. Everyone else comes to this
forum to ask questions or to provide help to others who have questions or
problems. Daniel has never helped anyone on this forum. He does like to
advertise his services with his web links, but I doubt that anyone who has
read all his posts would listen to his advice, much less pay for it.

In my first post to this thread I clearly indicated that it was not my
intention to post here until you chose to post totally misleading
(read non-factual) information. And my only purpose was to correct your
misstatement.

If this thread has persisted it is because you chose not to just say ...
oops and let it pass. I'm not trolling ... but rather responding to you.
So if you wish to this to end ... just don't respond. Simple eh!
--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.washington.edu
(replace 'x' with a 'u' to reply)

[Data Goob]

Daniel Morgan wrote:

Data Goob wrote:

OK on Sun Starfire UE 10000 it's shared-everything, but is that on
all platforms?

Yes. Because unlike some other RDBMS products there is only a single
code base specificatin. There is no difference in any regard between
running Oracle on any compatible operating system.

I would still be skeptical about the underlying activity, the "code
base" is actually **not** the same simply because of different hardware
architectures. The ability to manage cache coherence, i/o bandwidth,
and a whole bunch of other hardware items can drastically affect how
the database will perform. It might be transparent to you the end-user,
but how the hardware is laid out, not to mention disks can make all the
difference in the world. Which is why Oracle may perform well in a
big SMP environment and poorly elsewhere. It will do well on the
Starfire, or Superdome, but cannot be expected to work as well on
Intel simply because the hardware ( read CPUs, memory, bus ) are
not the same as the Starfire or Superdome. In that regard I can get
a lot more bang for the buck not using Oracle. I still fail to see
how 10G will cluster well ( if at all ) without the use of shared-
nothing on small 1U boxes.
....
Nonsense. Sorry but nonsense. I can not think of a single SQL or PL/SQL
command or built-in package or function or functionality that is not
identical on every platform and operating system.

They can be the same to the end-user, but the underlying hardware
can make all the difference in the world, and that means that the
software libraries will compile differently, and the software will
work differently, same for DB2, or any software package. The commands
may be typed on the keyboard the same but the behavior of the software
will indeed be different. This is why Oracle will do well on big SMP
and not so well outside of big iron systems.

Hmmmm, not what I read. Every time I hear about Oracle it's their
distributed lock manager that degrades over N servers. The more servers
the more complicated it gets.

Well if that is true then you need to explain that to those nice folks
at amazon.com who somehow managed to miss that. You'll also have to
explain it to Boeing, and to numerous other firms of which I am
knowledgeable.

If they are using Oracle they are spending a lot of money to make
it work with big data. Maybe they have it on Starfires and HP
Superdomes, but geezuz, that's not considered the norm.
The reason I am so focused on Oracle these days, even though in the past
I worked on many RDBMS products is that, quite simply, that is where the
demand is here in the Pacific Northwest. You either work on SQL Server
or Oracle (with very few exceptions) and SQL Server is not something
that I feel particularly good about except for department level apps.

Hard to imagine otherwise.

[datab0y]

Daniel Morgan <da******@x.washington.edu> wrote in message news:<1089095289.250023@yasure>...

I visit all of the c.d. forum regularly because:

1. It helps me with my teaching.
2. It keeps me current with the topics of discussion in the industry
3. I have every one of these products installed on a machine and keep
my skill set reasonably current for projects involving system
migration.

Sounds great. But really doesn't answer why your only involvement in
the db2 group is to pan db2 and talk about oracle. Sure, sometimes
you probably correct non-factual oracle info. But you create so much
non-factual db2 carnage that your posts are a hazard to any
unfortunate readers that might actually base decisions upon your info.

So, either you are failing miserably to live up to your goals. Or you
haven't honestly stated your goals. Why don't you just stay on the
oracle group where they may tolerate oracle shills somewhat more?

[Rahul Kitchlu]

"Daniel Morgan" <da******@x.washington.edu> wrote in message
news:1089095289.250023@yasure...

The two largest Oracle databases of which I am aware ... there may well
be larger ... is 1.5 peta. I haven't worked on more than a handful of
databases in the last two years that were less than terabyte size.
Without knowing the author's name(s) and affiliation(s) it is impossible
to tell on what basis or for what purpose a statement may have been
made.

If there are limitations at 5TB ... once again ... that will be news to
the fine people at amazon.com and Boeing. When I was at Boeing working
on DCAC we were putting data warehouses into Teradata: These days they
stay in Oracle.

Failover and scalability are two entirely different things and I can't
imagine how they end up in the same sentence. But all of my personal
uses of Oracle partitioning such as range partitions with hash
subpartitions has always involved large GB or TB. Not once have I ever
seen them used for "small rolling windows of data" to quote you. But
rather for performance and maintainability on very very large quantities
of data.
--
Daniel Morgan

Database sizes managed by RDBMS are growing universally for Oracle and for
others, I think the main point is that Oracle will find it hard to keep up
at the edge of these systems due to scalability issues with shared
everything architecture. Oracle tried shared-nothing, failed at it and threw
it out. Now they are trying their hand at shared-everything approach to keep
up the hype. Shared-everything architecture on distributed hardware has
technical 'built-in' limitations. Marketing foils may give a gleaming
picture of the so-called Grid syndrome using db clusters on commodity
hardware that provide availability, scalability, performance, etc. The truth
is that replicating hardware coupling as on the zOS in the software layer on
distributed platforms just wouldnt work. You are bound to run in
sychronization limitations at the cache interconnect, serialization issues
for I/O, full membership needs at cluster manager layer, etc. Heck, DB2
invented shared-everything architecture on z/OS, if it were so great they
would have been the first ones to port it to distributed platforms. If
reference accounts are the talk of the town here, I am sure that any DB2 rep
can match/better any other RAC installs, specially in the DSS space. All RAC
can provide out of the box right now is faster 'instace' failover. Repeat:
just instance failover, which is not a complete availability story. And even
there this architecture introduces other single points of failure like the
shared disk, gcs, interconnect switch, etc. And yes, performance and
scaling... shared-everything architecture (RAC) does not include
partitioning!! Range and hash partitions might help with performance and
scale a bit, but then you are talking about shared-nothing NOT
shared-everything. If you understood the writeup thus far, I shouldnt have
to explain.

Cheers.

[Hardy]

oh, thank you all. your discussion benefit me much.

in the last two days I'm in a learning lab outside so be late to say thanks
to you all:)

"Data Goob" <da******@hotmail.com> ????
news:Qz****************@fe44.usenetserver.com...

Hardy wrote:

I'm pretty new in this field. when reading some 70x material, I met with
this term but cannot catch its accurate meaning. who can help me? thanks in advance:)~

did you try google? It amazes me how people don't use google.

http://www.google.com

Put in the word "shared-nothing"

http://db.cs.berkeley.edu/papers/hpts85-nothing.pdf

[Daniel Morgan]

Data Goob wrote:

Daniel Morgan wrote:

I would still be skeptical about the underlying activity, the "code
base" is actually **not** the same simply because of different hardware
architectures. The ability to manage cache coherence, i/o bandwidth,
and a whole bunch of other hardware items can drastically affect how
the database will perform. It might be transparent to you the end-user,
but how the hardware is laid out, not to mention disks can make all the
difference in the world. Which is why Oracle may perform well in a
big SMP environment and poorly elsewhere.

I will agree with you in theory but not in practice. Take a look at
two examples that I think will make the case:

1. Amazon.com has tossed out all but two of its big expensive SMP boxes
and now runs Oracle and its operations entirely on Intel and Linux.

2. Oracle Corp. has tossed out all but a handful of its big expensive
SMP and now runs its operations on Dell and RedHat.

Neither of these firms would have done so it it hurt them. And at a
wholly owned subsidiary of Boeing of which I am very intimately aware
I am presenting to the leadership team a plan to fork-lift out of the
buildings Sun-Solaris boxes and replace with Del-RedHat. And I have
all the metrics ... both performance and financial ... to support the
recommendation.

So your assumption and conclusion are not valid. Certainly not since
in the last three years.
--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.washington.edu
(replace 'x' with a 'u' to reply)

[Daniel Morgan]

da*****@yahoo.com wrote:

Daniel Morgan <da******@x.washington.edu> wrote in message news:<1089095289.250023@yasure>...

I visit all of the c.d. forum regularly because:

1. It helps me with my teaching.
2. It keeps me current with the topics of discussion in the industry
3. I have every one of these products installed on a machine and keep
my skill set reasonably current for projects involving system
migration.

Sounds great. But really doesn't answer why your only involvement in
the db2 group is to pan db2 and talk about oracle.

Actually it does. And in the words of Samuel Johnson:

"Sir, I have found you an explanation, but I am not obliged to find you
an understanding."

--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.washington.edu
(replace 'x' with a 'u' to reply)

[Daniel Morgan]

Rahul Kitchlu wrote:

Oracle tried shared-nothing, failed at it and threw
it out. Now they are trying their hand at shared-everything approach to keep
up the hype.
Now means for more than a decade. You make it sound like a decision made
last week.
Shared-everything architecture on distributed hardware has
technical 'built-in' limitations.

Which are?

--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.washington.edu
(replace 'x' with a 'u' to reply)

[Mark Townsend]

Mark A wrote:

Share-nothing is also used to distinguish DB2 and Teradata from other
parallel implementations such as Oracle,
Correct
which is not capable of true
share-nothing, even if you had one partition per node, because of the way
the Oracle parallel database works internally.
Debatable - It gets pretty damn close with some of the supported node
affinity, and the ability to push partition wise joins down. It's unfair
to categorize it as a limitation of Oracle's parallel database
capability. It's just a difference in approach. Basically shared nothing
trys to drive towards large parallel scans, and tends to need a lot of
hardware to do this (something IBM and Teradata have no actual problem
with :-) ). Oracle tends to try to use the optimizer and advanced
indexing strategies to avoid the need to do a large parallel scan, but
can do it if required. Horses for courses, youse pays youse monies and
takes youse choice.
Even though Oracle is not
capable of true share-nothing, it works well for moderate sized parallel
processing of data warehouses, but not quite as good as DB2 and Teradata.
It works pretty damn well for big ones as well - see
http://www.wintercorp.com/VLDB/2003_...%20Winners.pdf

Suprisingly enough, not a lot of mention the 'better' DB2 here. And the
one mention wants to remain Anonymous. Who could it be ? But I'm being
facetious.
Oracle multiple node implementations, because they are not true
share-nothing, actually enhances its ability to implement failover
capability, expressly because of its lack of a true share-nothing
architecture.

Correct. And in fact, Oracle's multi node capability (RAC) is used more
significantly in OLTP environments, where availability and low cost
scalability for ALL data operations (not just read/load) is important.
Typically is it difficult to set a shared nothing environment up to work
well for these other types of applications.

[Mark Townsend]

da*****@yahoo.com wrote:

2. Last I looked (about two years ago) the Meta Group (or was it
Gartner) cited Oracle as a high-risk at the 5+ terabyte data warehouse
size.

It was Gartner, and in fact, they also included DB2 as high risk as
well, scoring Teradata first on their Magic Quadrant, with IBM and
Oracle roughly equal. This has since changed, and if you have a spare
$495 you can check out the new DW MQ at
http://www3.gartner.com/DisplayDocument?doc_cd=121302

Note the quote from Kevin Strange

"The data warehouse database management system market lost participants
and lacked excitement. Yet, in the last 18 months, competition continued
to heat up, Netezza entered the market and leaders shifted."

Wonder which leaders shifted, and in what direction ?

[Mark Townsend]

Mark A wrote:

Two questions:

1. Why do you bother haunting a db2 forum? You neither ask questions
nor offer advice within a db2 context. You only shill for oracle.
What's the deal? Are you on their dime, or are you damaged in some
way?

just wondering...

1. Daniel is a troll and a menace to society. Everyone else comes to this
forum to ask questions or to provide help to others who have questions or
problems. Daniel has never helped anyone on this forum. He does like to
advertise his services with his web links, but I doubt that anyone who has
read all his posts would listen to his advice, much less pay for it.

I find this categorization slightly hypocritical. Daniel simply
responded to your un-solicited statements about Oracle, as is his wont.
The OP did not ask for your (or anybodies) opininon on Oracle, and did
not post to an Oracle group, yet you found the need to dis Oracle in
your reply. I actually think that the monotony that this question comes
up on c.d.i (and is never cross posted elsewhere), is sometimes boarding
on what I would call a troll itself.