Updated: May 13, 2020
- Oracle Databases include extra options that are not covered by the basic license
- Some of these options are enabled by default when creating new databases
- Organizations that enable extra options without licensing are out of compliance
Oracle provides a number of database options and management packs for the Oracle Database, which are licensable extra cost options. Unfortunately, many of our clients are surprised to learn that they are unknowingly using unlicensed database options and management packs and are therefore out of compliance. The reason for the confusion is due to the fact that depending on the version, database options and management packs are installed and many are enabled automatically.
As a post-implementation step, an organization should evaluate which database options and management packs meet the needs of the organization and determine if additional licensing is required. Any database options and management packs that are not licensed should be disabled prior to creating and using Oracle databases to prevent accidental use. Organizations should check usage on a regular basis to highlight compliance issues early and limit financial risks.
For database options, prior to 11gR2, Oracle provided an option to select or deselect database options during the installation process of the Oracle Database. As of 11gR2, this option is not available and all of the components that are licensed under the specific database edition are installed and many are enabled automatically.
Oracle provides a command-line utility called CHOPT to enable or disable Oracle options depending on the version. The ‘Y’ in the following table indicates that the option can be enabled or disabled using the CHOPT utility.
|Data Mining RDBMS Files||dm||Y||Y||N||N||N|
|On-Line Analytical Processing||olap||Y||Y||Y||Y||Y|
|Real Application Testing||rat||Y||Y||Y||Y||Y|
|Database Extensions for .NET 1.x||ode_net||Y||N||N||N||N|
|Database Extensions for .NET 2.0||ode_net_2||Y||N||N||N||N|
CHOPT will not remove database schemas and objects. This utility provides the benefit of easily enabling in the event that an option is licensed for use at a later stage. CHOPT is located in $ORACLE_HOME/bin directory. Prior to running CHOPT, verify if a database option is enabled or disabled by querying the V$OPTION view. The Oracle database should be shutdown prior to running the CHOPT utility. The syntax to enable or disable an option is as follows:
chopt [ enable | disable] db_option
After running the CHOPT utility, startup the Oracle database and verify that the option has been changed by querying the V$OPTION view.
For management packs, Oracle Enterprise Manager (Grid Control or Cloud Control) can be used to enable or disable management packs through the Management Pack Access page.
These management packs include:
- Diagnostics Pack
- Tuning Pack
- Data Masking and Subsetting Pack
- Cloud Management Pack
- Database Lifecycle Management Pack
- Change Management Pack
- Configuration Management Pack
- Patch Automation Pack
The Diagnostic and Tuning Pack functionality can be accessed through Enterprise Manager and database server APIs and command-line interfaces. As of 11g, Oracle provides a dynamic initialization parameter called control_management_pack_access to control access to the Diagnostic and Tuning Pack with one of the following values:
- NONE – Diagnostic and Tuning Packs are disabled.
- DIAGNOSTIC – Diagnostic Pack is enabled.
- DIAGNOSTIC + TUNING – Diagnostic and Tuning Pack are enabled. This is the default parameter.
Prior to changing, verify which initialization parameter value is in use by typing the following at the SQL prompt:
SQL> show parameter control_management_pack_access;
If unlicensed, the control_management_pack_access should be disabled by changing the initialization parameter value to NONE. The control_management_pack_access initialization parameter can be changed by typing the following at the SQL prompt:
SQL> ALTER SYSTEM SET control_management_pack_access = <value>;
After changing, verify that the initialization parameter value has been successfully changed.
Database option and management pack usage can be checked by querying the SYS.DBA_FEATURE_USAGE_STATISTICS view, which provides usage information such as the feature name, version number, whether a feature is currently in use, detected usages, first usage date, and last usage date. The DBA_FEATURE_USAGE_STATISTICS view is automatically updated once a week; however, the view can be manually updated by executing the following procedure:
SQL> EXEC SYS.DBMS_FEATURE_USAGE_INTERNAL.exec_db_usage_sampling(SYSDATE);
Miro is aware that many System Administrators or DBAs use the “clone-and-clip” methodology when spinning up new hardware and/or new database instances. This process is more expeditious than building a server from scratch. And it is also a quite mature approach.
Database cloning, in particular, is useful and popular for the DBAs who want to give their developers a full-sized instance by cloning a production instance into their test or development environment. Cloning enables the creation of a fresh installation with all updates and patches applied to it. This contrasts with going through the installation process by performing separate steps to install, configure, and patch the installation to match the production server. The expectation of cloning, buoyed by the results, are that the cloned installation performs the same as the source installation.
Cloning an Oracle Database or creating a database from an image of a production instance transfers historical database information and usage to the newly cloned instance. This makes the data as well as any past usage and function enablement (i.e., the initialization parameter described previously) identical to the source server. This means that any Database Management Packs and/or Options used on the source server will also be shown in the same way on the cloned server.
For that reason, the cloning process must be followed by the proper disablement of unlicensed Management Packs and/or Options as well as the removal of any access by unintended users of the new server.
Many of our clients are surprised to learn that they have usage for unlicensed database options and management packs. Non-compliance may result in the organization paying significant penalties and purchasing licenses at a higher cost. Organizations should disable unlicensed database options and management packs to prevent accidental use and should regularly check usage to highlight compliance issues early and limit financial risks. Please contact your trusted Miro Analyst or Miro Account Manager for questions or assistance with preventing accidental usage and determining database options and management packs usage (including options, packs, and features not mentioned in this document) to ensure a fully compliant environment.