Salut,
 
 
J'ai une procédure qui copie les lignes d'une table dans une table d'une autre base plusieurs fois par jour.
Jusqu'à présent comme tout marchait bien,je ne faisais pas de gestion d'erreur.
La procédure fait un insert into select * from masource; puis un commit;
 
Je compte intégrer maintenant la gestion d'erreur.
Dans la mesure ou je traite de grosse volumétrie,
si mon insert échoue en cours de travail que va faire ma procédure?
un rollback?la source peut contenir 1 million de lignes,
j'imagine que si elle fait un rollback d 'un million de ligne cela va prendre des heures?
 
Pour la gestion d'erreur,
qu'elle est la méthode la plus otpimale?avec un exception when others then ?
 
Merci
 
 
 
 
 
 
 
 
 
 

depuis le temps , que tu as posté ce message, tu as du avoir choisi une solution...
Par curiosité, quelle est elle? cela donne quoi le rollback d'un million de ligne?
n'as tu pas des soucis avec le niveau d'isolation de ta transaction?
Guillaume

je n'ai pas encore résolu le problème, jusqu'ici je n'ai pas encore eu le soucis.
Mais si jamais cela se produit, j'imagine que le tablespace va "péter".
 
Je voulais le faire avec bulk collect,
mais le hic est que si jamais ça tombe en erreur, je retombe dans la même problématique.
Si j'insère 900 000 (commit fait) et que le traitement tombe en échec pour les 100 000 dernières lignes,
je devrais les supprimer de la table et donc même problème.

bonjour,
 
je suppose que tu es sous oracle (tablespace)... Il est vrai qu'en oracle, la logique veut que ce soit le commit qui soit efficace et le rollback plus lent.
 
Après un rollback d'un million de ligne "d'un coup" est potentiellement lourd en temps mais si le segment d'undo est suffisamment "sizé" ça ne doit pas peter plus que ça pour moi, c'est plus une question d'impact sur les perfs ...
 
Par contre je ne vois pas en quoi un bulk collect peut aider en quoi que ce soit, c'est juste un mode de "lecture" des données d'origines, pas de gestion de la destination.
 
Mes questions sont :
- y a-t-il des données "pré-existantes" dans la table de destination ?
- quelle est le pb de "consistance" si pendant un temps le "reste" du monde voit les données des 900k lignes (si commit par palier de 100k) en attendant la reprise des "100k" restant ?
- as-tu pensé à utiliser une partition pour chaque nouvel "import" (dont la clé de partitionnement est un id d'import par exemple comme une date) ? mais ça impose de changer la structure de la table (ajout de la colonne pour la clé et passage en partitionné) mais permet d'isoler les données importées et de remplacer le rollback par un drop partition. Il existe aussi le "partition exchange" qui permet de "migrer" une partition d'une table à une autre (pour peu qu'elles aient la meme structure) et ainsi faire un import en "one shot"
 
Mais c'est difficile de proposer des choses sans connaitre les contraintes opérationnelles...
 
Qu'en pensez vous ?