Using Oracle VM to Create Dev and Test Environments

Oracle Solaris is on its way out, which means that for many shops the next project on the board will be to migrate to another operating system for Oracle database servers. Many choices are available with Linux being a top contender. If the enterprise is already using virtualization most likely Linux x86_64 is the O/S of choice. Oracle provides Oracle Enterprise Linux, a modified form of Red Hat pre-configured for database servers, that is available using the Oracle VM product. This is a good choice as it can reduce licensing costs over using VMWare since each individual VM doesn’t need licensing. Let’s see how using an Oracle OEL 7 VM can provide a test bed for database migrations.

Using an Oracle VM provides an environment that doesn’t require additional hardware expenditures and is configurable to provide one or more network interfaces; this is good because backup traffic can be isolated to its own network, separate from normal user traffic. It’s also easy to create and destroy these environments so they can be re-built with a more suitable disk/memory/CPU configuration, something physical hardware sometimes can’t provide. A simple configuration using OEL 7 and Oracle 12.2.0.1 might include:


Network interface eth0 configured for user traffic
Network interface eth1 configured for backup traffic
A 'standard' ORACLE_HOME configured for single-instance databases
The standard listener on port 1521, which can be reconfigured to use a non-standard port
One or more databases
Autostart configured for the databases when the VM is rebooted
Sufficient disk space for datafiles, controlfiles and redo logs
Oracle Managed Files to make file management simpler
Modified database templates preconfigured with the standard enterprise database configuration
(pre-configured options to install, additional tablespaces, etc.)

The above configuration allows for minimal intervention on the part of the DBA to create blank databases for the enterprise, ready for data import, necessary if the Data Pump method of database migration is used.

Moving from SPARC Solaris to x86_64 Linux means an ‘endian’ change for the database files and RMAN can perform this task given sufficient additional space to hold the converted files. This can also be accomplished by creating a blank database (as mentioned above) and using Data Pump to transfer the data. This second method requires less disk space since no interim files are created to effect the endian change. This is, of course, a decision only the enterprise can make. Advantages to the RMAN method include having RMAN do most of the actual work and allowing the migrated database to be ‘rolled forward’ before it is released to the users. Advantages of Data Pump include less overall space required and no endian conversion is necessary. Weigh the advantages of each method with their respective restrictions and select the desired method for migration.

As mentioned previously, using a VM for migrations allows for configuration changes that may not be possible with physical hardware (on-the-fly memory sizing and CPU allocation) and the option of re-building the VM with more appropriate parameters after initial testing reveals areas needing adjustment.

One issue with VMs is the possible performance degradation when multiple databases are running on the same virtual machine; remember that I/O traffic is compounded with a VM configuration as not only is the I/O affecting the virtual machine, it’s also affecting the underlying physical server hosting the various VMs. Careful consideration must be given to not be overly optimistic with respect to performance.

Virtual machines can be configured with high availability, which allows for moving a VM between servers in the pool depending on the load on a given server or its availability. Yes, similar configurations can be created for physical servers but it’s easier in the virtual machine ‘world’ as the underlying structure to implement such moves is already configured by the VM manager. This can make using a VM a more ‘reliable’, if not more resilient, option.

Server patching is different, since regular snapshots of the VM can be taken as restore points so, if a patch does adversely affect the VM it can be restored to its previous version fairly quickly. Snapshots though, are not a reliable method for backup up a VM as the database or databases are still running when such snapshots are taken. RMAN backups are recommended, either through scripts or with a media management layer, to ensure recoverability.

There are detailed instructions on the Internet for creating virtual machines with a variety of tools; with Oracle VM Manager templates can be uploaded that provide the pre-configured O/S and database software installation. Such templates usually are configured for RAC but offer the option of re-configuring for single-instance databases. Detailed instructions will not be provided in this article. Visit the following URL to read the Oracle VM instructions: How to Use Oracle VM Templates.

Although Solaris will be available until 2020 it’s a good idea to consider migrating to a platform offering longer-term support, like Linux on x86_64. Planning now may make the transition much easier when it finally becomes a necessity.

See all articles by David Fitzjarrell

David Fitzjarrell
David Fitzjarrell
David Fitzjarrell has more than 20 years of administration experience with various releases of the Oracle DBMS. He has installed the Oracle software on many platforms, including UNIX, Windows and Linux, and monitored and tuned performance in those environments. He is knowledgeable in the traditional tools for performance tuning – the Oracle Wait Interface, Statspack, event 10046 and 10053 traces, tkprof, explain plan and autotrace – and has used these to great advantage at the U.S. Postal Service, American Airlines/SABRE, ConocoPhilips and SiriusXM Radio, among others, to increase throughput and improve the quality of the production system. He has also set up scripts to regularly monitor available space and set thresholds to notify DBAs of impending space shortages before they affect the production environment. These scripts generate data which can also used to trend database growth over time, aiding in capacity planning. He has used RMAN, Streams, RAC and Data Guard in Oracle installations to ensure full recoverability and failover capabilities as well as high availability, and has configured a 'cascading' set of DR databases using the primary DR databases as the source, managing the archivelog transfers manually and montoring, through scripts, the health of these secondary DR databases. He has also used ASM, ASMM and ASSM to improve performance and manage storage and shared memory.

Latest Articles