Volume Snapshots and Oracle Home Considerations

In the midst of us needing to do more with less every day, many of us are incorporating clones to simplify data refreshes to non-production database environments. Working harder is just not an option when we can use newer technology to get more by doing less.

Knowing Your Environment

Doing less effectively requires some planning for Oracle and a few questions to be asked:

1. Will you need to deploy to a new host/VM target as part of a clone?
2. Will an image with Oracle be used for the new Host/VM target or will you need to build out the Oracle installation as part of the process?
3. Will the Oracle Inventory need to be refreshed as the database is new to the target?
4. Is the entire host going to be refreshed or just a single database/a few databases of the total housed on the target host?
5. Does the environment use Oracle multitenant vs. single instance?
6. Is the environment using RAC, ASM or Oracle Managed Files?

With these questions, a requirement for clear architecture design comes into play.  Even if it’s not how the architecture has always been designed for Oracle environments, a flexible and consistent architecture must be decided to be successful.  The natural life of a database is growth, and many are finding RMAN and or the logical equivalent, import/export through Oracle Datapump isn’t an option due to the time required to use these well-known tools to the DBA.  As newer cloning strategies around native cloning or volume snapshot clones are considered, architecture requirements become even more prevalent. Volume snapshots are heavily utilized by customers with Silk, so I’m always considering best practices and how they differ for Oracle from other platforms.

Oracle Complexities

Automatic Storage Management (ASM) results in Oracle managing storage, not just the relational system.  This can often result in a chicken before the egg scenario when performing clones, requiring a step-by-step approach, switching between storage features and Oracle ones to complete a clone.

Oracle’s complexity of incorporating the Oracle Inventory and having it at a different installation location than the ORACLE_BASE (example /opt/app/oracle) or the ORACLE_HOME (example /opt/app/oracle/product/<version>/dbhome_1) can result with the inventory installation being outside of the volume snapshot, creating an inconsistent copy to the target from the source.

Using Oracle’s native cloning technologies simplify some of this, but also introduces challenges considering there’s seven different cloning technologies available natively, (a few are promoted, and others just have customers using them.)  Where sparse clone in Exadata is an optimal solution, it’s only available in Exadata.  Snap clone for ZFS is another solid solution, but without a GUI unless you have incorporated additional options via the Oracle Enterprise Manager and requires ZFS or ZDLRA appliances.  Most DBAs have discovered value in PDB clones, but although they have come a long way in a short while, they are physical clones that consume storage and must be managed just as physical databases.  Storage bloat in the cloud can be very costly and this method of cloning will result in considerable storage growth if used for enterprise development and testing.

Recommended Practices

What have become my adopted recommended practices to ease cloning demands?  

1. Create a standard architecture build and move all Oracle hosts/VMs to this.  No one should be hunting around to figure out what volume datafiles reside on, etc.
2. Have a global scripts directory that can be accessed from a jump server to all hosts/VM targets.  This will ease the management of the scripts and consider wrapper scripts that call the secondary ones, including uniform scripting standards, too.
3. Automate all environment settings, scripting and cloning processes.  All steps should be logged, and failsafe built in as part of the processes. 
4. Leverage multiple Oracle database homes and install each one in a separate volume to enable individual ORACLE_HOME cloning.
5. Move the oraInventory to within the volume for each ORACLE_HOME.
6. Keep all database files inside a single volume, enabling the IO required at the volume level vs. splitting files across volumes.
7. Use ASMLIB driver and avoid the buggier ASM Filter driver until Oracle stabilizes it.  If you don’t want to use ASM, there’s very little performance and ease of management in my opinion and UDEV or LVM is available.

I’m sure there are other requirements that I’ve found helpful as I clone, but curious if there are recommended practices that others have come across or implemented that have simplified the management of database cloning?