Re: tough choices

Daniel Morgan wrote:
<snip>
>>>> The data sits on the same physical storage subsystem as it does in a
>>>> shared disc.
>>>> There is no problem for a partition to access that data from any
>>>> physical node it happens to run on using the same technology Oracle
>>>> exploits
>>> It can't use the same technology as shared everything is not shared
>>> nothing and visa versa. Can you clarify what you intended to say?
>> Yes I can, or at least I can try being fairly detached from cables and
>> plugs myself.
>> In an Orcale RAC setup each Oracle instance(?) of the cluster has
>> access to all the data. Obviously the system that the instance is
>> running on must have an interconnect to the storage subsystem.
>> Now while in DB2 with DPF a given databse partition only is allowed
>> access to teh data that it owns. that data usually still lives on the
>> shared storage subsystem and hance teh system that the partition runs
>> on has an interconnect to the that system, just the same as Oracle RAC
>> has.
>> So, the system has access to all the data. The DB2 partition has not.
> Which is critical when considering mean-time between failures which was
> the point I was making.

No it isn't. A node in RAC can die, a DB2 Partition can die. Lets assume both with the same likelyhood (let's put code quality aside for the sake of the argument..)
You have to willing (well you don't ahve to but it would be open mided) to concede that restarting the failed DB2 partition (on a different box) is an alternative to the Oracle RAC approach of redistributing teh work across the remaining RAC nodes.
I don't ask you to say whether it's better or not, I just ask you to consider it an alternative approach to solve the same problem.

>>>> 2. The time it takes to get the partition back into the game
>>>> compared to the failover work a RAC cluster has to do (such as
>>>> remastering locks).
>>> In my tests that is less than one second. Far to small with RAC to be of
>>> concern to anyone.
> Even Oracle's cover-your-a.. marketing talk says 3 seconds. So it really
> is inconsequential.

OK, so recussicating the failed DB2 partition in 3 seconds would then alos fall under inconsequential. And given that most connectiosn to other partitions may not even feel that the DB2 partition is down (because they don't talk to it) then maybe a few more seconds could be granted as acceptable.

>>>> E.g. one can oversize the number of partitions per physical node.
>>> Which equates to what in Oracle?
>> Does it have to equate to anything on Oracle?
>> I just describe a DB2 + DPF setup.
> No. I was trying to determine if there was an equivalency. Often the way
> each vendor uses/misuses words means the same thing exists but appears
> to be different. Or something doesn't exist but appears to.
I think the equivalency would be to run an 15 Node RAC on 3 boxes (on LAPRs perhaps).
If more resources are needed you get 2 more boxes and move 2 nodes from each box over to the two new boxes.
The number of nodes stayed the same, but you gained 66% more horsepower. I doubt that would make much sense with the RAC architecture, but it makes a lot of sense for DB2's.
> I wasn't aware of DPF.

Uhm.. but's what half our discussion in past were about :-(
> Correct me if I am wrong ... but it seems DPF
> is an extra cost add-in only available on ESE systems with that some
> functionality only works on AIX. One question ... is it supported by the
> optimizer?

To the best of my knowledge DPF is offered on all supported platforms of DB2 for LUW. The optimizer is very aware of DPF. An important job is to make sure the function and the data meet in the right place. So only minimal data needs to cross the wire.  > There is also, from what I can see a master instance which,
> if it goes down takes down, the entire thing down with it. Overall not
> a very pretty picture.

Not quite true, but not totally wrong either. The coordinator is the DB2 Partition that a client connects to. Each partition serves as coordinator. There is no master database partition. However, the DB2 catalogs today reside on one specific partition. So, if that partition came down and a local coordinator needed information which is not in it's cache (to compile a new statement referencing e.g. a previously unheard table) then that would be bad. Most customers I know using DB2 + DPF therefore do not allow connections to the catalog partition. It is dedicated to serve meta data.
>And providing functionality available in Oracle
> at no aditional cost, on all operating systems, and without the
> liability of one node being capable of bringing down the entire cluster.
OK, now we are talking licensing. I know neither Oracle nor DB2 licensing well enough to comment. I doubt RAC is free for Oracle's enterprice license, though.
>> The more RAC nodes you have the more likely it is that one of these
>> Dell boxes gets sick.
> But if it gets sick nothing changes.
>> Oracle RAC can fail over and not turn the sick box into a failed system.
> Not in my experience unless I am misunderstanding what you mean by using
> the highly technical term ... "sick." ;-)
Misunderstanding. Its the whole point of RAC to fail over (in contrast to simply fail)

> I've now had a chance to read all of the DPF documentation (well at
> least a lot of it) available on the net. I am far from impressed.
You are a fast reader I must say.

Cheers
Serge

-- 
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab