Understanding the AF/Oracle ESLA

“Failure is not an option – it comes bundled with the software.” – Anonymous

A proper understanding of Oracle product licensing is essential to planning and controlling costs associated with system development and deployment. This is especially true when working for the DOD, where STIGs require all software to be fully licensed and supported. Taking into account that the cost and number of licenses you need may vary depending on the operating system you choose to use, the number of physical CPU sockets in your hardware, the number of users your system will support, or whether or not your servers are virtualized, and it doesn’t take much to get completely lost. If you don’t plan and implement carefully, an audit of database usage by Oracle (yes, they do that!) could wind up costing you hundreds of thousands of dollars or more in additional fees.

One of the most problematic and confusing aspects of installing and using Oracle database (and especially the Enterprise Edition) is that by default all of the extra bells and whistles are installed along with the core functionality. Assuming for now that you have done your homework and accurately planned out which version of Oracle and which options you will need, how can you be sure that you are correctly configured and that there won’t be feature creep in your application as developers “discover” things that you thought were locked down or disabled? Right out of the gate it is important to know how to avoid installing any more than necessary, and to know how to detect and disable the features you don’t need or don’t have the right to use. Sounds simple, right?

The Air Force Oracle Enterprise Software License Agreement (ESLA) tells us what U.S. Air Force organizations are allowed to use right out of the gate, and make no mistake: it includes a lot of bells and whistles, but it doesn’t include everything and it doesn’t cover everyone. A lot of new features are included, such as the Partitioning Option, Real Application Clusters, and the Tuning and Diagnostics Packs. Some very specific use cases are excluded too, such as intelligence gathering or combat operations.

The current ESLA went into effect on 28 February, 2017, and is scheduled to run for five years. During this time, the Air Force is paying a flat rate for the unlimited usage of a long list of Oracle products, provided that each instance of their usage – including Development, Test, Production, and Disaster Recovery (COOP) – is registered with Mythics, Inc., who manages the license program for Oracle. The full list of software and options included in the current ESLA is shown below. Many other products are available at a substantial discount from Oracle.

  • Oracle Database and Database Options
    • Oracle Database Enterprise Edition
    • Oracle Advanced Security Option
    • Oracle Partitioning Option
    • Oracle Real Application Clusters
    • Oracle Database Vault
    • Oracle Diagnostics Pack
    • Oracle Tuning Pack
    • Oracle Database Lifecycle Management Pack
    • Oracle Data Masking and Subsetting Pack
  • Oracle Fusion Middleware Products
    • Oracle WebLogic Suite
    • Oracle WebLogic Server Management Pack Enterprise Edition
  • Oracle Identity Management and Security Products
    • Oracle Key Vault – Server
    • Oracle Enterprise Identity Services Suite
    • Oracle Audit Vault and Database Firewall
  • Oracle Business Intelligence Products
    • Oracle Business Intelligence Publisher

What Isn’t In the Brochure

One of the most critical pieces of information – in my opinion – regarding licensing of Oracle products isn’t even in the brochure. In a normal, commercial Oracle deployment, dealing with servers virtualized on WMware or HyperV can be very costly. Oracle typically requires you to license not just the number of virtual CPU cores assigned to your virtualized server, but to license the actual number of physical CPU cores available to the entire virtualization infrastructure. In other words, you would need to license the number of physical CPU cores that your virtual server could run on, not just the ones it is using at any given time.

Under the terms of the Air Force / Oracle ESLA however, the rules have been changed. Under the ESLA, you need only register the number of virtual CPU cores that your server requires. This is a huge cost savings and makes virtualization of database resources much more practical.

Another critical piece of information, concerning licensing Oracle in the Cloud, is also not in the brochure. Any ESLA licenses you obtain may be deployed in the Cloud so long as Oracle supports them in the particular architecture you plan to use. The terms of the ESLA limit the overall number of Oracle licenses that can be used in this way, however. No more than 50% of ESLA licenses Air Force-wide may be deployed in a cloud – either commercial, milCloud, or on-premise “cloud-in-a-box” infrastructure. As the ESLA license managers, Mythics must approve before you can register any licenses for cloud use.

Working with the Mythics License Orchestrator

