How the FlexNet Inventory Scanner Collects Oracle Inventory

When your chosen scheduling tool triggers the FlexNet Inventory Scanner on the target inventory device, the tracker component performs discovery on its local device (recording results in a .disco file). For Oracle, the discovery process tries to identify one or more paths for $ORACLE_HOME, using all of these platform-dependent methods in order (and combining the resulting dataset):

UNIX-like platforms — Oracle discovery	Windows platforms — Oracle discovery
1. The tracker scans the file system for any `oracle` executables. This scan honors the global settings for file system scans in the File Inventory section of the Inventory Settings page of the web interface, which may limit search paths or even disable file scanning entirely. On success, this search returns the file path ($ORACLE_HOME) and the executable ID.	1. The tracker looks for a registry entry under `HKLM\SOFTWARE\Wow6432Node\Oracle\` (or, on 32-bit systems, `HKLM\SOFTWARE\Oracle\`). On success, this returns the %ORACLE_HOME% path.
2. The tracker looks for an oratab file (installed in either /etc or /var/opt/oracle during database installation). On success, this provides the $ORACLE_HOME path, the executable ID for the oracle executable, and the System ID (SID) for each database instance listed in the oratab file. (See also note below.)	2. The tracker interrogates the Windows Service Control Manager. On success, this provides the %ORACLE_HOME% path, the System ID (SID) for the database instance running in that process, and the name of the related Oracle listener.
3. The tracker examines process listings for matches to ora_smon_*. On success, this provides the $ORACLE_HOME path and/or the executable ID for the oracle executable, as well as the SID for the running database instance and the user account running it. (See also note below.)	(No step 3 for Windows.)
4. The tracker examines process listings for tnslsnr. On success, this provides the $ORACLE_HOME path, the executable ID for the oracle executable, the name of the related Oracle listener, and the user account running the listener.	(No step 4 for Windows.)

Note: If a symbolic link was used in the $ORACLE_HOME path to start a particular Oracle database instance on a UNIX-like platform, this can 'hide' the database instance from inventory collection by the locally-installed tracker (ndtrack component). To ensure inventory collection from a database instance started with a symbolic link, use either (or both) of the following workarounds:

You can ensure that the Oracle home specified in the /etc/oratab file represents the ORACLE_HOME path used to start the database instance.
The account running the database instance (say OSUser4Oracle) may set an environment variable within its login profile specifying the ORACLE_HOME path (including the symbolic link) which was used to start the database instance. To test this setting, the following command should display the correct ORACLE_HOME path:
```
su -OSUser4Oracle -c "echo \$ORACLE_HOME"
```
Tip: If this environment variable is set for any account on the database server, it is applied to all database instances started by the same account on this server. Any mismatch between the (non-empty) environment variable, and the actual path used to start any of these database instances, prevents the collection of database inventory from the mismatched instance by the locally-installed inventory component (ndtrack). Conversely, you can prevent the environment variable option being used for all accounts on the target Oracle server by setting the UserDefinedOracleHome preference (details of this preference are included in the Gathering FlexNet Inventory PDF, available through the title page of online help).

Next, the tracker gathers general hardware and software inventory (recorded in an .ndi file) from the local device. This is the standard inventory gathering that the tracker gathers on every device where it is running.

If the tracker discovered one or more Oracle database instance(s) on the device, and all the required settings and account privileges are in place, the tracker also gathers inventory from all accessible Oracle database instances.

Tip: The definition of "accessible" changed at version 12.4 of the tracker (released with FlexNet Manager Suite 2017 R3):

For versions 12.3 and earlier, "accessible" excluded all Oracle database instances that are in standby mode
For versions 12.4 and later, the locally-installed tracker also collects inventory from Oracle database instances that are in standby (that is, MOUNTED but not in RUN mode), such as the standby instance in an Active Data Guard configuration.

The processes for gathering Oracle inventory on different types of platform are as follows.

For UNIX-like platforms, the tracker impersonates an appropriate account, determined by the configuration of the preferences shown below.

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).

Each column in this table shows a set of conditions in the first three rows, followed by the resulting behavior in the last two rows. Once a valid user account is determined, the tracker invokes the Oracle-supplied sqlplus utility, giving it either of the command line parameters shown in the last row as appropriate:

UNIX-like platforms — Conditions	Option 1	Option 2	Option 3	Option 4	Option 5
If the executable runs as	`root`	`root`	`root`	`root`	Any other account
and `OracleInventoryAsSysdba` =	`True`	`True`	`False`	`False`	n.a.
and `OracleInventoryUser` =	Valid user	Not set	Valid user	Not set	n.a.
Then: Impersonated account is	That user (see *Tip* below)	Process owner	That user (see *Tip* below)	Not supported	n.a.
Command line parameters for sqlplus	`"/ as sysdba"`	`"/ as sysdba"`	`"/ "`	No inventory	No inventory

Tip: If you intend to specify the OracleInventoryUser preference, it must be an exact match for any Oracle user name that:

Is also an operating system account
Has OS authentication enabled
Is a member of oinstall (or equivalent group, granting execute permissions for sqlplus)
Is either a current member of the dba group on the UNIX host server (when OracleInventoryAsSysdba=True or is unspecified); or has adequate permissions for inventory gathering (when OracleInventoryAsSysdba=False).

For Windows platforms, the tracker normally runs as LocalSystem, but may be run by another account that has administrator privileges (that is, is a member of the Administrators security group). In either case, the same account that is running the ndtrack executable is used to invoke the Oracle-supplied utility sqlplus, using the command line parameter "/ as sysdba". This remains true even if the Oracle database instance is running as a service user, as is possible from Oracle Database 12c; so that binaries controlled by the service account are now executed as LocalSystem (or at least with administrator privileges). It is, of course, best practice to ensure that any service account running a database instance is well secured, so that the binaries it controls are protected.

Where Oracle inventory is collected, the tracker also executes scripts provided by Oracle License Management Services (LMS) to gather software and hardware information about the servers where Oracle Database is installed.

These scripts are extracted from the InventorySettings.xml file that you installed in the same directory as the FlexNet Inventory Scanner. The data gathered by these scripts helps to populate the Oracle audit report available through FlexNet Manager Suite (navigate to the Discovery & Inventory > Oracle Instances page, and see details in the help for that page).

The tracker records the software and hardware results of the Oracle inventory gathering in a separate .ndi file.

By default, the FlexNet Inventory Scanner saves collected inventory in %temp%\FlexeraSoftware\$(UserName) on $(MachineId).ndi, where %temp% is the temporary directory for the account that is running the FlexNet Inventory Scanner, with the file name showing the account and machine ID related to the inventory run. The files remain here (for example, for your inspection in an XML editor) until over-written in the next inventory collection. Alternatively, if the command line used to invoke the FlexNet Inventory Scanner included the options

-o Upload=True -o
                            UploadLocation=http://YourBeaconServerURL/ManageSoftRL

, then immediately on completion of inventory gathering, the tracker uploads the .disco file and one or two compressed .ndi files to the appropriate inventory beacon.

Tip: If this upload should fail (for example, because of an incorrect upload parameter in the command line, or a temporary network problem), the FlexNet Inventory Scanner does not have the capacity to run a catch-up at a later time. (For this catch-up facility, install the full FlexNet inventory agent.)

The inventory beacon uploads all collected discovery and inventory information to the central application server (or, if it is a member of a hierarchy of inventory beacons, uploads the data to its parent in the hierarchy, and the upload is repeated until the data reaches the application server). Data is stored initially in the inventory database.

In due course, the inventory import (to the compliance database) and license reconciliation process runs (typically overnight, although an operator in a role granting the Configure inventory data and reconcile right can also trigger a full import and reconciliation). Progress is visible on the System Tasks page.

The Discovery & Inventory > Oracle Instances page lists the database inventory for all servers discovered and inventoried up to the time of the latest reconciliation calculation.