This discussion is archived
3 Replies Latest reply: Nov 13, 2012 7:14 PM by andrewmy RSS

Consolidate and Decommission madness in our shop

Tom Newbie
Currently Being Moderated
This question is about whether Non-prod Databases should be licenced

Version: 11.2.0.3 on RHEL 5.4

My Shop (an international Insurance Firm) has started to implement the policy of having the least number of databases as possible to reduce licence costs. So, we have been asked to move all SIT, UAT and pre-Prod schemas currently in standalone DBs into two large RAC DBs.
Eventually we'll end up having no DB servers to do some R&D stuff as the the two Large Development RAC DBs are shared by lots of application projects.

I would like to know if Oracle charges licensing fee for SIT,UAT,Pre-Prod DBs ?
  • 1. Re: Consolidate and Decommission madness in our shop
    EdStevens Guru
    Currently Being Moderated
    Tom wrote:
    This question is about whether Non-prod Databases should be licenced

    Version: 11.2.0.3 on RHEL 5.4

    My Shop (an international Insurance Firm) has started to implement the policy of having the least number of databases as possible to reduce licence costs. So, we have been asked to move all SIT, UAT and pre-Prod schemas currently in standalone DBs into two large RAC DBs.
    Eventually we'll end up having no DB servers to do some R&D stuff as the the two Large Development RAC DBs are shared by lots of application projects.

    I would like to know if Oracle charges licensing fee for SIT,UAT,Pre-Prod DBs ?
    All licensing and cost questions should be directed to someone who has the legal authority to represent Oracle in such matters. If you make the wrong decision and Oracle audits you, I don't think you want your defense to be "some stranger on the web said it would be OK". This is a forum of peer volunteers. That Oracle logo in the upper left corner is only because Oracle provides this space for said volunteers. It in NO WAY implies that anything said here is legally binding on Oracle Corporation.

    But you can get a good idea by simply reading the general licensing terms available at oracle.com. Generally they license by cpu/core/socket, not by database instance. In general, putting a separate schema for Dev, UAT, Pre-Prod, Whatever into one database costs the same (in terms of licensing) as putting up seperate instances for each on the same server.

    But again, you really must contact your official Oracle representative.
  • 2. Re: Consolidate and Decommission madness in our shop
    JohnWatson Guru
    Currently Being Moderated
    You don't license databases, you license machines. You can create as many databases as you want, if the machine is licensed: no need to consolidate the databases into one, just relocate them.

    Of course, running test and dev databases on the same boxes as the production DBs may cause some issues, but as you are on 11.2.0.3 you can take advantage of the policy management mechanism, the Resource Manager, and (theoretically, it isn't really there yet) QoS to make sure that your production systems always get adequate resources.

    An interesting project! Good luck with it.
  • 3. Re: Consolidate and Decommission madness in our shop
    andrewmy Journeyer
    Currently Being Moderated
    We have done similar consolidation - we grouped all our development, UAT, and test database instances from 8 individually licensed servers into 2 larger servers with processor licenses.

    You would still need to talk to Oracle to check on the costs to see if there are actually any savings - running many instances on a very powerful server may actually cost more than running the same instances on many smaller servers due to need to upgrade the license. For example, if you had 5 small servers all running standard edition one, and they are going to be moved to a single much more powerful server, it may cost more in the new configuration because processor count on the new server means it now requires Enterprise edition license.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points