Il n'y a pas de méthode directe; vous devrez soit analyser les journaux (comme mentionné dans une autre réponse), soit utiliser d'autres méthodes pour voir ce qui se passe dans un processus de longue durée.
Personnellement, je suggère d'utiliser des transactions autonomes pour activer cette fonctionnalité - pas sur la transaction elle-même, mais comme un mécanisme de journalisation vous permettant de savoir ce qui se passe. Par exemple, vous pourriez avoir PROCEDURE LONG_ACTION appeler PROCEDURE WRITE_LOG_ENTRY (défini comme une transaction autonome) qui écrirait un VARCHAR2 dans une autre table. Les transactions autonomes n'interfèrent PAS avec votre transaction actuelle (d'un point de vue LOGIQUE; méfiez-vous des impacts potentiels sur les performances) et vous pouvez donc voir ce qui se passe via vos entrées de journalisation, quel que soit un COMMIT ou un ROLLBACK dans votre transaction actuelle. Cela dit, vous pouvez le faire avec une seule déclaration DML massive; il faudrait utiliser une boucle.
Considérer:
TABLE LOG_ENTRIES defined as
activity_date date,
log_entry varchar2(2000)
TABLE BIG_JOB (definition doesn't really matter)
PROCEDURE WRITE_LOG_ENTRY
( str VARCHAR2 )
IS
PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
INSERT INTO LOG_ENTRIES VALUES ( SYSDATE, str );
COMMIT;
END;
PROCEDURE LONG_ACTION IS
c NUMBER;
BEGIN
FOR r IN ( SELECT * FROM BIG_JOB )
LOOP
c := c + 1;
UPDATE BIG_JOB z
SET fld = hairy_calculation
WHERE z.rowid = r.rowid;
IF MOD(c,500) = 0 THEN
WRITE_LOG_ENTRY ( c || ' rows processed.' );
END IF;
END LOOP;
COMMIT;
END;
Compte tenu de ce qui précède, vous obtiendrez une entrée de journal pour chaque 500 lignes traitées, quel que soit le succès de l'action longue. Si vous avez besoin d'un duplicata exact des données pour voir comment cela fonctionne, je suggère de créer une table en double et d'appeler une procédure qui dupliquera les données (la procédure étant une transaction autonome). Ensuite, supprimez les données après coup. (Pas besoin de duplication.)
De plus, si c'est à des fins de débogage, je suggère de supprimer ou de réduire considérablement la nécessité d'une telle journalisation lorsque les choses ont été testées. Et, comme toujours, testez, testez, testez sur votre propre système pour vérifier comment les choses vont fonctionner. (Voir le commentaire de Niall pour un bon exemple de la façon dont la journalisation peut considérablement affecter les performances.)
(Enfin, parce que j'ai négligé de le mentionner auparavant: méfiez-vous des transactions autonomes. Comprenez-les bien avant de les mettre en œuvre, et ne les utilisez pas "simplement parce que". Elles peuvent être utilisées de façon incorrecte de plusieurs millions éviter une erreur de mutation dans un déclencheur), il est donc toujours préférable de trouver des alternatives, si possible. Si vous ne le pouvez pas, procédez avec prudence. La journalisation pendant les opérations de longue durée a toujours été un cas où elle est assez sûre problèmes de performances), mais ne vous précipitez pas pour l'appliquer à d'autres utilisations sans en connaître les conséquences.)