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.
