Discussion :

[f-demu01]

Bonjour,

je suis en pleine rédaction de ma première vraie procédure PL/SQL, dont le but est d'insérer dans une table tierce, à partir d'une table lignes de commandes, des données de quantité commandée, expédiée, reste à expédier... calculs effectués à partir d'une autre table.
Donc je récupère les lignes de commandes concernées via un curseur, et dans l'exécution de ce curseur, je calcule les positions citées ci dessus, que je stocke dans des variables, tant que le curseur ramène des lignes.

Ma question est de savoir quelle est la solution performante entre effectuer un insert des valeurs A, B, C, D à chaque passage dans la boucle, ou bien gérer un tableau de type RECORD alimenté à chaque passage, puis ne faire qu'une insertion à la fin du traitement du curseur?

J'ai effectué des recherches dans la FAQ et sur le forums PL/SQL, je n'ai pas trouvé d'éléments pertinents. Etant novice dans la création PL/SQL, je crains que certains termes que j'utilise soient inappropriés, aussi n'hésitez pas à pointer mes erreurs sémantiques

je vous remercie par avance de l'aide que vous pourrez m'apporter.

Cordialement,

[skuatamad]

Salut,

Effectivement faire des traitements de masse c'est beaucoup plus performant que les insert ligne à ligne cf tuto

[f-demu01]

merci skuatamad,

je pense effectivement que c'est le genre de comparaison que je n'arrivais pas à trouver. Il me reste à comprendre le fonctionnement

Merci en tous cas de ton aide,

Cordialement

[dgi77]

Il faut toujours garder à l'esprit que l'accès au disque dur est au moins 100 fois plus coûteux que l'accès à la mémoire vive, donc l'accès à une table est au moins 100 fois plus coûteux que l'accès à une variable mémoire.
D'où l'intérêt de faire les algos lourds en manipulant des tableaux, puis de faire un INSERT final, qui au passage peut gagner en performance en l'utilisant avec un FORALL (documenté dans le tutoriel PL/SQL du site).

[mnitu]

Il faut toujours garder à l'esprit que l'accès au disque dur est au moins 100 fois plus coûteux que l'accès à la mémoire vive, donc l'accès à une table est au moins 100 fois plus coûteux que l'accès à une variable mémoire.
D'où l'intérêt de faire les algos lourds en manipulant des tableaux, puis de faire un INSERT final, qui au passage peut gagner en performance en l'utilisant avec un FORALL (documenté dans le tutoriel PL/SQL du site).

Désolé, mais ce n'est pas une histoire d'accès au disque!
Au départ les données sont toujours sur le disque! La lecture ligne à ligne n'implique pas un accès au disque à chaque fetch! Etc.

[f-demu01]

Désolé, mais ce n'est pas une histoire d'accès au disque!
Au départ les données sont toujours sur le disque! La lecture ligne à ligne n'implique pas un accès au disque à chaque fetch! Etc.

Bonjour,

effectivement, la lecture ne me pose pas vraiment de problème, il s'agit en fait de l'insertion de données dans une autre table (données provenant de la lecture d'une table) qui me fait poser des questions: je vois deux façons de faire mon algo, soit en insérant ligne à ligne à chaque fetch, soit en gérant un tableau de records, qui fait l'insertion une fois toutes les lignes traitées et le fetch terminé.

Je vais donc a priori me tourner vers FORALL, avec tout de même une petite précision (pour être sûr): le fait de gérer le commit après mon forall effectuera bien un seul accès disque ?

d'avance merci

Cordialement

[dgi77]

Au départ les données sont toujours sur le disque! La lecture ligne à ligne n'implique pas un accès au disque à chaque fetch! Etc.

Est-ce que j'ai dit que chaque fetch implique un accès disque ???
Toujours est-il, par contre, qu'il implique un accès disque tous les N fetch, ce qui justifie de passer par des variables mémoires. Je donnais une tendance pour que f-demu01 ait une idée du fonctionnement. Maitenant si tu as la science suffisante pour nous donner la valeur du N en fonction des différents paramètres à prendre en compte, libre à toi de disserter...
Au passage, pourrais-tu aussi nous expliquer l'intérêt du BULK COLLECT si le FETCH n'est pas gourmand en accès disque.
Pour f-demu01, le BULK COLLECT est le pendant du FORALL, mais quand tu "balances" les données dans les variables.

Désolé, mais ce n'est pas une histoire d'accès au disque!

Donc je suis désolé, mais je maintiens que c'est une histoire d'accès au disque!

Quand c'est possible la solution la plus performante est

Code :

INSERT INTO TABLE
SELECT ... FROM T1, T2 etc.
Parfois cette solution peut être mise en pratique en utilisant les fonctions pipelined.

Certes, mais si tu lis le post initial de f-demu01, tout laisse à penser que son algo est fonctionnellement trop compliqué pour être résolu en ensembliste.

Bonjour dgi77,

j'ai imprimé, lu et testé le cours de SheikYerbouti concernant l'utilisation des collections et de FORALL. A plusieurs reprises, il est dit que le forall peut être fait directement si la collection (le type record dans mon cas) reprend la structure de la table à alimenter. Cela signifie-t-il que ecla ne fonctionne pas avec une collection dont le schéma ne reprend que certaines colonnes de la table ?

Cordialement,

Je n'ai pas testé, mais je suppose que si les colonnes manquantes n'ont pas de contrainte NOT NULL, ça devrait passer

[f-demu01]

D'où l'intérêt de faire les algos lourds en manipulant des tableaux, puis de faire un INSERT final, qui au passage peut gagner en performance en l'utilisant avec un FORALL (documenté dans le tutoriel PL/SQL du site).

Bonjour dgi77,

j'ai imprimé, lu et testé le cours de SheikYerbouti concernant l'utilisation des collections et de FORALL. A plusieurs reprises, il est dit que le forall peut être fait directement si la collection (le type record dans mon cas) reprend la structure de la table à alimenter. Cela signifie-t-il que ecla ne fonctionne pas avec une collection dont le schéma ne reprend que certaines colonnes de la table ?

Cordialement,