Puis-je remplacer savepoints pour démarrer de nouvelles transactions dans Oracle?

Question

En ce moment, le processus que nous utilisons pour insérer des ensembles d'enregistrements est quelque chose comme ceci:

(et notez que « l'ensemble des dossiers » signifie quelque chose comme le dossier d'une personne ainsi que leurs adresses, numéros de téléphone, ou tout autre tables jointes).

1. Lancer une transaction.
2. Insérer un ensemble d'enregistrements qui sont liés.
3. Engagez si tout a réussi, revenir autrement.
4. Retour à l'étape 1 pour la prochaine série d'enregistrements.

Faut-il faire quelque chose de plus comme ça?

1. Démarrer une transaction au début du script
2. Lancer un point de sauvegarde pour chaque ensemble d'enregistrements.
3. Insérer un ensemble de documents connexes.
4. Annulez au point de sauvegarde s'il y a une erreur, continuer si tout est réussi.
5. Valider la transaction au début du script.

Après avoir quelques problèmes avec ORA-01555 et lire quelques articles Demandez Tom (comme celui-ci ), je pense à essayer le deuxième processus. Bien sûr, comme Tom souligne, le démarrage d'une nouvelle transaction est quelque chose qui devrait être défini par les besoins des entreprises. Est le deuxième processus peine d'essayer, ou est-ce une mauvaise idée?

Answer 1

Une transaction doit être une unité significative de travail. Mais ce qui constitue une unité de travail dépend de contexte. Dans un système OLTP une unité de travail serait une personne seule, ainsi que leurs informations d'adresse, etc. Mais il semble que si vous implémentez une certaine forme de traitement par lots, ce qui est de charger beaucoup de personnes.

Si vous rencontrez des problèmes avec ORA-1555, il est presque certainement parce que vous êtes ont une longue requête en cours d'exécution à fournir des données qui est mise à jour par d'autres transactions. L'intérieur de votre boucle engager contribue à l'utilisation cyclique des segments UNDO, et ainsi aura tendance à augmenter la probabilité que les segments que vous comptez sur pour assurer la cohérence de lecture auront été réutilisés. Ainsi, le fait pas est probablement une bonne idée.

Que l'on utilise Savepoints est la solution est une autre affaire. Je ne sais pas quel avantage qui vous donnerait dans votre situation. Comme vous travaillez avec Oracle10g peut-être vous devriez envisager d'utiliser en vrac journalisation des erreurs DML à la place.

Sinon, vous voudrez peut-être réécrire la requête de conduite pour qu'il fonctionne avec de petits morceaux de données. Sans en savoir plus sur les spécificités de votre processus, je ne peux pas donner des conseils précis. Mais en général, au lieu d'ouvrir un curseur pour 10000 enregistrements, il pourrait être préférable d'ouvrir vingt fois pour 500 lignes d'un pop. L'autre chose à considérer est de savoir si le processus d'insertion peut être rendu plus efficace, par exemple en utilisant la collecte en vrac et FORALL.

Answer 2

Quelques réflexions ...

1. Il me semble l'un des points de la liaison AskTom était de la taille de votre rollback / undo de manière appropriée pour éviter les années 1555. Y at-il une raison cela est impossible? Comme il le souligne, il est beaucoup moins cher d'acheter le disque que d'écrire / maintenir du code pour gérer contourner les limites de rollback (même si je devais faire une double-prise après avoir lu l'étiquette de prix de 250 $ pour un lecteur 36GB - que le fil a commencé en 2002 ! Bonne illustration de la loi de Moore!)
2. Ce lien (Burleson) montre un problème possible avec savepoints.
3. Votre transaction en réalité les étapes 2,3 et 5 dans votre deuxième scénario? Si oui, est ce que je ferais - commets chaque transaction. Ça fait un peu pour moi comme le scénario 1 est une collection de transactions que dans une?