ADF Oracle connector V2.0 - ORA-50000: Connection request timed out

Question

ADF Oracle connector V2.0 - ORA-50000: Connection request timed out

sunil gupta 6

While using Oracle Connector V2 in Azure Data Factory (ADF), we experienced recurring failures in opening and closing connections, resulting in error messages such as:

ErrorCode=OracleConnectionOpenError, Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException, Message=Failed to open the Oracle database connection., Source=Microsoft.DataTransfer.Connectors.OracleV2Core, Type=Oracle.ManagedDataAccess.Client.OracleException, Message=ORA-50000: Connection request timed out, Source=Oracle Data Provider for .NET, Managed Driver

And

Error: Data Provider for .NET, Managed Driver,''Type=OracleInternal.Network.NetworkException,Message=ORA-12570: TNS:packet reader failure. https://docs.oracle.com/error-help/db/ora-12570/,Source=Oracle.ManagedDataAccess,''Type=OracleInter… TNS:packet reader failure. https://docs.oracle.com/error-help/db/ora-12570/,Source=Oracle.ManagedDataAccess,''Type=System.Net.… connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond,Source=Oracle.ManagedDataAccess,'

It was working fine with Oracle EBS V1 connector from last couple of years. Tried with new IR upgrade but issue didn't resolve.

Anyone suggest if facing similar kind of issue?

Natheem Yousuf 345 Reputation points

2025-11-17T08:24:32.12+00:00
Hi sunil gupta

This usually points to either the Oracle managed driver / pooling behavior or an intermittent network/firewall drop between the Integration Runtime and the DB. Try these focused fixes (short checklist):

Increase/adjust Oracle client timeouts and pooling behaviour (make the connector wait longer for new connections and avoid reused dead pooled connections): set a larger connection timeout and enable connection validation (for ODP.NET use Validate Connection=true or add a larger Connection Timeout / Incr Pool Size tuning). Many folks resolved ORA-50000 by giving the managed driver more time and validating connections. Stack Overflow

Reduce concurrency / pool pressure on the DB from ADF (lower max pool size, reduce parallel copy concurrency or batch jobs) so you don’t exhaust available sessions — V2 has different pooling behaviour vs V1. Microsoft Learn

Check network path / firewall / load-balancer timeouts and any packet inspection devices — ORA-12570 (packet reader failure) is commonly caused by network drops, intermediate devices, or MTU issues. Run tnsping, tcpdumps or enable SQL*Net client tracing to capture the failure window. asktom.oracle.com

Upgrade or pin the Oracle ManagedDataAccess driver to a known-good version (some ODP.NET Core releases showed async / pooling-related ORA-50000 bugs); test with the same driver locally to reproduce. GitHub

Turn on ADF / Self-Hosted IR diagnostics (integration runtime logs, copy activity logs) and capture the exact timestamps — correlate with DB listener logs to see if the DB closed the socket or the network dropped it. If nothing shows, open an Azure support ticket with logs. Microsoft Learn

If you want, share which IR you’re using (Self-hosted or Azure-hosted/Managed VNet), the Oracle DB version, and your connector connection string (redact creds) — I’ll suggest the exact connection-string knobs and concurrency numbers to try.

Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.
JuliaMarvin 19,050 Reputation points Volunteer Moderator

2025-11-17T08:44:47.65+00:00

Moderator note

@Natheem Yousuf

Your willingness to help in Microsoft Q&A is appreciated, however please refrain from simply copying and pasting AI generated content.

Users are capable of asking copilot or other AI services themselves, most ask here because they want help from a real person with some experience.

Please read https://learn.microsoft.com/en-us/answers/support/ai-usage-policy

as well as https://learn.microsoft.com/en-us/answers/support/code-of-conduct
Manoj Kumar Boyini 12,815 Reputation points Microsoft External Staff Moderator

2025-11-28T13:03:11.2066667+00:00

Hi sunil gupta,

