Skip to main content
Delphix

Understanding vFiles (KBA3789)

 

 

KBA 3789

 

vFiles

vFiles are also known as unstructured files, which refers to data stored in a file system on UNIX/Linux or Windows that is not managed by a Database Management System (DBMS) or similar database software.

Unstructured files can consist of anything from a simple directory to the root of a complex application like Oracle E-Business Suites.  As with other data types, you can configure a dSource for unstructured files to sync periodically with a set of unstructured files external to the Delphix Engine. This dSource is a copy of these physical files stored on the Delphix virtualization engine.  

On UNIX/Linux platforms, dSources are initially linked and periodically synced by an implementation of the open-source rsync utility.  
On Windows, files are linked and synced using the Microsoft robocopy utility.  Unstructured file dSources enable you to provision “vFiles,” which are virtual copies of data that are fully functional read write copies of the original source.  vFiles can be mounted to one target host, or to many target hosts.

Delphix also has the concept of an empty vFile, which is a vFile with no initial source data, thus not a dSource.  This is an empty directory or folder mounted directly to a target host, with no link/sync from a source host.  This folder can then be populated like any other directory or folder from the target host or hosts.

Scenarios for Using vFiles

  1. Virtualizing the directory containing RDBMS software executables and libraries (i.e. Oracle Database $ORACLE_HOME directory), along with virtualizing the Oracle virtual database itself

Scenario 1: Where the $ORACLE_HOME is virtualized along with the virtualized Oracle database, it is now possible to test most patches and upgrades fully, because now the files and directories can be rewound to a starting point, or refreshed completely from their sources.

  1. Virtualizing the directory containing application code (i.e. Peoplesoft, Siebel, etc) along with the virtual database on which it depends

Scenario 2: There are many situations where application code and database objects are part of a change being tested.  Only virtualizing the database but not the application code makes testing complicated. Delphix support for the full stack of the Oracle E-Business Suites (EBS) suite is an excellent example, where the application code on the EBS database tier (a.k.a. dbTechStack) is a vFile, the application code on the EBS applications tier (a.k.a. appsTier) is one or more additional vFile(s), with both of these glued together with the core EBS database VDB.

  1. Creating a shared folder for storing scripts or common utilities across an enterprise

Scenario 3: It is common for non-production hosts to have shared folders or directories, usually mounted from an NFS or Samba server and managed by systems- or network-administrators.  In this situation, the Delphix virtualization engine becomes the NFS or Samba server, managed by the Delphix administrator.
The most common use-case for this is providing a shared folder containing scripts and programs used by Delphix VDB hooks, or an installation of the open-source DxToolkit package, or other useful utilities which are not part of standard distributions which are often used in Delphix hooks such as the PLINK executable, or the JQ executable, etc.

The reason for doing this is that often program code needs to be virtualized along with the database, in order to allow refresh, rewind, and other control of the full stack application being tested.
 

How to Deploy vFiles?

First, one must link a dSource, as described Linking Unstructured Files, which also describes the use of SnapSync policies for scheduled automated syncing.

Once an unstructured file dSource is linked, then one can provision vFiles, as described Provisioning Unstructured Files as vFiles, and customizations such as methods for starting/stopping application processes are deployed using hooks as described Unstructured Files with Hook Operation.