Discussion :

[weebib]

Bonjour,

Je travaille sur un ensemble de procédures stockées qui ont pour but de transférer des données d'un schéma à un autre. Les traitements consistent donc essentiellement en des gros SELECTs sur le schema source et des INSERTs ou UPDATEs sur le schéma destination. Le problème c'est que pour chaque procédure, il y a un catch qui fait un rollback en cas d'erreur. Cela signifie donc que si une seule ligne viole une éventuelle contrainte, la procédure entière est annulée.

Ma question est donc la suivante : y aurait-il un moyen de :
- faire en sorte que le traitement continue pour les autres lignes (un "best effort" en quelque sorte),
- ou bien au moins avoir la possibilité dans le catch de loguer la ligne incriminée?

Merci d'avance,
Pierre

[plaineR]

A tes 2 questions je vais répondre sans doute, mais n'ayant pas l'algorithme, cela me semble difficile de te répondre précisément

Comment ramène tu tes lignes ? avec un curseur ?

As-tu un moyen d'identifier facilement les lignes ?

[weebib]

A tes 2 questions je vais répondre sans doute, mais n'ayant pas l'algorithme, cela me semble difficile de te répondre précisément

Comment ramène tu tes lignes ? avec un curseur ?

As-tu un moyen d'identifier facilement les lignes ?

Je vais essayer d'être plus explicite. J'arrive juste sur le projet sans aucune expérience en PL/SQL ni sur les bases de données en général. La base destination est une base de reporting qui est essentiellement une copie de la base de production mais avec des tables dénormalisées pour optimiser les SELECTs.

Je me trouve donc confronté avec trentaine de procédures que j'essaye d' "optimiser" et de rendre plus robustes. Les "algorithmes" sont plus ou moins les mêmes : INSERT INTO SchemaDest.A SELECT FROM SchemaSource.A WHERE (des conditions notamment sur le caractère nouveau de l'enregistrement). En l'état, je pense pouvoir dire que je n'ai pas accès aux numéros de lignes.

Il faut savoir que le traitement actuel prend de l'ordre d'une vingtaine d'heures donc je suis assez hésitant face à l'utilisation de curseurs dont on me dit qu'ils peuvent avoir un impact négatif sur les perfs (mais n'ayant pas testé, je peux aisément me tromper). Je suis donc prêt à entendre l'avis d'un expert...

[plaineR]

Etant donné que tu traites tes lignes de manière ensembliste, il me semble assez difficile d'en isoler une.

Il est exact que traiter les lignes une par une (curseur) sera sans doute moins performant (il existe néanmoins des cas où ce n'est pas vrai).

[weebib]

Etant donné que tu traites tes lignes de manière ensembliste, il me semble assez difficile d'en isoler une.

Il est exact que traiter les lignes une par une (curseur) sera sans doute moins performant (il existe néanmoins des cas où ce n'est pas vrai).

C'est bien ce que je craignais. J'avais espéré la possibilité d'une bidouille basée sur ROWCOUNT qui aurait donné le nombre de lignes insérées avant la levée de l'exception.

Ca peut paraître naïf, mais je trouve dommage qu'il n'existe pas de mécanisme permettant à ORACLE de continuer l'insertion/l'update sur les enregistrements valides.