Just checking if you get a chance to see my previous response, please let me know if you have any further queries.
sunil gupta 6 Reputation points

2025-11-28T14:05:32.22+00:00

Hi Manoj, Thanks for sharing all research.

We tried all four properties as suggested below but thats not solve the issue, as it reoccur with no consistency.

"supportV1DataTypes": true, "enableBulkLoad": false, "statementCacheSize": 50, "fetchSize": 1048576

Another thread, for concurrency adjustment, we have 100+ pipelines and several are using copy activity with business purpose. Therefore changes of concurrency & parallel operations seems to be a massive development & testing efforts.

We raise a ticket with Microsoft as well and they suggest couple of changes in Oracle side tnsname.ora files. (CONNECT_TIMEOUT and TRANSPORT_CONNECT_TIMEOUT from the sqlnet.ora file).

Network trace also fine as verified with network team.

Looking forward any response if that can set uniformly at config level which previously worked with V1 connector.

Regards

Sunil
Manoj Kumar Boyini 12,815 Reputation points Microsoft External Staff Moderator

2025-11-28T15:24:54.2666667+00:00

Hi sunil gupta,

Thanks for the update. Since you've already opened a Microsoft support ticket and they recommended updating the Oracle-side sqlnet.ora / tnsnames.ora settings (CONNECT_TIMEOUT and TRANSPORT_CONNECT_TIMEOUT), that aligns with what we typically see with the Oracle V2 connector.

V2 performs stricter connection validation compared to V1, so any low timeout values on the Oracle listener side can cause intermittent ORA-50000 and ORA-12570, even when the network trace looks clean. This is why V1 worked consistently, but V2 exposes the issue.

The advantage of applying the Oracle-side timeout configuration is that it becomes a central fix and avoids modifying 100+ ADF pipelines.

Once your Oracle team updates those timeout values, the V2 connector usually stabilizes without requiring concurrency changes in ADF.

If the problem still continues after applying the recommended settings, please share: – the updated timeout values in sqlnet.ora the latest failure timestamp

I can cross-check them with known Oracle V2 behavior and help you further.

2 answers

Your answer

JuliaMarvin 19,050 Reputation points Volunteer Moderator

2025-11-17T08:44:47.65+00:00

Moderator note

@Natheem Yousuf

Your willingness to help in Microsoft Q&A is appreciated, however please refrain from simply copying and pasting AI generated content.

Users are capable of asking copilot or other AI services themselves, most ask here because they want help from a real person with some experience.

Please read https://learn.microsoft.com/en-us/answers/support/ai-usage-policy

as well as https://learn.microsoft.com/en-us/answers/support/code-of-conduct
Manoj Kumar Boyini 12,815 Reputation points Microsoft External Staff Moderator

2025-11-28T13:03:11.2066667+00:00

Hi sunil gupta,

Just checking if you get a chance to see my previous response, please let me know if you have any further queries.
sunil gupta 6 Reputation points

2025-11-28T14:05:32.22+00:00

Hi Manoj, Thanks for sharing all research.

We tried all four properties as suggested below but thats not solve the issue, as it reoccur with no consistency.

"supportV1DataTypes": true, "enableBulkLoad": false, "statementCacheSize": 50, "fetchSize": 1048576

Another thread, for concurrency adjustment, we have 100+ pipelines and several are using copy activity with business purpose. Therefore changes of concurrency & parallel operations seems to be a massive development & testing efforts.

We raise a ticket with Microsoft as well and they suggest couple of changes in Oracle side tnsname.ora files. (CONNECT_TIMEOUT and TRANSPORT_CONNECT_TIMEOUT from the sqlnet.ora file).

Network trace also fine as verified with network team.

Looking forward any response if that can set uniformly at config level which previously worked with V1 connector.

Regards

Sunil
Manoj Kumar Boyini 12,815 Reputation points Microsoft External Staff Moderator

2025-11-28T15:24:54.2666667+00:00

