High Availability Network Setup for Continuous Incremental Updates

Content

Important: The following article is relevant only if you want to use continuous incremental updates. To set up an entirely new network for the use of incremental updates now or later, you can follow the description here, as it leaves you with the option to use continuous incremental updates in the future. Also follow the description here if you want to extend an existing high-availability setup for incremental updates, so that it allows you to use continuous incremental updates. However, if you do not want to use the feature at all (continuous incremental updates, that is), you do not have to change your network configuration. It is worth mentioning that continuous incremental updates are enabled by default in Db2 Analytics Accelerator for z/OS Version 7.1.1 and later releases..

The setup described here uses a Db2 data sharing group with two members, each of which running in a different logical partition (LPAR). Each LPAR resides on a different physical box to form a high-availability (HA) environment with disaster recovery (DR) and failover (between distributed components) capabilities in a client productive environment. For a HA setup of Db2 in such an environment, a Totally Stubby Area (TSA) is usually used on the application side. Such a setup will take care of the network traffic without knowing the route to the IBM Z system (in this example, there are two possible ways), which increases the system's overall resiliency. For setup details, refer to OSPF Design and Interoperability Recommendations for Catalyst 6500 and OSA-Express Environments and chapter 4 of IBM z/OS V1R13 Communications Server TCP/IP Implementation: Volume 3 High Availability, Scalability, and Performance.

The TCP/IP stacks of the LPARs are named TCPIP1 for LPAR1, and TCPIP2 for LPAR2. Dynamic routing is set up on the IBM Z, by use of an OMPRoute.

The diagram below illustrates this setup:

The Db2 data sharing group is called DWCDBE4; its members are called SE41 and SE42. The member SE41 runs in LPAR1, whereas the other member, SE42, runs in LPAR2. Both LPARs belong to the same sysplex. A coupling facility (CF) is used, so that both members can be reached over a single IP address (group IP). Client applications reach the data sharing group over the company's intranet using group IP 9.152.64.226 (Distributed Dynamic Virtual IP Address, DDVIPA1). The accelerator communicates with the data sharing group over the private network (group IP 10.101.14.225, which is part of DDVIPA2. Note that DDVIPA2 is defined as a subnet of the private network in the 10.101.14.abc range. Both connections use the port 11040. The CF and the DDVIPA ensure that every Db2 request will be answered at the network or IP address that it came from, without exception. This is to guarantee security. The private accelerator data network between the accelerators and the LPARs - defined as an IP network in the range from 10.101.12.xyz to 10.101.14.abc - is still intact. Assume that the DDVIPA1 has already been set up. So the main focus is on DDVIPA2 and on an online migration towards the integration of DDVIPA2.

Separate instances of the CDC replication capture agent are running in each LPAR. The first started task creates a CDC instance and automatically becomes the active instance if the corresponding Db2 member in that LPAR is online. The other instance will be in Hot Standby mode, which means that it can communicate with Db2, but remains in a waiting state and will not monitor the Db2 transaction log, and therefore not propagate data changes to the accelerator or accept agent log-on requests before it is granted exclusive access to the CDC metadata tables. Only one instance can be the active instance that replicates the data of the selected tables to the accelerator.

When an instance enters the active mode, it initializes its own TCP/IP task, which in turn starts a BIND operation that associates a TCP port with a TCP/IP stack. For the z/OS Communication Server, this BIND operation is a request to pass control to the TCP/IP stack of the LPAR whose IP address is specified in the BIND command. The entire operation is carried out in a Dynamic Virtual IP Addressing (DVIPA) environment. The agent communicates with the accelerator over the DVIPA (IP address 10.101.14.228 and port 5996. See the next chapter).

If the CDC instance that is currently active becomes unavailable, the DVIPA address of this instance is passed to one of the Hot Standby instances. This is called failover. As a result, one of the Hot Standby instances goes into active mode.

1. Infosphere CDC for z/OS Installation

This part guides you through the setup of the Infosphere CDC instances. Follow the IBM InfoSphere Change Data Capture Installation Documentation to install and run the Infosphere CDC instance on each LPAR of your Db2 data sharing group. Make sure that the latest program temporary fixes (PTFs and PUT Levels), especially for PM82593 and PM85740, have been applied.

