How do I collect Oracle inventory if only the Flexera agent Oracle discovery can be used?

[#1]

Summary

If only the Oracle Listener Authentication discovery performed by the Flexera agent can be used, this article covers how to ensure the beacons get the required Oracle information.

Synopsis

Some customers are not able to discover Oracle databases over the network and are not keen to rely on TNSNames.ora files but can deploy the Flexera agent to these servers which then discover the Oracle services, then we need to make sure that the beacons which are carrying out the Oracle inventory rule are receiving information about installed Oracle services and making use of it.

An alternative to this process is to the use the 2015 R2 SP4 or above agent to collect Oracle inventory locally - this would require Local OS authentication to be enabled.

Workaround

There are several stages involved to make sure that this can be done:

1. Due to a known issue with how the Oracle Listener scan works on the agent, the attached trigger must be added to the FNMP database as a temporary measure (not required for FNMS 2015 R2 and above) ? there are some important notes in the Additional Information section which must be taken into account.

2. Ensure that the Flexera agent is installed locally on the Oracle server and that Tracker\CurrentVersion\PerformOracleListenerScan=True is set to ensure that the agent discovers the Oracle services; this information is stored in a .disco file which is uploaded to the beacon and then to the FNMS server. If this property does not exist, it will be using the default of True.

3. Once that disco file is imported, ensure that the Database tab of Device Properties for this server now contains Oracle service information.

4. There is then a process on the core server which exports the known discovered information for devices on a periodic basis, this is based on a setting called ?DiscoveryFullExportPeriodMins? and by default is set to 1440 minutes (1 day). In the attached FastExporter.sql script, the first query sets this to 10 minutes which is better for the initial setup / testing but can be set back to 1440 once all of the Oracle inventories are in the system if desired.

5. This export will publish the results to http://server/inventory-beacons/api/download/discovery-export-full on the FNMS server and when accessed you?ll be prompted to download a file called something like ?8.zip? and this contains a .disco file which you should check to ensure that it has the Oracle service information (Look for a <KnownService?> XML tag).

6. To ensure that the export does download at the next Beacon Policy update run the second script in the attached FastExporter.sql script which will set the BeaconPolicy.LastDiscoveryFullExportTime field to NULL. Then when BeaconPolicy.xml is downloaded from http://server/inventory-beacons/api/policy/?BeaconUID=(ca817a0d-44d2-4ecd-aed3-493a1bfae8de) where ?ca817a0d-44d2-4ecd-aed3-493a1bfae8de? is the BeaconUID of the beacon running Oracle inventory ? it will also download the Discovery export.

7. Next you need to update the rule that the Beacon runs to collect Oracle inventory, by changing the name or something similar; to clarify, the following actions are recommend for the targets:

   1. Discover Oracle databases

   2. Also gather Oracle database inventory

      1. TNS names file

8. Updating the rule, forces the BeaconPolicy to update which is what causes it to check for a new export. You can confirm that the Discovery Export has been done as when you update the rules on the beacon it will say in the BeaconEngine.log something like: ?Downloading item 'discovery-export-full' using URI 'http://server/inventory-beacons/api/download/discovery-export-full'.?

9. You should then see the ?8.zip? (or whatever number it was from step 5 above) located in the C:\ProgramData\Flexera Software\Beacon\DiscoveryExport folder of the beacon.

10. Provided that there is no TNSNames.ora file in the ?C:\ProgramData\Flexera Software\Beacon\TNSNames? directory on the beacon then in the BeaconEngine.log the ?Flexera.Beacon.Engine.ActionExecution.TNSNamesDataSource? data source will say that there are ?0 artifacts to process? which means that there are no TNS files and therefore will just carry on.

11. Once subnet checking is completed you should see in the BeaconEngine.log something like: ?Importing devices from data source 'Flexera.Beacon.Engine.ActionExecution.LocalDiscoExportDataSource', which has 1 artifacts to process...? which means that 1 disco file from the Discovery Export was used for importing.

12. Further down you should then see a message similar to ?Finished processing task of type 'TaskType_OracleInventory' on target '192.168.63.33' with result 'XX'? where XX is the exit code ? this proves that Oracle inventory is being attempted and you should be able to get a status message for that device.

If you are still not getting inventory, it could be that the Oracle inventory task failed in which case follow the standard process of enabling +Scheduling/RemoteExecution and +Inventory/Oracle in either the etap.trace (FNMS server) or etdp.trace (Inventory Beacon) and see if that tells you what failure is occurring on the actual Oracle inventory.

Additional Information

Please bear in mind that there is a known issue (FNMS-21233) where the format of the service name in the Agent discovery files is host/service whereas on the server only the service is used. This is what the trigger addresses as without it the Oracle inventory does not start as the service name in the exported disco file is seen to be incorrect.

The trigger will resolve this but it?s not productized and Engineering have confirmed that it will need to be removed before doing a database migration. This issue is resolved in FNMS 2015 R2 and above so the trigger is no longer required for that version but the rest of the article applies.