Re: Consolidation onto Exadata Cloud_at_Customer on premise cores-->OCPUs

From: Franck Pachot <franck_at_pachot.net>
Date: Sun, 2 Sep 2018 13:18:16 +0200
Message-ID: <CAK6ito2HvPd7onGW-1S1563yT1+9dTAPzJeQ-s2uTsv-p-P2Xg_at_mail.gmail.com>



Hi,

In your list of consolidation options, I agree with all except: 2. Oracle VM.
I understand that the infrastructure team fears to manage another hypervisor but OVM is not so difficult when used for simple things (here you just need CPU pinning). You have RAC databases, that's more complex to manage. If you want to reduce complexity, check if you really need RAC. In my experience, OVM was the right choice to do capacity on demand for customers where ODA was not a solution (e.g because of lack of flexibility in editions, in storage capacity). However, you are right that a cloud solution may be easier to present to financial folks, and Oracle gives good discounts when moving on-premises licenses to Cloud credits.

You didn't mention any DR solution. RAC protects the service, but not the data. DR solutions will be different in Standard and Enterprise editions. Do you plan to have two cloud_at_customer Exadata? That's big hardware to run 40 databases.

Now about OCPUs, that's not easy. This 30-40% reduction means nothing. Do not count on reduction when going on Exadata as lot of Exadata features are there to use more CPU: parallel query, HCC compression,... You save on BI queries if they are offloaded to SmartScan which really depends on your workload. But when you consolidate all your databases, there's probably only a small part of it which benefits from SmartScan.

The major reduction comes from Cloud services and consolidation. Probably not from multitenant as most of your databases will not share the same CDB (you have some Standard Edition, you have different versions, maybe different charactersets, and will still separate prod environments). You will probably run one database service per database. However, while on-premises you size each server to cope with the peak activity, the cloud service allows you to stop some instances when not used (e.g a test environment used once per month) or run with low OCPU and be ready to increase only when needed. If you have access to autonomous services, you can even do this scale-up without application interruption.

Those are just ideas to think about. Choosing and sizing a different infrastructure is something more complex.

Regards,
Franck.

On Sat, Sep 1, 2018 at 7:22 PM anthony Sanchez <anthonycsanchez_at_gmail.com> wrote:

> Hello Folks,
>
> I'm trying to figure out what my OCPU requirements will be if I migrate
> from:
>
> non exadata / non multitenant --> exadata cloud_at_customer (includes
> multitenant)
>
> I've heard from one exadata customer that you can expect a 30-40%
> reduction in db compute cores needed. I anticipate that multi tenancy will
> help the reduction of CPU cores needed as well. I understand that the
> gains realized will depend on types of workloads and other factors. I'm
> hoping others can share their experiences with regards to cpu core
> reduction (for different workloads and overall) and also general
> experiences with exadata cloud_at_customer. All feedback welcome and
> appreciated!
>
> some background:
> I work for a municipality. We are an Oracle and SQL shop and have 2 DBAs,
> each of which wear many hats.
>
> For Oracle we have:
> a mix of 11.2.0.4 and 12.1.0.2
> both Oracle Linux and Windows - ODA's and HP servers
> some standard edition
> enterprise edition plus partitioning and some RAC
>
> We have roughly 25 oracle databases, and are about to kick off a big
> project that will add 5 more databases. We foresee growing by another 5-10
> databases over the next few years. Our workloads are diverse and the
> majority of our databases are under 200G, with a handful that cross into a
> few TB.
>
> We keep buying hardware to satisfy different licensing combinations. Our
> leadership is not comfortable with moving workloads to the public cloud and
> it must remain on premise. We have a new system coming on board with
> significant Oracle hardware and licensing requirements, and I thought
> perhaps this might be an opportunity to pick a solution that would enable
> us to consolidate across the organization.
>
> I want to consolidate, not worry about licensed options anymore, make
> patching easier with less downtime (2 dba's, many hats), have room for
> growth over the next 5 years, and have the TCO be the same or better than
> the traditional HW/SW approach we have now. For the TCO I can't assign a
> dollar value to things like better up time, improved security, time saved
> through easier administration, all packs are included, etc. Finance folks
> will reject those numbers.
>
> We've explored a few different consolidation options:
>
> 1. vmware - licensing kills us
> 2. oracle vm - infrastructure team doesn't want to support.
> 3. ODAs - can't support different licensing combinations effectively
> 4. purchase exadata - seems to add more administrative work to our
> plates based on discussions with other entities
> 5. exadata cloud_at_customer - on premise cloud, maybe a good fit, hard
> to calculate TCO
>
>
> thanks!
>
> Anthony
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Sun Sep 02 2018 - 13:18:16 CEST

Original text of this message