Issues with Inventory Gathering

FlexNet Manager Suite 2020 R1 (On-Premises)

It is possible for the installed FlexNet inventory agent to succeed at its local discovery task (identifying the presence of Oracle Database on the inventory device), and yet to fail to deliver inventory for the associated Oracle instances on the inventory device (the Oracle server).

Be sure that you have validated all the prerequisites (see Troubleshooting Agent-Based Collection of Oracle Inventory). In particular, remember that Oracle inventory collection on UNIX-like platforms requires that the FlexNet inventory agent must be running as root.

Symptoms

Discovery of the Oracle server itself has succeeded, and it is therefore visible in Discovery & Inventory > All Discovered Devices; but
Records of Oracle database instances known to be on that server are missing from Discovery & Inventory > Oracle Instances. The issue may be:
- Inventory gathering (this topic)
- Inventory uploads (see Issues with Uploads).

To troubleshoot Oracle inventory collection:

In the web interface, navigate through Discovery & Inventory > All Discovered Devices to open the properties for the target inventory device (the Oracle server), and check the Status tab for issues with local Oracle inventory collection.
Providing that status uploads are running, any errors while taking inventory of an Oracle database instance are displayed here. These errors may guide discussions with your Oracle database administrator; or direct you to step 5 to check for connection problems. If the database instance isn't displayed, continue with next steps.
On a UNIX-like target inventory device, check whether eTrust Access Control is in use, and if so whether it has been configured to include ndtrack in the LOGINAPPL class.
On a UNIX-like platform, the tracker attempts to use setuid to impersonate an appropriate user to gather Oracle inventory. By default, eTrust Access Control does not permit this impersonation, and inventory gathering fails. The fix is to change the configuration of eTrust as described. For more information, see the eTrust Access Control Administration Guide (https://supportcontent.ca.com/cadocs/0/g007711e.pdf).
On the target inventory device (of any platform type), open the tracker.log file in a text editor, and check for the indications of success:
- On Windows: $(TempDirectory)\ManageSoft\tracker.log
- On UNIX-like platforms: /var/opt/managesoft/log/tracker.log
Look for the following events within the expected time-frame (by default, the FlexNet inventory agent collects and uploads inventory on a daily basis):
- Starting oracle inventory and Finished generating inventory indicate the start and end of the Oracle inventory collection process.
- Uploading file <filename (Oracle).ndi.gz> indicates the upload of the compressed Oracle inventory file has commenced.
- File <filename (Oracle).ndi.gz> removed from upload directory indicates the successful upload of the inventory file.
If these success points are all logged (or if only the last one is missing), the issue may be in uploading inventory files (see Issues with Uploads). If, instead, it is inventory collection that is failing, continue.
Tip: The tracker.log file also includes details of Oracle options that are found on each database instance. For example, a database instance may produce a log entry like this:
```
[dateTime (G, 0)] {25332} |   AdvancedCompression_ByTableCompression: Installed = 1, Used = 0
```
This entry clarifies that the Advanced Compression option is available for the database instance, but is not (yet) known to be in use on this instance. In fact, this is one of several Oracle queries that test for use of the Advanced Compression option, such as:
- AdvancedCompression_ByTableCompression
- AdvancedCompression_BySecureFilesCompressionAndDeDuplication
- AdvancedCompression_ByLogArchiveCompression
- AdvancedCompression_ByFeatureDataGuard.
If Used gives a non-zero result in any of these queries, the option is considered used and licensable on the database instance. This level of detail allows you to dig deeply and identify the particular Oracle query that defines the usage.
Furthermore, if it happens that the current database instance is also the repository for an installation of Oracle Enterprise Manager, the log for each query is extended with the Oracle server name and the database instance name for each managed database instance as well:
[dateTime (G, 0)] {25332} | LifecycleManagementPack_ByOEMMgmtTargets: [dateTime (G, 0)] {25332} | server1.example.com/orcl11g2: Installed = 1, Used = 1 [dateTime (G, 0)] {25332} | server1.example.com/orcl11g: Installed = 1, Used = 1 [dateTime (G, 0)] {25332} | server2.example.com/orcloem: Installed = 1, Used = 1 [dateTime (G, 0)] {25332} | server3.example.com/orcl12db: Installed = 1, Used = 1 [dateTime (G, 0)] {25332} | server1.example.com/orclstd: Installed = 1, Used = 1
Ensure that the collection of inventory is correctly scheduled, using these platform-dependent commands:
- On Windows: ndschedag -t machine
- On UNIX-like devices: /opt/managesoft/bin/ndschedag -e
Make sure that the Generate Inventory task is visible, and that the next run time is populated appropriately. If the schedule is empty, review installation.log to look for errors in downloading device policy.
Validate that the appropriate account can use sqlplus to connect to your test database instance:
1. Identify the account relevant to this database instance.
  For example, on UNIX-like platforms:
  - If you are using the OracleInventoryUser preference on this inventory device (server), use that account
  - If not, identify the account that started the database instance. For example, the following command line lists all database instances on this server in the format oraclesid_smon_ORACLESID (the placeholders are replaced with the instance's system identifier in lower- and upper-case), with each row beginning with the relevant account name for that instance:
```
ps -ef | grep smon 
```
2. Validate whether the OracleInventoryAsSysdba preference (in the config.ini file for the local FlexNet inventory agent on UNIX) has been set to false.
  This determines the command line parameters you will need when testing:
```
sqlplus "/ " # when OracleInventoryAsSysdba=false
sqlplus "/ as sysdba" # in all other cases 
```
3. Still using UNIX as our example, log in as root (the FlexNet inventory agent runs with this level of privilege to collect Oracle Database inventory, and using this saves you providing a password with the su command), and then switch to the identified account to run sqlplus, ensuring that the environment variables are set for the Oracle home directory and the system identifier (SID) for the current database instance:
```
su accountUnderTest
export ORACLE_HOME=OracleHomeDirectory
export ORACLE_SID=OracleSID
cd $ORACLE_HOME/bin
./sqlplus "/ as sysdba" # or modified as noted above
```
  If the connection is successful, sqlplus prints a Connected to: summary for the current database instance. Validate that the permissions are adequate and the database instance is fully operational with a test query such as:
```
SELECT VERSION FROM V$INSTANCE;
```
  A response of the full version ID for the Oracle Database confirms that inventory collection can proceed. If connection was successful but inventory collection is still not succeeding, skip ahead to step 8. If connection did not succeed, continue here.
4. On all operating systems, check whether the preference OracleInventoryAsSysdba is set to true or is not specified (when the default is also true). If so, make sure that the account running the database instance is listed in the ORADBA group (the local ora_dba security group on Windows and the dba group on UNIX-like platforms).
  By default this group exists, and the account running the database instance is listed in it; but it is possible that the group has been removed on [some of] your Oracle servers. For full details about alternative accounts and all account requirements, see the OracleInventoryUser and OracleInventoryAsSysdba preferences in the Gathering FlexNet Inventory PDF, available through the title page of online help. If the account running the database instance is missing from the group, add it, and re-run the connection test described in step 5.
  
  Otherwise, with the account being present but the connection test still failing, ask your Oracle DBA for assistance to resolve the problem of the account's access to sqlplus.
On Windows platforms, check that the OracleServicedatabaseName is running.
For example:
```
C:\Users\Administrator\tasklist /svc | find "oracle"
```
Note that although the Oracle Database must attach itself to the Windows service revealed by this command, it is possible for the service to be running while the Oracle Database itself is not started. Therefore, if you found that you had to restart the Windows service, also recheck that Oracle Database (and its instances) are running. The appropriate sqlplus command shown in the previous step validates this.
If you have not already done so as part of your troubleshooting of discovery, set up for a trace file, and re-run the inventory command to check for any reported issues.
More details are in Issues with Discovery, but the summary is:
1. Remove the leading # from the following lines of etcp.trace, located in the installation folder for FlexNet inventory agent, and also edit the file path/name for the output log file, saving the changed file with the same name in the same location:
```
+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
```
2. Re-run the inventory command (ndtrack -t machine).
3. Examine the log file you specified.
  A line like the following indicates the start of the Oracle inventory logic:
```
31.8850, pid 5835 (Inventory/Tracker/Oracle/Listener): Oracle inventory is enabled. 
Performing Oracle inventory.
```
The remaining checks are for less common corner cases that have been detected.
On UNIX-like systems, check whether the OracleHomeDirectory/bin/oracle executable may have been upgraded or replaced without restarting the database instance. If you cannot determine whether the executable has been changed, restart the database instance to test whether this clears the problem.
Remember that the tracker examines process listings, and if the original process was not restarted, it is now referencing a file that is no longer available, because it has been updated or replaced. Of course, if the executable has been changed, a process restart is essential, if for no other reason than to allow the database instance to utilize the updated code.
Also on UNIX-like platforms, verify which version of the ndtrack executable is collecting inventory, and if necessary upgrade the FlexNet inventory agent.
Versions of the tracker earlier than 13.0.1 may fail to gather Oracle inventory on servers where permissions have been tightened to prevent global read access to Oracle directories or files. Choose any of the following methods to verify the version of ndtrack:
1. If you already have a discovered device record for the server, navigate to its discovered device properties, select the Inventory evidence tab and the Software sub-tab. Find FlexNet inventory agent in the listing, which includes its version.
  
  Tip: For UNIX-like platforms, for legacy reasons, the FlexNet inventory agent is listed as ManageSoft for platform Managed Devices.
2. On the target inventory device (the Oracle server), read /var/opt/managesoft/etc/config.ini in a text editor, and validate the version of the inventory agent saved in the read-only ETCPVersion preference.
  
  CAUTION:
  Never edit this value manually.
3. Examine the log file for ndtrack, as this reports the version of the agent in use.
  The default paths for logging depend on the inventory collection method:
  - For the locally-installed FlexNet inventory agent, see /var/opt/managesoft/log/tracker.log (or check for a custom value saved as ManageSoft\Tracker\CurrentVersion\LogFile in the /var/opt/managesoft/etc/config.ini file)
  - For the lightweight FlexNet Inventory Scanner (presented as ndtrack.sh on UNIX-like systems), and also for zero footprint inventory collection, see /var/tmp/flexera/log/tracker.log
    Tip: If ndtrack.sh is executed by a non-root account userName, the log defaults to: /var/tmp/flexera.userName/log/tracker.log.
4. On the target inventory device, review the latest .ndi file.
  Between inventory collections, the most recent general inventory file is saved on the inventory device in /var/opt/managesoft/tracker/inventories, and the version appears at the top of the file as the Tracker attribute of the Inventory XML element.
  Tip: The .ndi file for Oracle inventory is not preserved uncompressed in the same way. The Oracle inventory file is immediately compressed and an upload is attempted. But for the purpose of identifying the release of FlexNet inventory agent in use on this device, any .ndi file will suffice,
5. If you are using ndtrack.sh (the lightweight inventory scanner), this command line reports the version:
```
cd directoryContainingScanner
./ndtrack.sh --version
```
If the version of ndtrack on this device is 13.0.0 or earlier, upgrade to a later version.

If everything appears to check out correctly but problems persist with Oracle inventory collection, please collect all details and log files and seek further assistance (see Requesting Further Assistance).

FlexNet Manager Suite (On-Premises)

2020 R1