Delphix, EBS and Configuration Control

Guest blogger: Shawn McElhinney - In any Oracle E-business Suite, (EBS) environment, configuration control is significantly important to ensure consistency and knowledge that during deployment, everything will go as planned without any steps missed or misconfigured. Over the course of my career I've seen a myriad of approaches to configuration control.  While every company may have their own approach, the one consistency remains that at some point, mistakes will happen.

Refreshing environments on a scheduled basis can help alleviate this issue.  Implementing a refresh schedule brings a level of rigor to an implementation and forces developers to periodically check in code to prevent it from being lost.

The concept is simple.  An environment refresh schedule is established, most often on a monthly cycle.  The goal is to use production as the source instance and clone it to the desired targets.  This may not seem like a major undertaking, but as your EBS system grows, the time required to perform this activity increases.  As the size of the production system increases, the longer the downtime for refreshing your targets.  This results in downtime for these valuable resources, as developers and testers can't work if they don't have an environment to work on.

This creates a downward spiral - as your data grows, you have more scenarios to validate code against or you run the risk of introducing bugs when the code is promoted.  More data, more testing scenarios.  RapidClone, the most often used scripting process for cloning, does not maximize the value of this model, by itself, it actually inhibits it.

If you rely on RapidClone alone, the reality is your refresh cycle becomes inversely proportionate to the size of your data!  The end result: you refresh/clone with less frequency, leaving developers to work with stale data, testers with datasets that may not accurately depict the current state of production, and a higher probability of incomplete code and/or bugs being deployed to production.

To combat this without Delphix one might opt to "pad" their solution with additional environments.  This enables a DBA to shift activities from environment "A" to environment "B" to accommodate a clone/refresh.  This still introduces risks of disk over-allocation and does not address excessive cloning time.  It can also introduce instance sprawl - where owners refuse to give up "their" instance for refresh because they can't afford to have it down for days.

With Delphix, the capability to utilize virtual clones eases a majority of this pain.  It starts by ingesting a full copy of your production instance - data, binaries, the entire database and application stack.  The Delphix engine also compresses your data during ingest to roughly 30% of the current physical size.  It is also capable of synchronizing with production periodically to ensure your virtual image remains current.

This almost negates instance size as an inhibitor of cloning.  Think of Delphix as a genie who mystically gave you 3 times the space for your instances!  Not only does Delphix compress the instance into an image, but it also provides integrated utilities that work in conjunction with RapidClone and enable you to augment the cloning process with your own custom pre and/or post-clone scripts!

Probably the best thing I've seen out of this particular functionality is the time savings.  Leveraging Delphix for EBS enables DBAs to reduce their cloning time from days to hours, or in some cases minutes!  An added benefit is the configurable user interface that is capable of allowing instance consumers (developers, functional users, DBAs, etc) to actually provision an instance on their own and manage that instance as if it was source code!

Let's recap.  Configuration control is designed to ensure you are deploying stable development items (code, configurations, etc.) to your production instance.  As this instance grows, cloning becomes more and more resource consuming (time, disk space) and the frequency of clone refreshes decreases.  This decreased frequency significantly increases the risk of inadequately tested code being promoted to production.  This ultimately puts the stability of your production instance at risk.

Delphix decreases your instance footprint by orders of magnitude, maintains a source instance that remains synchronized with production, and substantially decreases the time invested in the cloning process.

Wanna know what it feels like to be a superhero?  Take Delphix for a spin.

You can read more from Shawn McElhinney at https://shaggydba.wordpress.com.