Oracle Enterprise Manager – How to Avoid Unexpected Licensing Challenges

Oracle Enterprise Manager

How to avoid unexpected licensing challenges

Oracle Enterprise Manager – How to Avoid Unexpected Licensing Challenges

  • 31 mayo 2021
  • 6.27 minutes to read

Oracle Enterprise Manager (OEM) is a set of web-based systems management tools for managing the Oracle environment (Database and Applications tiers). OEM provides tools to monitor the Oracle environment and automate (both one-time and repetitive in nature) database and application administration tasks. OEM performs much of its activity through intelligent agents known as Oracle Management Agents. These agents run as autonomous processes on a managed node and perform execution and monitoring tasks for OEM, communicating using the Hypertext Transfer Protocol (HTTP or HTTPS).

Oracle Enterprise Manager is installed with the Oracle Database. Its functionalities are contractually only allowed to be used in conjunction with Oracle Database Enterprise Edition (although it is technically functioning with Oracle Database Standard Edition TWO programs as well) and the Oracle Enterprise Management Packs are enabled by default, ready to be used.

OEM Installation Process

Oracle Enterprise Manager can be deployed in three different architectures:

  • Database control - OEM application for managing a single Oracle Database. The binaries are always installed with the database software, and the OEM repository is optionally created and configured as part of the database creation.
  • Grid control - OEM’s web-based interface for centrally managing multiple Oracle environments from a single point. It requires a separate installation and configuration.
  • Cloud control - Enterprise Manager Cloud Control is a system management software that delivers centralized monitoring, administration, and lifecycle management functionality for the complete IT infrastructure, including systems running Oracle and non-Oracle technologies.

Oracle Enterprise Manager itself is part of the Oracle Database license and does not require a separate license. The OEM functionality included in the Oracle Database is, in essence, a set of basic functionalities which can be used to perform usual administrative tasks (e.g.: creating database objects [tables and indexes], managing user security, backing up and recovering the database, and importing and exporting data).

By default, during the installation process, the Oracle Management Agent (OMA) enables several so-called "Database Enterprise Edition Management Packs" including the ‘Diagnostics Pack’, ‘Tuning Pack’, ‘Database Lifecycle Management Pack’, ‘Data Masking & Subsetting Pack’, ‘Cloud Management Pack for Database’, without any connection to what a customer has licensed. As an end-user, you therefore need to proactively deselect unlicensed packs after installing the agent on a target database to avoid any unlicensed use. Doing so would, however, store a timestamp in the Database and will make the "Pack Access Agreed" marked TRUE in the underlying database schema.

Those premium functionalities contained within OEM require a separate Oracle license, the so called "Oracle Database Enterprise Edition Management Packs" or "OEM Pack”. Technically, however, such an OEM Pack does not exist – these consist of a "suite" of database features which Oracle classifies as licensable features.

In the past, OEM versions prior to Database 10g, OEM Packs were optionally installed on request of the end-user as part of OEM installation process. As of version 10g, OEM Packs are always installed with the configuration of the basic OEM functionality without the end-user having any control. As of this version, a new feature has been introduced for the end-users as well. It is called the "Management Pack Access" page and on this page, users can start enabling or disabling access to the OEM Packs functionality from that version.

When access is enabled for an OEM Pack, all the interface elements (tabs, buttons, and hyperlinks) and functionalities corresponding to the specific OEM Pack are enabled and can be accessed by the end-users.
Disabling Pack access will result in disabling or hiding all the corresponding interface elements but does not result in a deinstallation.

Starting with Database version 10g, OEM binaries, including all the packs, are always installed with the database software. The OEM Packs are installed and enabled by default with the configuration of the DB Enterprise Manager, which is part of the database creation process.

Common Challenges

Many end-users are found to be non-compliant during the course of an audit because the “Pack Access” was agreed, or Automatic Workload Repository reports were used. Many end-users, however, do not have a clear view of what this means.

Pack Access Agreed

