This Delphix HANA Virtualization Plugin is limited to supporting only HANA 2.0. The Delphix plugin delays recovery until a user decides to provision a virtual database for the first time from a specific source and snapshot.

A dSource of a physical database is a collection of full and incremental backups. A dSource of a virtual database is a collection of filesystem snapshots of the VDB at a specific point in time.

Snapshots within a dSource which is backed by a physical database represent incremental backups, which have been added to the list of files available for recovery.

The first provision of a point in time on a Timeflow initiates HANA recovery, using the full backup and any incremental backups contained within that snapshot. This process brings down the entire HANA system on the target for the duration of recovery. Recovery can be a lengthy process. The duration of recovery time is subject to the size of the database being recovered. Following recovery, the system is re-enabled and HANA is virtualized.

Creating a VDB of a (recovered root) VDB has no impact on the availability and is very fast.

Delphix recommends a tiered approach to provisioning: recover once a root VDB and then clone multiple child VDBs from this single root. Failure to follow this recommendation means customers lose the ability to harness our products key value proposition for HANA, which is agility. Below are the recommended tiers:

  • dSource: the ingested HANA backup file sets sourced from a physical database.
  • Root Virtual Database (VDB): A virtual HANA database constructed by recovery.
  • Child Virtual Database (VDB): A copy of the root VDB created at a specific point in time, cloned using Delphix technology. These copies are fast to create with a small initial storage footprint. Child VDBs are the recommended workbench for developers. Multiple Child VDBs can exist from a single root VDB. Each Child VDB corresponds to a root VDB snapshot.

Operational Best Practice:

  • Co-ordinate first provision to any target as this will take the entire HANA system down for the duration of recovery.
  • Construct one root VDB, based off a physical database dSource snapshot. Shut down the root VDB on the target to protect it and save HANA resources. Construct multiple child VDBs descended from the root VDB.
  • Create Object names which are meaningful.
  • Create Dataset Groups which help delineate to which tier an object belongs. For example:

  • Consider dividing targets into highly available systems (where child VDBs reside) and those which may be more commonly used for first provision (recovery of root VDBs).

  • Disable recovered root VDBs once they are provisioned AND provision children from these root objects. The children are dispensable in the sense that they require very little time and effort to construct.

Benefits of this Plugin Architecture:

  • No formal requirement for a staging target
  • Virtualization of individual tenant databases instead of the entire system
  • Ability to mix and match virtualized tenants across any HANA system
  • Reduced Storage footprint. Child VDBs may use significantly less storage while their on-disk representation matches the root VDB.
  • Relaxes strict requirement of exact HANA version match between source and target, leveraging HANAs ability to recover an earlier version against a more recent version. Note: Only a backup from a tenant database system can be utilized to copy into a tenant of another tenant database system.
  • Source backup files can be ingested from a surrogate host which is different from the production source host - thereby minimizing impact to the production source host.