This Delphix HANA Virtualization Plugin supports HANA version 2 exclusively; there is no support for HANA version 1. This solution invokes HANA recovery of database backup files when a user chooses to provision a virtual database from a specific source and snapshot.

A dSource of a physical database is a collection of Full and Delta (incremental or differential) backups. The necessary backups to create the dSource can be created one of two possible ways:

  • Delphix-initiated backups (where Delphix performs the actual backup operation during a dSource snapshot)
  • External backups (where the backup files are created outside of Delphix and must exist prior to dSource snapshot operation)

This solution does not incorporate HANA archived logs; virtual databases can only be provisioned from HANA backup files of a dSource (inheriting the state of the database which is preserved by the backup file). 

With Delphix-initiated backups, the first dSource snapshot performs a Full backup, and all subsequent dSource snapshots perform Incremental backups, building upon the first Full backup.
With External backups, the first dSource snapshot must include a Full backup, but can optionally include one or more Delta backups. Subsequent dSource snapshots can be based upon additional Delta backups (building upon a predecessor Full backup), or another Full backup.
There are two forms of External backups supported by the HANA plugin:

  • Native Backups (where backups are written in Native storage format to local storage, without the involvement of a third-party backup tool)
  • Third-Party Backups (where the integration of HANA and a third-party backup tool causes the backup files and backup metadata to be managed centrally by the third party backup system and repository). As of the 5.3.7 release, the HANA plugin supports only Commvault third-party backups.

 In the case of the Commvault external backups, a dSource snapshot consists of metadata information only. Unlike Native external backups, the Commvault solution omits the transfer of the backup files onto the Delphix Engine. All backup files reside on Commvault only and are retrieved from Commvault during the HANA recovery e.g. the creation of a VDB from a dSource snapshot).

With all forms of backup in this solution, VDB provision operations from a dSource snapshot must invoke the HANA database recovery of the relevant HANA backup files. This HANA database recovery process must stop the entire HANA instance on the target for the duration of recovery. The HANA instance may contain multiple tenant databases, causing them all to stop during the database recovery steps. HANA database recovery can be a lengthy process. The duration of recovery time is subject to the size of the database being recovered. After completion of HANA recovery, the HANA instance is restarted along with the pre-existing tenants and will contain the newly-recovered VDB tenant.

VDB provision operations from a VDB snapshot (ie: not from a dSource snapshot) do not require HANA database recovery, do not stop the target HANA instance and tenants, and can occur very quickly.

Because of this HANA recovery requirement, Delphix recommends a tiered approach to provisioning of virtualized databases:

  • recover a dSource snapshot once to create a VDB  (called a ROOT VDB).
  • clone one ore more user VDBs (called CHILD VDBs) from the single ROOT VDB.

Failure to follow this recommendation diminishes the 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 the first provision to any target as this will take the entire HANA system down for the duration of recovery.
  • Construct one root VDB, based on 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 that are meaningful.
  • Create Dataset Groups that help delineate to which tier an object belongs. For example:

  • Segregate user targets  (where CHLD VDBs reside) from the target where HANA recovery must take place to create the ROOT VDB.

  • Provision end-user VDBs as CHILD VDBs, so that they can be created, refreshed and rewound quickly (ie: without the need for HANA recovery during the CHILD VDB operation)
  • Perform any common post-recovery operations on the ROOT VDB and snapshot it prior to provision of CHILD VDBs for end-users, to further streamline provisioning steps

  • Disable ROOT VDBs so that data remains untouchable by end-users, and to save system resources.

Benefits of this Plugin Architecture:

  • Avoids absolute 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.
  • Backup through CommVault is also supported with this Plugin. Database Backup taken by CommVault can be used to create dSource and VDB. A dSource in such cases will include only the metadata information only and hence reduced storage footprint.

Related Topics

Delphix Architecture with HANA