A Standard Way of Thinking Part Two
July 20, 2012 2 Comments
by Paul Bullen, Senior License Consultant
In my last blog post, I introduced the basics regarding Oracle Database Standard Edition. To recap, Standard Edition/Standard Edition One is a very capable and high-performing database, which is limited by the socket capability of your server (maximum of 4 sockets for SE, 2 for SE1) and the inability to license and use some database options against your database: but all for a mere fraction of the price of Enterprise Edition. Note a key point here – it’s the capability of the server in terms of socket count that’s the restriction – not what’s actually deployed. If you have an 8 socket server that has only 2 sockets occupied, then SE/SE1 aren’t viable options.
But when it is viable, the potential savings are higher than I told you last time due to the way a Processor is defined for Standard Edition.
Expanding on the pricing model for Standard Edition, you are allowed to run any number of cores in those 4 sockets and you pay by the occupied socket, NOT by the core. Let’s look at the Dell R910 we mentioned last time. This has 4 sockets and so is fine for Standard Edition. Let’s not go daft here and just assume it actually has 2x Intel E7-2800 processors installed, with 10 cores per processor – and we are going to license it with the Processor metric (because we are very careful about using Named User Plus for licensing)
For Enterprise Edition, we need to do a quick calculation to work out the number of licensable ‘Oracle Processors’, i.e. take the core factor into account. So processors multiplied by cores per processor multiplied by appropriate core factor gives us:
2 x 10 x 0.5 = 10 Oracle Processors (for Enterprise Edition)
10 Oracle Processors (Enterprise Edition) at $47,500 each = $475,000 list license cost
Wow. Standard Edition is a bit easier – 2 occupied sockets give us 2 Oracle Processors;
2 Oracle Processors (Standard Edition) at $17,500 each = $35,000 list license cost
There’s no typo here. SE is 92% cheaper!! When you consider on-going support costs, this is significant.
Hopefully your interest is raised: why would you not go for Standard Edition? The main reason we hear is because some database options cannot be used in Standard Edition. Let’s clear one thing up straight away. RAC (Real Application Clusters) can be used with Standard Edition (not Standard Edition One), and best of all, in this case RAC will be free. Yes: you pay nothing to use RAC with Standard Edition! You have to split the 4-socket limit across the RAC cluster, so typically you’ll be looking at two servers each with two sockets, though you could have a 4 by 1-socket node cluster.
The database options ‘missing’ which seem to cause most pain or an issue to adopting Standard Edition are Diagnostics, Tuning packs and Data Guard. Each DBA and organisation has its own standards for supporting and managing database so it is hard to undermine or question them here however, given the cost savings, a review of any such standards is worthwhile.
It is also worth bearing in mind that for the three options mentioned, there are very good third party tool vendor solutions which offer very similar (and sometimes more mature) capabilities and are specifically built and marketed to function with Standard Edition.
Hopefully these posts are giving you a flavour of the potential that Standard Edition Database could have for your organisation: with everyone currently looking to reduce costs and demonstrate savings, Standard Edition (and our expertise!) may be your saviour. Next time we’ll look at some other ‘quirks’ of Standard Edition. I’m not going to have space here to go over every aspect of Standard Edition, so please let me know if you have any questions in the meantime especially if you are thinking of making the strategy change to Standard Edition.