Documentation 5.0

Release Information

Introduction

Getting Started

Delphix Engine System Administration

Virtual Database Management with the Delphix Engine

Data Backup and Recovery

Delphix Modernization Engine

Delphix Masking

Virtualizing Unstructured Files in the Delphix Engine

Virtualizing Oracle E-Business Suite in the Delphix Engine

JetStream

Mission Control

Delphix Express User Guide

Reference

Documentation for Previous Versions of the Delphix Engine

Delphix Server 3.0 Documentation
Delphix Server 3.1 Documentation
Delphix Engine 3.2 Documentation
Delphix Engine 4.0 Documentation
Delphix Engine 4.1 Documentation
Delphix Engine 4.2 Documentation
Delphix Engine 4.3 Documentation

Skip to end of metadata
Go to start of metadata

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 log in to the workstation where the request originated. More information of 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 Instances

A DB2 instance is a logical database manager environment that can catalog databases and set configuration parameters. Depending on specific needs, customers can create multiple instances on the same physical server to provide a unique database server environment for each instance. Associated with an instance is the concept of an instance owner. This is the user that "owns" that instance and has SYSADM authority over the instance and all databases inside that instance. SYSADM authority is the highest level of authority in DB2 and lets this user perform several database management activities such upgrade, restore, edit configurations, etc... More information about intances can be found the IBM knowledge center. 

Delphix DB2 Instances

Delphix operates on the instance level and requires that the staging and target hosts must have the empty instances created a prior to Delphix using them, and the instance owners added as environment users. It is important to note that our dSources and VDBs are entire instances and NOT specific databases inside an instance.

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 non-forced 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.