Troubleshooting Oracle Inventory Using the FlexNet Inventory Scanner
If you are using the FlexNet Inventory Scanner for Oracle discovery and inventory collection, a successful installation and invocation of the FlexNet Inventory Scanner is a prerequisite. As these processes are entirely in your control, the following guide assumes that you have validated them first.
To troubleshoot Oracle discovery and inventory gathering by the FlexNet Inventory Scanner:
-
Before concluding that there is a problem, ensure that you
have allowed sufficient time for:
- Discovery and inventory processes on the target device (check the schedule you have configured for the FlexNet Inventory Scanner, and allowing just a few minutes to gather inventory, even for a large server)
- File upload to the inventory beacon, and from there to the central application server (typically within several minutes of the data gathering being completed)
- Inventory import from the inventory database to the main compliance database (typically scheduled overnight)
- The license reconciliation calculations (typically scheduled overnight).
If, after this process has completed, the target Oracle server does not appear in Discovery & Inventory > All Discovered Devices, it is time to continue troubleshooting. (If the device does appear in this listing, but the Oracle instance is not visible in Discovery & Inventory > Oracle Instances, skip forward to step 4.)
-
On the target Oracle server, examine the tracker log file in the appropriate
folder from this list:
- On Windows: %temp%\ManageSoft\tracker.log (where $(TempDirectory) is the temporary folder for the account running the tracker), or your chosen location if you redirected the logging at the command line.
- On UNIX-like platforms:
- When the executable has run as the
root
account, in /var/tmp/flexera/log - When the executable has been run by any other user account (represented as UserName), in /var/tmp/flexera.UserName/log.
- Your chosen location if you redirected the logging at the command line or in the ndtrack.ini file of preferences on UNIX-like platforms.
- When the executable has run as the
Verify the following events:- The event Uploading file <filename.disco> indicates the generation of the discovery file has succeeded (upload is normally attempted immediately after creation of the discovery file).
- The event File <filename.disco> removed from upload directory indicates the successful upload of the discovery file.
-
If there is no evidence of a successful upload:
-
Check the discovery upload folder on the target Oracle server, since
files should be left behind when upload fails:
- On Windows: $(TempDirectory)\FlexeraSoftware\, where $(TempDirectory) is the temporary directory for the account that is running the FlexNet Inventory Scanner
- On UNIX-like platforms:
- When the executable has run as the
root
account, in /var/tmp/flexera/uploads/Discovery - When the executable has been run by any other user account (represented as UserName), in /var/tmp/flexera.UserName/uploads/Discovery.
- When the executable has run as the
-
If the relevant discovery upload folder still contains the
.disco file, discovery is working but uploads
are failing:
- Double-check that the tracker command line options passed to the FlexNet Inventory Scanner correctly identified an accessible upload location on the correct inventory beacon.
- Ping or otherwise check network access from the target Oracle server to the inventory beacon.
- Ensure that the ManageSoftRL file share remains configured on the relevant inventory beacon (it is configured as part of the installation of the inventory beacon) and accessible.
- Can you be sure there wasn't an intermittent network problem at last inventory time?
-
If the relevant discovery upload folder on the target Oracle server is
empty, upload to the inventory beacon may have worked as the first
stage, and you can check for a later problem in the upload chain:
Switch to the relevant inventory beacon, and:
- Check $(CommonAppDataFolder)\Flexera Software\Incoming\Inventories. This is the staging folder for data uploaded from target devices but not yet uploaded to the parent of this inventory beacon. If a file is still here, the upload from this inventory beacon to its parent (another inventory beacon) has failed.
- Check logs for any issues in $(CommonAppDataFolder)\Flexera Software\Compliance\Logging\BeaconEngine.
-
Check the discovery upload folder on the target Oracle server, since
files should be left behind when upload fails:
-
If discovery is working but Oracle inventory is not, the target Oracle server
is visible in Discovery & Inventory > All Discovered Devices, but there is no record of the Oracle instance(s) running on that
server in Discovery & Inventory > Oracle Instances. To troubleshoot, return to the log file for the
ndtrack component on the target Oracle server:
Verify the following events:
- Starting oracle inventory and
Finished generating inventory indicate the
start and end of the Oracle inventory collection process.Note: On a UNIX-like platform, the tracker attempts to use setuid to impersonate an appropriate user 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). - Uploading file <filename (Oracle).ndi.gz> indicates the upload of the compressed Oracle inventory file.
- File <filename (Oracle).ndi.gz> removed from upload directory indicates the successful upload of the inventory file.
- Starting oracle inventory and
Finished generating inventory indicate the
start and end of the Oracle inventory collection process.
-
If Oracle Database inventory gathering is
failing, first ensure that the appropriate account can use
sqlplus
to connect to the database instance:- 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
- If you are using the
- 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:sqlplus "/ " # when OracleInventoryAsSysdba=false sqlplus "/ as sysdba" # in all other cases
- 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 thesu
command), and then switch to the identified account to runsqlplus
, ensuring that the environment variables are set for the Oracle home directory and the system identifier (SID) for the current database instance:
If the connection is successful,su accountUnderTest export ORACLE_HOME=OracleHomeDirectory export ORACLE_SID=OracleSID cd $ORACLE_HOME/bin ./sqlplus "/ as sysdba" # or modified as noted above
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:
A response of the full version ID for the Oracle Database confirms that inventory collection can proceed.SELECT VERSION FROM V$INSTANCE;
If you cannot connect successfully, ask your Oracle DBA for assistance to resolve the problem. If connection was successful, continue with the following checks.
- On UNIX-like systems, check whether the OracleHomeDirectory/bin/oracle executable may have been upgraded or replaced without restarting the database instance. 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. If you cannot determine whether the executable has been changed, restart the database instance to test whether this clears the problem. 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 (versions 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). Use any of the following methods to verify the version
of ndtrack:
- 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. (On UNIX-like platforms, for legacy reasons, this is listed as ManageSoft for platform Managed Devices.)
- 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. - 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.logTip: If ndtrack.sh is executed by a non-root account userName, the log defaults to: /var/tmp/flexera.userName/log/tracker.log.
- Open an .ndi file saved on the
locally-installed FlexNet inventory agent, which reports
the version creating the file. Between inventory
collections, the most recent 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 theInventory
XML element. - If you are using ndtrack.sh, this
command line reports the
version:
cd directoryContainingScanner ./ndtrack.sh --version
- On all operating systems, if the preference
OracleInventoryAsSysdba=true
or is not specified (when the default is also true), 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 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 theOracleInventoryUser
andOracleInventoryAsSysdba
preferences in Gathering FlexNet Inventory.
- Identify
the account relevant to this database instance. For example, on
UNIX-like platforms:
FlexNet Manager Suite (On-Premises)
2023 R1