Using tnsnames Discovery with Direct Inventory

FlexNet Manager Suite 2023 R2 (On-Premises)

In this approach, the direct inventory part of the process is unchanged, but there is a different method to discover the Oracle database instances from which to gather inventory. This approach uses the content of a tnsnames.ora file to identify the target instances.

This Oracle-standard file can be created in any of three ways:

• You can copy it from your Oracle server and save it to the folder (identified below) on the inventory beacon where it will automatically be actioned.
• You can use the OEM adapter to create an tnsnames.ora file in the standard format, and save it to the correct folder on the appropriate inventory beacon that will perform the direct inventory collection. The OEM adapter is documented in FlexNet Manager Suite Inventory Adapters and Connectors Reference.
• You could create one manually (although this would represent a considerable maintenance burden, and is not a recommended path).

The following diagram shows an example scenario of the most interesting case, using the OEM adapter. If you are intervening manually, be sure to place your copy of the tnsnames.ora file in the correct folder as described below.

The above diagram shows Subnet 1 and Subnet 2. Subnet 1 is assigned to Inventory Beacon 1 and Subnet 2 is assigned to Inventory Beacon 2. Each subnet contains:

• Two Oracle Database servers
• Oracle Enterprise Manager
• The OEM adapter (from Flexera), which may be co-located with Oracle Enterprise Manager or installed in another convenient location with fast network access to its related installation of Oracle Enterprise Manager (there is a 1:1 relationship, with one adapter required for each instance of Oracle Enterprise Manager).

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; similarly, DB3 and DB4 are running versions using the same OLEDB driver, although this may be a different driver than used in Subnet 1, since this subnet is already 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. On each target Oracle server, set up the special "audit account" for collecting database inventory (see Credentials for Direct Collection of Oracle Inventory).
2. Record the credentials for the special audit account in the secure Password Manager on each applicable inventory beacon.
3. Create a rule that combines the use of tnsnames.ora for 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 in your network. You can use subnet name, IP address, or pattern matching on the device name to identify devices in the target definition.
     Tip: The limitation on remote administration of the Oracle listener, disallowed from Oracle Database 12c, is not relevant when you are using discovery through tnsnames.ora. No administrative password for the listener is required with this discovery method.
   • Action: Create an action that includes these settings:
     • For Action type, choose Discovery and inventory.
     • In the Discovery of devices section, select TNSNames file for Oracle databases (only).
     • Expand the Oracle database environments section, and ensure that Discover Oracle database environments is clear (not selected).
     • 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 using tnsnames.ora for discovery with direct inventory gathering for Oracle. The remainder of these steps cover normal operation.

4. Each instance of the OEM adapter connects to its Oracle Enterprise Manager, and collects the connection information for all Oracle Database servers managed by that instance of Oracle Enterprise Manager.
5. The OEM adapter formats the information into a tnsnames.ora file.
6. The OEM adapter connects to the inventory beacon it has registered, and saves the tnsnames.ora file in the special path %CommonAppData%\Flexera Software\Repository\TNSNames (on stand-alone inventory beacons; but if the inventory beacon is co-located on your batch server, the path becomes $(CommonAppDataFolder)\Flexera Software\Warehouse\Repository\TNSNames\).
   Tip: If you are copying a tnsnames.ora file from your Oracle server, be sure to save it to this same path on your inventory beacon: %CommonAppData%\Flexera Software\Repository\TNSNames. Every .ora file in this folder is automatically used for targeting for direct inventory collection from the Oracle database instances that it identifies. This means that you can even mix files generated by the OEM adapter (always named tnsnames.ora) with files copied from another Oracle server, or one you have created manually. In these latter cases, be sure to rename the files you place manually (for example, manualtnsnames.ora or tnsnamesServer33.ora), because the next run of the OEM adapter overwrites the tnsnames.ora file in the TNSNames repository.
7. 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).
8. 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 opens each .ora file it finds in %CommonAppData%\Flexera Software\Repository\TNSNames, and converts each database instance there to a discovered device record. Each identified database instance is then tested against the current scope of the inventory beacon, where 'scope' means the intersection of its assigned subnet and the target declared as part of the rule it is currently running. Database instances that are both within the assigned subnet and within the current target are added to an xxxx(InScope).disco file. Database instances that fail either of these tests are added to an xxxx(OutScope).disco file.
   All this information is included in the two .disco files when they are uploaded to the central application server. 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.
9. 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.
10. 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.
11. 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.
12. 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.
13. 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.