by Joe Grant (@dba_jedi), Principal Architect

In a recent blog post, I focused on initial Oracle deployments and the variety of decisions that come with implementing Oracle for the first time. For this article, I plan to offer a deeper dive on one of those decisions and offer details on the differences between Oracle Standard Edition 2 (SE2) and Enterprise Edition (EE). My intent is not to convince you one way or the other, but rather to help you make your own informed decision.

Note: There were two previous editions of Oracle Standard Edition – Standard Edition (SE) and Standard Edition 1 (SE1).

Licensing Costs

While not the only factor in making a decision, the costs involved play a significant part in the final decision. If the use of Oracle Standard Edition 2 (SE2) is suitable for the project/application, using it can save quite a bit of money. Licenses for Oracle software are processor based, and there are a few important differences between SE2 and Oracle Enterprise Edition (EE) that should be noted.

With EE, the software is licensed on what is referred to as a processor basis. A processor does not equal a socket, but rather all cores on the processor are counted and then a core factor applied. For x86_64 the core factor is 0.5. As an example, a single processor with 22 cores would count as 11 processors for licensing purposes (1 socket x 22 cores per socket x 0.5 core factor = 11).

The software is also licensed on a processor basis for SE2,. In this case however, the number of cores is irrelevant. A single socket with four cores costs the same as a single socket with 22 cores.

Now for the numbers, at list price one processor license of EE is $47.500 and one processor license of SE2 is $17,500. Be aware however, that purchasing Oracle software is a lot like buying a new car, no one ever pays list price. Discounts are customary, but are also dependent on a long list of factors (that no one will give us the formula for, if one even exists). Some quick math:

• EE: Two-socket server with 22 cores per socket and a 0.5 core factor = 22 processor licenses required. 22 processor licenses x $47.500 = $1,045,000
• SE2: Two-socket server with 22 cores per socket = 2 processor licenses required. 2 processor licenses x $17,500 = $35,000

There is a second licensing metric called Named User Plus (NUP) that can be used. With this method, the processor-based licensing (noted above) is still calculated, then per processor minimums are applied. Typically for EE, this is 25 NUP licenses per processor, for SE2 it is 10 NUP licenses per server. The number of users also need to be counted. Per processor/per server minimums or actual users will need to be purchased, depending on which is greater.

The cost for EE is $950 per user, and for SE2 it is $350. Using the same two socket server as noted above, the per processor minimums would be:

• EE: 22 processor licenses x 25 NUP per processor x $950 = $522,500
• SE2: 1 server x 10 NUP per processor x $350 = $3,500

The breakeven point for EE is 50 users per processor. Whereas, the breakeven point for SE2, assuming a 2-socket server, is 100 users per server. For organizations running at, or even near, these user counts using the processor metric may be preferred.

In a virtualized environment, using SE2 can be of great benefit. Once the physical server is licensed, one can then place as many VMs on the server as the server is capable of running. While the same goes for EE, the costs of licensing the server itself are considerably higher.

Once final cost consideration is Oracle support, the gift that just keeps on giving charging. Support costs are based on the purchase price of the software itself. Just like with taxes, the more you spend on the purchase, the more you spend annually on support. Additionally, Oracle adds 3-5% annually to support renewal costs.

SE2 Restrictions

As with all SE products, there are a handful of restrictions that keep people from easily using SE2. Some of these restrictions, listed below, have changed with the introduction of SE2, as they were different for previous editions SE and SE1.

• Only licensable on servers with up to two sockets
  • SE was four sockets, SE1 was two sockets
• Restricted to 16 threads per database
  • The database engine automatically enforces this
  • Previous editions did not have this restriction
• Does not allow for the licensing of any options or management packs
  • Options – extra cost features such as Partitioning, Compression, etc.
  • Management packs – extra cost features used for database management such as Diagnostics Pack

These restrictions may seem extensive and very limiting, but in practice they are not so bad. A two-socket server can be very powerful, and in virtualized environments is capable of running quite a few VMs.

RAC Bundle

Warning, this is a bit of a tangent. This one gets a little complicated, so if you are in an environment that uses Oracle 19c or newer only, skip to the next section.

In the previous edition of SE, and in earlier versions of SE2 (version 18c or older) Oracle allowed customers to use Real Application Clusters (RAC) for free. This was a significant benefit, but Oracle kept messing with it. If you are running Oracle SE2 19c or newer, this benefit has been removed. For SE2 versions 12.1.0.2+, 12.2.0.1, and 18c (12.2.0.2) the customer can use the RAC bundle with the following restrictions.

• The two-socket restriction applies to the cluster and not the server
  • Two single socket servers must be used
• The 16-thread limitation applies to the cluster and not individual hosts

When using the previous editions of SE, and versions 12.1.0.1 or older, these restrictions were not imposed. Additionally, the cluster was permitted to have up to four sockets. This allowed clusters with two, three, and four nodes.

Functionality

In addition to the restrictions noted above, there are some minor functional differences between the editions. These differences are noted in the Oracle documentation in the Database Licensing Information User Manual. Reading through this list can be a bit daunting, so I will attempt to sum it up.

• The first thing of note is that SE2 and EE share a code base, and the database functions as one would expect.
• A significant number of the differences described in the manual stem from the fact that you cannot license extra cost options and packs for SE2. In the manual, Oracle lists a function and marks it as a ‘no’ for SE2 and ‘yes’ for EE, then makes the caveat that it is an extra cost feature. Odds are that the extra cost feature(s) are not going to be licensed anyway.
• Certain activities are not eligible for online maintenance, which includes rebuilding a table/index, moving a table, and other maintenance related Weigh your prospective need to perform these tasks while the database is running against the cost of EE. In practice, these restrictions are usually not that difficult to work around.
• In SE2, the parallel engine in not available. As such, there are several activities that cannot use a degree of parallelism greater than 1. This includes parallel queries, RMAN backups, and/or Data Pump exports. There are a handful of other activities that also use parallelism. Again, in practice this is usually not an issue, and there are several strategies for dealing with it.

Again, this is a summary of the major points and is not intended to be a complete list. So, review the available documentation, weigh the actual need for the feature, and then decide if the feature is needed or if there is another available solution. Just like when shopping for a new car, a feature like heated seats may seem really important at the time so you spend extra for it. Then a short time later, you end up moving to Houston, and no one in Houston ever needed heated seats. So, you wind up paying for a feature that at one time seemed really important, but ultimately was never used.

Summary

As one could guess, Oracle would much rather you purchase EE, which is why they have lots of selling points to inspire you to go in that direction. Over the years however, I have installed many Standard Edition (SE, SE1, SE2) databases that worked well, and helped to keep costs down for clients.