Ensure that the VSAM meta-data cluster (the name is defined by replacing the <MetaDatacluster> placeholder in the CHCDFMTD installation job) has the value (3 3) for the SHAREOPTIONS keyword. The VSAM metadata cluster is referenced by the CHCMTDTA DD name in the CDC startup JCL and must be shared by the active instance and all hot-standby instances. All instances that use the same CDC metadata tables (which can be identified by the owner name) within a Db2 subsystem or data sharing group must reference the same VSAM metadata cluster.

If a log cache is used, the VSAM cluster for the L2 cache that is created by the CHCCRCCH installation job (named <CACHE.QUALIFIER>.CHCCACHE) must be created with value (2) for the SHAREOPTIONS keyword and must also be shared by the active instance and all hot-standby instances.

Similarly, the PAL (product administration log) VSAM cluster that is created by the CHCDFPAL installation job (named <PALcluster>) must be created with the value (2 3) for the SHAREOPTIONS keyword (see APAR PI54370) and must also be shared by the active instance and all hot-standby instances.

You can use the ARMWRAP program to ensure that the address space is restarted in case it fails unexpectedly. See the IBM z/OS Automatic Restart Manager Redpaper for more information .

The IP configuration for the Infosphere CDC for z/OS instances are defined in the CHCCMMxx member (xx is the suffix that you chose during the installation). In this example, the instances use TCP port 5996, which is defined by the SERVICENAME keyword, and a TCP/IP stack named TCPIP, which is defined by the SUBSYSTEM keyword.

TCP/IP SERVICENAME=5996,
      SUBSYSTEM=TCPIP

To verify this step, start Infosphere CDC and review the CHCPRINT data set in the SPOOLed output. The output must contain the following information:

CHC9512I Using TCP/IP Subsystem address space TCPIP
CHC9523I TCP/IP Communication Support is active
CHC5099I CMO Task was initialized successfully
CHC6804I TCP Listener was initialized on service name 5996, port  5996

1.1 z/OS Communications Server Setup for CDC

To reserve the port 5996 for the Infosphere CDC instances and associate the port number with the Dynamic VIPA address 10.101.14.228, use the following statement in the PROFILE TCPIP data set for the TCP/IP stacks of both LPARs. This data set can be found, for instance, at SYS4.PARMLIB.TCP. Use different names for the CDC address space in each stack (CDCSE41 is the name of the first address space in LPAR1 in this example. CDCSE42 is the name of the second address space. You would have to enter CDCSE42 when defining the second stack).

Important: The DVIPA address must belong to the same subnet as the accelerator that you want to enable for incremental updates. Here, this subnet is called DDVIPA2.

PORT                                                                            
  5996 TCP CDCSE41 BIND 10.101.14.228; CDC AGENT BIND TO DVIPA ADDRESS 

The VIPADYNAMIC keyword sets the operation mode to dynamic. The VIPARANGE statement defines a pool of continuous IP addresses used by applications or started tasks like CDC agents or the MODDVIPA utility. The statement reserves within the private network a subnet of 30 IP addresses for dynamic usage on the IBM Z side. IP address 10.101.14.228 is used for CDC agents on data sharing group DWCDBE4. The NONDISRUPTIVE keyword determines that the connection will stay in case of a failover on the IBM Z. This will be transparent for the other side of the connection (in this example, this is IBM Db2 Analytics Accelerator for z/OS).

VIPADYNAMIC     ; VIPA DEFINITIONS
VIPARANGE MOVE NONDISRUPTIVE 255.255.255.224 10.101.14.224
ENDVIPADYNAMIC   

Note: 10.101.14.224 is the first address in the subnet that cannot be used by applications or started tasks.

Note: Here a range of 30 IP addresses is defined and can be used for a HA setup of multiple data sharing groups within this (one) subnet of the private accelerator data network.

To verify the configuration, the following commands are available. Run these on each LPAR for a complete overview. Note that the output does not show all the information previously mentioned, especially not the information from chapter 2:

1. Verify the DVIPA configuration by entering the following command:

    DISPLAY TCPIP,TCPIP,NETSTAT,VIPADCFG

    The output of this command looks like this:

    LPAR1     12342 14:38:32.08 STC01367 00000010  EZD0101I NETSTAT CS V1R12 TCPIP 234
                                                   DYNAMIC VIPA INFORMATION:
                                                   VIPA RANGE:
                                                   IPADDR/PREFIXLEN: 10.101.14.224/27
                                                   MOVEABLE: NONDISRUPT
                                                   ...

