cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

FNMS agents and Oracle Enterprise Manager

Does anyone use both FNMS agents and the integration to Oracle Enterprise Manager?

Is there a benefit to importing OEM data if we already have agents deployed?

 

 

 

(3) Solutions

The std OEM integration exists to provide an ongoing set of (Oracle db instance) Targets, i.e. it ultimately generates discovery records with details of the Oracle instances hosted on the servers.  This is typically used when using the beacon to remotely collect Oracle database inventory via "Discovery and Inventory rules".

This remote beacon method used to be the only way to collect Oracle database inventory until late in the FNMS 2015 release cycles when the capability was added to the agent to automatically introspect db's residing on it's host.

So, if you are deploying agents and using them to collect DB inventory then you are already targeting the known devices, so the OEM integration is not needed as you aren't using Discovery and inventory rules.
The only real value it *might* provide is to help identify potential Oracle servers that you don't have the agent deployed to (by comparing the OEM initiated Discovery records to agents deployed).

-Murray

View solution in original post

I want to add one MINOR clarification here. In really locked down environments, there may be a password requirement when querying the TNS Listener. In this instance, the FlexNet Inventory agent may NOT be able to get the list of running instances and connection information during the agent run. I rarely run into this "in the wild" - but wanted to make sure you were aware of it. In this instance, we would rely on OEM's generated (or manually generated) TNS information for connection information in order to perform remote Oracle Inventory to gather the instance specific information.

View solution in original post

Just be careful where you have an FNMS agent installed and running on an OEM server and the agent installed on a DB server being managed by the OEM.

Historical Oracle usage data held in the embedded database on the OEM server will be processed as inventory in FNMS together with the Oracle Inventory from the target DB server.

If you running FNMS 2018 or higher you see where the inventory source has come from (Local or OEM).  

The OEM database may contain historical past usage which you need to be aware of and so there could be conflicting data from what your DB Server agent is telling FNMS and what the OEM inventory for that same server is telling FNMS.

Disable 'GatherOracleInventory' on the OEM server FNMS agent if you just want to see the LMS evidence from the FNMS agents.

Jens

View solution in original post

(3) Replies

The std OEM integration exists to provide an ongoing set of (Oracle db instance) Targets, i.e. it ultimately generates discovery records with details of the Oracle instances hosted on the servers.  This is typically used when using the beacon to remotely collect Oracle database inventory via "Discovery and Inventory rules".

This remote beacon method used to be the only way to collect Oracle database inventory until late in the FNMS 2015 release cycles when the capability was added to the agent to automatically introspect db's residing on it's host.

So, if you are deploying agents and using them to collect DB inventory then you are already targeting the known devices, so the OEM integration is not needed as you aren't using Discovery and inventory rules.
The only real value it *might* provide is to help identify potential Oracle servers that you don't have the agent deployed to (by comparing the OEM initiated Discovery records to agents deployed).

-Murray

I want to add one MINOR clarification here. In really locked down environments, there may be a password requirement when querying the TNS Listener. In this instance, the FlexNet Inventory agent may NOT be able to get the list of running instances and connection information during the agent run. I rarely run into this "in the wild" - but wanted to make sure you were aware of it. In this instance, we would rely on OEM's generated (or manually generated) TNS information for connection information in order to perform remote Oracle Inventory to gather the instance specific information.

Just be careful where you have an FNMS agent installed and running on an OEM server and the agent installed on a DB server being managed by the OEM.

Historical Oracle usage data held in the embedded database on the OEM server will be processed as inventory in FNMS together with the Oracle Inventory from the target DB server.

If you running FNMS 2018 or higher you see where the inventory source has come from (Local or OEM).  

The OEM database may contain historical past usage which you need to be aware of and so there could be conflicting data from what your DB Server agent is telling FNMS and what the OEM inventory for that same server is telling FNMS.

Disable 'GatherOracleInventory' on the OEM server FNMS agent if you just want to see the LMS evidence from the FNMS agents.

Jens