Re: tough choices

Daniel Morgan wrote:

> If I have a single table in a tablespace in Oracle stored in a single
> datafile the data is equally accessible from all nodes. Lose a node and
> there is no negative effect on the ability to access any part of a the
> data in that table. Federate the data as is required by shared nothing
> architectures and the loss of a single node effectively kills the
> system.
>
> Thus with shared everything the more nodes the less likely a failure
> whereas with shared nothing loss of a node makes part of the data
> inaccessible.

Let's clarify the lingo:
DB2 II uses federation. One of the main properties of federation is that any one piece of the federation is pretty independent from the rest. They may not even know or admit they are part of it (a bit like Bavaria or Quebec ;-)
DB2 UDB for LUW + DPF is a partitioned DBMS. The partitioning is done on a logical level. Partitions assume logical (not physical) ownership of data. If a partition goes down it can either simply be restarted, or, if there is a problem with the hardware that hosts the partiton the partition can be restarted on another hardware.
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

So the question really boils down to this: 1. The time it takes to detect a partition is down. That is a universal problem independent of the underlying technology. 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).

A curious fact (no more no less) is that there are numerous kinds of applications where a set of clients only ever accesses one or a few partitions of the overall system. In these cases an unrelated partition can fail over completely without notice by those clients. An example may be the operation of a retail store chain with a partitioning key on the store id. While headquartes may not be able to get the big picture while a partition fails over, most the individual stores can operate without a hitch throughout the event.

It's my understanding that remastering locks by contrast has a global impact. Does this happen twice, btw? First time when the node goes down. Second time when it comes up?

While _adding_ a partition to increase capacity would usually be followed by a redistribute which, today, has significant impact, the fact that nodes are not physical has interesting implications. E.g. one can oversize the number of partitions per physical node. When more capacity is needed additional hardware can be made available and the partitions themselves get redistributed amongst the new infrastructure. Note that no data has to move since no partition was added or removed.
Similarly one would never remove a partition during an HA event or to lower resource consumption. One simply restarts the partition or clears out a physical node.

In reality most DB2 + DPF customers run more than one partition per physical node. So this is indeed a realistic option.

-- 
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab