Skip to main content
Skip table of contents

New features (IBM Db2)

Release 4.8.0

  • SkipDb2VersionCheck 
    Since the dSource snapshot metadata did not have modpack and fixpack version details taken before DB2 connector version 4.5.1, if the customer wishes to provision VDBs from these older snapshots, the skipDb2VersionCheck needs to be set to true so the connector overrides the check for modpack and fixpack changes and only compares major and minor changes. Doing this might not guarantee successful provisioning as DB2 does not support successful provisioning between different instances with differing modpack and fixpack version.

Release 4.7.4

The IBM Db2 v4.7.4 plugin is now available on the download site. This plugin release consists of only bug fixes. Refer to the Fixed Issues page.

Release 4.7.3

This release version has been removed. Please install or upgrade to a later version.

Release 4.7.2

  • Skip data path verification (Optionally)
    You can now skip the data path verification process during VDB Snapsync if required. The skipDataPathVerification value is mandatory, if you are upgrading datasets from connector versions <=3.1.1 and do not wish to perform VDB re-provision or refresh.

Release 4.7.1

This plugin release consists of only bug fixes.

Release 4.7.0

  • SSL/TLS support for HADR ingestion
    The Db2 plugin version 4.7.0 introduces SSL/TLS support for HADR ingestion, enhancing data security during replication by encrypting data in transit between primary and standby databases.

  • Dynamic UI for Db2 virtualization

    With the introduction of various dynamic UI features, you can now experience a streamlined and user-friendly interface that adapts based on your selected choices, simplifying the linking process.

Release 4.6.1

This plugin release consists of only bug fixes.

Release 4.6.0

This plugin release has the following set of new features and bug fixes.

  • Staging push support for DPF databases
    The Db2 Plugin 4.6.0 version introduces Staging push support for DPF databases. This allows you to ingest databases using a backup agent solution of your choice.

  • VDB Provision with user-defined mount base
    This plugin version introduces support for user-defined mount base for VDBs, which allows you to provide a mount base of your choice during the provisioning of a VDB. Note: DIR_CACHE for the instance needs to be set to NO when users want to update the VDB dataset with the new mount base.

  • Optionally skip archive log validation
    With this feature, you can skip the archive log validation process during Snapsync if you choose to do so.

  • Load copy files support for Staging push
    The load copy files are now supported by the DB2 staging push automation script. This allows you to provide the load copy files along with the archive logs to successfully roll forward the database.

  • Allow Db2 dSources with Backup logs to rollforward to PIT
    The Db2 plugin introduces the Rollforward to a timestamp option to make sure the dSource is rollforwarded to the current time if no timestamp is provided during snapshot or to a PIT (timestamp) provided in Snapshot parameters or in Snapsync with Params.

Release 4.5.1

This plugin release consists of only bug fixes.

Release 4.5.0

This plugin release has the following set of new features and bug fixes.

  • Support for multiple backup paths for dSource ingestion
    The Db2 Plugin 4.5.0 version introduces the support for multiple backup paths instead of one for dSource ingestion. This allows you to provide single backup path for the dSource ingestion and add more backup paths with a dynamic UI to accommodate for the extra backup directories where the backup was split into.

Release 4.4.2

This plugin release consists of only bug fixes.

Release 4.4.1

This plugin release consists of only bug fixes.

Release 4.4.0

This plugin release has the following set of new features and bug fixes.

  • DB2 pull performance optimization
    The Db2 Plugin 4.4.0 version introduces the Pull Performance Optimization feature, which attempts to optimize the dSource workflows by allowing users to provide the degree of parallelisation to run the database restore operation. This feature allows users to ingest large databases in a faster way, provided that there are sufficient resources for Db2 plugin to implement this parallelisation in the operation.

  • Source sizing implementation on the DSIL DB2 plugin
    The source sizing feature aligns the data source experience with Delphix database standards that will improve your ingestion reporting experience on the per TB pricing model. This feature enables you to calculate the dataset size based on the total allocated space on the mount point provided by the Delphix Engine for the dataset. For more details about this feature, see Source Sizing Implementation for Datasets.

