Troubleshooting Direct Inventory Using Network Scan

IT Asset Management (Cloud)

In direct gathering of Oracle inventory, the FlexNet Beacon engine connects directly to Oracle databases using database port information. If you select network scan as the method of discovery, the FlexNet Beacon engine first tries to discover the required port information by finding and querying the appropriate Oracle listener services.

To troubleshoot Oracle inventory gathering with discovery by network scanning:

  1. In the web interface for IT Asset Management, go to the Oracle Instances page (Inventory > 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.)
  2. Another quick check is to look at the All Discovered Devices page (Inventory > Network Discovery > 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:
    1. Click the filter icon above the right end of the list, and in the quick filter row, select Oracle = Yes.
    2. Next to the filter icon, click the notification icon to reduce the list to only those Oracle servers reporting problems.
    3. In the list, click the Name of a discovered device to open its properties, and select the Status tab.
    4. 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.
  3. Go to the Discovery and Inventory Rules page (Data Collection > IT Assets Inventory Tasks > Discovery and Inventory Rules), select the Rules tab and:
    1. Find the appropriate rule, and check that its Rule status value shows Enabled. (A disabled rule never executes.)
    2. 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.
    3. 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.
    4. 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.
    5. 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.
  4. 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.
  5. Verify the listener ports settings specified in the Oracle database environments section of the action definition. If you are not sure about the correct port settings, ask your database administrator. For more information, see Using Network Discovery with Direct Inventory.
  6. Switch to the Targets tab, locate the target whose name you noted earlier, and click the editing (pencil) icon on the right-hand end to examine the specified target. Validate that the setting for Define machines to target includes the Oracle server you are searching for. If you are suspicious that your target is not working correctly, you can also expand each of your other targets looking for an Exclude condition in Define machines to target. Any overlapping exclude condition in any target, even though that target is not linked in this particular rule, always overrules any Include condition. Be sure that your target Oracle server is not accidentally excluded.
  7. Check that the appropriate inventory beacon can access the Oracle server:
    1. If necessary, identify the subnet that contains the undiscovered Oracle server, and find this subnet in the All Subnets page (Inventory > Network Discovery > All Subnets) to identify the inventory beacon managing the subnet. (If the subnet has not yet been assigned to an inventory beacon, fix that first by clicking the edit icon, and in the Beacon name column, selecting an inventory beacon from the drop-down list.)
    2. Validate that the correct 32-bit OLEDB drivers are installed on the appropriate inventory beacon (as described in Direct Collection of Oracle Inventory).
    3. On the appropriate inventory beacon, run the FlexNet Beacon software as administrator, and examine the local Password Manager.
    4. If (as is likely) the Oracle listener for the undiscovered database instance on the Oracle server is protected by an administrative password, ensure that the password (only, no account name required) is saved in the Password Manager.
    5. Ensure that the special account to access the database instance has been recorded in the secure Password Manager. For details, see Credentials for Direct Collection of Oracle Inventory, and for required database permissions see Appendix C: Oracle Tables and Views for Oracle Inventory Collection. Ensure that the credentials set up for the database instance are identically matched in the Password Manager.
  8. 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.
  9. For inventory-specific errors, check the $(CommonAppDataFolder)\Flexera Software\Compliance\Logging\InventoryRule\DeviceInventory.log and OracleDBInventory.log files on the inventory beacon.
  10. 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.
  11. 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 the Reconcile page (Data Collection > Process Data > Reconcile), ensure that the Update inventory for reconciliation option is selected, and click Reconcile.)
  12. If the problem persists, contact Flexera support with detailed information and log files.

IT Asset Management (Cloud)

Current