Using Network Discovery with Direct Inventory

FlexNet Manager Suite 2020 R2 (On-Premises)
In this approach, each inventory beacon takes responsibility for both discovery of the Oracle servers and taking inventory of the database instances on them.
Remember: From Oracle Database 12c onwards, password access direct to the listener to query it for the available instances has been blocked, so that this method of discovery is available only for earlier versions of Oracle Database.
The following diagram shows an example scenario:


The above diagram shows three database servers, two on Subnet1 and one on Subnet2. The Subnet1 is assigned to Inventory Beacon1 and Subnet2 is assigned to Inventory Beacon2. Note that in this diagram, DB1 and DB2 are running versions of Oracle Database compatible with the same OLEDB driver, as discussed in Direct Collection of Oracle Inventory; separately, DB3 may also be compatible, or may require a different version, which may be the reason that it is managed by a separate inventory beacon.

The following description assumes that all the prerequisites listed in Direct Collection of Oracle Inventory have been satisfied, including the installation of an appropriate version of the 32-bit OLEDB driver (one version per inventory beacon) for each target Oracle Database.

  1. It is likely that the Oracle Net Listener(s) on each target Oracle server has/have been configured with a password for administrative use, as when collecting status and the list of known services (as discussed in Direct Collection of Oracle Inventory, which also lists the versions of Oracle Database for which this approach is supported). If so, ensure that the password is recorded in the secure Password Manager on each appropriate inventory beacon. No user name is required when you record the listener password.
  2. On each target Oracle server, set up the special "audit account" for collecting database inventory (see Credentials for Direct Collection of Oracle Inventory).
  3. Record the credentials for the special audit account in the secure Password Manager on each applicable inventory beacon.
  4. Create a rule that combines network discovery with direct inventory. Navigate to Discovery & Inventory > Discovery and Inventory rules and use these settings:
    • Target: Create a target to identify all Oracle servers (up to and including Oracle Database 11g) in your network. You can use subnet name, IP address, or pattern matching on the device name to identify devices in the target definition.
    • Action: Create an action that includes these settings:
      • For Action type, choose Discovery and inventory.
      • In the Discovery of devices section, select Network scan, and ensure that the appropriate ports are listed. These are the ports tested for the existence of the server itself (typically, for example, 22 for a UNIX server and 139 for a Windows server). Customize this list if your environment requires it. The hardware (server) must respond before further discover of Oracle details is attempted.
      • Expand the Oracle database environments section, and select Discover Oracle database environments. In the additional controls for Discovery methods, select Port scan, and if necessary update the list of ports to include all listener ports used in your environment. When each inventory beacon executes this action, it tests each port in turn on each target server, seeking a response from Oracle Net Listener. (Less commonly, if you have SNMP configured on your Oracle servers, you may select the SNMP option as well, or instead.)
      • In the same section, select Gather Oracle database environment inventory. This is the switch to turn on direct inventory gathering for Oracle database instances.
      • Schedule: Specify the running schedule for this rule.

    This completes the initial configuration for network discovery with direct inventory gathering for Oracle. The remainder of these steps cover normal operation.

  5. By default, every 15 minutes each inventory beacon checks for any updates to its policy, which also transfers any changed discovery and inventory rules. (To adjust this download schedule, see Inventory Settings Page > Beacon Settings Section in the online help.) Each inventory beacon exercises only those rules that apply to its assigned subnet(s).
  6. When the related schedule triggers an applicable rule:
    1. The inventory beacon reports to the central application server that the task is commencing. You can navigate to Discovery & Inventory > Discovery and Inventory Rules and click the rule name to view its status. Wait (while the remainder of the process takes place) until the Status field shows Completed. This process may take some time to complete and you may have to revisit or refresh the page from time to time.
    2. The inventory beacon scans each of its assigned subnets, recording every device that responds to probing on the specified device ports. (Each of these discovered devices will be reported to the central application server in the uploaded .disco file, regardless of what else is found on each device.)
    3. The inventory beacon next probes each discovered device for a response on each of the specified listener ports (or, less commonly, collects SNMP data from each discovered device and checks for the presence of Oracle database instances).
    4. From devices where a listener responds, the inventory beacon extracts the list of known Oracle services (database instances).
    All this information is included in the uploaded .disco file. For direct inventory gathering (where the discovery files may be larger than with the locally-installed FlexNet inventory agent), .disco files are compressed for upload.
  7. The FlexNet Beacon engine (on each inventory beacon) uses the discovered services information to connect to each database instance, and collect Oracle Database inventory data. The results are saved into an .ndi inventory file (specific to Oracle inventory only) for each server.
    Tip: Because listeners may know about database instances on several distinct servers, one inventory beacon may return database inventory from multiple servers, and (depending on the configuration of your network and listeners) not necessarily restricted to the subnet(s) assigned to that inventory beacon. The FlexNet Beacon engine uses information retrieved from each database instance to identify the servers, and ensure that it returns one .ndi inventory file per server.
  8. Where Oracle inventory is collected, the FlexNet Beacon engine also executes the software scripts provided by Oracle Global Licensing and Advisory Services (GLAS) to gather software information about the Oracle Database installation. It is important to realize two things:
    • These are the same GLAS scripts, as amended from time to time, that are downloaded to the inventory beacon in the InventorySettings.xml file (which is saved in Program Files (x86)\Flexera Software\Inventory Beacon\Remote Execution\Public\Inventory). As always, they do not contribute to the collection of FlexNet inventory, but are used only for the preparation of an Oracle audit report (available to operators who have appropriate access rights in the Discovery & Inventory > Oracle Instances page, with more details available in the help for that page.)
    • However, the Oracle GLAS scripts include two separate parts: SQL queries to gather information from Oracle database instance(s); and scripts to execute on the target server and gather the required hardware information. With this direct connection method of inventory collection, there is no file transfer of any kind to the target server, so that the GLAS hardware scripts cannot be executed on the Oracle server by this method. In contrast, the GLAS SQL queries are executed during the direct connection to each database instance, and the resulting GLAS software data is uploaded to the central application server; but in the normal course of events, the absence of hardware data is unlikely to satisfy an Oracle audit. Therefore, if your strategy is to use only the direct method of inventory collection, you should also plan another method to execute the GLAS hardware scripts on each Oracle server. Alternatively, reconsider the local installation of either the full FlexNet inventory agent, or the lightweight FlexNet Inventory Scanner; or re-evaluate the Zero-footprint method of inventory collection. All of these methods conveniently collect, upload, and create audit-ready packages for all the software and hardware data required for database licensing by Oracle GLAS, and without additional effort on your part.
  9. Immediately after inventory gathering, the inventory beacon compresses the .ndi file(s) and .disco files, and uploads them 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). It is initially stored in the inventory database.
  10. 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.
  11. 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.

FlexNet Manager Suite (On-Premises)

2020 R2