Discovery - Oracle CBD & PDBs

[Tim80]

Hello - 

We are having an issue that we are working through with support but I wanted to ask if anyone has run into the same issue as us and if you were able to find a workaround. 

We are trying to discover Oracle CDBs and PDBs and have found that we are only able to capture 1 CDB and their PDBs per host. Apparently this is by design and the pattern only expects to find one set (CDB and PDBs) per host.

But we have more than 1 set of CDB/PDBs per host. Meaning on one server we have CDBDB1, PDBDB1 - CDBDB2, PDBDB2 - CDBDB3, PDBDB3.

Support has suggested that we make an enhancement request but before I do that I wanted to see if anyone has run into this issue. I wasn't able to find an Oracle doc that stated that best practice was to only have one set per host, and would have thought this is common across customers but I am not an Oracle expert.

For reference we have applicative credentials in addition SSH creds to access the servers and can discover them wo issue.

[AdBe]

Hi all, 

the logic for populating the connect_sql table is the following:

1. Identification section "Identification for Oracle DB entry point type(s) - no instance"

a) steps 31-35 collecting connect descriptor (service_name and port) from tnsnames.ora file, with failover scenarios if the tnsnames.ora file is not under the default location (ORA_HOME/network/admin) or has a different structure.

b) shared library "Collect listener info" gathering information for the services associated with the listener via lsnrctl status command

c) step "Filter service names" comparing the results from the tnsnames.ora file and the output from the lsnrctl status command

d) different failover steps

- "Filter to SID if listener is empty" situation where the lsnrctl status output is empty; 

- "Failover if connect sql is empty" taking the net service name from the lsnrctl status populating them into temporary table listener_service in cases if the table connect_sql is empty but have output from the listener status

- "Get alias with tnsping" trying /bin/tnsping command to check if the net service name is persisting somewhere in tnsnames.ora file (remote listener case, this step is triggered rarely).

Now the most essential steps:

1. "Get DB unique name" with the following command:

"export TNS_ADMIN=" + $ora_home_exe + "/network/admin;export ORACLE_HOME=" + $ora_home_exe + "; echo  \"show parameter db_unique_name from v\$database;\" |" + "\"" + $ora_home_exe + "/bin/sqlplus\" -s " + "$$username$$/'$$password$$'@" + $computer_system.primaryHostname + ":" + $connect_sql[1].listener_port + "/" + $connect_sql[1].service_name

trying to obtain the DB_UNIQE name with the connect descriptor already gathered from the steps mentioned above.

2. "Get DB domain" with the following command:

"export TNS_ADMIN=" + $ora_home_exe + "/network/admin;export ORACLE_HOME=" + $ora_home_exe + "; echo  \"show parameter db_domain from v\$parameter;\" |" + "\"" + $ora_home_exe + "/bin/sqlplus\" -s " + "$$username$$/'$$password$$'@" + $computer_system.primaryHostname + ":" + $connect_sql[1].listener_port + "/" + $connect_sql[1].service_name

trying to obtain the DB_DOMAIN name with the connect descriptor already gathered from the steps mentioned above. 

With the values for DB_UNIQE name and DB_DOMAIN in step "Filter service names with DB name" the pattern logic is trying to compare the connect descriptor with these values returned.

=================================================================

Now what are the possible configuration options/scenarios and possible issues:

1. Starting from version 12c to 19c (versions which support CDB/PDB configuration, non-standalone), tnsnames.ora (configuration) file is NOT mandatory anymore.

2. SID is not always exported (to act as connect descriptor such as net service name)

3. The discovery user configured associated with the applicative credentials, don't have permissions to execute lsnrctl status command.

4. The oratab file is not always configured, in order to be used from the pattern for gathering information.

5. The sqlnet.ora file is not always configured in order to be used from the pattern for gathering information.

6. Listener is residing on remote host, but the pattern is trying to obtain information for the current host.

Summing up, those point mentioned above (1-6) what should be the best possible way to obtain connect descriptor information such as net service name and port (the port may also vary, it's not mandatory to be de default one - 1521)? Because without those parameters, it's impossible to remotely connect to a DB. 

I hope these descriptions here helped a bit more, for understanding the Oracle on Unix pattern logic and it's corresponding extension sections. Any recommendations / concerns and guidelines are welcome.

Best regards

Adrian

[Renato Alves]

Good morning gentlemen, still in 2023 I'm having problems with the discoveries in PDBS, in fact I can make the discovery in CDBs, the schemas of the CDBs, I can discover the PDBs, even if there is more than one, I believe that this was already solved some time ago , but I can't discover the schemas that are inside the PDBs. Anyone with this problem? Thanks

[Gaurav3]

Hi, Are you able to discover the PDBs?

Thanks

[pratiksha5]

How you are able to discover the PDB? 

[kenewik]

Nice post.