Peoplesoft on Federated UDB?

[BadPony]

Anyone using Peoplesoft on a Federated UDB
(shared nothing)Environ ment on Open System Platforms?
Preferably AIX, but any war stories would be good.

TEA
EB-C

[Serge Rielau]

Bad Pony,

I haven't but I'm a DB2 developer, not a consultant.
Note that IBM is pushing DPF for BI which is not what Peoplesoft does AFAIK.
An SAP BW would be a different story alltogether.

Cheers
Serge

[Mark A]

"Serge Rielau" <sr*****@ca.e ye-be-em.com> wrote in message
news:bu******** **@hanover.toro lab.ibm.com...

A question of definition I suppose. I suppose for the reasons you stated
commonly "shared nothing" refers (or at least I refer) to logical
ownership. I.e a node will neither share memory, nor data with any other
node.
You are correct that today this does neither mean that the nodes may not
share the same box right down to real RAM a single CPU and the hard drive. I.e. I can run DB2 with several nodes (shared nothing) on my Laptop and
I do that on occasion.

Interestingly thsi means that the lines beween "shared disk" and "shared
nothing" contiously blur. E.g. while in Oracle RAC ("shared disk") each
node can get any data, there is AFAIK still one node that "controls" a
given pice of data at least from a locking perspective. (resulting in a
redistribution of the control when a node goes down).
(I'm sure if I'm wrong Daniel M. and Mark T. will not hesitate to
correct me :-)
Similarly in DB2 a failing node can be replaced by another node.
The truth (or let's call it winning architecture), in the end, will be
somewhere in the middle I'd guess and it will be neither shared disk,
nor shared nothing.

Cheers
Serge

Share nothing parallel architecture has no real meaning in for a single
partition database on a single node. That makes no sense because there are
not multiple partitions that share hardware resources. "Share nothing" or
"share whatever" only makes sense in the context of a multi-partition
database.

I didn't mean to suggest that in a share nothing environment, that
nodes/partitions don't sometimes share data, such as when a failover happens
or when join takes place that causes data to be transferred from one
node/partition to another. That really has nothing to do with whether an
architecture is share nothing, since the partitioning scheme of the data is
determined by DBA and not by the hardware or database software.

Early implementations of share nothing parallel database where limited by
the hardware. The last "forced" share nothing architecture from Teradata was
implemented on nodes that consisted of Intel 486 PC's running a propriety
16-bit OS that was incapable of sharing hardware resources. The first
implementations of DB2 PE (Parallel Edition) were implemented on single
processor RS/6000 nodes (AIX SMP was not available at that time IIRC), so
one DB2 partition per physical node was the norm.

The point is that share nothing is the relationship between the hardware
node and the logical partition. Most large scale IW parallel databases have
moved away from shared nothing because for price/performance reasons, as the
improvements in hardware and SMP operating systems makes at least some
sharing much more efficient and scalable. Although it is certainly true in
terms of absolute performance, that shared nothing does scale in a more
linear way when extremely large databases are needed. But shared nothing is
usually not the best in terms of price/performance.

Interestingly, recent hardware solutions provided with the IBM eServer 325
(and perhaps other vendors) has rekindled interest in share nothing (or
share less) implementations because of the affordability of AMD 64 bit nodes
on IBM blades. The IBM benchmarks for TPC-H used 2 partitions per physical
node (with a dual processor), but it would have been interesting to see the
difference in absolute performance and price/performance if they had only
used on partition per physical node.

Note that if one only creates a single partition on a dual-processor (or
more) physical node (blade), that is not sharing. The CPU's are not shared
with any other partition.

[Mark Townsend]

> E.g. while in Oracle RAC ("shared disk") each

node can get any data, there is AFAIK still one node that "controls" a
given pice of data at least from a locking perspective. (resulting in a
redistribution of the control when a node goes down).
Hmm - a little understated I think. A data block in a nodes memory will
have the associated locking information in the same memory as well. The
same data block can also be in memory on different nodes - each with
it's own lock information.

It's only when the the data is being updated that a special write lock
is migrated to or "mastered on" the node that is actually doing the
update. This is the Cache Fusion aspect of RAC (basically we use shared
memory techniques to do this).

However, there is not a single mastering node, as all nodes can be
masters of different bits of data at the same time.

If a node goes down, then any data blocks in that node's memory that
were dirty from writes need to be rebuilt and remastered on the
surviving nodes (maybe - if nobody wants them, you can do it later). So
hot blocks are read from disk (or, given that they are hot, will
probably already be in the recovering nodes memory), redo is applied,
and on you go.

Interestingly enough, the more nodes, the less work per node that needs
to be done if a node goes down. Makes the low cost blade environments
Mark alluded to a very, very interesting proposition.
(I'm sure if I'm wrong Daniel M. and Mark T. will not hesitate to
correct me :-)
Similarly in DB2 a failing node can be replaced by another node.

Well, there is actually no similarity between the time Oracle RAC takes
to re-build the dirty blocks from a lost node, and the time required for
a node to takeover another node's disk. The outage on one is measured in
seconds, the other isn't.

[Daniel Morgan]

Mark A wrote:

"Serge Rielau" <sr*****@ca.e ye-be-em.com> wrote in message
news:bu******** **@hanover.toro lab.ibm.com...

A question of definition I suppose. I suppose for the reasons you stated
commonly "shared nothing" refers (or at least I refer) to logical
ownership. I.e a node will neither share memory, nor data with any other
node.
You are correct that today this does neither mean that the nodes may not
share the same box right down to real RAM a single CPU and the hard

drive.

I.e. I can run DB2 with several nodes (shared nothing) on my Laptop and
I do that on occasion.

Interesting ly thsi means that the lines beween "shared disk" and "shared
nothing" contiously blur. E.g. while in Oracle RAC ("shared disk") each
node can get any data, there is AFAIK still one node that "controls" a
given pice of data at least from a locking perspective. (resulting in a
redistributio n of the control when a node goes down).
(I'm sure if I'm wrong Daniel M. and Mark T. will not hesitate to
correct me :-)
Similarly in DB2 a failing node can be replaced by another node.
The truth (or let's call it winning architecture), in the end, will be
somewhere in the middle I'd guess and it will be neither shared disk,
nor shared nothing.

Cheers
Serge

Share nothing parallel architecture has no real meaning in for a single
partition database on a single node. That makes no sense because there are
not multiple partitions that share hardware resources. "Share nothing" or
"share whatever" only makes sense in the context of a multi-partition
database.

I didn't mean to suggest that in a share nothing environment, that
nodes/partitions don't sometimes share data, such as when a failover happens
or when join takes place that causes data to be transferred from one
node/partition to another. That really has nothing to do with whether an
architecture is share nothing, since the partitioning scheme of the data is
determined by DBA and not by the hardware or database software.

Early implementations of share nothing parallel database where limited by
the hardware. The last "forced" share nothing architecture from Teradata was
implemented on nodes that consisted of Intel 486 PC's running a propriety
16-bit OS that was incapable of sharing hardware resources. The first
implementations of DB2 PE (Parallel Edition) were implemented on single
processor RS/6000 nodes (AIX SMP was not available at that time IIRC), so
one DB2 partition per physical node was the norm.

The point is that share nothing is the relationship between the hardware
node and the logical partition. Most large scale IW parallel databases have
moved away from shared nothing because for price/performance reasons, as the
improvements in hardware and SMP operating systems makes at least some
sharing much more efficient and scalable. Although it is certainly true in
terms of absolute performance, that shared nothing does scale in a more
linear way when extremely large databases are needed. But shared nothing is
usually not the best in terms of price/performance.

Interestingly, recent hardware solutions provided with the IBM eServer 325
(and perhaps other vendors) has rekindled interest in share nothing (or
share less) implementations because of the affordability of AMD 64 bit nodes
on IBM blades. The IBM benchmarks for TPC-H used 2 partitions per physical
node (with a dual processor), but it would have been interesting to see the
difference in absolute performance and price/performance if they had only
used on partition per physical node.

Note that if one only creates a single partition on a dual-processor (or
more) physical node (blade), that is not sharing. The CPU's are not shared
with any other partition.

The only two commecial RDBMS products with shared nothing architecture
are DB2 on mainframes (not other platforms) and Oracle on all platforms.
It will be nice when IBM can implement this for DB2 on all platforms.

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

[Daniel Morgan]

Mark Townsend wrote:

> E.g. while in Oracle RAC ("shared disk") each

node can get any data, there is AFAIK still one node that "controls" a
given pice of data at least from a locking perspective. (resulting in
a redistribution of the control when a node goes down).

Hmm - a little understated I think. A data block in a nodes memory will
have the associated locking information in the same memory as well. The
same data block can also be in memory on different nodes - each with
it's own lock information.

It's only when the the data is being updated that a special write lock
is migrated to or "mastered on" the node that is actually doing the
update. This is the Cache Fusion aspect of RAC (basically we use shared
memory techniques to do this).

However, there is not a single mastering node, as all nodes can be
masters of different bits of data at the same time.

If a node goes down, then any data blocks in that node's memory that
were dirty from writes need to be rebuilt and remastered on the
surviving nodes (maybe - if nobody wants them, you can do it later). So
hot blocks are read from disk (or, given that they are hot, will
probably already be in the recovering nodes memory), redo is applied,
and on you go.

Interestingly enough, the more nodes, the less work per node that needs
to be done if a node goes down. Makes the low cost blade environments
Mark alluded to a very, very interesting proposition.

(I'm sure if I'm wrong Daniel M. and Mark T. will not hesitate to
correct me :-)
Similarly in DB2 a failing node can be replaced by another node.

Well, there is actually no similarity between the time Oracle RAC takes
to re-build the dirty blocks from a lost node, and the time required for
a node to takeover another node's disk. The outage on one is measured in
seconds, the other isn't.

I'm flattered that someone mentioned us by name "Daniel M. and Mark T.
will not hesitate" and we didn't.

Taught a RAC class just today ... we created the equivalent of a 6 CPU
mid-size box with a few thousand dollars worth of commodity Intel-based
hardware, a couple switches, and a NetApp NAS filer head. Not just
scalability but fail-over. One at a time we pulled the plug on 5 of the
machines and each time, with only a 15-20 seconds delay, the load was
redistributed until number six took over the entire load and not a
single transaction rolled back. Ah beauty of shared nothing.

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

[Serge Rielau]

I'll let that last one go or we'll have to nest OTs....
Actually I let that whole thread go.

Cheers
Serge

PS: Mark: if you folks don't deliver O10g within a week you'll have an
expired TPC-C result on your hands.. What's up?

[Serge Rielau]

I trust you just confused a few words here.... DB2 z/Series is shared
disk and so is Oracle RAC.

[Daniel Morgan]

Serge Rielau wrote:

I'll let that last one go or we'll have to nest OTs....
Actually I let that whole thread go.

Cheers
Serge

PS: Mark: if you folks don't deliver O10g within a week you'll have an
expired TPC-C result on your hands.. What's up?

I've got 10g ... don't you? ;-)

In a few weeks I'll send you my copy.

Good question Serge ... yeah Mark ... What's up? ;-)

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

[Daniel Morgan]

Serge Rielau wrote:

I trust you just confused a few words here.... DB2 z/Series is shared
disk and so is Oracle RAC.

Old syntax habits die hard.

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

[Mark A]

"Daniel Morgan" <da******@x.was hington.edu> wrote in message
news:1075003854 .992919@yasure. ..

The only two commecial RDBMS products with shared nothing architecture
are DB2 on mainframes (not other platforms) and Oracle on all platforms.
It will be nice when IBM can implement this for DB2 on all platforms.

--
Daniel Morgan

DB2 for Linux, UNIX and Windows clearly supports shared nothing
architecture. This is really a hardware issue, not a software issue. AFAIK,
all multi-node parallel databases that support multiple nodes, also support
shared nothing hardware (one database partition per physical node), although
it is often not cost effective to implement that way.