Troubleshooting Direct Inventory Using tnsnames.ora

FlexNet Manager Suite 2020 R2 (On-Premises)

In direct gathering of Oracle inventory, the FlexNet Beacon engine connects directly to Oracle databases using database port information. If you select the tnsnames.ora file as the method of discovery, the FlexNet Beacon engine uses the port information contained in that file.

To troubleshoot Oracle discovery and inventory using tnsnames.ora:

  1. 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.)
  2. Check Discovery & Inventory > All Discovered Devices and validate that the Oracle server is listed there. If the tnsnames.ora file is resolved correctly and the data from it is uploaded, a discovered device record is created (after inventory import). (If the device is present, can you check whether the Oracle service was running at the time of last inventory gathering? The service must be running for Oracle discovery and inventory to succeed.) You can also use this listing to check for Oracle servers that are discovered, but reporting 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. Navigate to Discovery & Inventory > Discovery and Inventory Rules > Rules tab, and:
    1. Find the appropriate rule, and check 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 (that is, the total number identified in all the .ora files saved on every inventory beacon executing the rule). This number should match (or possibly exceed) your expectations for Oracle servers within the targeted subnets, as identified in the .ora files. 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 listener returns an error, or does not identify any services (database instances).
      In addition, the tnsnames.ora file saved on a particular inventory beacon may identify database instances that are out of scope for that inventory beacon (either outside its assigned subnets, or outside the target[s] for the current rule). Any out-of-scope database instances are included in this count of Service discovered; but the out-of-scope instances are skipped for inventory gathering by this inventory beacon.
      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. Inventory gathering cannot succeed in the following cases, which are logged in $(CommonAppDataFolder)\Flexera Software\Compliance\Logging\InventoryRule\RuleID\OracleDBInventory.log on the inventory beacon:
      • A database instance listed in the .ora files on an inventory beacon falls outside the scope of the inventory beacon (where the 'scope' is the intersection of the subnets assigned to the inventory beacon and the target for the rule that the inventory beacon is executing). In this case the OracleDBInventory.log file includes an entry like Skipped device 'deviceName' because it was not within the authorised ranges for this beacon and rule. In the case where the database instance is in the correct subnet assigned to the inventory beacon, but not listed in the targets incorporated in the currently-executing rule, the log entry is like Skipped device 'deviceIP' because it has no targets that are active (part of the current rule).
      • A database instance identified in an .ora file is not active at inventory time. In this case the OracleDBInventory.log file includes an entry like No inventory gathered for device 'deviceIP' because discovery did not find the service on the device. (Direct inventory gathering cannot access any standby database instances to collect inventory, since these instances are also 'dark' to the listener. To collect inventory covering standby database instances, use a locally-installed tracker of version 12.4 or later, through one of Agent-Based Collection of Oracle Inventory, FlexNet Inventory Scanner Collection of Oracle Inventory, or Zero-footprint Collection of Oracle Inventory.)
      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. (Direct inventory gathering cannot access any standby database instances to collect inventory, since these instances are also 'dark' to the listener — as noted above.)
    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, ensure that TNSNames file for Oracle databases is selected.
  5. Check the set-up of the inventory beacon responsible for directly gathering the Oracle inventory:
    1. If necessary, identify the subnet that contains the undiscovered Oracle server, and find this subnet in Discovery & Inventory > 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. 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.
    5. Verify the existence of one or more .ora file(s) in the TNSNames repository folder ($(CommonAppDataFolder)\Flexera Software\Repository\TNSNames) on the inventory beacon. If none is present, trace back the methods that should be updating the file(s) here (as discussed in Using tnsnames Discovery with Direct Inventory).
  6. 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.
  7. For inventory-specific errors, check the $(CommonAppDataFolder)\Flexera Software\Compliance\Logging\InventoryRule\DeviceInventory.log and OracleDBInventory.log files on the inventory beacon.
  8. 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.
  9. 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.)
  10. If the problem persists, contact Flexera support with detailed information and log files.

FlexNet Manager Suite (On-Premises)

2020 R2