Version 19c

General Information
Library Note Morgan's Library Page Header
Which has the higher priority in your organization: Deploying a new database or securing the ones you already have? Looking for a website, and resources, dedicated solely to securing Oracle databases? Check out DBSecWorx.
Be sure to view the full listing of monographs in Morgan's Library
Purpose Virtualization is a great concept. Occasionally it also actually has value in practice. The point of this page in the library is not to tout the value of Oracle VM (OVM) which now with Version 3+ is turning into something decent, or to say nice things about IBM's VPars and other virtualization technologies whose origins go back to the old IBM 370 mainframe days ... perhaps earlier. Nor is the purpose to slam Dell/EMC's VMWare products for their total inadequacy as a production database environment. Rather it is to point out the obvious to anyone wishing to visit this page and read it. The following is taken, verbatim, from Oracle Support. Emphasis on specific points is mine.
Virtualization Technologies
Network There are three different versions of network virtualization I have found two explicit and one implicit. One explicit version is typified by network admins creating VPNs on existing infrastructure such as a Cisco switch. The other typified by appliances such as Oracle's OVN (Virtual Network Appliance). The implicit version is typified by blade servers such as Cisco's UCS where no-one openly states that the network is virtualized by it must be by definition as the chasis doesn't have sufficient NIC cards to do anything but virtualize.

Either form of explicit network virtualization will work for stand-alone databases but with the former there are very large dangers in letting a network administrator use it with the RAC cluster interconnect. Oracle has very explicit guidelines for using VPNs for the interconnect and they must be followed or the DBA will spend countless hours tracking down hard to identify failures.

The implicit form, in blade servers such as UCS should NEVER be used for the cluster interconnect unless you are being paid by the hour during outages. The most unstable RAC clusters I have worked with were all built on blades. And not only are they unstable but the merging of packets of different types, with different protocols, renders tracing somewhere between difficult and impossible.
Storage Storage virtualization typified by storage arrays such as the EMC VMax and Hitachi VSP can be very valuable if the storage administrator truly understands the implications and most do not.

The worst storage virtualization failure I observed was caused by a storage admin allocating 12GB of space to multiple databases on the theory that they would never, between them, use the 12GB because redo logs were deleted every night after the RMAN backup completed. Except, of course, for the nights on which there were backup failures which resulted in the space filling up and all of the databases failing when they could no longer archive redo logs. The DBA team had a difficult time figuring out how multiple databases crashed within minutes of each other for the exact same reason when it had appeared each has 12GB of available space and none had used that much space. Needless to say the storage team had not explained their attempted sleight-of-hand to the DBAs who wasted hours trying to figure out what had happened.
Operating System There are only three forms of O/S virtualization that should be trusted for RAC databases: Oracle Virtual Machine (OVM), Solaris Containers, and IBM LPars (both AIX and Z Series). Everything else is unsupported by Oracle and will cause you to waste far more money than management thinks they will save with virtualization. Remember too, between Thanksgiving and Christmas when you want to be with the family and the system is running at peak load ... the management will be at home with their families. You will be trying to work an SR with Oracle Support who, knowing what you did, will be remarkably unsympathetic.
Support Position for Oracle Products Running on VMWare Virtualized Environments [ID 249212.1]
Oracle Support Doc Purpose
Explain to customers how Oracle supports our products when running on VMware

Scope & Application
For Customers running Oracle products on VMware virtualized environments.
No limitation on use or distribution.

Support Status for VMware Virtualized Environments
Oracle has not certified any of its products on VMware virtualized environments. Oracle Support will assist customers running Oracle products on VMware in the following manner: Oracle will only provide support for issues that either are known to occur on the native OS, or can be demonstrated not to be as a result of running on VMware.

If a problem is a known Oracle issue, Oracle support will recommend the appropriate solution on the native OS. If that solution does not work in the VMware virtualized environment, the customer will be referred to VMware for support. When the customer can demonstrate that the Oracle solution does not work when running on the native OS, Oracle will resume support, including logging a bug with Oracle Development for investigation if required.

If the problem is determined not to be a known Oracle issue, we will refer the customer to VMware for support. When the customer can demonstrate that the issue occurs when running on the native OS, Oracle will resume support, including logging a bug with Oracle Development for investigation if required.

NOTE: Oracle has not certified any of its products on VMware. For Oracle RAC, Oracle will only accept Service Requests as described in their note on Oracle RAC 19c and later releases.

Related Topics
Oracle Support
What's New In 19c
What's New In 20c-21c

Morgan's Library Page Footer
This site is maintained by Dan Morgan. Last Updated: This site is protected by copyright and trademark laws under U.S. and International law. © 1998-2021 Daniel A. Morgan All Rights Reserved