Problème d'extrêmes lenteurs avec le service lié ADF Oracle V2 pour les CLOB.

Question

Problème d'extrêmes lenteurs avec le service lié ADF Oracle V2 pour les CLOB.

Emmanuel Convers 0

Bonjour,

J'utilise Azure Data Factory pour récupérer des données dans Oracle.

Avec le service lié Oracle V1, tout va bien, mais il va disparaitre et il faut donc migrer en V2. Sauf qu'en V2, toutes mes tables Oracle qui contiennent des champs de type CLOB mettent beaucoup plus de temps à être récupérées. Pour les plus grosses, on peut passer de 2h à plus de 12h...

Je viens de mettre à jour le runtime d'integration microsoft pour la dernière version 5.57.9350.2 mais le problème reste le même.

Ces champs me sont utiles donc je ne peux pas simplement les ignorer.

Avez-vous déjà rencontré ce problème et avez-vous trouvé une solution ?

Merci d'avance.

Anonyme

2025-09-15T06:33:46.67+00:00
Hi @Emmanuel Convers

Thank you for reaching out to Microsoft QA.

To assist you further with troubleshooting, could you kindly provide the following details:

Are you still experiencing the issue mentioned above?

If yes, please share all relevant error messages encountered during the migration activity

Additionally, we kindly request you to elaborate on the issue above with more clarity and detail to help us assist you more effectively.

Thanks,
Vrishabh
Anonyme

2025-09-16T07:02:35.79+00:00

Hi @Emmanuel Convers

Do you have any updates on the above requested details.

Thanks,
Vrishabh
Emmanuel Convers 0 Points de réputation

2025-09-16T07:59:15.5033333+00:00

Bonjour Vrishabh,

Merci pour ton retour.

Le problème est toujours d'actualité. Je voulais faire un jeu de tests pour avoir des données précises mais je n'ai pas eu le temps. Du coup je vais le décrire plus précisément maintenant :

Nous récupérons des données de tables Oracles pour en faire des fichiers parquets que l'on dépose sur un storage Azure à travers Azure Data Factory.

Pour le moment, nous utilisons un service lié Oracle 1.0 à travers un runtime integration basé sur un set de 4 VM et nos performances sont correctes.

Cependant, il est recommandé de passer en Oracle 2.0 car 1.0 va disparaitre. Nous avons donc tenté la migration. Pour la plupart des tables Oracle, nous ne rencontrons pas de problème. Par contre, pour les tables Oracle qui ont un champ de type CLOB, les performances chutent complètement en 2.0.

Imaginons que nous prenons une table avec un champ EXAMPLE_ID et un champ EXAMPLE_CLOB, en v1.0, le débit de copie va être de 30Mo par seconde, alors qu'en v2.0 il est de moins de 1Mo par seconde.

En revanche si l'on prend une table avec un champ EXAMPLE_ID et un champ EXAMPLE_STRING, que ce soit en v1.0 ou en v2.0, le débit est bon et d'environ 30Mo/seconde.

C'est très problématique pour nous car nous ne pouvons pas convertir les CLOB en STRING car ils peuvent être très grands et donc seraient tronqués. Et ces champs sont des données dont nous avons besoin.

Est-ce que ce problème a déjà été remonté et est-ce qu'il y a déjà des gens qui travaillent dessus pour le corriger ? Car c'est une vraie régression entre le connecteur 1.0 et le 2.0.

Merci d'avance pour votre réponse.

Emmanuel Convers
Anonyme

2025-09-17T14:03:02.4333333+00:00

Hi @Emmanuel Convers

Just checking if the steps and reference documents provided above were helpful in addressing your query, or if you need any further assistance.

Thanks,
Vrishabh
Anonyme

2025-09-18T12:51:19.6733333+00:00

Hi @Emmanuel Convers

Just checking in on my earlier response—did the solution work out for you, or do you need any further assistance.

Thanks,
Vrishabh

2 réponses

Votre réponse

Anonyme

2025-09-15T06:33:46.67+00:00

Hi @Emmanuel Convers

Thank you for reaching out to Microsoft QA.

To assist you further with troubleshooting, could you kindly provide the following details:

Are you still experiencing the issue mentioned above?

If yes, please share all relevant error messages encountered during the migration activity

Additionally, we kindly request you to elaborate on the issue above with more clarity and detail to help us assist you more effectively.

Thanks,
Vrishabh
Anonyme

2025-09-16T07:02:35.79+00:00

Hi @Emmanuel Convers

Do you have any updates on the above requested details.

Thanks,
Vrishabh
Emmanuel Convers 0 Points de réputation

2025-09-16T07:59:15.5033333+00:00

Bonjour Vrishabh,

Merci pour ton retour.

Le problème est toujours d'actualité. Je voulais faire un jeu de tests pour avoir des données précises mais je n'ai pas eu le temps. Du coup je vais le décrire plus précisément maintenant :

Nous récupérons des données de tables Oracles pour en faire des fichiers parquets que l'on dépose sur un storage Azure à travers Azure Data Factory.

