I’ve touched on this issue before over at my previous blog and also talked about it at UKOUG Tech13. The presentation at Tech13 was more than 90% demos so hasn’t left a lasting record of the issue and the previous blog post doesn’t go into significant detail. I think it is worth highlighting what I see as a potentially very significant issue when configuring Oracle’s Universal Connection Pool (UCP) for Fast Connection Failover (FCF).
I’ll cut straight to the chase: If you use Thin-style Service Name Syntax (aka Easy Connect) in the URL for UCP when using FCF then you are leaving yourself open to wondering why your connection pool has not opened any connections on the instance that you just started the service it uses on. If you have enabled logging for UCP (11.2) then you would find yourself looking at the following:
oracle.ucp.jdbc.oracle.OracleDatabaseInstanceInfoList.getConnectionToNamedInstance URL invalid for connecting to named instance
The scenario in which you encounter this is specific: A service is started on an instance that didn’t offer the service at the time the connection pool was established.
A few examples of when this can happen are:
- You have a service that is defined as preferred on some instances and available on others then one of the instances where the service is preferred dies and it starts on an available instance.
- You have a service that is preferred on an instance, but that instance is not up and therefore not offering the service at the time the application connection pool is established.
- You have a service that has failed over to an available instance at the time the application connection pool is established and you then want to move the service from an available instance to a preferred instance without forcing a disconnect.
Returning to the error message “URL invalid for connecting to named instance” and considering the full syntax for Easy Connect, specifically the option to include the “instance_name”, this seems like a JDBC bug (as I think I recall Tim Hopkins suggesting).
So what’s the answer? Simply ensure that your clients use an Oracle Net connection descriptor. In case it needs stating: there is no problem with using the SCAN in the Oracle Net connection descriptor. I currently believe that using LDAP or TNS entries will also work fine as they ultimately result in the client having an Oracle Net connection descriptor, but I haven’t found the time to test them yet.
Anyway, I live in a world where restarting your application or relying on inactiveConnectionTimeout in order to establish connections to all instances that offer the relevant service would not be seen as acceptable, and rightly so. We have the technology available to allow us to move database services around without the application feeling it. You just need to make sure you have everything set up exactly how it needs to be.
It’s worth mentioning that Martin Bach recently published a post on Application Continuity where he also encountered a problem using the Thin-style Service Name Syntax.