Does DB2 UDB support parallel database i.e processing is taking place
on multiple nodes at the same time allowing users to be active on more
than one node simultaneously. This is to allow for failover as well as
load balancing?

Is there an equivalent of Real Application Cluster (RAC) in Oracle.
Where we can cluster at application level rather then hardware such as
HACMP.

Thanks & Rgds,
F

DeeBee2 wrote:[color=blue]
> Does DB2 UDB support parallel database i.e processing is taking place
> on multiple nodes at the same time allowing users to be active on more
> than one node simultaneously. This is to allow for failover as well as
> load balancing?
>
> Is there an equivalent of Real Application Cluster (RAC) in Oracle.
> Where we can cluster at application level rather then hardware such as
> HACMP.[/color]
Pretty loaded question. You are asking for two questions at once:
Failover and Parallelism

DB2 supports what is commonly called shared nothing parallelism for
scale out.
This has little to do with failover. It's pure breed scale out geared
towards >500GB data.
Typically DPF (Data partitioning feature) is used for warehousing.
But OLTP applications, when designed properly, can also take advantage
of it.

For failover you can use solutions such as provided by Veritas or you
can use HADR.

W.r.t RAC there is no direct match. DPF installations have a bigger
(more extreme) sweet spots with >100 nodes becoming typical, but they
are not geared for high availability without HACMP.

HADR is a pure breed failover and disaster recovery solution (for
disaster recovery you need dataguard in Oracle, not RAC).

It makes no sense to directly compare these since they address different
requirements

Tell us more about the business requirement of the question. Otherwise
this thread is going to turn into flame war in no time.

Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

Serge Rielau wrote:[color=blue]
> DeeBee2 wrote:[color=green]
>> Does DB2 UDB support parallel database i.e processing is taking place
>> on multiple nodes at the same time allowing users to be active on more
>> than one node simultaneously. This is to allow for failover as well as
>> load balancing?
>>
>> Is there an equivalent of Real Application Cluster (RAC) in Oracle.
>> Where we can cluster at application level rather then hardware such as
>> HACMP.[/color]
> Pretty loaded question. You are asking for two questions at once:
> Failover and Parallelism[/color]

There is a company (xkoto) that has developed a software/hardware
solution that provides the equivalent of RAC for DB2 UDB. I believe
there are certain limitations as to the client software you use.

I haven't used this, but it seems like an interesting technology.

Interesting...
http://www.eweek.com/article2/0,1759...119TX1K0000594

Some obvious issues around NOT DETERMINISTIC and EXTERNAL ACTION events.
But it will cover many cases.
Not clear how they add a node or re-integrate a bounced system... (synch up)

Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

Ian wrote:
[color=blue]
> There is a company (xkoto) that has developed a software/hardware
> solution that provides the equivalent of RAC for DB2 UDB.[/color]

Not the same thing as RAC at all - basically multiple copies of the same
database all over the place - a data farm. Really not a good thing to be
doing - you trade out up-to-date data for scalability. The more you
scale, the less up-to-date your datra becomes. And management becomes a
nightmare. FYI - there are multiple vendors doing similar things - MySQL
has a similar capability, Avokia also does something similar.

Mark Townsend wrote:[color=blue]
> Ian wrote:
>[color=green]
>> There is a company (xkoto) that has developed a software/hardware
>> solution that provides the equivalent of RAC for DB2 UDB.[/color]
>
> Not the same thing as RAC at all - basically multiple copies of the same
> database all over the place - a data farm. Really not a good thing to be
> doing - you trade out up-to-date data for scalability. The more you
> scale, the less up-to-date your datra becomes. And management becomes a
> nightmare. FYI - there are multiple vendors doing similar things - MySQL
> has a similar capability, Avokia also does something similar.[/color]
I agree it's not the same as RAC. It's like active/active HADR.
But I don't get your comment on "up-to-date".
How does relicating all updates to multiple nodes reduce up-to-date-ness.

Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

Mark Townsend wrote:[color=blue]
> Ian wrote:
>[color=green]
>> There is a company (xkoto) that has developed a software/hardware
>> solution that provides the equivalent of RAC for DB2 UDB.[/color]
>
> Not the same thing as RAC at all - basically multiple copies of the
> same database all over the place - a data farm.[/color]

From a technical perspective, that's true.

But from an end-user perspective, it's the same: Adding servers
to the cluster provides high availability and additional capacity.
[color=blue]
> Really not a good thing to be doing - you trade out up-to-date data
> for scalability. The more you scale, the less up-to-date your datra
> becomes. And management becomes a nightmare.[/color]