Pour le moment, nous utilisons un service lié Oracle 1.0 à travers un runtime integration basé sur un set de 4 VM et nos performances sont correctes.

Cependant, il est recommandé de passer en Oracle 2.0 car 1.0 va disparaitre. Nous avons donc tenté la migration. Pour la plupart des tables Oracle, nous ne rencontrons pas de problème. Par contre, pour les tables Oracle qui ont un champ de type CLOB, les performances chutent complètement en 2.0.

Imaginons que nous prenons une table avec un champ EXAMPLE_ID et un champ EXAMPLE_CLOB, en v1.0, le débit de copie va être de 30Mo par seconde, alors qu'en v2.0 il est de moins de 1Mo par seconde.

En revanche si l'on prend une table avec un champ EXAMPLE_ID et un champ EXAMPLE_STRING, que ce soit en v1.0 ou en v2.0, le débit est bon et d'environ 30Mo/seconde.

C'est très problématique pour nous car nous ne pouvons pas convertir les CLOB en STRING car ils peuvent être très grands et donc seraient tronqués. Et ces champs sont des données dont nous avons besoin.

Est-ce que ce problème a déjà été remonté et est-ce qu'il y a déjà des gens qui travaillent dessus pour le corriger ? Car c'est une vraie régression entre le connecteur 1.0 et le 2.0.

Merci d'avance pour votre réponse.

Emmanuel Convers
Anonyme

2025-09-17T14:03:02.4333333+00:00

Hi @Emmanuel Convers

Just checking if the steps and reference documents provided above were helpful in addressing your query, or if you need any further assistance.

Thanks,
Vrishabh
Anonyme

2025-09-18T12:51:19.6733333+00:00

Hi @Emmanuel Convers

Just checking in on my earlier response—did the solution work out for you, or do you need any further assistance.

Thanks,
Vrishabh

Answer 1

Emmanuel Convers 0

Bonjour,

J'ai pris connaissance de la réponse merci.

Malheureusement, soit ce sont des choses déjà en place chez nous (TLS 1.3, Staging, ...), soit ce sont des solutions qui ne marchent pas dans notre cas (CLOB de plus de 4000 caractères).

Je vais vérifier le paramètre supplémentaire de fetch size pour les lob mais je n'ai pas encore eu le temps.

J'espère surtout qu'il y aura un fix de la part de Microsoft avant la fin du support de la v1.0...

Anonyme

2025-09-19T15:00:43.1566667+00:00

Salut @Anonymous

Merci de partager les détails. En ce qui concerne vos commentaires supplémentaires, nous nous coordonnerons avec l'équipe produit et vous tiendrons au courant.

Merci
Vrishabh

Answer 2

Hi @Emmanuel Convers

Thank you for providing additional details. Your patience and understanding are truly appreciated.

Here's a clear, step-by-step analysis and resolution plan based on the latest documentation, community feedback, and system updates.

Confirm Runtime Environment Compatibility

Oracle Connector v2.0 requires TLS 1.3, which is only supported on Windows Server 2022 or Windows 11.
Ensure your SHIR VMs are running a TLS 1.3–capable OS.
If TLS 1.3 is not listed under protocols, you may need to enable it via registry edits. [How to get...rosoft Q&A]

Optimize CLOB Handling

CLOB fields are known to cause performance degradation due to their size and streaming behavior.
Oracle Connector v2.0 introduces stricter parsing and mapping logic, which may affect how CLOBs are processed. [Azure Data...rosoft Q&A]
Avoid SELECT statements with semicolons and ensure proper parameterization in queries.

Use Staging Techniques

Instead of direct copy, use a staging table or intermediate format (e.g., CSV or Avro) before converting to Parquet.
This can reduce transformation overhead and improve throughput.

Use Custom Query with SUBSTR

If data size permits, use Oracle SQL DBMS_LOB.SUBSTR function to retrieve chunks of CLOB as strings.
Example SQL query in ADF Copy Activity source:

SELECT EXAMPLE_ID, DBMS_LOB.SUBSTR(EXAMPLE_CLOB, 4000, 1) AS EXAMPLE_CLOB_PART FROM EXAMPLE_TABLE

Note: This will read the first 4000 characters. You can split the CLOB into multiple parts by running multiple copy activities with different offsets.

Tune Integration Runtime Settings

Increase batch size and parallel copy threads in the Copy Activity settings.
Use compression where possible to reduce payload size.

Latest Updates & Known Issues

Release Notes show multiple bug fixes and enhancements to Parquet and ORC formats, but no direct fix for CLOB performance yet. [Release Notes (10)]
The issue is acknowledged by Microsoft staff and is under review, but no ETA for a fix is available. [Azure Data...rosoft Q&A]

For mitigation workaround:

Use staged export (Data Pump or external table).
Use DBMS_LOB.SUBSTR to split large CLOBs into manageable strings if feasible.
Continue using v1.0 for CLOB-heavy tables until October 31, 2025, if feasible.
For v2.0:
- Use staging and transformation strategies.
  - Confirm TLS 1.3 support.

Thanks,
Vrishabh