2. Verify the PORT configuration by entering the following command:

    DISPLAY TCPIP,TCPIP,NETSTAT,PORTL

    The output of this command looks like this:
    LPAR1     12342 14:39:18.02 STC01367 00000010  EZD0101I NETSTAT CS V1R12 TCPIP 23
                                                   PORT# PROT USER FLAGS RANGE SAF NAME
                                                   5996 TCP CDCSE41 DABU
                                                      BINDSPECIFIC: 10.101.14.228
                                                   ...

3. You can display the current DVIPA status of a system by using the following command:

    DISPLAY TCPIP,TCPIP,NETSTAT,VIPADYN

    The output of this command looks like this:
    LPAR1     12342 14:41:04.12 STC01367 00000010  EZD0101I NETSTAT CS V1R12 TCPIP 252
                                                   DYNAMIC VIPA:
                                                   IPADDR/PREFIXLEN: 10.101.14.224/27
                                                     STATUS: ACTIVE ORIGIN: VIPARANGE BIND DISTSTAT:
                                                     ACTTIME: 12/07/2016 13:26:33 JOBNAME: CDCSE41
                                                  ...

    This example shows that the CDC Agent CDCSE41 in LPAR1 is running and that it uses the DVIPA address 10.101.14.228.

4. Verify the current DVIPA status of a sysplex by entering the following command:

    DISPLAY TCPIP,TCPIP,SYSPLEX,VIPADYN

    The output of this command looks like this:             
   LPAR1     12342 14:43:52.32 STC01367 00000010  EZZ8260I SYSPLEX CS V1R12 105                      
                                                  VIPA DYNAMIC DISPLAY FROM TCPIP    AT LPAR1        
                                                  LINKNAME: VIPL0A6508F9                            
                                                  IPADDR/PREFIXLEN: 10.101.14.224/27                  
                                                   ORIGIN: VIPARANGE BIND                          
                                                   TCPNAME  MVSNAME  STATUS RANK DIST              
                                                   -------- -------- ------ ---- ----              
                                                   TCPIP    LPAR1     ACTIVE                        
                                                  ...

    The example shows that the DVIPA address 10.101.14.228 is used by an application in LPAR1.

1.2 Testing CDC failover

When you start the first instance of the Infosphere CDC Capture Agent, which will become the active instance, verify that the dynamic VIPA address is created correctly. This is indicated by the following message, which is displayed during the start procedure:

EZD1205I DYNAMIC VIPA 10.101.14.228 WAS CREATED USING BIND BY CDCSE41 ON TCPIP

All subsequently started instances will enter the Hot Standby mode. This is indicated by the following message, which is shown at the start of each additional instance:

CHC9212I The meta data owned by <owner> is being used by
        another instance of InfoSphere CDC for z/OS, this
        instance is entering Hot Standby mode

If the active instance ends abnormally, or if the system on which it is running becomes unavailable, one of the Hot Standby instances takes over. This is indicated by the following message:

CHC9211I Termination of Active instance of InfoSphere CDC for
        z/OS using meta data owned by <owner> detected, this
        instance is leaving Hot Standby mode and will become
        Active

To initiate a failover manually, you can use the HANDOVER parameter of the SHUTDOWN command. The syntax of the command is as follows:

MODIFY <A/SName>,SHUTDOWN,[SCHED=<DateTime>|NORM|IMMED|ABORT],[HANDOVER]

where <A/SName> is the name of the instance of the Infosphere CDC Capture Agent.

• If you shut down the active instance with the HANDOVER parameter, one of the Hot Standby instances reacts as though the active instance had been abnormally terminated, and becomes the new active instance.
• Do not use this command for the active instance without the HANDOVER parameter, or issue a z/OS STOP command for this instance because either command shuts down the active instance and all Hot Standby instances.
• If you use this command for a Hot Standby instance or issue a z/OS STOP command for such an instance, only the specified Hot Standby instance is shut down.

The following example shows the output of a SHUTDOWN command invocation with the IMMED and HANDOVER parameters for the CDCSE41 instance.

Command:

MODIFY CDCSE41,SHUTDOWN,IMMED,HANDOVER

