While Delphix is widely deployed at Oracle customers, the question comes up about how to use Delphix with Exadata. Many companies are using these products together and we’ll discuss some of the typical considerations for this deployment scenario.
The first step with the Delphix workflow is syncing to source systems. Delphix uses standard RMAN APIs to sync with Oracle databases and thus is 100% compatible with Exadata sources. There are some connectivity options as the Exadata database nodes have multiple network interfaces. At a minimum, Exadata database servers are configured with client-access and management-access interfaces. There are also extra optionally configured network interfaces. If desired, one can isolate Delphix traffic onto one of these extra interfaces or simply use the standard client-access interface.
Delphix can leverage any storage product supported by the underlying hypervisor (e.g. VMware, KVM) or cloud platform used for the Delphix VM. Databases and file systems deployed using Delphix are typically on industry standard Flash or Fiber-channel storage. Direct access to Exadata storage is restricted and thus not available to Delphix.
Oracle databases hosted by Delphix can be deployed on any of Unix/Linux platforms supported by Oracle. In the Exadata context, Delphix “VDBs” can run on the database servers within Exadata or any Linux/x86 server of your choice. Delphix simply looks like NFS storage to the VDB host (Exadata or standard x86).
Delphix has full support for the rich Oracle features like Advanced Compression, Encryption, Multi-tenant, and In-Memory. However, Oracle has placed a license restriction on Hybrid Columnar Compression (HCC) to running on Oracle storage only. While Delphix can also use Oracle ZFS and Flash products, the current product does not pass this Oracle kernel check for HCC. This compression option is primarily used for read-only data seen with Data Warehouse deployments. For transactional applications like Oracle EBS, Peoplesoft, and SAP, Exadata customers typically are using Advanced Compression if any compression at all. Delphix can ingest HCC source data without issue, again using standard RMAN APIs. To access that data (on ‘non-Oracle’ storage), one needs to uncompress the data using something like ‘alter table … move uncompress.’ Another approach is to leverage Oracle database links from a Delphix VDB back to a source or test master on Exadata. Again HCC data is primarily read-only so creating multiple copies of that data is of limited value.
Delphix supports high-performance workloads when deployed with best practices and proper infrastructure. These design activities are particularly important for the Exadata scenario. For example if the workload requires 2 GB of network IO and 20K IOPS, one needs the networking and storage to support it. Flash storage is growing more popular in IT shops and may be a consideration here. The common recommendation for Exadata customers is to keep a performance or user acceptance test environment on Exadata to support a true like-for-like comparison. Delphix has a ‘virtual to physical’ or ‘virtual to Exadata’ process where databases can be rehydrated back onto physical Exadata/ASM storage. This means that performance or UAT environments can also be built from Delphix, if desired. Some customers have also used this approach for their production Exadata migrations.
Here is an example customer landscape with production and QA using Exadata while core development and testing leverages Delphix. In summary, Delphix and Exadata have been commonly deployed to leverage the strengths of each product.
