Tags: active, allowing, database, db2, morethan, multiple, mysql, nodes, oracle, parallel, placeon, processing, sql, time, udb, users

Parallel Database

On Database » DB2

9,292 words with 9 Comments; publish: Fri, 23 May 2008 13:48:00 GMT; (25062.50, « »)

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

All Comments

Leave a comment...

  • 9 Comments
    • DeeBee2 wrote:

      > 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.

      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

      #1; Fri, 23 May 2008 13:50:00 GMT
    • Serge Rielau wrote:

      > DeeBee2 wrote:

      > Pretty loaded question. You are asking for two questions at once:

      > Failover and Parallelism

      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.

      #2; Fri, 23 May 2008 13:51:00 GMT
    • Interesting...

      http://www.eweek.com/article2/0,175...3119TX1K0000594

      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

      #3; Fri, 23 May 2008 13:52:00 GMT
    • Ian wrote:

      > There is a company (xkoto) that has developed a software/hardware

      > solution that provides the equivalent of RAC for DB2 UDB.

      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.

      #4; Fri, 23 May 2008 13:53:00 GMT
    • Mark Townsend wrote:

      > Ian wrote:

      >

      > 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.

      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

      #5; Fri, 23 May 2008 13:54:00 GMT
    • Mark Townsend wrote:

      > Ian wrote:

      >

      > Not the same thing as RAC at all - basically multiple copies of the

      > same database all over the place - a data farm.

      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.

      > 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.

      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.

      #6; Fri, 23 May 2008 13:55:00 GMT
    • Serge Rielau wrote:

      > Typically DPF (Data partitioning feature) is used for warehousing.

      > But OLTP applications, when designed properly, can also take advantage

      > of it.

      >

      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

      #7; Fri, 23 May 2008 13:56:00 GMT
    • Serge Rielau wrote:

      > But I don't get your comment on "up-to-date".

      > How does relicating all updates to multiple nodes reduce up-to-date-ness.

      >

      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.

      #8; Fri, 23 May 2008 13:57:00 GMT
    • sethwai.db2.todaysummary.com.yahoo.com wrote:

      > Serge Rielau wrote:

      > 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,

      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

      #9; Fri, 23 May 2008 13:58:00 GMT