Issues with Discovery

FlexNet Manager Suite 2022 R1 (On-Premises)

Having checked the prerequisites (see Troubleshooting Agent-Based Collection of Oracle Inventory) and shown that the FlexNet inventory agent is correctly installed and can access the InventorySettings.xml file, you already know that the discovery process for initially identifying the target inventory device (the Oracle server) has worked.

However, there is a second kind of discovery involved in gathering Oracle inventory. Recall that the installed FlexNet inventory agent is policy-driven, not rule-driven (meaning that after device discovery, it is no longer affected by discovery or inventory rules that you set in the web interface). It has no local record of previous discoveries; it has only its policy driving it to see what is available on this inventory device. In the case of an Oracle server as the target inventory device, the installed FlexNet inventory agent is driven to prepare three files for upload:

The standard hardware and software inventory (.ndi) file that is prepared on every inventory device
Remember: If the PerformOracleFMWScan preference is true (and InventorySettings.xml is available and up-to-date), this .ndi includes any evidence found for Oracle Fusion Middleware applications.
A separate discovery (.disco) file that records the (re-)discovery of the installed Oracle Database
A separate inventory (.ndi) file exclusively for the inventory of all the Oracle database instances found on this device.

Symptoms

If this stage of discovery fails, the typical symptoms are:

The inventory device (Oracle server) is visible in the Discovery & Inventory > All Discovered Devices page
The Oracle instance(s) are missing from the Discovery & Inventory > Oracle Instance page.

To troubleshoot Oracle discovery:

To quickly determine whether the problem is in generating or uploading the discovery file, check on the inventory device for a blocked upload of the .disco file:
- On Windows: $(CommonAppDataFolder)\ManageSoft Corp\ManageSoft\Common\Uploads\Discovery
- On UNIX: /var/opt/managesoft/uploads/discovery/.
A discovery file (.disco) present in the appropriate folder means discovery is working, but that the upload is failing (since, after a successful upload, the file is removed from this folder). In this case, switch to debugging uploads (see Issues with Uploads). The absence of a file is therefore ambiguous: it may mean either that the file creation is failing, or that the first stage of upload has succeeded and that the problem is further upstream in the path from inventory device to application server.
If the folder is empty, you may check the following log file for evidence of a previous successful upload:
- On Windows: $(TempDirectory)\ManageSoft\tracker.log
- On UNIX-like platforms: /var/opt/managesoft/log/tracker.log
(Because uploads are attempted immediately after inventory collection, they are logged by the tracker component. If this attempt fails and the catch-up upload is attempted later, this is logged by the uploader component.) Verify the following events within the expected time-frame (by default, the FlexNet inventory agent collects and uploads inventory on a daily basis):
- The event Uploading file <filename.disco> indicates that the generation of the discovery file has succeeded (upload is normally attempted shortly after creation of the discovery file, when inventory has been collected).
  Important: Take note of the URL given in this step, which should be of the form:
  'http://192.53.15.139/ManageSoftRL/Inventories'
  The two trailing values are normally consistent for all inventory beacons:
  
  The ManageSoftRL folder is the web service for receiving uploads
  
  Inventories indicates the temporary storage location on the inventory beacon.
  
  The IP address allows you to identify the inventory beacon that FlexNet inventory agent chose for this upload (keeping in mind that FlexNet inventory agent chooses the optimum inventory beacon for each upload, and that it may select different servers at different times, depending on networking conditions). This log entry is one of the few ways to identify the inventory beacon used for any given upload.
- The events Upload successful and File <filename.disco> removed from upload directory indicates the successful upload of the discovery file.
These events indicate that discovery is working, the first stage of upload from the inventory device to an inventory beacon has also worked, and your problem may lie further upstream. Switch to debugging uploads (see Issues with Uploads).
If the folder is empty and tracker.log gives no indication of a recent successful upload, check further in tracker.log for evidence of successful discovery of database instances, validating results against your expectations for this Oracle server.
Look for entries like the following:
```
Started tracking Oracle database instances using inventory recognition rules
Executing oracle inventory rules
 ===== Discovered Oracle database instances and listeners
```
This should be followed by reports of separate instances, each commencing with +--, and reporting either a path to the dbhome, an instance name discovered as a running process, or a listener name. This list typically closes with:
```
Oracle database instances were discovered for inventory. 
```
Tip: If this section is missing completely, the most common problem is the absence of prerequisites, including a license for FlexNet Manager for Datacenters, and the InventorySettings.xml file. If you have not already validated these prerequisites, refer back to Troubleshooting Agent-Based Collection of Oracle Inventory for details.
If the log file reports any issues with discovery, attempt to remedy those before continuing.
If logged results were incomplete, or you wish to examine the results intended for upload in the .disco file, change to the installation directory for FlexNet inventory agent, and use the following platform-dependent command line to generate a new discovery file:
- For Windows: ndtrack -t machine -o Upload=False
- For UNIX-like devices: bin/sh ./ndtrack -t machine -o Upload=False
The Upload=False option prevents upload of the generated .disco file by the FlexNet inventory agent, so that it is saved in the path described in step 1. Inspect the discovery folder again:
- If a .disco file is present now, continue with step 5.
- If there is no .disco file created, skip to step 6.
Open the .disco file in a text editor, and check for any evidence of Oracle services.
- If you find such evidence, the discovery process is probably working correctly. Look elsewhere for your problem, such as in uploads (see Issues with Uploads).
- If there is no such evidence:
1. Again look for evidence of Oracle discovery in the tracker.log file, as described in step 3.
2. If you can, remedy any problems highlighted in this log file.
3. If you are unable to diagnose further, generate a trace file (as in the next step) before you seek further assistance (see Requesting Further Assistance).
As no .disco file was created, and the tracker.log file (see step 3) does not give enough information, increase the level of tracing before running the inventory (and related discovery) command again:
1. Switch to the installation directory for FlexNet inventory agent.
2. Open the etcp.trace file from this folder in a flat text editor.
3. Uncomment (remove # from the start of) the following lines:
```
+Inventory/Oracle
+Inventory/Oracle/SDK
+Inventory/Oracle/Query
+Inventory/Oracle/Query/Substitution
+Inventory/Oracle/Query/Execution
+Inventory/Oracle/Listener 
+Inventory/Oracle/Listener/Detail
+Inventory/Tracker/Environment
```
4. Also uncomment one of the lines that declare the file path and file name (pattern) for the output trace file, optionally customizing the path:
  On Microsoft Windows:
```
filename=C:\ManageSoft%p_%d_%t_%u.log # filename pattern with everything!
```
  On UNIX-like platforms:
```
filename=/tmp/log/ManageSoft%p_%d_%t_%u.log # filename pattern with everything!
```
  Tip: Keep at least the %u option, so that each run gives the trace file a sequential number. With no variables in the file name, each run appends data to the same file, which can quickly become unmanageably large.
5. Save the etcp.trace file, and re-run the ndtrack command (see step 4).
6. Examine the output .log file(s) in the path you declared.
7. If you can, correct any reported problems. If not, include your trace files with your log files, and seek further assistance (see Requesting Further Assistance).

FlexNet Manager Suite (On-Premises)

2022 R1