Extra db calls being made while probes are active or Oracle 10G dbs
We've been testing a rather large applcation code base recently and have doen the with and without probe testing to validate. I'm usually right in that the probes aren't doing anything major extra, but in this case it appears there's something odd going on.
When probes are enabled for a set of JBOSS instances as well as their TOMCAT counterparts which both are connected to ORACE 10G server databases through jdbc we get
SELECT sys_context('USERENV', 'SERVER_HOST'), sys_context('USERENV', 'INSTANCE_NAME') FROM dual
Executed for each and every jdbc execute statement it seems. At PT load levels that equates to nearly 9 million calls in 10 mins and it's consistent with rate of load too. I was guessing maybe something to do with topology or autodiscovery but can't seem to find any indication of this "instance" finder logic that would match anything in any of the config files in use by the probe.
Could this be related to some bytecode injection around one of the jdbc points in a code file?
Under load it basically appears to cause us to use extra cpu then we enter into high cursor pin S wait states then even more cpu spin. Remove the probes and the Oracle server behaves normally and those extra 9 million calls never show up.
They downed the probes before I could turn off the jdbc tracking altogether while testing or I would have done that next.
If there is a way to still have jdbc resource tracking enabled while not forcing this extra lookup that would be the ideal solution however.
I'm definitely open to ideas. We will most likely be opening a case shortly hereafter as well with support.
I always hate it when things are blamed on the probes... but this one is stumping me.
Re: Extra db calls being made while probes are active or Oracle 10G dbs
It will be executed for every new database connection. If the application creates a new database connection for its every jdbc 'execute' statement (which is very inefficient), then the Diagnostics agent will be very inefficient, too.
To disable Diagnostics generated queries, uncomment this line in capture.properties: # db.collection.class.name = com.mercury.opal.capture.FallbackDBCollection