Under the ESLA, all Oracle licenses used on AFNET are requested and managed through the Mythics License Orchestrator for the US Air Force. This portal was developed by Mythics using Oracle APEX, and is located at https://usaf.mythics.com.

By default, licenses in the Orchestrator can only be viewed and managed by a single user. In the case of most organizations this is not sufficient, if for no other reason than the need to maintain access to your license data during personnel transitions. On request, Mythics is capable of enabling your organization’s licenses to be viewed and managed by multiple users.

Once your account has been created and you log on, you will be presented with a welcome page that includes a high level description of the ESLA and contact information for ELSA administrators both at Mythics and within the Air Force. A detailed description of the License Orchestrator’s functions, how to navigate them and get started can be found under the “USAF Oracle ESLA Portal Overview” item of the navigation menu, or here.

Dealing with Unlicensed Features

It is important not only to register what you are using for licensing purposes, but to understand what you have not licensed, too. The Oracle Database 12c STIG states explicitly in Finding ID V-681681 that, “Applications must adhere to the principles of least functionality by providing only essential capabilities. Unused, unnecessary DBMS components increase the attack vector for the DBMS by introducing additional targets for attack. By minimizing the services and applications installed on the system, the number of potential vulnerabilities is reduced. Components of the system that are unused and cannot be uninstalled must be disabled.” This especially includes any and all features that are unlicensed, which should therefore be “unused” by definition.

Prior to Oracle 12c it was possible to select which extra options were enabled during the software installation process. Undesired options could be disabled right from the start. Beginning with 12c all binary options are enabled by default, and you must disable them manually after the installation is complete but before any instances are created. As such, it is important when installing Oracle to initially perform a software only installation. Once the Oracle software has been installed and patched appropriately for your environment, use the “chopt” utility on Windows or Linux to remove the extra enterprise features for which you are not licensed from the Oracle kernel. For most people this will likely mean disabling all of them. usage:

chopt <enable|disable>

          dm = Oracle Data Mining RDBMS Files
        olap = Oracle OLAP
partitioning = Oracle Partitioning
         rat = Oracle Real Application Testing

e.g. chopt disable rat usage:

chopt <enable|disable>

          dm = Oracle Data Mining RDBMS Files
          dv = Oracle Database Vault option
        lbac = Oracle Label Security
        olap = Oracle OLAP
partitioning = Oracle Partitioning
         rat = Oracle Real Application Testing

Also note that beginning with 12c some binary options can no longer be disabled in this manner. Oracle Label Security Option and Database Vault Option cannot be removed from the kernel.

Once all the required kernel options have been disabled, you can create your database instance using the Database Configuration Assistant  (DBCA). When your database instance has been created, check all initialization parameters related to feature usage to ensure they are set correctly as well.

    New to Oracle 12c, this setting will disable the In-Memory Column Store feature, which is separately licensed and enabled by default, and prevent accidental activation and usage reporting which is described by Kevin Closson in this post.
    In both 11g and 12c this setting will disable the Performance and Tuning Packs for DB Console and Oracle Enterprise Manager, which are also separately licensed and enabled by default. Note that these packs are included in the ESLA and need not be disabled for a registered database installation, but you must register them separately, in addition to the database software.

Check the DBA_FEATURE_USAGE_STATISTICS view with the follow query on a regular basis to monitor feature usage and make sure nothing unexpected is or becomes active.

select u1.name, u1.detected_usages
from dba_feature_usage_statistics u1
where u1.version =
  (select max(u2.version) from dba_feature_usage_statistics u2
   where u2.name = u1.name)
order by u1.name;

Proper enabling or disabling of database features is important on two levels. From a financial perspective it is important not to accidentally use database features for which you have not purchased a license. Oracle makes it very easy to make use of things that we should not, and eventually they will send a bill. From a security perspective it is important to disable all of the features that you are not using because it reduces the number of potential attack vectors that an intruder might use against you. If, for example, a vulnerability is found to exist in the OLAP Option that allows escalation of privileges, unlinking that feature from the Oracle kernel will neutralize the weakness. For these reasons it is critical for every database administrator to be precise in how they install and configure every database.

One thought on “Understanding the AF/Oracle ESLA

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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

This site uses Akismet to reduce spam. Learn how your comment data is processed.