Starting with Oracle Database 10g, all OEM Packs are installed and enabled by default. Quite often, Oracle DB admins make use of different diagnosis features without being aware of the licensing implications. The OEM Packs can be enabled and disabled from the GUI interface. Nevertheless, the moment an action is taken from the interface (enabling/disabling), the Pack Access will be agreed, storing information about the timestamps and the user who took these actions.

OEM Pack Access Enabled does not mean that the pack is also used. Although the functionalities are accessible for the end-users, it is possible that the user has not used any of the packs. This usage cannot be confirmed by the information stored in the Oracle Database. Pack Access Agreed means that the user took some actions as explained below:

OEM Pack Access Agreed means:

  • For 10g Database Control, it means that at least one user logged into the OEM console, read the Licensing Information from the welcome screen, and clicked the I Agree button to access the database console
  • For all the rest of 10g and later versions, it means that at least one user accessed the "Management Pack Access" page, changed the pack access checkboxes (all enabled by default), and clicked on the Apply button.

As a result of the above “pack access enabled and agreed” does not mean that the corresponding pack is in use.

Automatic Workload Repository (AWR) and Automatic Database Diagnostics Monitor (ADDM)

The use of the features AWR (Automatic Workload Repository) or ADDM (Automatic Database Diagnostic Monitor) – both part of Diagnostics Pack – are often found to be in use. Sometimes, however, end-users do not recognize the use of these features when confronted by them during an Oracle audit. Be aware that it’s not uncommon that if you reraised a ticket with Oracle Support, your support representatives asked your database administrator at that moment in time to run an AWS report (nobody being aware that this requires a separate license).

In order to provide you an overview of the different database features that are part of the separate licensable programs "Diagnostics Pack" and "Tuning Pack", the below table has been created.

Features

Diagnostics Pack

  • Automatic Workload Repository (AWR)
  • Automatic Database Diagnostic Monitor (ADDM)
  • Performance monitoring (database and host)
  • Event notifications: notification methods, rules, and schedules
  • Event history and metric history (database and host)
  • Blackouts
  • Dynamic metric baselines
  • Monitoring templates
  • Memory-access based performance monitoring
  • Active Session History (ASH)
  • Supporting functionality to perform per stream bottleneck detection and per component top wait event analysis
  • Execution of the Real Application Testing 'Replay Compare Period Report'
  • Performance monitoring and diagnostics (database and host)
  • AWR Warehouse
  • Compare Period ADDM
  • Real Time ADDM
  • ASH analytics
  • Performance Hub
  • Exadata Cell Grid Administration
  • Exadata Cell Grid Performance
  • Exadata Cell Group Health Overview page
  • Exadata Resource Utilization
  • Notifications
  • Metric and Alert/Event history
  • User-Defined Metrics and Metric Extensions
  • Management Connectors
  • Dynamic metric baselines and Adaptive metric thresholds
  • Monitoring templates and Template Collections
  • Replay Compare Period Report

Tuning Pack

  • SQL Access Advisor
  • SQL Tuning Advisor
  • SQL Tuning Sets
  • Reorganize objects (dbms_redefinition)
  • Automatic SQL Tuning
  • SQL Monitoring
  • Oracle Database In-Memory Advisor
  • SQL Profiles
  • Real-time SQL and PL/SQL Monitoring
  • Real-time Database Operations Monitoring

The usage of "Tuning Pack” requires a license for "Diagnostics Pack” as well.

The licensing of OEM Packs can be subjective if no clear usage can be identified in the Oracle Database. If an end-user has enabled and agreed to use the Packs, in most cases the end-user needs to be licensed. In case you are not licensed for the OEM Packs and you don’t recognize the use, the following steps can be taken:

  • Decide which OEM Packs you want to keep and buy the appropriate licenses.
  • Disable the Packs access for all the OEM Packs that are not licensed.

Disabling the Packs usage is a simple task that can be performed by a DBA and will not require the DB to be reinstalled. Please note that Oracle would require you to disable the Pack access and not de-install the Packs if they are not required.

Get in Control of Your Oracle Licensing

Are you making use of OEM but aren’t sure how to avoid licensing challenges?

Contact us

Comente este artículo

¡Déjenos un comentario para conocer lo que piensa sobre este tema!

Deje un comentario

Artículos relacionados