James Morle's BlogRSS Feed
System Architecture Series: Introduction to the Series and LicensingPosted on 7:45 am November 1, 2012 by James Morle
This blog post is an introduction to a few posts that can be grouped together under the banner of 'System Architecture'. Specifically, I'm referring here to Oracle Database System Architecture, not system architecture in general nor 'Oracle architecture' in general, which is an ever-growing beast.
In this series of posts, I will take at look the following important aspects of Oracle architecture:
- Storage technology
- Storage networking
- Network technology
- Processor technology
- High Availability
- Memory hierarchies
- Corporate realities
Or at least that's the plan. Now I'm looking at the list it seems more like a multi-volume book than a handful of blog posts. Let's see how we get on, with a deliberate overriding attempt to be concise and not get too entrenched in important-but-voluminous low level details. So let's get cracking on the first item: Licensing.
Licensing is the single most important factor in an Oracle database architecture, period. If you are not focused on the licensing realities that pertain to an Oracle database architecture, it is unlikely that you will make the right decisions elsewhere in the architecture. The reason for this is twofold: Oracle licenses will likely be the single most expensive capital and operational cost in the budget, and they scale inversely with the efficiency of the architecture. This is all assuming, of course, that you are licensed by processor license, which is certainly the case for most customers, even if they are not aware of it. Even so-called Unlimited License Agreements carry inherent risk that the customer is ultimately exposed to processor-based licensing.
So let's look at the pricing. I've assumed Enterprise Edition for this post, as this is the most common amongst our clients, and I have selected a common choice of additional database 'options'. The following data is taken from the publicly available "Oracle Technology Global Price List", which is available here. The prices quotes here were listed in the price list dated September 26, 2012.
- Database (Enterprise Edition): $47,500 per processor
- Real Application Clusters: $23,000 per processor
- Partitioning: $11,500 per processor
- Active Data Guard: $10,000 per processor
- Diagnostics Pack: $5,000 per processor
- Tuning Pack: $5,000 per processor
Remember that a 'processor' is defined as a CPU core with a core factor applied to it (more on this below).
To save you getting out the calculator: If your system requires all those product options, the total is $102,000 per processor. Let's now assume that you purchase a really modest server such as an HP DL380p Gen8 with a single Intel E5-26xx series processor and 16GB of memory. That's a small box by modern standards, but it has six cores, even in this minimal configuration. The core factor for Intel x86 processors is 0.5, meaning that this machine requires 3 (6 cores times 0.5 core factor) Processor Licenses: $306,000 in software licenses for a $4,000 server. But it's worse than that: You actually need a minimum of two of those servers for production because you have selected RAC as part of the architecture, and then probably another two for DR. That's $16,000 in hardware (excluding the storage) and a whopping $1,224,000 in software licenses.
Clearly, to put it mildly, the Oracle database is a 'premium' product. And this is why it is so vital that the license cost and, by implication, the processing efficiency of those licenses, must be one of the primary factors in assessing the options for a system architecture.
In the process of these blog posts, I will make constant reference back to the license efficiency of the various options, where it makes sense, because you really do need to think about these things. Just Sayin'.
OK, perhaps a couple more license considerations before I sign off for this instalment.
Here's a good one: Don't ever repurchase your Oracle licenses. OK, there are probably some exceptions, but in general there is only one beneficiary of a newer set of licensing terms, and that is a certain Oracle Corporation. Here's why:
- Each license purchased from Oracle comes with an applicable Oracle License and Services Agreement (OLSA) that applies to that license. Over time these have become more and more restrictive in nature, and more favourable for Oracle. For example, the number of 'Named User Equivalent' licenses that apply to a Processor License have changed considerably over time. When you repurchase a license, only the latest OLSA applies to that purchase.
- Ongoing support costs. Old licenses were probably purchased at lower cost than the new licenses, and Oracle's support fees are calculated as a percentage (22%) of the net license cost. So if the new license cost more than the old one, your annual support fees also increase.
The general rule of thumb is this: the older your current OLSA is, the more important it is that you think carefully before repurchasing Oracle licenses.
Here's another good one: Are 'perpetual' licenses the most sensible purchase? Unless your requirement for Oracle processing is at least doubling every three years, a perpetual license is almost certainly a waste of money. A mixture of Term Licenses and Perpetual Licenses may be a much more cost effective solution.
A 3 year Term license for the Enterprise Edition of the database is $23,750, which is 50% of the cost of a Perpetual License. This level of cost reduction applies to all the options too, so a 3 year term license for the whole set of licenses costs half as much as the perpetual license equivalent. If you are to assume, and it's a pretty safe bet, that you will need half or less processors in your hardware refresh in three years, this allows the opportunity* to retire haf the licenses at that point. In our example above, the license purchase cost would drop by $306,000 (half of the infrastructure could be licensed at 50% reduction using term licenses) if you think this might be possible. It's an unfortunate fact that Oracle still charge the same amount for term licenses as perpetual licenses when it comes to support (22% of a perpetual license rather than 22% of the term license price), otherwise even more savings could be made. But I guess that's fair enough from their standpoint.
The point I am trying to make here is this: None of these considerations are in any way 'dodgy', or trying to defraud Larry out of his next island in the Pacific Ocean. Or to put it in taxation terms, it is avoiding rather than evading. These considerations are genuine aspects that should be instrumental in any system architecture.
We will return to licensing regularly during subsequent posts in this series.
* I state 'opportunity' here because, even if the CPU speeds have effectively doubled in the forthcoming three year period, the chance of reducing the required processor licenses all hinges on whether you can use an architecture (such as the Oracle Database Appliance, or an approved virtualisation technology) to implement a system that uses a lower CPU core count than is actually shipped by the likes of Intel. Or to be more specific, Intel will almost certainly not be producing three-core versions of the future processors so you must have an approved way to only license a subset of the cores in the processor socket. Oracle seems to be more open to partial licensing than they used to be, so hopefully this trend will continue.