Tips for Connecting .NET Apps to Oracle Autonomous Database
Last year, I blogged how to connect Azure Web Apps to Oracle Autonomous Database. Many developers have used these instructions to start developing all sorts of .NET Autonomous Database (ADB) apps, not just Azure apps. That has been great to hear!
That’s not to say all attempts to connect to ADB have been smooth. Developers have approached me needing help if they encounter a problem, usually a result of a configuration difference between my tutorial and what the developer is using. In all cases, we’ve been successful connecting when troubleshooting the configuration difference. I’d like to share those findings so that the community can benefit.
Enable Loading User Profiles for Web Apps
If you encounter the error,ORA-00542: Failure during SSL handshake, for an ADB web application, verify you have set the Microsoft Internet Information Services configuration LoadUserProfile setting to “true” (on-premises) or WEBSITE_LOAD_USER_PROFILE setting to “1” (Azure). By default, the value is “false” or “0”. Loading the user profile enables your web app to use the Oracle wallet stored on the file system or on Azure. You need the Oracle wallet credentials for connecting to most ADB instances.
The ORA-00542 error is a generic TLS/SSL error. It could also be a result of other issues. However, not enabling the load of the user profile is the most common reason I’ve seen this error occur.
Enable TLS 1.2 in .NET
Most ADB connections require Transport Layer Security (TLS) 1.2 or higher. If TLS 1.2 is not configured correctly across the stack, you will generally see an ORA-00542 exception with an inner exception indicating “The credentials supplied to the package were not recognized.”
ADB supports TLS 1.2. ODP.NET 12.2 and higher supports TLS 1.2. But what about .NET Framework and .NET Core?
As of this writing, the lowest .NET Core version currently supported is 2.1. .NET Core 2.1 supports TLS 1.2. So, this won’t be a problem on .NET Core no matter the supported version you use.
On .NET Framework, the version you use may require additional configuration to enable TLS 1.2. Microsoft recommends .NET Framework 4.7 or higher. If you use a lower .NET Framework version, additional configuration is generally required. Microsoft provides instructions on configuring TLS in .NET Framework.
Use the Newest ODP.NET Release
As a general matter, the ODP.NET dev team fixes bugs with every major and minor release. I recommend using the newest ODP.NET version you can when connecting to ADB. The newest version will always work with ADB and have the latest patches applied. You can download the newest versions from NuGet Gallery (managed ODP.NET and ODP.NET Core) or My Oracle Support (unmanaged ODP.NET).
Azure Web Apps Drops Idle TCP Connections
A different connection problem type is Azure connections are severed when idle for more than four minutes. Azure Web Apps will drop these ADB connections resulting in an error, such as ORA-12570: Network Session: Unexpected packet read error. This problem isn’t specific to ADB. It occurs with any database using Azure Load Balancer.
From the Azure documentation:
In its default configuration, Azure Load Balancer has an idle timeout setting of 4 minutes. If a period of inactivity is longer than the timeout value, there’s no guarantee that the TCP or HTTP session is maintained between the client and your cloud service.
There are two ways to prevent connections from being severed.
- Either increase the default idle timeout setting, IdleTimeoutInMinutes, on the Azure Load Balancer.
- Or set the ODP.NET KeepAlive properties (KeepAlive, KeepAliveInterval, and KeepAliveTime) to periodically send a probe packet with no data to reset the load balancer’s idle timeout.
Either method will prevent the load balancer from severing your idle database connections prematurely.
Conclusion
These were some of the common ADB ODP.NET connectivity issues I’ve seen customers encounter and the methods to resolve them. Hopefully, it has helped you get connected and working with ADB.
