DB2 Delta Server

Author Product Version Reference Download
Chris Roffler 9.6

DB2 demo


Almost every large enterprise system includes legacy applications or backend systems that are communicating with the enterprise main database system for reporting, batch processing, data mining, OLAP and other processing activity. These applications might not need to access the data grid to improve their performance or scalability. They will be using the database directly. Once these systems perform data updates , removing data or add new records to the database, these updates might need to be reflected within the data grid. This synchronization activity ensures the data grid is consistent and up to date with the enterprise main database server.

The Delta Server described with this pattern responsible for getting notifications from the database for any user activity (excluding data grid updates) and delegate these to the data grid. You may specify the exact data set updates to be delegated to the data grid.


We have an In-Memory Data Grid (IMDGClosed In-Memory Data Grid. A set of Space instances, typically running within their respective processing unit instances. The space instances are connected to each other to form a space cluster. The relations between the spaces define the data grid topology. Also known as Enterprise Data Grid - EDG) that is used for querying information. The initial load of the data grid was performed from a DB2 Database. The data grid is not used as a system of record in this case, meaning that any changes to the objects in the data grid are not propagated back to the database. Non-Aware Data-Grid Clients are updating the Database. These updates (insert, update and delete) need to be reflected in the data grid.

We will show you how you can implement this scenario with GigaSpaces. A fully functional example is available for download.


  • DB2 Advanced Server 10+ installation using default user (db2inst1) and group (dasadmin1)
  • MQ Server 7+ installed using the default user group mqm and add user db2inst1 to mqm group


For simplicity, we install and execute this demo using the DB2 default user db2inst1. Log in to the Linux machine using the user db2inst1. Download the sample code and extract to a folder, say /home/db2inst1/db2mqrep. We'll refer to this path as DEMO_HOME.

The following JAR files are needed for this example:

 These files must be copied from the MQ server that you are running against.


 Other jars:


 Prepare the db Demo Files

Change directory to the db2mqrep directory. We'll execute a script that creates the db2sampl database PUBSRC and configures it for this demo. Execute the script democreatedb.sh using the command from a terminal window:


If your db2inst1 home directory doesn't match the script, please update the path to the exact one on your installation.

You should see the following message on your terminal window:

 Creating database "PUBSRC"...
 Connecting to database "PUBSRC"...

 Setting Up the MQ Queue Managers

If the db2inst1 account is not part of the mqm group, then you need to add it to the group. In this step we will setup the replication for the database changes. Execute the following script using the asnclp command:

 asnclp -f demomq.asnclp

The output on the console should look something like this:

 CMD: asnclp session set to q replication;
 CMD: create mq script config type E

The previous script generates a shell script which needs to be executed. Let's make this file executable first.

 chmod u+x qrepl.pubsrc.mq_aixlinux.sh

Execute using the following command:


You should now see output on the console similar to below:

 WebSphere MQ queue manager created.
 Directory '/var/mqm/qmgrs/PUBSRC' created.
 The queue manager is associated with installation 'Installation1'.
 Creating or replacing default objects for queue manager 'PUBSRC'.
 Default objects statistics : 74 created. 0 replaced. 0 failed.

To setup the asnclp session to replicate, execute the file demopub.asnclp

 asnclp -f demopub.asnclp

You should see the following output:

 CMD: asnclp session set to q replication;
 CMD: set run script now stop on sql error on;

Create a directory called myQCap inside your current folder and cd to it and execute the following command:

 asnqcap capture_server=PUBSRC

This will capture the actual replication information. You should see the following output:

 ASN0600I "Q Capture" : "" : "Initial" : Program "mqpub 10.1.0 (Level s120403, PTF LINUXAMD64101)" is starting.
 ASN7010I "Q Capture" : "ASN" : "WorkerThread" :
 The program successfully activated publication or Q subscription "EMPLOYEE0001"
 (send queue "ASN.PUBSRC.DATA", publishing or replication queue map "PUBSRC.ASN")
 for source table "DB2INST1.EMPLOYEE".


 Running the Demo

Step 1: Start the GigaSpaces agent.


Step 2: Set environment variables for MQ.

 export MQ_JAVA_INSTALL_PATH=/opt/mqm/java
 export MQ_JAVA_DATA_PATH=/var/mqm
 export MQ_JAVA_LIB_PATH=/opt/mqm/java/lib64

Step 3: Start the Delta Server.

 java -Djava.library.path=/opt/mqm/java/lib64 -cp "/opt/mqm/java/lib:./*"
 -qmgr PUBSRC -queue ASN.PUBSRC.DATA -time 60000 -out DEPFiles

Make sure you include all the JARs that are MQS specific.

Step 4: Update the database to force notifications.

 db2 connect to PUBSRC

 db2 "insert into employee(empno, firstnme, lastname, edlevel,workdept) values ('000015','MARK','POTTER',18,'C01')";

 db2 "insert into employee(empno, firstnme, lastname, edlevel,workdept) values ('000016','SALLY','JOHNSON',18,'A00')";

If you start the GigaSpaces Management Center, you should see under "mySpace" the entries we have inserted into the database.