Message output:
LPAR1     12342 15:01:37.08 STC01367 00000010  EZD1298I DYNAMIC VIPA 10.101.14.228 DELETED FROM TCPIP                
LPAR1     12342 15:01:37.08 STC01367 00000010  EZD1207I DYNAMIC VIPA 10.101.14.228 WAS DELETED USING CLOSE API BY CDCSE41 ON TCPIP

LPAR2     12342 15:01:37.14 STC01855 00000010  +CHC9211I (CDCSE42) Termination of Active instance of IBM InfoSphere CDC for z/OS using meta data owned by CD ...                        
LPAR2     12342 15:01:37.14 STC01855 00000010  +CHC9211I (CDCSE42) ... CUSER detected, this instance is leaving Hot Standby mode and will become Active                                  
LPAR2     12342 15:01:37.49 STC01459 00000010  EZD1205I DYNAMIC VIPA 10.101.14.228 WAS CREATED USING BIND BY CDCSE42 ON TCPIP

Note: The goal of this setup is to keep incremental updates active at all times. If the active CDC instance communication with the corresponding Db2 member of the data sharing group is lost - for instance because a Db2 member went down - it goes into a wait state, and a failover is triggered automatically. A hot standby CDC instance takes over to keep the incremental update process going. The waiting instance will enter the hot standby mode when the coresponding Db2 member comes online again and communication is possible. If the active instance itself is lost, an instance in hot standby mode will automatically become the new active instance. Failovers will re-occur each time an active instance is lost. This process goes on until the last hot standby CDC instance has become active. The only purpose of the HANDOVER keyword is to trigger a manual failover, that is, a failover not caused by an unexpected loss of Db2 or the CDC address space.

2. Continuous IU network specifics

This part guides you through the setup of the DDVIPA2 network. The DVIPA used for the CDC agents will stay the same, so a reload of tables that are already enabled for incremental updates is unnecessary. The new Db2 for z/OS HA setup DDVIPA method INADDR_ANY must be used for this solution. That means that binding the Db2 started task in the port statement to one specific IP address in the TCP/IP stack configuration is not supported, since this BINDSPECIFIC method can only handle one IP and for this solution two DDVIPAs are required. Instead, use BSDS to specify one DDVIPA for DDVIPA1, and use the methods shown below for DDVIPA2. For more information on these methods, see IBM Knowledge Center - Db2 for z/OS - Specify DVIPA and IBM Knowledge Center Db2 for z/OS - Specify DVIPA - Example of TCP/IP configuration statements.

The setup of DDVIPA2 is called online migration because the Db2 system will be available all the time (there is no service interrupt). You can make this a part of the step that installs Db2 PTFs and CDC PTFs as part of an IBM Db2 Analytics Accelerator for z/OS rolling upgrade. This is optional (not mandatory). The setup is a one-time manual effort. It ensures full HA for Db2 for z/OS as well as for CDC in the IBM Db2 Analytics Accelerator for z/OS private data network and is transparent to IBM Db2 Analytics Accelerator for z/OS. Follow the next steps to complete the setup:

1. System setting to start

All members of the data sharing group, which are (at least in this example) distributed over two LPARs must be running and the CDC agents must also be up. CDCSE41 is the active instance.

2. Define a Db2 group IP in DDVIPA2 on LPAR1

For the CDC agent CDCSE41, initiate a failover to CDCSE42. Shut down CDCSE41 and take down Db2 member SE41 (and all possible other Db2 members of the changed data sharing group on the same LPAR). For instance, use stop mode quiesce and execute an obey statement on LPAR1:

V TCPIP,,OBEY,DSN=SYS4.PARMLIB.TCP(LPAR1OBEY)

LPAR1OBEY:

VIPADYNAMIC
VIPADEFINE MOVE IMMEDIATE 255.255.255.224 10.101.14.225 ;DDVIPA2 DB2 GROUP in private accelerator data network
VIPADISTRIBUTE DEFINE 10.101.14.225 PORT 11040
DESTIP ALL
ENDVIPADYNAMIC

Note: This will be propagated to all attached LPARs of the data sharing group. Include this step in the data set containing the TCP/IP configuration, so that it is available permanently at each following restart. Be aware that every LPAR can have multiple active TCP/IP stacks at the same time, so there might be more than one data set.

