- descriptionOfIssue: We upgraded from Azure Data Factory Linked Service Oracle v1 to Oracle v2 due to v1 deprecating on 3/31/2026. We are seeing intermittent ORA-12650: No common encryption or data integrity algorithm errors. If we retry the pipeline, it

Hi @rajesh kumar
Thanks for the details.

The error ORA-12650 usually means there is a mismatch in encryption settings between ADF (Oracle v2 connector) and the Oracle DB.

Since your pipelines work on retry, this is most likely happening because different SHIR nodes are behaving differently.

What to check:

1. Make sure all 3 SHIR nodes have the same Oracle client configuration (especially sqlnet.ora)
2. Restart SHIR service on all nodes once after verifying
3. Try running with one node at a time to see if a specific node is causing the issue

Why this happens:

Oracle v2 uses updated drivers, so encryption negotiation is stricter. If one node has slightly different settings, it can fail intermittently.

I hope this helps. let me know if you have any questions.

Intermittent ORA-12650 after upgrading to the Oracle linked service v2 is caused by a mismatch between the client‑side encryption/integrity settings introduced in v2 and the Oracle server’s SQLNET encryption configuration. With multiple SHIR nodes, some connections can negotiate a common algorithm while others fail, which explains the intermittent behavior and why retries eventually succeed.

To stabilize connectivity, align the Oracle server and ADF v2 client settings so that a common algorithm is always available:

1. Verify and adjust Oracle server SQLNET settings On each Oracle source server, review:
   • SQLNET.ENCRYPTION_SERVER
   • SQLNET.CRYPTO_CHECKSUM_SERVER
   • SQLNET.ENCRYPTION_TYPES_SERVER
   • SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER
   Ensure the server is configured with secure algorithms that are compatible with the v2 client. At minimum, add the following to the server if not already present:
   • For SQLNET.ENCRYPTION_TYPES_SERVER:
     • AES256
     • AES192
     • 3DES168
     • AES128
     • 3DES112
     • DES
   • For SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER:
     • SHA256
     • SHA384
     • SHA512 (for Oracle 19c or higher)
   This ensures the server can negotiate with the secure algorithms used by the ADF v2 connector and OpenSSL 3.0.
2. Configure the ADF Oracle v2 linked service encryption properties In the Oracle v2 linked service (used by all three SHIR nodes), explicitly set the client‑side properties so they can always find a common algorithm with the server:
   • encryptionClient: choose based on server policy and negotiation matrix. Common options:
     • required if the server is configured to accept/request/require encryption.
     • accepted or requested if the server may not always require encryption.
   • encryptionTypesClient: include all supported algorithms so at least one overlaps with the server, for example:
     • (AES128, AES192, AES256, 3DES112, 3DES168)
   • cryptoChecksumClient: set to accepted, requested, or required to match server behavior.
   • cryptoChecksumTypesClient: include all supported algorithms, for example:
     • (SHA1, SHA256, SHA384, SHA512)
   These settings widen the negotiation space and remove intermittent “no common algorithm” failures across SHIR nodes.
3. Use the negotiation matrix to validate behavior The effective behavior is determined by the combination of client and server settings. For each of encryptionClient and cryptoChecksumClient, confirm that the client/server combination does not fall into a “Connection fails” cell in the negotiation table:

   	Client\Server	rejected	accepted	requested	required
   	rejected	OFF	OFF	OFF	Connection fails
   	accepted	OFF	OFF	ON	ON
   	requested	OFF	ON	ON	ON
   	required	Connection fails	ON	ON	ON

   For example, if the server is required and the client is rejected, the connection will always fail. Intermittent failures can occur if different SHIR nodes or Oracle listeners use slightly different settings or if some servers lack certain algorithms.
4. Ensure all SHIR nodes are consistent
   • Confirm all three SHIR nodes use the same linked service configuration (including encryption properties).
   • Confirm all nodes are on the same version (already 5.58.9395.1) and have identical OS/OpenSSL configuration.
5. If still intermittent, broaden client algorithms further If some Oracle servers are older or inconsistently configured, keep the client as permissive as security policy allows:
   • encryptionClient = requested
   • cryptoChecksumClient = requested
   • encryptionTypesClient = (AES128, AES192, AES256, 3DES112, 3DES168)
   • cryptoChecksumTypesClient = (SHA1, SHA256, SHA384, SHA512)
   Then gradually tighten server and client policies once stable connectivity is confirmed.

These changes remove the intermittent ORA‑12650 by guaranteeing that every connection attempt from any SHIR node can negotiate at least one common encryption and checksum algorithm with the Oracle server.

References:

• Troubleshoot the Oracle connector in Azure Data Factory and Azure Synapse
• Copy data from and to Oracle by using Azure Data Factory or Azure Synapse Analytics