Although the oracle probe install is fine, setup is ok, and alarms and QoS are being generated correctly, they do not seem to be correlated under their corresponding robot.
In Infrastructure Manager we see the alarms incoming.
Also, in USM the Robot looks good with data from other probes.
However, when checking the robot, we can't see any oracle related Qos/alarm.
This happened only for one Robot using the Oracle probe but not for others.
In DrNimbus we can see that Oracle data for this robot is flowing and identified its dev_id, finishing on “C0185”.
However, to compare it, we also checked the “dev_id” from other probes and they have different dev_ids.
So we searched for it on cm_device table:
select * from cm_device where dev_id like '%0185'
and found a dev_name of ".82.5.180"
Checking again the device on cm_computer_system
select * from cm_computer_system
where name like '%.82.5.180%'
Indeed its there but with another name!
Checking in USM again for that Name and yes, the alarms and QoS are being received as Name “.82.1.180”.
After comparing tnsnames.ora from a working Server with the one from the failing, customer noticed a space between the connection string and the equal sign in tnsnames.ora.
This is the way the listener was configured:
eseatmauv00063|root|/~) cat /apps/oracle/orabin/product/12.1.0/dbhome_1/network/admin/tnsnames.ora
After deleting the blank after "LISTENER_HYPERION" and resetting dev_id / discovery, the oracle probe started to send the correct dev_id.