3. Define a Db2 member IP as an alias in DDVIPA2 on LPAR1

Start Db2 member SE41 and add the alias LPAR1SE41_10 to BSDS for DDVIPA2:
//LOGODDF JOB (DE#3557),'DB2 DDF',NOTIFY=&SYSUID,
//         REGION=4096K,
//         MSGCLASS=H
//IFCSD EXEC PGM=IKJEFT01,DYNAMNBR=20,COND=(4,LT)
//STEPLIB DD DISP=SHR,DSN=SYS1.DSN.SE41.SDSNEXIT
// DD DISP=SHR,DSN=SYS1.DSN.V100.SDSNLOAD
//SYSPRINT DD SYSOUT=*
//SYSTSPRT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSTSIN DD *
DSN SYSTEM(SE41)
-MODIFY DDF ALIAS(LPAR1SE41_10) ADD
-MODIFY DDF ALIAS(LPAR1SE41_10) PORT(11040)
-MODIFY DDF ALIAS(LPAR1SE41_10) IPV4(10.101.14.226)
END
//*

Start the alias LPAR1SE41_10 by issuing: -SE41MOD DDF ALIAS(LPAR1SE41_10) START
Note: Automate the start of the alias for later or repeated starts of Db2
Note: The alias is used to enable Db2 to monitor the second set of DVIPA addresses for HA. The MODDVIPA utility is used in the next step. See also IBM Knowledge Center - Db2 for z/OS - Using the MODDVIPA utility Examples.

4. Activate Db2 monitoring for the alias defined in step 3 on LPAR1

Modify the Db2 member SE41 with the second IP member address 10.101.14.226 (DVIPA in DDVIPA2 space)

//LOGODVI JOB (DE#3557),'MODDVIPA',NOTIFY=&SYSUID,
//         REGION=4096K,
//         MSGCLASS=H
//SE41     EXEC PGM=MODDVIPA,REGION=0K,TIME=1440,
//             PARM='POSIX(ON) ALL31(ON)/-p TCPIP -c 10.101.14.226'
//*

Note: Automate this step for later or repeated starts of Db2

5. Define a Db2 group IP in DDVIPA2 on LPAR2

Start CDC agent CDCSE41. It goes into hot standby mode. Initiate a CDC failover from CDCSE42 to CDCSE41 and shut down CDCSE42. CDCSE41 is now the active agent. Take down Db2 member SE42 (and all possible other Db2 members of the changed data sharing group on the same LPAR). For instance, use stop mode quiesce and execute an obey statement on LPAR2:

V TCPIP,,OBEY,DSN=SYS4.PARMLIB.TCP(LPAR2OBEY)

LPAR2OBEY:

VIPADYNAMIC
VIPADEFINE MOVE IMMEDIATE 255.255.255.224 10.101.14.225 ;DDVIPA2 DB2 GROUP in private accelerator data network
VIPADISTRIBUTE DEFINE 10.101.14.225 PORT 11040
DESTIP ALL
ENDVIPADYNAMIC

Note: If you use this setup as part of a rolling IBM Db2 Analytics Accelerator for z/OS upgrade, execute this step after the work on Db2 member on LPAR1.

Note: Include this step in the data set containing the TCP/IP configuration, so that it is available permanently at each following restart..

6. Define a Db2 member IP as an alias in DDVIPA2 on LPAR2

Start Db2 member SE42 and add the alias LPAR2SE42_10 to BSDS for DDVIPA2:

//LOGODDF JOB (DE#3557),'DB2 DDF',NOTIFY=&SYSUID,
//         REGION=4096K,
//         MSGCLASS=H
//IFCSD EXEC PGM=IKJEFT01,DYNAMNBR=20,COND=(4,LT)
//STEPLIB DD DISP=SHR,DSN=SYS1.DSN.SE42.SDSNEXIT
// DD DISP=SHR,DSN=SYS1.DSN.V100.SDSNLOAD
//SYSPRINT DD SYSOUT=*
//SYSTSPRT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSTSIN DD *
DSN SYSTEM(SE42)
-MODIFY DDF ALIAS(LPAR2SE42_10) ADD
-MODIFY DDF ALIAS(LPAR2SE42_10) PORT(11040)
-MODIFY DDF ALIAS(LPAR2SE42_10) IPV4(10.101.14.227)
END
//*