Well, let's give them the benefit of the doubt and assume that their
solution works as advertised. xkoto says that their solution takes
care of ensuring that all copies of the database are up-to-date.

Serge Rielau wrote:[color=blue]
> Typically DPF (Data partitioning feature) is used for warehousing.
> But OLTP applications, when designed properly, can also take advantage
> of it.
>[/color]

Serge,

I'm interested in this. Can you point us toward additional
information. It seems to me that the shared nothing architecture is
superior for data warehousing but not optimal for OLTP. It bugs me a
bit that for the OLTP UDB systems I've been involved with we usually
end up with an active-passive setup to allow for failover. We
essentially have an unused piece of hardware. With RAC at least you
get to use all the hardware even though there is an overhead cost.

Lew

Serge Rielau wrote:
[color=blue]
> But I don't get your comment on "up-to-date".
> How does relicating all updates to multiple nodes reduce up-to-date-ness.
>[/color]

For two nodes (active/active HADR) it's not in issue. For 20 it becomes
problematic. For 200 nodes, on a reasonably busy system, latency of
replication becomes an issue.

sethwai@yahoo.com wrote:[color=blue]
> Serge Rielau wrote:[color=green]
>> Typically DPF (Data partitioning feature) is used for warehousing.
>> But OLTP applications, when designed properly, can also take advantage
>> of it.
>>[/color]
>
> Serge,
>
> I'm interested in this. Can you point us toward additional
> information. It seems to me that the shared nothing architecture is
> superior for data warehousing but not optimal for OLTP. It bugs me a
> bit that for the OLTP UDB systems I've been involved with we usually
> end up with an active-passive setup to allow for failover. We
> essentially have an unused piece of hardware. With RAC at least you
> get to use all the hardware even though there is an overhead cost.[/color]
Lew,

This depends on your frame of mind.
Note that there doesn't have to be a 1-1 mapping between database and
the physical machine.
While the standby HADR system is idle (well it is rolling forward) the
machine doesn't have to.
If you have two databases for example you can use them to mutually fail
over.
Also the standby machine can be your test and development environment.
If production fails over you shoot development down if necessary.
Keep in mind that a good test environment should as much as possible
mimic the production system.
Even if you don't use the other machine at all you have to consider
total management cost of an active active clustering.
HADR is certified with the vast majority of apps because it is
non-invasive. You know what you get. There is soemthing to be said for
simplicity.

The gist of DPF in OLTP is that typically the OLTP system does not
undergo as rigorous a design as a warehouse. DPF demands dicipline and
rewards with near linear scalability.

I just went to www.ibm.com and did two searches: HADR; and DB2 BCU
Both yield quite a bit of information.
(BCU stands for balanced configuration unit.. a standard way of
designing DPF systems)

Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

Hi Serge,

The prime idea is to have a failover but at the same we do not want the
secondary node sitting in the corner doing nothing instead we want to
utilise it to load balance.

"One line business requirement is to attack clustering at the
application level i.e layer sever of OSI model from the network
perspective."

I look forward to your response.

thanks & regards,

DeeBee2 wrote:[color=blue]
> Hi Serge,
>
> The prime idea is to have a failover but at the same we do not want the
> secondary node sitting in the corner doing nothing instead we want to
> utilise it to load balance.
>
> "One line business requirement is to attack clustering at the
> application level i.e layer sever of OSI model from the network
> perspective."[/color]
I take offense to the "do nothing" part. Unless you have no test and
development, nothing else that's not required to be HA then do-nothing
is your choice, not DB2's fault.
Anyway in a three-tier environment work load balancing is often doen
through websphere AFAIK.

Cheers
Serge

PS: Your business requirement should be to look ate the price tag of
the system and to get the system that gets the job done. Business
requirements should start with the business, not with technology. Just
my 2 cents Canadian

--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

DeeBee2 wrote:[color=blue]
> Hi Serge,
>
> The prime idea is to have a failover but at the same we do not want the
> secondary node sitting in the corner doing nothing instead we want to
> utilise it to load balance.[/color]

Keep the total cost in mind, too. IBM is forgiving if you have a
true standby system - you only pay to license one CPU instead of all
CPUs in the server. This can be a significant cost savings, especially
if you have 4+ cpus in your server.

So, make sure you consider that cost savings -- my experience has been
that the person signing the check suddenly isn't so concerned about a
box "just sitting in the corner."