Showing results for 
Show  only  | Search instead for 
Did you mean: 

Manged ODP.NET Provider & Connection Pool monitoring


Our ASP.NET web application consists of SOAP & REST services and uses the Managed ODP.NET driver for Oracle connectivity. The oracle driver uses connection pooling and this feature is enabled by default based on the uniqueness of the connection string.

We recently switched to the managed ODP.NET driver which deploys with application (from Un-managed which relies on Oracle client installed on server) and as part of this change, our connection string has the full connection value that would sit in TNS, for example like so:



DynaTrace does not show a connection pool being used. I looked at the purepaths of the web service calls to the point where database calls are being made, and it shows "Unknown" for database pool type and everything else as blank.

Are there any known issues with the managed ODP.NET driver picking up the connection pool? We're trying to ascertain if this is a monitoring issue or if it is a driver configuration issue.




We have exactly the same issue here at our customer. Recently they changed the driver from unmanaged to managed and from that moment on, no more connection pool metrics.

Also, all SQL statements are registered under "Database" in stead of under a certain SID.


I have created a support ticket for this and want to share the answer here as it is probably valuable for a lot of users.

the managed ODP.NET provider is unfortunately not supported and we also do not have any product idea in our forums yet, so please create one if required.

By the way, dedicated support is only a requirement for the connection pool information, so SQL statements are captured as usual via the standardized ADO.NET API.

As an alternative, can you please try the new agent platform (formally known as OneAgent), since it also has a generic approach implemented, where the connection string is parsed and generic information like server name, etc. tried to be extracted? As far as I know, the ODP.NET provider is using standard key-value pairs therefore, so it should work. For the connection pool timeseries measurements itself, I'm not sure if the new agent platform will also be able to deliver that.

For trying the new agents, see Please let us know the outcome.

I have created an RFE now:

So, you can start voting.