Consolidation and Oracle licensing

By Paul Bullen, Senior License Consultant

When talking to customers we often hear about plans for consolidation – it still holds appeal as a way of reducing costs and it’s easy to see why: fewer physical servers to manage, less power requirements, less cooling, less data centre space, more efficient servers with faster processors : to name a few of the potential savings. The broader aims are understandable: reduce the proliferation of an expensive resource to the fewest possible in order to reduce costs. What about Oracle licensing: how is this affected by infrastructure consolidation (we’ll discuss consolidation of licenses/support renewals at another time!)? In the majority of organisations, servers running Oracle database are an ideal target for consolidation: other Oracle products are less commonly ‘sprawled’ but the principles below are the same.

First, we must remember what metrics Oracle licensing is based on. Broadly speaking, technology products -Oracle database and options- are based on (physical) processors or Named Users. Consolidation is clearly going to have some impact on processors: as part of any well planned exercise, an overall view of the total number of processors before and after consolidation will be available. However, for Oracle licensing it is important to categorise these processors by their make and model in order that you can understand the ‘core factored’ processor count. This can be especially relevant if you have moved from single core processors—newer processors will be much faster, have multiple cores and may still be covered by the same amount of license.

If you are licensing by Named Users, it is important to remember that this metric is based on processors if your license allocations are set at the ‘minimums’. Of course if your Named User allocation for a server is more than the minimums this may not be as big an issue. However, the important point to remember for both is that consolidation can increase the Oracle processor counts, and so it is important to ensure the minimums are still met after consolidation.

A big factor, often overlooked (not just for consolidation) and regardless of metrics, is how the target system will be licensed whilst it is built: aka ‘parallel running’. It is imperative that whilst the target system is built, the appropriate license is in place. Unless you have some very special terms and conditions, you will have to buy licenses for all environments and all installations of Oracle no matter how transient.

Other factors to be careful of is whether the target systems will be in a virtualised environment which could be very expensive: a classic example of consolidation is a VMware cluster, a popular choice for consolidation but has massive implications – this should ring alarm bells for anyone interested in Oracle licensing!

Let’s work through an example. Suppose our old clunky legacy kit includes 5 servers, each with 4 single-core SPARC-III Oracle processors. We’ve been good and licensed these with 20 Oracle processor licenses. Our new environment will be 2 new shiny servers, each with 2 x Intel 6500 processors: these pack 8 cores per processor with a core factor of 0.5. Our new requirement will be 16 processors: we ‘free up’ 4 Oracle processors-worth of license (approx £120k list license value!). However, how do we license the new servers whilst they are built ahead? We may have some surplus license lying around (assuming we manage our license estate and know such things), perhaps we could scale down the source system and release some license, whilst running target with reduced processing power or we may have to buy another license to cover the build ahead. Regardless, we need to ensure we are compliant before, during and after the exercise.

So, to re-iterate: ensure ‘source’ and ‘target’ processor details (and any impact as a result of a move into virtualisation) are captured and calculations are performed for Oracle licensing. Also, do not forget to ensure that you license your target environment whilst it is built. These points may seem trivial but modelling the effects on Oracle licensing can be very complicated – best to call in the experts if you need any assistance.


2 Responses to Consolidation and Oracle licensing

  1. Tom Morris says:

    Good/clean information Paul and I know you were steeped in these conversations when we worked together,

    The recently announced SPARC Supercluster was anticipated and looks v.interesting. As I haven’t worked through the figures yet, what’s your view on the license effectiveness of the SPARC Supercluster versus it’s opposite x86 incarnation (widely referred to as Exadata)?

  2. Paul Bullen says:

    Hi Tom. From what I’ve seen of the T4 benchmarks it’s hard to see through all the marketing to get real results of using T4 for real-world database workloads. We’ll try and do some more in-depth analysis on this but gut feel is that the Exadata Intel processors are modern enough to still pack a punch and give T4 a run for its money. Given both have a core factor of 0.5 and that the Supercluster is (license-wise) effectively a large server, the license cost depends on the stack you choose to run on it: to all intents and purposes it boils down to performance of the processors. Obviously if you are using encryption this could possibly swing quickly towards Sparc having the license advantage.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: