Why would we not deploy 2 or more DBs in the same VMware VM?

Matt:

The technique you are describing is called instance stacking. There are three approaches to consolidation, generally:

• Instance stacking (running multiple instances per OS image).
• Schema stacking (taking multiple logical databases and consolidating them into a single database using individual schemas to segregate the projects).
• OS-level virtualization.

It is obviously possible (although not terribly common) to use any of these in combination. Thus, you could (theoretically) use instance stacking on a VM, as you indicate.

Problem is, both instance stacking and schema stacking are no longer recommended by Oracle as a best practice. I see these methods used occassionally (like Penske was using instance stacking in an EBC I attended recently). However, according to Oracle's own documentation (http://www.oracle.com/technetwork/database/multitenant-wp-12c-1949736.pdf), both instance stacking and schema stacking are now deprecated. The problem with instance stacking is that it provides no effective way to do things like load balancing and quality of service. Thus, one instance can run wild, and soak up all of the resources of the box, while the other instance is suffering performance issues. OS-level virtualization allows you to set resource sharing for VMs such that a production VM is guaranteed access to hardware resources, and a test / dev VM can never steal those resources away from the production VM. Similarly, with virtualization, you can use live migration to dynamically move a workload from one physical server to another, thus avoiding islands of capacity. Instance stacking provides none of these features.

As for schema stacking (which you did not ask about), that creates huge security concerns.

The way I usually put it in terms of both instance stacking and schema stacking is that they are not dead, but they are both smelling really bad.

Let me know if this helps.

Regards,

Jeff