Re: consolidation

From: Jeremy Schneider <jeremy.schneider_at_ardentperf.com>
Date: Tue, 13 Oct 2015 12:32:05 -0400
Message-ID: <CA+fnDAbH=y8c-dpC3WnkOJpM_dh_sZf=Xkqum6oP62n-RLsjTg_at_mail.gmail.com>



On Tue, Oct 13, 2015 at 11:25 AM, Tim Gorman <tim_at_evdbt.com> wrote:
> Q: Why isn't the hosting team and vendor proposing a VM cluster to run VMs
> on a template of one database instance and listener per VM instead?
>
> A: Because then you wouldn't need as much hardware, and it would be too
> easy to manage, and it would be more highly available, all of which results
> in lower M2V (a.k.a. money to vendor) and M2H (a.k.a. money to host).

Definitely a good architecture, but there is still a case to be made for other modes of consolidation!

  1. i do think VM-based consolidation makes a strong manageability argument
  2. every VM needs an IPs, and in some cases that might be a limited resource
  3. if you have lots of small databases with small SGAs, then VM-based consolidation might be very memory-inefficient. in that case you may need *more* hardware to do VM-based consolidation that you'd need for instance-level consolidation.
  4. some apps support schema/tablespace-level consolidation which probably beats everything else for efficiency. also 12c containers may give these same efficiencies around RAM/SGA.

i had a blog post about this a few years ago...

http://ardentperf.com/2013/12/02/osp-2c-build-a-standard-platform-from-the-bottom-up/

but i've hijacked woody's thread now! changing the subject line...

--
http://about.me/jeremy_schneider
--
http://www.freelists.org/webpage/oracle-l
Received on Tue Oct 13 2015 - 18:32:05 CEST

Original text of this message