Jim Hannan (@jim_m_hannan), Principal Architect

With core counts rapidly increasing per socket (currently we are seeing chips with 20+ cores per socket), Oracle felt they needed to do something about their SE and SE1 licenses, which offered ever increasing capability to their customers at a significantly reduced cost compared to Enterprise editions. This is because the SE/SE1 licenses had been socket based with no restriction of core count. With the release of 12c (12.1.0.2), they certainly did something. Oracle took cues from Microsoft, and in addition to the 2-socket maximum, they added a software limitation of 16 threads per database instance. This seems a little overly restrictive to me, but again they felt they had to do something. However, let’s not discount the value of SE2. SE2 still is a valid alternative to Enterprise Edition and most companies would be surprised by how many of the their Oracle databases can run happily on SE2. Sure, 16 threads does not sound like much, but think about the power of todays chips and leveraging virtualization with 2 socket, 24 core per socket (48 cores) ESX hosts. You can run a lot of SE2, especially for workloads that do not need the Enterprise Edition features and do not demand more than 16 threads during peak processing.

Note: I alluded to this above, but it’s worth mentioning again – Oracle still has the 2-socket limitation but no core limitation in SE2. You can buy a 2-socket server with 20+ cores per socket. If this is a physical server, each of your database instances will be throttled at 16 threads. But you’re still free to run multiple instances and take advantage of all the cores. Better still, deploy the server as an ESX host and build as many virtual machines as you like with a cap of about 16 vCPUs each.

In 12c, Oracle introduced container databases. So while a multitenant and single tenant deep dive is out of scope for this blog, I still want to touch on Container Databases (CDB) enough to explain single tenant, which is key to SE2 upgradability.

Note: Oracle has said in publications that they plan to only offer single tenant and multitenant in future releases. As we are all aware, there is no need to panic, these things tend to roll out slowly, if at all.

Single Tenant – Container Database

Starting first with the CDB, it should feel very familiar to most Oracle DBAs with a few years of experience. It has a very similar structure to a pre-12c traditional Oracle database. As Tim Hall of oracle-base.com states the CDB has all “the working parts” of a traditional database. These allows for creation of portable PDB (pluggable databases). The PDB runs as a component of the CDB. The PDB structure only contains what is specific to the database, mostly containing datafiles and tempfiles. Again, taking cues from Microsoft, Oracle extended the idea of pluggable databases and allows for implementation of a portable database that has many advantages not covered in this blog. In the case of SE2 a streamlined upgradable path from SE2 to Enterprise Edition using PDB is available. Simply move the PDB from the SE2 DB to Enterprise Edition CDB and you have successfully upgraded from SE2 to EE. Also not to be overlooked, you can move SE2 to another CDB on another server or virtual machine as desired. You may choose to do this if a database is getting busier than expected – in the case of a virtual machine this could help from growing the resources (CPU and memory) beyond the current container size.

The single tenant has the advantage of allowing organization to quickly scale from 16 threads in SE2 to as many cores as needed in the EE licensing processor model (more on NUP later). Additionally, if you need a feature/option like Partitioning, Advance Security, Tuning Pack, or Advance Compression you have a streamlined process to get to Enterprise Edition.

Single Tenant is included as part of your SE2 license. It is difficult to support the notion that deploying all SE2 databases as PDBs should be a best practice for all organizations. Why? Multitenant CDB/PDB is a paid feature in 12c Enterprise Edition, listing at $17,500.00. Not a trivial expense. In table 1 we look at Oracle SE2 and Enterprise list costs.

Table 1 – Oracle List Pricing for SE2 & Multitenant EE [1]

On a few occasions I have noticed some hesitation from organizations to use Standard Edition because Diagnostic and Tuning are unavailable. AWR, the main component/tool of Diagnostic Pack, has a no charge alternative called STATSPACK. It has been available as far back as 9i. Essentially, STATSPACK and AWR reports are nearly identical and allow you to identify bottlenecks, configuration or code tuning opportunities. The primary difference is the availability of preconfigured roll-up / historical views in AWR. But, what I am saying is that you can get everything you need for tuning with STATSPACK. I have been involved with as many STASPACK tuning projects as AWR, although to be fair it is trending more towards AWR reports.

Wrapping up this blog, we should discuss NUP licensing. It has been raised from a minimum of 5 users to 10 users per server in SE2, but that is still an incredible value. That is a 10-user minimum per server not socket! For databases with a small amount of users, this becomes very attractive licensing option.

With the SE2 maximum of 16 threads, you should also plan on how you will gather schema statistics. Our blog on gathering statistics in Standard Edition will help you get started. We recommend looking for a low activity time of day and completing it as quickly as possible with the 16 threads.

[1] Reference: http://www.oracle.com/us/corporate/pricing/technology-price-list-070617.pdf