Troubleshooting Zero-footprint Collection of Oracle Inventory

In the web interface for FlexNet Manager Suite, navigate to Discovery & Inventory > Oracle Instances to identify the database instances that have been discovered successfully. You may wish to focus on instances you expected to find that are not present on this page. (It is helpful to know the device name of an Oracle server you wish to examine, as you can use the name in searches in various lists.)

Another quick check is to look at Discovery & Inventory > All Discovered Devices and validate that the Oracle server is listed there. If the device itself cannot be discovered, no services on it can be discovered either. Also check for Oracle discovered devices listing problems:

Click the filter icon above the right end of the list, and in the quick filter row, select Oracle = Yes.
Next to the filter icon, click the notification icon to reduce the list to only those Oracle servers reporting problems.
In the list, click the Name of a discovered device to open its properties, and select the Status tab.

Expand the Oracle Database inventory section, which displays any error message returned by the Oracle listener on this discovered device. Seek the help of your Oracle database administrator to resolve any issues.

Here are some common errors with suggested things to check:

Error Message	Notes
ORA-12170: TNS: Connect timeout occurred	Ensure that no firewall is blocking connection to the database. Ensure that the database is online and running on correct IP.
ORA-12541: TNS: no listener	The database is shutdown. Ask your database administrator to start the database. Ensure that no firewall is blocking connection to the database. Ensure that the listener is not password protected. If it is, add the listener password to the Password Manager on the appropriate inventory beacon.
ORA-00942: table or view does not exist	Ensure that the table listed in the error message exists. Ask your database administrator to create the table if it does not exist.
ORA-12514: TNS: listener does not currently know of service requested in connect descriptor	TNS names file is not correct. This is common when a database is set to listen for only “SID” or only “Service_Name”.
ORA-01017: invalid username/password; logon denied	Indicates incorrect permissions. Ask your Oracle Database administrator to rerun the Flexera 'audit user' script (for details, see Credentials for Direct Collection of Oracle Inventory).
ORA-01034: ORACLE not available ORA-27101: shared memory realm does not exist Linux-x86_64 Error: 2: No such file or directory	These errors typically mean that a discovered Oracle database instance was not running at inventory time. Ask your Oracle Database administrator whether the instance can be made active for the next inventory gathering process.
ORA-01033: ORACLE initialization or shutdown in progress	Oracle is stuck in a reboot process. Ask your database administrator to shutdown and restart the database.
ORA-12518: TNS: listener could not hand off client connection	Indicates a network problem. Ensure that the appropriate inventory beacon can access the Oracle server.
ORA-00604: error occurred at recursive SQL level 1	Indicates incorrect permissions. Ask your Oracle Database administrator to rerun the Flexera 'audit user' script (for details, see Credentials for Direct Collection of Oracle Inventory). Note: On a UNIX-like platform, the tracker attempts to use setuid to impersonate the appropriate account to gather Oracle inventory. If you are using eTrust Access Control on this server, by default it does not permit this impersonation, and inventory gathering fails. The fix is to change the configuration of eTrust to include ndtrack in the `LOGINAPPL` class. For more information, see the eTrust Access Control Administration Guide (https://supportcontent.ca.com/cadocs/0/g007711e.pdf).
ORA-00257: archiver error. Connect internal only, until freed	Indicates an archive error. Ask your Oracle Database administrator to check the `archiver.log` file for the error.

Navigate to Discovery & Inventory > Discovery and Inventory Rules > Rules tab, and:

Find the appropriate rule, and check that its Rule status value shows Enabled. (A disabled rule never executes.)
Click the title of the relevant rule and note the Action name and Targets name for this rule for use shortly. Also validate that the Schedule details are as expected.

Look in Current run or Last completed run to see the number of database instances discovered, inventoried, skipped, and failed. Here are some notes to assist your analysis of these figures:

Column	Notes
Service discovered	The number of Oracle database instances discovered in the last execution of the rule. This number should match (or possibly exceed) your expectations for Oracle servers within the targeted subnets. However, database discovery cannot succeed when: The target device is powered off at the time of rule execution (to recover, re-run the rule when the server is operational). The listener on the device is not operating when the rule executes (to recover, re-run the rule when the listener is running). The password for the listener is not available in the Password Manager on the inventory beacon attempting discovery. The listener returns an error, or does not identify any services (database instances).
Inventory completed	The count of those instances from which database inventory has been collected. In an ideal world, this count of successful inventories may match the discovery result in the previous column. Differences should be tracked in the next two columns.
Inventory skipped	The count of database instances where collection of database inventory was not attempted. If a server is within scope for the inventory beacon, but no listener is identified on that server, it is counted as skipped.
Inventory failed	The count of database instances where inventory collection was attempted but failed. This may be because: The credentials for the database instance were not configured in the Password Manager on the inventory beacon attempting to collect database inventory. The instance was not running at inventory time. The instance was running, but was not active (that is, was in the idle state) at inventory time.

Look to the bottom of the same expanded panel, and click Show/hide task status and history. By default this lists the last five executions of the rule. You can expand one (such as the most recent) to see all the inventory beacons that received the discovery and inventory rule (it still shows as Scheduled on inventory beacons that do not manage the appropriate subnets). You should find the intended inventory beacon in this list, where you can check the value in the Status column.
Use the + icon to expand more details for the chosen inventory beacon, and you see entries such as Performing discovery and Gathering Oracle database inventory. In the right-hand column are links for Download log. Download these, unzip the archive, and examine in a text file editor for clues to the problem.

In the area summarizing the run results, the Devices failed to be inventoried field indicates the number of devices for which general hardware and software inventory collection has failed. You can click the link to view the details in the Rule Execution Details page. For more information, see the Rule Execution Details page in the online help.

Using the noted Action name for this rule, switch to the Actions tab, locate the relevant action, and click the editing (pencil) icon on the right-hand side to show the details. In the Discovery of devices section, where Network scan is selected, verify the correct ports are included for all Oracle servers where database instances are running (especially focusing on instances that have not yet been discovered). If you are not sure about the correct port settings for each Oracle server, ask your system administrator. Recall that a probe on the ports listed here must get a response from the server itself before further discovery or inventory work is attempted.

In the General hardware and software inventory section, ensure that the Gather hardware and software inventory from all target devices option is selected.

If it appears that connection has been made and inventory collected, check for problems with file upload from the inventory beacon to the central application server. On the inventory beacon, examine C:\Windows\Temp\ManageSoft\uploader.log for any issues with uploads.

Still on the inventory beacon, check for inventory-specific errors in $(CommonAppDataFolder)\Flexera Software\Compliance\Logging\InventoryRule\DeviceInventory.log and OracleDBInventory.log files.

To enable richer logging on the inventory beacon, enable tracing by removing the hash character (#) from the following lines of the etdp.trace file present in the %Program Files (x86)%\Flexera Software\Inventory Beacon\ folder:

+Inventory/Oracle
+Inventory/Oracle/SDK
+Inventory/Oracle/Query
+Inventory/Oracle/Query/Substitution
+Inventory/Oracle/Query/Execution
+Inventory/Oracle/Listener 
+Inventory/Oracle/Listener/Detail

Important: After making changes to the etdp.trace file, you must use the Windows Service Controller on the inventory beacon to stop and restart the beaconengine service.

Rerun the rule to collect Oracle discovery and inventory information, so that additional logging is created. See whether these richer logs assist in identifying the problem. Wait until after the next inventory import, and then look for both the discovered device (All Discovered Devices) and its Oracle instance (Oracle Instances). (Rather than waiting, an operator in an Administrator role can navigate to License Compliance > Reconcile, ensure that the Update inventory for reconciliation option is selected, and click Reconcile.)

If the problem persists, contact Flexera support with detailed information and log files.