How Agent-Based Collection of Oracle Inventory Works
In local agent-based inventory collection, FlexNet Manager Suite collects Oracle inventory through the FlexNet inventory agent installed on each Oracle server within your network. This method is simplest in operation, as each FlexNet inventory agent performs discovery and inventory for its respective Oracle server, and the various processes are managed automatically.
The installation of the FlexNet inventory agent is detailed in the Gathering FlexNet Inventory PDF for either the Adopted case or the Agent third-party deployment case. This topic summarizes operation after deployment.
The following diagram shows an example scenario for a single inventory beacon.
The diagram shows three database servers, two in Subnet1 and one in Subnet2. An instance of FlexNet inventory agent has been installed on each of these database servers. The inventory beacon has been assigned to cover both of these subnets and can connect to every Oracle server. All the prerequisites outlined in Agent-Based Collection of Oracle Inventory are satisfied.
- By default, every 15 minutes each inventory beacon checks for any updates its own
policy, from which it derives policy to share with the devices it is managing. (To adjust
this download schedule, see Inventory Settings Page > Beacon Settings Section in
the online help.) This policy may:
- Update the schedule for the installed FlexNet inventory agents if this has been changed (see Inventory Settings Page > Inventory Agent Schedule Section in the online help)
- Update the InventorySettings.xml file, if this has been changed by a recent download of the Application Recognition Library (this file includes specialized actions for gathering Oracle inventory).
- When the global schedule for inventory collection by the installed FlexNet inventory agents triggers, each FlexNet inventory agent performs discovery on its local device
(recorded in a .disco file). This process is run by the tracker
component of the FlexNet inventory agent (ndtrack executable). 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 anyoracle
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 correctORACLE_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 theUserDefinedOracleHome
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):The processes for gathering Oracle inventory on different types of platform are as follows.
- 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.
- 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 theEach 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:
LOGINAPPL
class. For more information, see the eTrust Access Control Administration Guide (https://supportcontent.ca.com/cadocs/0/g007711e.pdf).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 theOracleInventoryUser
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 forsqlplus
) - Is either a current member of the
dba
group on the UNIX host server (whenOracleInventoryAsSysdba=True
or is unspecified); or has adequate permissions for inventory gathering (whenOracleInventoryAsSysdba=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 asLocalSystem
(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 Global Licensing and Advisory Services (GLAS) to gather software and hardware information about the servers where Oracle Database is installed. (These scripts, as amended from time to time, are downloaded to the tracker from the InventorySettings.xml file. They are used only for the preparation of an Oracle audit report, available to operators who have appropriate access rights in the page, with more details available in the help for that page.)
- The tracker records the software and hardware results of the
Oracle inventory gathering in a separate .ndi file.Tip: Notice that the installed FlexNet inventory agent responds to settings in the Inventory Settings page of the web interface, and does not follow the rules or schedules in the Discovery and Inventory Rules page, which are used by inventory beacons. This means that you do not need to set a particular rule to cause the installed FlexNet inventory agent to perform these discovery and inventory-gathering actions, as (subject to its local settings in the Windows registry, or config.ini file on UNIX-like platforms) it always does these, including checking for and collecting Oracle inventory on its local device.
- Immediately on completion of inventory gathering, the tracker uploads the .disco file and one or two compressed .ndi files to the appropriate inventory beacon. If some temporary network problem causes this upload to fail, there is a catch-up task to try again overnight (using the ndupload component).
- 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 page lists the database inventory for all servers discovered and inventoried up to the time of the latest reconciliation calculation.
FlexNet Manager Suite (On-Premises)
2020 R2