New Features

The Db2 Plugin version 3.0.0 introduces support to Db2 Database Partitioning Feature (DPF). This will help the customer to ingest the data to a staging dsource from a Db2 DPF enabled source.

Database Partitioning Feature

Database Partitioning Feature (DPF) lets you partition your database across multiple servers. Since you can add new machines and spread your database across them, this allows users to scale their database. This means more CPUs, more memory, and more disks from each of the additional machines are available for your database. DPF can be used to manage large databases for a variety of use cases including data warehousing, data mining, online analytical processing (OLAP), or online transaction processing (OLTP) workloads.

DPF enables the user to divide a database into database partitions, a database partition is a part of a database that consists of its own data, indexes, configuration files, and transaction logs. Each database partition can be configured on the different physical server having its own set of computing resources, including CPU and storage. When a query is processed, the request is divided so each database partition processes the rows that it is responsible for. DPF can maintain consistent query performance as the table grows by providing the capability to add more processing power in the form of additional database partitions. This capability is often referred to as providing linear scalability using Db2s shared-nothing architecture.

DPF is an approach to sizing and configuring an entire database system. Please follow the recommended practices for optimal performance, reliability, and capacity growth. Please refer to IBM documentation of DPF for more details in IBM knowledge center.

Pipelining logic for implementing parallel restores

The plugin employs a parallel pipeline methodology so that the restore operation of non-catalog partitions can be performed in parallel in the Database Partitioning Feature (DPF). The number of parallel restores is determined by the value of “restorePipelineLimit” (default value is 10) in <Toolkit directory>/advanceConfFlag.conf. The parameter “restorePipelineLimit” is configurable by end-users. The plugin performs parallel restore for all non-catalog partitions. For e.g. If the total number of non-catalog partitions is 15, and the "restorePipelineLimit" parameter is set to 10, the first set of 10 restores will happen in parallel. The plugin will track the restore of each partition present in the pipe. Whenever a restore of a partition completes, it will move out from the pipe and a new partition will enter into that pipe. Thus, the plugin ensures that the pipe will always have the user-configured number of partitions being restored (default=10).

Data Synchronization

When Customer Supplied Archive Logs” feature is used along with Db2 DPF feature, users will have to place the archive logs inside a folder with a name as NODE<Partition number> where <Partition number> is a four-digit number. For example, if the source environment has two partitions then the user-provided log path will have folder names NODE0000 and NODE0001. Both the folders will have respective archive logs. Snapshot operation will be used to apply the archive logs.

Advance Configuration file

The advanced config file is created at <Toolkit directory>/advanceConfFlag.conf during discovery or environment refresh operation if the file does not pre-exist already. This file will have the following configurable parameters:

  • Common Group (notCommonGroupFlag)
    • This parameter sets the permission of "mnts", "logs" and "code" directories at <Toolkit dir>/DB2 location. 
    • Set notCommonGroupFlag to false,  if the primary group of the primary environment user (user which is used to do discovery) is shared with the instance users.
    • Set notCommonGroupFlag to true,  if you don't want to share any group between the primary environment user and the instance users.
    • Once the necessary changes are made, refresh the environment in order to make the changes applicable.

        By default, the notCommonGroupFlag parameter is not specified in the file. This means that the plugin implicitly assumes its value as false. The valid values for this parameter are true or false.

  • Allow Source Database on Same Instance (allowSourceDBonSameInst)
    By default, the DB2 Plugin restricts the provisioning of a VDB on a DB2 instance which contains a database with the same name as the VDB's source database
    For example:
    • When provisioning a VDB from a VDB then source VDB is treated as the source database.
    • When provisioning a VDB from a dSource then a staging database is treated as the source database.

 Set allowSourceDBonSameInst to true, if the user wants to provision a VDB on an instance which contains a database with the same name as the VDB's source database.  The valid values for this parameter are true or false.

  • Restore Pipeline limit (restorePipelineLimit) 
    Db2 DPF Plugin performs restoration of all non-catalog partitions in parallel. 
    The parameter restorePipelineLimit allows the user to configure the number of partitions that should be restored in parallel. When the new advanceConfFlag.conf file is created during environment refresh or discovery operation, the default value of restorePipelineLimit is set to 10. If the advanceConfFlag.conf file is already present, the user will have to set the value of restorePipelineLimit parameter to the desired value. Valid value for this field is any positive integer.

