DB2 on Delphix: An Overview
Delphix Administration / DB2 Environments and Data Sources / DB2 on Delphix: An Overview

Introduction to DB2

DB2 for Linux, UNIX and Windows is a database server product developed by IBM. Sometimes called DB2 LUW for brevity, it is part of the DB2 family of database products. DB2 LUW is the "Common Server" product member of the DB2 family, designed to run on most popular operating systems. By contrast, all other DB2 products are specific to a single platform.

DB2 LUW was initially called DB2 Universal Database (UDB), but over time IBM marketing started to use the same term for other database products, notably mainframe (z-Series) DB2. Thus the DB2 for Linux, UNIX and Windows moniker became necessary to distinguish the common server DB2 LUW product from single-platform DB2 products.

The current DB2 LUW product runs on multiple Linux and UNIX distributions, such as Red Hat Linux, SUSE Linux, AIX, HP/UX, and Solaris, and most Windows systems. Multiple editions are marketed for different sizes of organization and uses. The same code base is also marketed without the DB2 name as IBM InfoSphere Warehouse edition.

The version numbers in DB2 are non-sequential with v10.1 and 10.5 being the two most recent releases. Specifics of DB2 versions and platforms supported on Delphix are located in the DB2 Compatibility Matrix. 

DB2 Authentication

Authentication is the process of validating a supplied user ID and password using a security mechanism. User and group authentication is managed in a facility external to DB2 LUW, such as the operating system, a domain controller, or a Kerberos security system. This is different from other database management systems (DBMSs), such as Oracle and SQL Server, where user accounts may be defined and authenticated in the database itself, as well as in an external facility such as the operating system.

Any time a user ID and password is explicitly provided to DB2 LUW as part of an instance attachment or database connection request, DB2 attempts to authenticate that user ID and password using this external security facility. If no user ID or password is provided with the request, DB2 implicitly uses the user ID and password that were used to login to the workstation where the request originated. More information on DB2 authentication and authorization is available via IBM documentation.

Delphix DB2 Authentication

Delphix for DB2 requires that that the staging and target hosts must already have the necessary users and authentication systems created/installed on them. Delphix will neither create users nor change database passwords as part of the provisioning process.

DB2 Database Level Support

DB2 database level support contains:

  • Support of multiple database linking in a Single Instance, which allows Delphix Engine users to utilise an available instance on the target more efficiently.
  • Supports the use of customer supplied directory for DE Toolkit, DB2 Mount Points, and DB2 Delphix files/logs. Customers can now easily manage all of their content in once place.
  • Supports BLU feature which is an in-memory concept of DB2.
  • Supports Kerberos environments.
  • Support for VDB at same OS version level or one level higher than Staging/Production.
  • Intelligent handling of HADR log-gaps.

High Availability Disaster Recovery (HADR)

The HADR feature of IBM DB2 provides a high availability solution for both partial and complete site failures. It protects against data loss by replicating data changes from a source database, called the primary, to one or more target databases, called the standby. 

Delphix HADR

HADR replication takes place at a database level, not at the instance level. Therefore, a standby instance can have multiple databases from multiple different primary servers/instances on it. If the instance ID on the Delphix standby is NOT the same as the instance ID on the primary, the Delphix standby instance ID MUST have database permissions secadm and dbadm granted to it on the primary database. These permissions, and all HADR settings, must be implemented on the primary database BEFORE you take the backup on the primary database.

Log Transmitting

All changes that take place at the primary database server are written into log files. The individual log records within the log files are then transmitted to the secondary database server, where the recorded changes are replayed to the local copy of the database. This procedure ensures that the primary and the secondary database servers are in a synchronized state. Using two dedicated TCP/IP communication ports and a heartbeat, the primary and the standby databases track where they are processing currently, the current state of replication, and whether the standby database is up-to-date with the status of the primary database. When a log record is "closed" (still in memory, but has yet to be written to disk on the primary), it is immediately transmitted to the HADR standby database(s). Transmission of the logs to the standbys may also be time-delayed.

Multiple Standby

Beginning in DB2 v10.1,the HADR feature supports multiple standby databases. This enables an advanced topology where you can deploy HADR in multiple standby mode with up to three standby databases for a single primary. One of the databases is designated as the principal HADR standby database, with the others termed as auxiliary HADR standby databases. As with the standard HADR deployment, both types of HADR standbys are synchronized with the HADR primary database through a direct TCP/IP connection. Furthermore, both types support the reads on standby feature and can be configured for time-delayed log replay. It is possible to issue a forced or unforced takeover on any standby, including the delphix auxiliary standby. However, you should never use the Delphix auxiliary standby as a primary, because this will impact Delphix performance.


Delphix HADR Synchronization

The Delphix for DB2 uses the HADR capability of DB2 to synchronize data from a production DB2 database into a Delphix-controlled DB2 "standby" server. By using this mature and existing DB2 capability, the Delphix Engine is able to ingest data and keep the standby server in sync with only a minimal impact on production. The HADR connection is configured to Super-Asynchronous (SUPERASYNC) mode where log writes are considered successfully transmitted when the log records are sent from the primary database. Because the primary database does not wait for acknowledgements from the standby database, there is no delay on the primary and transactions are considered committed regardless of the state of the replication of that transaction. For further information on Delphix synchronization, see Linking a dSource from a DB2 Database: An Overview.