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

[Blair Adamache]

The systems that started this thread cost over six million dollars and
have 64 CPUs. Presumably, the performance experts of Oracle and HP
worked together to achieve the nn% scalability that took the thread on
this tangent. Don't know if these experts ever took courses at the
University of Washington, or asked for a refund.

Daniel Morgan wrote:

dba wrote:

Daniel Morgan wrote:

Anyone getting only 60% scalability with RAC needs to take the class
I teach. They are missing something essential.

Add every person that's ever tried to scale RAC over 16 nodes. Daniel,
you're going to be a very rich man!

DBA

I'll take you up on it. The class is free...

Now I understand your reference to academic freedom earlier in this thread.

[Buck Nuggets]

Mark Townsend <ma***********@ comcast.net> wrote in message news:<40******* *******@comcast .net>...

What is an OEM licence ?

management purchased the oracle license through the vendor, since it
was much cheaper than either the oracle or db2 licenses.
Unfortunately it turns out that it does not include any kind of oracle
support.

Theoretically, we can get support from the vendor, and in their
opinion the database is an embedded technology within their product.
In reality, oracle, db2, etc aren't very good embedded products and
the vendor doesn't have a good support structure.

buck

[Blair Adamache]

OEM = original equipment manufacturer

Mark Townsend wrote:

What is an OEM licence ?

[Mark Townsend]

Buck Nuggets wrote:

Mark Townsend <ma***********@ comcast.net> wrote in message news:<40******* *******@comcast .net>...

What is an OEM licence ?

management purchased the oracle license through the vendor, since it
was much cheaper than either the oracle or db2 licenses.
Unfortunately it turns out that it does not include any kind of oracle
support.

Theoretically, we can get support from the vendor, and in their
opinion the database is an embedded technology within their product.
In reality, oracle, db2, etc aren't very good embedded products and
the vendor doesn't have a good support structure.

buck

OK - so what we would call an ESL (Embedded Software Licence). Note that
your not really supposed to be installing or upgrading or even patching
the database software in these environments (the vendor is supposed to
send you a new version of their app with the latest and greatest version
in it). I'd be interested in said vendors name if you want to send me
offline. C'est la vie.

[Mark Townsend]

Blair Adamache wrote:

OEM = original equipment manufacturer

Mark Townsend wrote:

What is an OEM licence ?

Thank you - and remember, keep banging the rocks together, guys.

[Joseph]

"Mark A" <ma@switchboard .net> writes:

I don't know what you mean by parallelism of joins and individual buckets.
But Teradata in the mid 1980's worked pretty much the same way DB2 does
today (at a conceptual level). The table was spread across multiple
partitions based on a hash key, and each partition processed the data in
parallel. Cross partition joins were supported.

When you decluster relations across nodes by, say, hash partitioning,
then to join to relations you need to join the corresponding fragments
if they are both hashed on the join attributes in the declustering.
Here I'm using the term fragment for the set of tuples for a relation
stored at a single node after declustering.

You can further parallize the join of a pair of fragments by using
a hash-join algorithm, but using a different hash function than
was used to decluster the relations. This further partitions each
fragment into buckets that can be joined independently of each other.
Each of these bucket joins can be started on separate processors
enable the steps of a hash join of fragments to be computed in parallel.
The initial declustering of relations enables I/O parallelism, but
the hashing with a separate function to compute hash joins of each
pair of fragments enables CPU parallism. Teradata did not support this
in the mid 1980s. It did use a sort-merge join algorithm in which each
fragment can be partitioned into smaller pieces to be sorted in parallel,
but the merge operation is single-threaded so this join algorithm is not
as parallelizable as a hash-join.

The first GAMMA paper describing the system was published and presented at
the VLDB 1986 conference, meaning the paper was submitted in fall 1985. It
would have been a working system by then, so I'd say the shared-nothing
parallel DB architecture was independently developed by Teradata and
DeWitt's research group, with the latter more highly developed
technologically . Of course, Teradata had to spend more time getting
the code to production standards, whereas a research can just do a prototype
as proof of concept.

Cheers,

Joseph

[Mark Townsend]

FYI - Oracle also added this capability (we call it partition-wise join)
when we added Hash partitioning in Oracle8i Release 1 - around
1998/1999. ? Note that only one side of the join actually needs a hash
partition key, the other can be hashed on the fly to match.

And before you ask, yes we will ship the join to the nodes that have
data locality.

Joseph wrote:

"Mark A" <ma@switchboard .net> writes:

I don't know what you mean by parallelism of joins and individual buckets.
But Teradata in the mid 1980's worked pretty much the same way DB2 does
today (at a conceptual level). The table was spread across multiple
partitions based on a hash key, and each partition processed the data in
parallel. Cross partition joins were supported.

When you decluster relations across nodes by, say, hash partitioning,
then to join to relations you need to join the corresponding fragments
if they are both hashed on the join attributes in the declustering.
Here I'm using the term fragment for the set of tuples for a relation
stored at a single node after declustering.

You can further parallize the join of a pair of fragments by using
a hash-join algorithm, but using a different hash function than
was used to decluster the relations. This further partitions each
fragment into buckets that can be joined independently of each other.
Each of these bucket joins can be started on separate processors
enable the steps of a hash join of fragments to be computed in parallel.
The initial declustering of relations enables I/O parallelism, but
the hashing with a separate function to compute hash joins of each
pair of fragments enables CPU parallism. Teradata did not support this
in the mid 1980s. It did use a sort-merge join algorithm in which each
fragment can be partitioned into smaller pieces to be sorted in parallel,
but the merge operation is single-threaded so this join algorithm is not
as parallelizable as a hash-join.

The first GAMMA paper describing the system was published and presented at
the VLDB 1986 conference, meaning the paper was submitted in fall 1985. It
would have been a working system by then, so I'd say the shared-nothing
parallel DB architecture was independently developed by Teradata and
DeWitt's research group, with the latter more highly developed
technologically . Of course, Teradata had to spend more time getting
the code to production standards, whereas a research can just do a prototype
as proof of concept.

Cheers,

Joseph