Interaction with Oracle Enterprise Manager

FlexNet Manager Suite 2020 R2 (On-Premises)

If you are using Oracle Enterprise Manager to manage various Oracle Database installations (together with the many database instances that these may support), there are two completely separate ways that FlexNet Manager Suite can interact with your installation(s) of Oracle Enterprise Manager, using it either:

• As a discovery tool to identify database instances
• As a management reporting tool to track Oracle options/applications being remotely managed on [some of] those database instances.

These two approaches are entirely independent, and you may use both within your enterprise, if need be.

Discovery

The goal here is to create an authoritative listing of all the database instances running on Oracle servers within your enterprise. This discovery process helps ensure that your Oracle inventory can be complete, and avoids nasty surprises if you are ever involved in an Oracle audit.

The approach is as follows:

• A unique copy of the OEM adapter, a utility from Flexera, is associated with each installation of Oracle Enterprise Manager.
• The OEM adapter extracts the identities of all the database instances known to this installation of Oracle Enterprise Manager. It structures the data into the Oracle-standard file format, tnsnames.ora.
• The OEM adapter is also linked to a particular inventory beacon, and automatically writes its prepared tnsnames.ora file into a known path on the inventory beacon. Because the OEM adapter always writes a file with the same name into the same path, the easiest configuration is to support each OEM adapter with its own distinct inventory beacon.
• In due course, the inventory beacon connects directly to each database instance identified in [all of the] .ora files waiting in the special directory, and collects Oracle inventory from each database instance (the "direct" inventory model). The inventory from each database instances is saved into an .ndi file, and uploaded to the central application server along with all other collected inventory.

You can find more insight in the topic Using tnsnames Discovery with Direct Inventory within this chapter. Details on obtaining, deploying, and configuring the OEM adapter are included in the FlexNet Manager Suite Inventory Adapters and Connectors Reference PDF, available through the title page of online help.

Reporting on management of Oracle options

Oracle options (and management packs or applications) attached to database instances have separate licensing implications, and must be tracked. An Oracle administrator may authorize their use in either of two ways:

• She may log in directly to the database instance, and authorize use of an option locally — in inventory terms, this option is visible only in the inventory gathered locally on this Oracle server
• She may access Oracle Enterprise Manager and authorize the option from there, acting 'remotely' on the target database instance — this option is then visible both in the local inventory gathered from the remote database instance, and also in the inventory gathered from the OEM repository (the particular database instance within which Oracle Enterprise Manager stores its management data, but here named differently to reduce confusion).

Of course, these actions may be conducted by different administrators, even on the same database instance; and things may get confusing. To help you sort out where Oracle options were authorized, FlexNet Manager Suite displays the name of the Oracle Enterprise Manager server that reports management information for a given database instance (visible in the properties of the database instance). In the same properties pages, you can see every option authorized for the database instance, and for each option see whether it was authorized locally on the database instance, or remotely by someone using Oracle Enterprise Manager.

And the good news is this requires no special set-up or configuration. It does not matter which method of collecting Oracle inventory you use:

• Agent-based, with the locally installed FlexNet inventory agent deployed either through automated adoption or with your preferred third-party tools
• Zero-footprint, where the FlexNet inventory agent is remotely installed by an inventory beacon and removed again after its work is done
• The light-weight FlexNet Inventory Scanner (provided that you have also deployed InventorySettings.xml to the folder where the scanner executes)
• Direct inventory-gathering from the inventory beacon accessing the listener for the database instance.

In all those cases, when inventory is collected from the database instance, it automatically includes any Oracle Enterprise Manager data that is saved in that database instance (which, as then becomes obvious, is also an OEM repository). After the inventory from all database instances is uploaded and imported, FlexNet Manager Suite identifies the managing installation of Oracle Enterprise Manager against both:

• Each target database instance, and
• The individual Oracle options on it that were authorized through Oracle Enterprise Manager.

You can see the results in the web interface for FlexNet Manager Suite by opening the properties sheet for the target database instance (for example, navigate to Discovery & Inventory > Oracle Instances, and click the chosen name in the Instance column). Look in the General tab of the properties to see the Managing OEM, the particular installation of Oracle Enterprise Manager that, within its own inventory of the OEM repository, most recently showed details about this target database instance. Switch to the Options tab in the same properties sheet to see the Oracle options associated with this database instance, and whether they were authorized locally (on This instance) or remotely (by Oracle Enterprise Manager, being that installation identified on the General tab).

Tip: One point about configuration is to ensure you are using appropriate versions. From Oracle 12c, the OEM repository may be saved in a pluggable database. If you use Oracle 12c (or later), you must also use a version of the inventory component (ndtrack) that can collect inventory from pluggable databases. This requires version 13.0.1 of the FlexNet inventory agent, which was distributed with FlexNet Manager Suite 2018 R1 hotfix 02. This (or a later) agent remains backward compatible with inventory beacons and the central application server for version 2016 and later, so that if need be, you can update only FlexNet inventory agent.

Some important points to notice are these:

• Obviously, linking the two inventory sources (local database instance and OEM repository) relies on both inventory files being imported. Furthermore, they are matched by the hostname for the database instance recorded in both inventories. If, for example, your OEM installation reports database instances not by hostname but by IP address, then the matching cannot occur. In that case, you would see separate inventories for the two database instances involved (the target database instance and the OEM repository instance), but no connection between them.
• FlexNet Manager Suite identifies the OEM installation by the Oracle Database server where the management information was found. In the normal course of events where the OEM console and the OEM repository are on the same server, this goes unnoticed, and you can easily recognize the server name. However, if you have separated your OEM console (on, say, myConsoleServer) from the OEM repository (on, say, fatOracleDatabaseServer), you may not instantly recognize the latter as the OEM server name when you have in mind the different name for your OEM console.
• Your configuration of Oracle Enterprise Manager can become even more exotic. "Each administrator is associated with a specific repository... The repository tables can be installed in any database accessible to the Console. ... Also, the repositories for the administrators do not have to be in the same database." (https://docs.oracle.com/cd/A57673_01/DOC/sysman/doc/A55896_01/ch1.htm) Suppose that administrators Sam and Pat have their own separate OEM repositories, and these happen to be on different Oracle Database servers (svrSamDB and svrPatDB). Now, both Sam and Pat remotely access the same database instance ODBINS47, and both authorize some Oracle options on ODBINS47. You can see that when inventory is imported from svrSamDB, the properties of ODBINS47 are updated to show that svrSamDB is its managing installation of OEM; and later, when inventory is processed from svrPatDB, the properties of ODBINS47 switch over to reveal its new managing installation of OEM. In such a fluid environment, the properties of each database instance show management by the installation of OEM most recently imported. The behavior of linking the latest import from an OEM repository works well if you are actually switching management from one installation of OEM to another. The new management OEM is displayed after the very next Oracle inventory import (typically part of the overnight full inventory import and license consumption calculations). However, if you really are allowing multiple administrators working from separate OEM repositories to manage the same database instance, the assigned Managing OEM field reveals only the most recent import from an OEM repository. In less fluid, "normal" environments, where each database instance is managed by a single installation of OEM using an OEM repository on a single database server, you can rely on the stable presentation of these facts.

For more information, see the online help for the Oracle database instances properties sheet.