Oracle Database Options and Packs Licensing

Oracle Database Options and Management Packs are add-on products that extend the functionality of the Oracle Database. These include features like Partitioning, Advanced Security, Diagnostics Pack, Tuning Pack, Oracle Real Application Testing, Multitenant, and many others. It is crucial to know that these options are not included in your base database license – they must be licensed separately if used. This article explains how options/packs are licensed (spoiler: they must match your database’s licensing compliance pitfalls, especially accidental usage of options), and best practices to avoid audit issues related to these add-ons.

What Are Database Options and Packs?

Database Options are extra-cost features that provide specialized capabilities on top of Oracle Database Enterprise Edition. Examples of paid options include:

• Oracle Partitioning – Enables table partitioning for better compliance.
• Oracle Advanced Security – Provides Transparent Data Encryption and Data Redaction.
• Oracle Database In-Memory – In-memory column store for acceleration of analytics.
• Oracle Real Application Clusters (RAC​ database to run across multiple servers (we’ll discuss RAC in detail in the next section).
• Oracle Multitenant – Pluggable database architecture (as of Oracle 19c, Multitenant is required for more than one user-defined pluggable DB and is a paid option for EE).

Management Packs (which Oracle sometimes calls packs or features) are add-ons for database management/monitoring:

• Diagnostics Pack – Enables in-depth performance monitoring (such as AWR reports, ASH, etc.).
• Tuning Pack—Automates SQL tuning and indexing recommendations (requires Diagnostics Pack as a cycle Management Pack, Data Masking Pack, etc.), as well as various other administrative add-ons.

These options and packs significantly enhance Oracle’s functionality but come at an additional cost. They are only available with the Enterprise Edition (EE) of Oracle Database (Standard Edition cannot utilize them). Each option or pack has its license that you must purchase in addition to your EE database licenses.

Licensing Metrics Must Match the Database

A fundamental rule: Oracle requires that any options or packs be licensed using the same metric and quantity as the associated database. In other words, if your database is licensed per processor, the option must be licensed per processor for the same number of processors. If Named User Plus licenses your database, the option must be licensed by Named User Plus with compliance. The licensing must mirror the base database:

• Processor Example: Suppose you have Oracle Database EE licensed on a server with 24 cores = 12 Processor licenses (after core factor). If you enable the Partitioning option on that database, you must also purchase 12 Processor licenses of Oracle Partitioning. Every core that the database runs on must be licensed for the option. Even if you only partition one table, the option license must cover the whole server because the option is enabled at the database instance level.
• Named User Plus Example: You have an EE database licensed for 200 Named Users. If you decide to use Advanced Security (TDE encryption) on that database, you must also license 200 Named Users for Oracle Advanced Security. You cannot license just a subset of users for the option – it has to match or exceed the database’s user count. Even if only 50 users use the encrypted data, Oracle’s rule is that all 200 database users are counted since the feature is available at the database level.

In practice, most Oracle EE customers use processor licensing for servers that host multiple applications or unknown user counts, and NUP licensing is only for smaller controlled environments. Either way, the option licenses should be acquired with the database. During audits, Oracle will check that equivalent option licenses cover any usage of an option. If not, it’s flagged as a compliance gap.

Accidental Usage – A Common Audit Pitfall

One of the biggest risks with Oracle options/packs is inadvertent or unauthorized usage. Many of these features can be turned on with a simple command or may even be enabled by default in certain tools, leading to “accidental” usage that still requires licensing. Oracle’s audit team (LMS) has scripts that detect option usage; even brief or trial usage can put you out of compliance. Some scenarios to watch for:

• Features Enabled by Default: Certain packs, like Diagnostics and Tuning, are automatically enabled if you use Oracle Enterprise Manager (OEM) or run particular PL/SQL packages. For example, running an AWR report or ADDM analysis will utilize the Diagnostics Pack; using the SQL Tuning Advisor invokes the Tuning Pack. If DBAs execute these without licenses, it’s a violation. It’s easy to do inadvertently because the database doesn’t prevent it – it just logs the usage.
• Trial Activations: A DBA might turn on Advanced Compression or Partitioning on a table to test performance, or enable Oracle Database Vault for evaluation, then forget to turn it to Oracle policy, the moment an option is enabled and used, a license is required – even if only for a short test – are using a separate evaluation license in a sandbox (and not production data), this can lead to compliance issues.
• Partitioning by developers sometimes creates partitioned tables if they have the privileges, but they do not realize that partitioning is a licensed option. The database will happily create the partitioned table; Oracle will later detect it in the audit view and expect a Partitioning option license.
• Multitenant “Single-PDB” Misunderstanding: In Oracle 12c, having one user-created pluggable database (PDB) was allowed without the Multitenant license, but as of any use of more than one PDB requires the Multitenant option. If an admin creates multiple PDBs for convenience, they might unknowingly trigger the need for Multitenant licenses. This is a common gotcha for those upgrading to 19c and beyond.
• Diagnostics/Tuning Pack on SE2: Standard Edition databases cannot license most packs, but the Oracle Enterprise Manager agent might still collect some stats. Ensure Oracle’s parameter controlling pack usage (CONTROL_MANAGEMENT_PACK_ACCESS) is set to NONE on SE2 to avoid inadvertently using pack features that are not on SE2.

How Oracle Detects Usage: Oracle provides the view DBA_FEATURE_USAGE_STATISTICS (and related views) that log usage of options and management packs. The LMS audit scripts query these to find even option or pack was used (e.g., it might show “Partitioning – Used 5 times” or “Tuning Pack – Last used on 2025-03-01”). If such usage is found and you don’t have a corresponding license, Oracle will assume you are **using the option without a license, which can lead to a hefty bill. Many customers are surprised in audits by features they didn’t know were enabled.

Compliance Tips for​ What You Don’t Use: Oracle allows you to explicitly turn off certain options to prevent accidental use. For instance, you can set initialization parameters like _disable_partitioning or use Oracle’s chopt utility to remove option binaries. For management packs, use the CONTROL_MANAGEMENT_PACK_ACCESS parameter (e.g., set it to NONE or DIAGNOSTIC+TUNING as appropriate) to restrict usage. Turning off unlicensed options reduces the risk of someone accidentally invoking them. Monitor Feature Usage Regularly: Run queries against DBA_FEATURE_USAGE_STATISTICS in all your databases and review which options/packs are used. If you find an option was toggled on, investigate and remediate. You might be able to negotiate with Oracle if it were truly a one-time accidental use, but it’s safer to ensure it never gets logged in the first place.

• Educate DBAs and Developers: Ensure your technical teams know that enabling certain features has license implications. Executing an EXPLAIN PLAN in SQL Developer can invoke the Tuning Pack if SQL Developer’s auto-tuning features are on. DBAs should only use pack features when they know those packs restrict those with privileges from using certain packages or OEM features. Training and clear internal policies can prevent costly “oops” moments.
• Match Metrics: As mentioned, always purchase options with the same metrics and counts as your database. Keep documentation of your licenses showing, for example, “Oracle Database EE—4 processors” and “Oracle Partitioning—4 processors.” In an audit, you’ll need to demonstrate that any option in use has an equal number of licenses. If you up your core count for a database, remember to also true-up the options.
• Beware of Pack Usage on Clients: Sometimes tools like Oracle Client, Oracle SQL Developer, or third-party monitoring tools can trigger pack usage on the server. For example, Oracle SQL Developer has a feature to generate and explain plans with tuning advice – a sufficiently privileged user could record a tuning pack usage on the database. Ensure that either those features are disabled on client tools or that such client access is done with accounts that cannot use the pack-related APIs.
• Consider License Packs/Bundles: Oracle offers some bundled offerings (like Database Enterprise Edition High Performance or Extreme Performance editions) that include certain options (e.g., many commonly used options in one price). If you need many options, sometimes these bundles or an Unlimited License Agreement (ULA) might be more cost-effective. Always analyze the break-even point – e.g., if you plan to use Partitioning, Advanced Security, and Diagnostics across many cores, a bundle could save money versus buying each option separately.
• Audit Before Oracle Does: Perform your internal license review, especially before any Oracle LMS audit is anticipated. Look at not just feature usage views but also Oracle’s LMS scripts (if you can obtain them via Oracle’s support or partners) to see what they would flag. You should find an accidental Partitioning usage now and address it (either by turning it off and documenting it was an error, or by purchasing the license if you truly need it) rather than have Oracle discover it.

By tightly controlling and monitoring database options and packs, you can enjoy their powerful capabilities without falling into the trap of unlicensed usage. Awareness and proactive management of these add-on features can avoid many compliance issues (and surprise bills).

Recommended Inventory: Your Options: Maintain a list of which Oracle options and packs your organization has licensed, and for which databases. Cross-check this against feature usage in those databases. This lets you quickly spot if an unlicensed feature shows up. For example, you can take immediate action if you haven’t purchased Oracle Advanced Compression but view that someone has enabled it.

• Use Server Settings to Enforce Compliance: Wherever possible, configure your databases to prevent use of unlicensed options. For instance, set CONTROL_MANAGEMENT_PACK_ACCESS = NONE if you have no Diagnostic/Tuning Pack licenses, so those pack features cannot be invoked. Oracle provides scripts (chopt on Linux/Unix) to remove option libraries (like Partitioning, RAC, etc.) from the Oracle binary – use these for databases with those options.
• Train and Communicate: Ensure that all DBAs and developers with elevated access understand exactly which options are licensed in each environment. They should know that turning on an option or using certain OEM screens can trigger license requirements. Establish an internal approval process before any new feature or patch is enabled in an Oracle database.
• Regularly Review Oracle’s Price List and Policies: Oracle occasionally introduces new options or changes terms (for example, how Multitenant became required for multiple PDBs). Stay up to Oracle’s official price list and licensing documentation. If a new database feature is released, assume it’s a paid option unless explicitly stated as free. Oracle’s Licensing Information User Manual for each DB version often lists which features require separate corporate those details into your compliance checklists.
• Conduct Internal Audits (Feature Usage Reports): At least annually (if not quarterly), run feature usage reports on all production (and test) databases. Flag any “Used” features that shouldn’t be. If found, determine the cause, remove the usage, or acquire the license. Document these findings – if Oracle ever questions past usage, having a record that you detected and turned off an option on a certain date (with no further usage after) may help to show good faith compliance efforts during audit discussions.
• Engage Oracle or Experts When Unsure: If unsure whether a certain configuration triggers a license requirement, ask Oracle (through your account manager) or consult third-party Oracle licenses. For example, “Does using Oracle’s Data Pump compression require an Advanced Compression license?” – (answer: basic compression for export is free, but the “Compress for OLTP” feature for data beyond Data Pump requires Advanced Compression). It’s better to get clarity ahead of time than to assume and be wrong. Oracle’s published FAQs and documents (and experienced licensing consultants) can clarify these nuances.

In summary, treat Oracle options and packs with as much diligence as the database. Only enable what you’ve licensed, and license everything you enable. Accidental usage is one of Oracle’s favorite audit findings – but with care, you can avoid those traps and fully leverage Oracle’s advanced features legitimately.