DB2 LUW partitioned databases haven't been called DPF, the Database Partitioning Feature, since 2007.  However, a lot of people still use the term.  That's not a bad thing, but they tend to search with it, too  :)   That means they don't always find the answers they want.  For example, how do I do HA for DB2 DPF?  I get that one often enough that I'm going to provide some answers in this post.


First, understand that DB2's partitioned database function is now found in several products:

  • All InfoSphere Warehouse editions and
  • The two Warehouse Features for DB2 (Base and Enterprise)


Next, know that built into all of these is the IBM Data Replication technology called Q Replication.  Why does that matter?  Q Replication is commonly used as a high availability solution for DB2.  It works well with DPF.   All you need to know is how to use it and whether you need to buy it.  Let's start with cost.


Is Q Replication Free?


For many years, Q Replication has been available in the Homogeneous Replication Feature for DB2 and InfoSphere Replication Server.  However, to provide Q as an HA option with DB2, IBM recently started making two-DB2 Q Replication available at no extra cost in several products, including the warehouse products.  That means an HA solution comes with all DB2 partitioned databases (starting with 9.7.2).  It also means you have an HA solution for IBM Smart Analytics Systems since their software stack includes InfoSphere Warehouse.


How Does It Work with DPF?


With Q Replication, you can choose to have any database partitioned - source, target, or both.  I'm going to use a picture that has partitioned databases at both sites.  It highlights the main points we want to discuss.



Notice the following:

  • There is no per-system replication set up required.
    • Only one Capture program is needed on the source.
    • Only one Apply program is needed on the target.
  • Capture can run on any source system (partition server).
    • This is possible because Q Capture attaches to all partitions, reads their logs, and then merges log records to rebuild transactions.
  • Apply can run on any target system.
    • Apply connects to the database, issues SQL, and DB2 handles distributing data across partitions - just as it does for any other DB2 app. 
  • For an HA solution, you would also have a Capture running on the second site and an Apply on the first.
    • This is the same way you would implement HA with Q Replication for non-partitioned databases.

All of this can be set up through a GUI or scripting.



Best Practices


The key ones are:

  • Run the Q Capture program on the source system with the admin partition.
    • This is not mandatory, but is a good starting point.
  • Run the Q Apply program on one of the following systems (in order of preference):
    • The system with the partition(s) that will receive the most replicated data.
    • The target system with the least activity.
    • The target system with the admin partition.
  • Install WebSphere MQ on the same system where the Q Replication programs run.
    • This provides optimal performance.


For More Information...


You can find more information several places:


If you have questions, see the Q Replication message board on developerWorks.





Views: 3224


You need to be a member of ChannelDB2 to add comments!

Join ChannelDB2

Featured Downloads

Try BLU Acceleration on Cloud

© 2020   Created by channeldb2.   Powered by

Badges  |  Report an Issue  |  Terms of Service