Oracle Database Products – keeping all the eggs in one basket

The old adage goes “don’t have all your eggs in one basket” but when it comes to Oracle Databases in a virtualized environment this may actually be a good idea. By managing how you deploy your Oracle database and especially your database Options and Packs you can dramatically reduce your software license costs and avoid compliance risks.

Recap on core based licensing

The licenses (entitlement) to use Oracle database products for the most part use a core based metric to measure how much you should pay. For each physical server the number of cores on a processor multiplied by a weighting (called an Oracle Core Factor) all added up, give you the number of cores that need to be licensed. Because Oracle do not recognize most virtual server partitioning methods what this also means is that where you have a server virtualized, you must license all cores available on the hardware, not just the cores assigned to your virtual machine. Simple Example: Virtual Cluster host has 64 cores with a database running on a virtual machine with 2 cores assigned. You must get 64 cores of Oracle database licenses.

The Basket

The Oracle licensing rules around core counts basically mean that you should treat each virtual host or cluster as a “basket”. Whether you have one or a hundred instances of a particular database product (eggs in our metaphor) in the basket, you only pay once per produce for all cores available.

Which Eggs in which Basket?

It must be kept in mind that Oracle treats Database Options and Packs as separate products (duck verses chicken eggs), similarly for different editions, so if you add even one such product to the basket it will cost you the total number of cores. You might decide that for both management and cost reasons to have more than one basket. Examples of this scenario are:

  • Consolidate expensive Options into once virtual host
  • Server and database status, keeping production and pre -production systems separate.
  • Some systems are on a different license metric such as Named User Plus verses core. Common in development environments.
  • Different product families, database and middleware on separate virtual hosts.
  • Backup, Disaster Recovery or High Availability systems.

The Exceptions

If you are in an Oracle Unlimited License Agreement (ULA) you will temporarily ignore this advice as you try to over deploy on the products covered by your ULA. Also where you have business units with a different Oracle contracts in place it might not make sense either.

Conclusion

The costs or licensing Oracle’s database products is significant and in many cases outweigh the cost of additional infrastructure. Creating separate “baskets” and moving your product deployments around so that all the “eggs” of a similar kind are together, makes sense, generate significant savings, making it easier to manage and reduces the likelihood of a compliance gap.

Reference

Oracle Core factor Calculation Microsoft Introduction to Core Based Licensing Oracle Partitioning Methods

« | »

Piaras MacDonnell