How to clear the ODP.NET connection pool on connection errors?

If you can use odac (odp) 11g, you have setting Validate Connection for your pool. It can validate the connection before you use it.

The Validate Connection attribute validates connections coming out of the pool. This attribute should be used only when absolutely necessary, because it causes a round-trip to the database to validate each connection immediately before it is provided to the application. If invalid connections are uncommon, developers can create their own event handler to retrieve and validate a new connection, rather than using the Validate Connection attribute. This generally provides better performance.

If it will not be good enough - you can try this document from oracle.

Connection Pool Management

ODP.NET connection pool management provides explicit connection pool control to ODP.NET applications. Applications can explicitly clear connections in a connection pool.

Using connection pool management, applications can do the following:

Note: These APIs are not supported in a .NET stored procedure. Clear connections from connection pools using the ClearPool method.

Clear connections in all the connection pools in an application domain, using the ClearAllPools method.

When connections are cleared from a pool, ODP.NET repopulates the pool with new connections that have at least the number of connections set by Min Pool Size in the connection string. New connections do not necessarily mean the pool will have valid connections. For example, if the database server is down when ClearPool or ClearAllPools is called, ODP.NET creates new connections, but these connections are still invalid because they cannot connect to the database, even if the database comes up a later time.

It is recommended that ClearPool and ClearAllPools not be called until the application can create valid connections back to the database. .NET developers can develop code that continuously checks whether or not a valid database connection can be created and calls ClearPool or ClearAllPools once this is true.

Also, may be this post will help you.

Update:As pointed by @MPelletier, for oracle 12 the link is different.

Generally speaking, you should avoid trying to manipulate the connection pool for any ADO.NET provider (and also WCF channels - an aside). If you application needs to be resilient in the face of underlying data errors (e.g. timeouts, broken connections in pool, etc.) then you should implement the appropriate level of transaction to ensure data integrity and retry logic to re-execute the failed operation.