A new Flexera Community experience is coming on November 18th, click here for more information.
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?
May 16, 2019 03:45 PM
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
May 16, 2019 07:34 PM - edited May 17, 2019 09:19 AM
May 17, 2019 09:35 AM
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
May 17, 2019 10:03 AM
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
May 16, 2019 07:34 PM - edited May 17, 2019 09:19 AM
May 17, 2019 09:35 AM
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
May 17, 2019 10:03 AM
User | Count |
---|---|
8 | |
7 | |
3 | |
3 |