Start the alias LPAR2SE42_10 by issuing: -SE42MOD DDF ALIAS(LPAR2SE42_10) START
Note: Automate this step for later or repeated starts of Db2

7. Activate Db2 monitoring for the alias defined in step 6 on LPAR2:

Modify the Db2 member SE42 with the second IP member address 10.101.14.227 (DVIPA in DDVIPA2 space):

//LOGODVI JOB (DE#3557),'MODDVIPA',NOTIFY=&SYSUID,
//         REGION=4096K,
//         MSGCLASS=H
//SE42     EXEC PGM=MODDVIPA,REGION=0K,TIME=1440,
//             PARM='POSIX(ON) ALL31(ON)/-p TCPIP -c 10.101.14.227'
//*

Note: Automate this step for later or repeated starts of Db2

8. Finish your work to bring the system into the same state as in step 1.

Start CDC agent CDCSE42. It goes into hot standby mode.

The migration flow is complete and Db2 is set up for HA in DDVIPA2 with the group IP (DDVIPA) address 10.101.14.225. Member SE41 has the member IP (DVIPA) address 10.101.14.226 and member SE42 has the member IP (DVIPA) address 10.101.14.227. The CDC IP (DVIPA) address is still 10.101.14.228. The Db2 group IP (DDVIPA1) address 9.152.64.226 also remains unchanged, like the complete DDVIPA1 network. The member IP (DVIPA) of SE41 is 9.152.64.194, and the member IP (DVIPA) of SE42 is 9.152.64.195. The TCP/IP configuration for a HA environment for incremental updates on LPAR1 looks like this:

PORT
...
   11040 TCP SE41DIST SHAREPORT                   ;DB2 GROUP DDVIPA
   11040 TCP SE42DIST SHAREPORT                   ;DB2 GROUP DDVIPA
   11046 TCP SE41DIST                             ;DB2 MEMBER DVIPA
;  11047 TCP SE42DIST                             ;DB2 MEMBER DVIPA
    5996 TCP CDCSE41  BIND 10.101.14.228          ;CDC DVIPA
...
IPCONFIG SYSPLEXROUTING DATAGRAMFWD
DYNAMICXCF 9.122.64.250 255.255.255.248 1                  ;CF network
VIPADYNAMIC
VIPARANGE MOVE NONDISRUPTIVE 255.255.255.224 9.152.64.192  ;DDVIPA1 network
VIPARANGE MOVE NONDISRUPTIVE 255.255.255.224 10.101.14.224 ;DDVIPA2 network
...
VIPADEFINE MOVE IMMEDIATE   255.255.255.240 9.152.64.226   ;DB2 GROUP DDVIPA
VIPADISTRIBUTE DEFINE 9.152.64.226 PORT 11040              ;in DDVIPA1
                DESTIP ALL
VIPADEFINE MOVE IMMEDIATE   255.255.255.224 10.101.14.225  ;DB2 GROUP DDVIPA
VIPADISTRIBUTE DEFINE 10.101.14.225 PORT 11040             ;in DDVIPA2
                DESTIP ALL
...
ENDVIPADYNAMIC

Note: The TCP/IP configuration of LPAR2 has an active port statement for SE42DIST and an inactive port statement for SE41DIST.
Note: Db2 member IPs in DDVIPA1 are also part of this TCP/IP configuartion, but they are left out here for simplification.
Note: The VIPA ranges can be used for multiple data sharing groups and corresponding CDC instances with HA requirements because the IP ranges in this example are probably wide enough. If not, you can extend the range to comprise 256 IP addresses. For instance, there could be two more data sharing groups, with members on LPAR1, LPAR2, LPAR3 and LPAR6.

To view this setup on the IBM Z, use the display statements in section 1.1, "z/OS Communications Server Setup for CDC". To check the DDF setup, you can use the detail option in the statements -SE41DIS DDF DETAIL (this will show you the DDVIPA1 setup for Db2) and -SE41DIS DDF ALIAS(LPAR1SE41_10) DETAIL (this will show you the DDVIPA2 alias setup for Db2). Unfortunately, an overall view is not available.

This concludes the HA network setup for continuous incremental updates. Now you can enable the feature on the IBM Db2 Analytics Accelerator Console. See the product documentation for details.