Hi sunil gupta,

Thanks for the update. Since you've already opened a Microsoft support ticket and they recommended updating the Oracle-side sqlnet.ora / tnsnames.ora settings (CONNECT_TIMEOUT and TRANSPORT_CONNECT_TIMEOUT), that aligns with what we typically see with the Oracle V2 connector.

V2 performs stricter connection validation compared to V1, so any low timeout values on the Oracle listener side can cause intermittent ORA-50000 and ORA-12570, even when the network trace looks clean. This is why V1 worked consistently, but V2 exposes the issue.

The advantage of applying the Oracle-side timeout configuration is that it becomes a central fix and avoids modifying 100+ ADF pipelines.

Once your Oracle team updates those timeout values, the V2 connector usually stabilizes without requiring concurrency changes in ADF.

If the problem still continues after applying the recommended settings, please share: – the updated timeout values in sqlnet.ora the latest failure timestamp

I can cross-check them with known Oracle V2 behavior and help you further.

Answer 1

Hello @Natheem Yousuf ,

I am using ADF + SHIR (5.60.9438.1 - latest IR)+ Oracle DB version 19.0.0.0.0 + EBS connector 2.0.

I also increase the connectiontimeout property to 180, however it didn't work.

The Oracle Linked Service in ADF always relies on Microsoft’s Oracle ODBC/ADO.NET provider and does not use the Oracle ODP.NET driver. Therefore, ODP.NET-specific capabilities are not supported in ADF. ODP.NET is typically configured through app.config or web.config files in .NET applications.

We observe if we switch back to EBS 1.0 Connector, then connection work fine. really strange.

Linked service-

{

"name": "LinkSvc",

"type": "Microsoft.DataFactory/factories/linkedservices",

"properties": {

    "annotations": [],

    "type": "Oracle",

    "version": "2.0",

    "typeProperties": {

        "server": "ServerName:Port/ServiceId",

        "connectionTimeout": 180,

        "authenticationType": "Basic",

        "username": "<UserName>",

        "password": {

            "type": "AzureKeyVaultSecret",

            "store": {

                "referenceName": "LinkSvcKeyv",

                "type": "LinkedServiceReference"

            },

            "secretName": "oracleEBSConnStringPass",

            "secretVersion": ""

        },

    },

    "connectVia": {

        "referenceName": "Password",

        "type": "IntegrationRuntimeReference"

    }

}

}

Natheem Yousuf 345 Reputation points

2025-11-17T09:18:39.7766667+00:00

Thanks for the update. It is helpful to see what made the V2 connector work in your setup.

Answer 2

Hi sunil gupta,

Thanks for the details. This behavior is specific to the Oracle v2 connector. Even with the same SHIR and the same Oracle 19c system, v2 opens and validates connections differently than v1, which can surface as:

ORA-50000 (connection pool timeout)

ORA-12570 (packet reader failure due to dropped/slow network reads)

To stabilize v2, a few tuning properties that align its behavior closer to v1 usually help.

Update linked service with these V2 properties:

"typeProperties": {
  "server": "ServerName:Port/ServiceId",
  "connectionTimeout": 180,
  "authenticationType": "Basic",
  "username": "<UserName>",
  "password": { ... },

  "supportV1DataTypes": true,
  "enableBulkLoad": false,
  "statementCacheSize": 50,
  "fetchSize": 1048576
}

These settings reduce connection pressure, avoid unnecessary bulk sessions, and improve stability with EBS workloads.

Lower ADF Concurrency:

Set parallel copies = 1
Set max concurrent connections = 2–3

Quick network check for ORA-12570
From the SHIR machine:

tnsping ServerName

ping -M do -s 1472 ServerName

If packet loss occurs, a firewall/inspection device may be closing the connection.

Please let us know if you have any questions and concerns.

Share via

ADF Oracle connector V2.0 - ORA-50000: Connection request timed out

2 answers

Your answer