Re: oracle costs

Hello,

Jack Is a Oracle Cloud DB an option for you ? you can use your perpetual license there

For DEV/TEST environment could be suitable to avoid cost licensing just for this

On Tue, 1 Oct 2019 at 09:04, jh3dt68_at_yahoo.com <dmarc-noreply_at_freelists.org> wrote:

> Franck, I appreciate your insights. We use partitioning, therefore SE
> isn't an option. The software is on a perpetual license, not a term license
> but the software was all from one purchase order so I think we're stuck
> with Oracle recalculating the maintenance costs based on the remaining
> cores. We are only going to combine the DEV and TEST environments, going
> from 4 environments to 3. I like what you and Tim Gorman suggest but I'm
> not sure how long new hardware will take to get thru our procurement
> process. I'm also thinking that once we inform Oracle of the core count
> reduction, we will immediately trigger an audit.
>
> thanks,
>
> - Jack
>
> On Tuesday, October 1, 2019, 2:08:11 AM EDT, Franck Pachot <
> franck_at_pachot.net> wrote:
>
>
> Jack,
> Few ideas here.
> So, for the moment you have one contract with 48 EE processors or that is
> on multiple contracts because you bought them at a different time? That's
> important because you may be able to stop one contract and keep another.
> But if it is all in the same contract, then you have to re-buy the needed
> licenses if you want to reduce. And have a smaller discount then.
> The second point if you have to re-buy is whether you need EE or can go to
> SE where you count the sockets and you have one socket per server, right?
> That can be a huge cost saving. Of course you will not have the same
> protection as Data Guard. But there are solutions like Dbvisit standby
> which are ok if business is ok for a RPO of 10-15 minutes in case of
> failover.
> Oracle VM is a good solution to limit the licenses on servers with too
> many cores. For sure it is something new to learn and setup, but you should
> not see it as "another VM stack" if you use it only for CPU pinning. You
> will not do HA, vMotion... with it
> If you accept to stop test and dev in case of failover, then you may run
> on 2 servers only: PROD on one site and DR+DEV+TEST on the other.
> Franck.
>
>
> On Tue, Oct 1, 2019 at 1:19 AM jh3dt68_at_yahoo.com <
> dmarc-noreply_at_freelists.org> wrote:
>
> Hello all,
>
> Where I work we have Oracle EE running on 4 physical Dell servers, all
> running Oracle 12.2 and RHEL 7. The environments are PROD, DR, TEST and
> DEV. At present all of the servers have 4 sockets with 12 cores per socket,
> for a total of 96 CPU cores of Oracle EE . Unfortunately, due to budget
> cuts, management is asking us to reduce our annual Oracle maintenance
> costs, either that or we have to lay off a couple of developers, there are
> 15 people total in our shop. Our first thought was to combine DEV and TEST
> as both of those environments are not fully utilized. That would reduce our
> core count by 1/4. But digging into the contracts and the world of Oracle
> licensing (ugh), it looks like Oracle could re-calculate the maintenance
> costs based on the current list price of annual support, not on the
> discount price we received when buying Oracle 4 years ago. That means we
> wouldn't pay more but maintenance costs might not be any less. The other
> idea we had, was to convert the CPU licenses to Named User Plus licenses
> for DEV/TEST. There are only 15 people who ever use the DEV/TEST
> environments and we would leave PROD/DR alone for now. I understand there
> are processor minimums which must be accounted for, but if we combine the
> DEV/TEST and switched to NUPs I'm hoping it would result in some cost
> reduction, even if Oracle tries to claw back some of the savings.
>
> Any insights or suggestions are greatly appreciated,
>
> - Jack H.
>
>

--
http://www.freelists.org/webpage/oracle-l