Release 4.3.2

This plugin release consists of only bug fixes.

Release 4.3.1

This plugin release consists of only bug fixes.

Release 4.3.0

The DB2 plugin 4.3.0 introduces Staging push support for HADR dSources. You can now create and maintain dSources configured with HADR using the Staging push option.

Release 4.2.1

This plugin release consists of only bug fixes.

Release 4.2.0

This plugin release has the following set of new features and bug fixes.

  • Dsource snapshot with user-defined timestamp
    The Db2 Plugin version 4.2.0 introduces the dsource snapshot with the user-defined timestamp feature. This feature enables the user to specify a timestamp during dSource snapshot so that staging will roll forward to the requested timestamp before performing the dSource snapshot. For more information, see Linking a Db2 dSource.

Release 4.1.3

This plugin release consists of only bug fixes.

Release 4.1.2

This plugin release consists of only bug fixes.

Release 4.1.1

This plugin release consists of only bug fixes.

Release 4.1.0

This plugin release has the following set of new features and bug fixes.

  • User-specified mount path For DB2 dSource
    Users can specify the mount path of their choice on the target host to host the dSource dataset.

  • Staging push automation
    A set of scripts is being provided that can be used to automate the steps related to the restore and rollforward operations on the dSource.

Release 4.0.1

The Db2 Plugin version 4.0.1 includes the below improvements.

  • Added support for 11.1.4.6 fix pack.

Release 4.0.0

The Db2 Plugin version 4.0.0 includes the below improvements.

  • Plugin generated log file will now be placed at <toolkit path>/<Delphix_COMMON>/DB2_18f4ff11-b758-4bf2-9a37-719a22f5a4b8/logs/<instance name>.

  • More user-friendly log statements will be printed.

  • The logging.properties and advanceConf.config configuration files are now merged into the db2_plugin.conf file.

  • Dependency on redirect restore script to get the data path information is now removed.

Release 3.1.1

The Db2 Plugin version 3.1.1 introduces the support for full online backups, which are taken using the "exclude logs" syntax. This support is only applicable to the dSources created using the Backup and Logs ingestion mechanism on a single partition. 

In Db2, users have the flexibility to exclude logs while taking the full online backups. The Db2 plugin will read the backup header from the user-provided backup file. The backup header is used to figure out whether the backup was taken using the "exclude logs" syntax or not. In case the plugin detects that it was taken using the "exclude logs" option, then the required changes will be made in the restore syntax.

Release 3.1.0

The Db2 Plugin version 3.1.0 introduces the Staging Push feature. This feature will allow users to control the restore of the staging database and they can also control the state of the restored staging database. With the Staging Push feature, the restore and rollforward operations will be managed by the user from the CLI. During dSource creation (or RESYNC) the plugin will create an empty mount point and will provide a restore and rollforward template that will help the user to create the redirect restore script. Once the dSource will be ready then the user can perform restore and rollforward operations from CLI. The restore must be as per the plugin provided template. After the restore, the staging database should remain in rollforward pending state, and prior to the next snapshot, the user can do a rollforward to a specific Point-in-Time (by providing a timestamp to rollforward command) against the available archive logs.

Release 3.0.2

This release addresses a limitation in Db2 wherein the VDB can accept the connections when refresh, disable and delete Delphix operations are in process which eventually can corrupt the VDBs. This plugin version will reduce such occurrences by introducing maintenance window in these operations during which the VDB will not accept external connections. 

Release 3.0.1

The Db2 Plugin version 3.0.1 fixes the bug wherein the jobs on UI hung intermittently due to a known IBM Db2 bug.

Release 3.0.0

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 the restorePipelineLimit parameter to the desired value. The valid value for this field is any positive integer.

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

    CODE 
    # 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

restorePipelineLimit=10

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.

Contact Support Close