Oracle Database Discovery Failure

venkataramac
Tera Contributor

Hi

I have Oracle Database, which is running on the Server, Post Discovery Verified in the logs that the Detailed info about Database was available in Creating CI step with running processor as well. But it was not inserted into CMDB.

Identification rules:

Name, Class name - Verified in the CMDB there is no existing DB with same name.

2 REPLIES 2

ifti122
Tera Guru

Hi @venkataramac ,

Since Discovery logs showed that detailed information was gathered, but the CI was not inserted, the most likely cause is an issue with Identification and Reconciliation (IRE), specifically the identification rules. While you've checked for existing CIs with the same name, there are other factors that could be preventing the insertion.

 

Troubleshooting Steps

  1. Check the Discovery Log for Errors: The Discovery Status log for the specific scan is the most important place to look. Navigate to Discovery > Discovery Status and open the log for the scan that ran on your Oracle server. Within the log, look for messages related to the Oracle database pattern. It will often contain error messages or warnings explaining why the CI wasn't inserted, such as:

    • "No match found for <CI> in <CI class>": This indicates that the IRE couldn't find a matching CI to update, and for some reason, the pattern's logic to create a new one failed.

    • "Incomplete payload data": This could mean that a required attribute for identification (e.g., a process ID or instance name) was not captured, preventing the CI from being created.

    • Permission Denied: The credentials used for discovery might not have sufficient permissions to run the necessary commands to get all the required information. The log will often show an "access denied" or "permission denied" error.

  2. Verify Oracle Discovery Prerequisites: Ensure all prerequisites for Oracle discovery are met. This includes:

    • Credentials: The ServiceNow Discovery user needs specific permissions on the Oracle server to access listener processes and database files. You may need a dedicated Oracle DBA account for the discovery credentials.

    • Oracle Listener Process: Discovery relies on the Oracle Listener (tnslsnr) process to find running instances. Verify that this process is running on the server.

    • Custom Installations: If Oracle was installed in a non-standard directory, the out-of-the-box discovery patterns may need to be modified to find the correct process names and file paths.

  3. Review the Identification Rule: Even if the name is unique, the identification rule for the cmdb_ci_db_ora_instance or cmdb_ci_oracle_database class might be looking for other attributes that are not being captured. Navigate to Configuration > CI Class Manager and check the identification rules for the relevant Oracle CI class.

    • The rule often uses multiple attributes as a combination to uniquely identify a CI, such as Name, Server, and Instance Name.

    • Make sure all the required attributes in the identification rule are being successfully populated by the discovery pattern. If one is missing, it can prevent the CI from being inserted.

  4. Debug the Discovery Pattern: If the above steps don't reveal the issue, run the Oracle discovery pattern in debug mode. This provides a detailed, step-by-step view of what the pattern is doing, including the commands it runs and the data it receives. This is the most effective way to pinpoint the exact step that is failing. You can identify the Oracle pattern that ran from the Discovery log, then navigate to it in the Pattern Designer and run it in debug mode against your server.

 

Thanks & Regards,
Muhammad Iftikhar
If my response helped, please mark it as the accepted solution so others can benefit as well.

venkataramac
Tera Contributor

Hi @ifti122 ,

 

I verified all the above-mentioned Steps; I don't find any error and there are other Databases which are same as this like xxx01@xx01 , xxx02@xx02, xxx03@xx03. Verified all the steps there are no difference found but only this xxx01@xx01  was not inserted into CMDB.