A default config file created during discovery or environment refresh operation:

# If the user is not sharing a common group between primary environment user and instance user.
# Then the user needs to set parameter notCommonGroupFlag as true.
# notCommonGroupFlag=true
# During provision operation check if instance contains a database name which is identical to the source DB name  used for provisioning operation.
# By default plugin will never allow creating a VDB on the instance where source database (or other database which is identical in name with source DB) already exists.
# If the user still wants to create a VDB on the instance which contains a database name which is identical to the source DB name used for provisioning operation,
# then the user needs to set parameter allowSourceDBonSameInst as true.
# allowSourceDBonSameInst=true
# Limit for parallel restores

Migration and Compatibility

Supported DBMS Versions

  • Db2 Enterprise Server Edition 10.5

  • Db2 Advanced Enterprise Server Edition 10.5

  • Db2 Enterprise Server Edition 11.1

  • Db2 Advanced Enterprise Server Edition 11.1

Supported Operating Systems

Supported Db2 Database Editions

  1. Enterprise Server Edition
  2. Advanced Enterprise Server Edition
  3. Advanced Edition
  4. Standard Edition
  5. For the supported Db2 versions, Delphix supports the corresponding Db2 Developer edition with Db2 plugin support
  • Delphix Support Policies specifically list Major and Minor release coverage. If a minor release is listed as covered, then all patch releases under that minor release are certified.
  • Db2 versions below 10.5 i.e (10.1, 9.8) are NOT supported by the plugin.
  • Db2 supports only 64-bit OS





Red Hat Enterprise Linux (RHEL) 

Support for RHEL 8.x requires installing the libncurses.5 library onto the host. Please reference KBA 5622  for actionable steps.

Db2 plugin support for below mentioned OS and Db2 versions

Supported DBMS Version
Supported OS Version10.511.111.5
RHEL 6.9

RHEL 7.0

RHEL 7.1

RHEL 7.2

RHEL 7.3

RHEL 7.4

RHEL 7.5

RHEL 7.6

RHEL 7.7(error)

RHEL 7.8(error)


RHEL 8.2(error)(error)

Advanced Interactive eXecutive (AIX)

Db2 plugin support for below mentioned OS and Db2 versions

Supported DBMS Version
Supported OS Version10.511.111.5
AIX 7.1

AIX 7.2

Plugin/Delphix Engine Compatibility

Plugins should be installed on compatible Delphix Engines per the table below:

The plugin versions starting 2.1.0 till 2.7.3 are on extended support. Please contact Delphix Support for any queries.

Plugin Version
Delphix Engine3.













Plugin Upgrade Path

Use the table below to determine the most efficient upgrade path from your current version to the latest version of the Db2 Plugin.

Your Version

Recommended upgrade path to Db2 3.0.0


Upgrade to 2.1.0, and follow the paths below.


Upgrade to 2.2.1, and follow the paths below.


Upgrade to 2.3.0, and follow the paths below.


Upgrade to 2.4.0, and follow the paths below.




Upgrade to 2.5.1, and follow the paths below.

2.5.1Upgrade to 2.6.0, and follow the paths below.



Upgrade to 2.7.0, and follow the paths below.





Upgrade to 3.0.0

Known Issues 

Db2 plugin version 3.0.0 contains the following known issue:



Workaround / Comments


Jobs on UI might hang intermittently due to a known IBM Db2 bugThis issue will be only observed when multiple datasets jobs, within the same Db2 instance, will get executed at the same time.