Discussion :

[DevNico]

Bonjour,

Une petite interrogation qui m'est venue alors que je testais les performances d'un tOracleInput selon son paramétrage :

D'après ce que j'ai compris, l'option 'Use Cursor' permet de positionner la valeur du fetchsize lors de la récupération des donnée venant d'un select. Elle améliore fortement les perfs de récupération des données lorsque le traitement talend accède à une base de données distante.

C'est l'équivalent de l'option 'Use Batch Size' pour les tOracleOutput.

Or, l'option Use Batch Size est cochée par défaut, alors que ce n'est pas le cas pour l'option 'Use Cursor'.

Est-ce que quelqu'un aurait une idée sur la raison de cette différence ?
Est-ce qu'il y aurait un inconvénient à l'utilisation du 'Use Cursor' ?

D'avance merci pour vos avis,
Nicolas

[elrudaille]

Bonjour,

La réponse à cette question m'intéresse également fortement.
Merci.

[easy-bi]

Hello,

Je n'ai pas de réponse certaine par manque de tests mais j'ouvre une piste...

L'option "Use Cursor" améliore les performances en paramétrant la méthode setFetchSize de l'objet java Statement.

setFetchSize(int rows)
Gives the JDBC driver a hint as to the number of rows that should be fetched from the database when more rows are needed for ResultSet objects genrated by this Statement.

Ceci est vrai si le paramètre defaultRowPrefetch de la connexion JDBC est correctement paramétré (par défaut 10)

N'hésitez pas à mettre vos retours/benchmark sur ce port

[easy-bi]

... valable pour oracle

Mais attention à ne pas trop l'augmenter dans le cas de champs très longs, exemple avec un VARCHAR(4000) dans ce document

Un cas extrême

si defaultRowPrefetch=1000
votre requête remonte 255 colonnes de 4000 caractères (8ko par colonne)
-> donc 2MO par ligne remontée

La mémoire nécessaire sera de 2 gigas -> 1000 * 255 * 8ko