No hay método directo; tendrá que analizar los registros (como se menciona en otra respuesta) o usar métodos alternativos para ver qué sucede en un proceso de larga duración.
Personalmente, sugiero usar transacciones autónomas para habilitar esta función, no en la transacción en sí, sino como un mecanismo de registro que le permite saber lo que está sucediendo. Por ejemplo, podría hacer que PROCEDURE LONG_ACTION llame a PROCEDURE WRITE_LOG_ENTRY (definido como una transacción autónoma) que escribiría un VARCHAR2 en otra tabla. Las transacciones autónomas NO interfieren con su transacción actual (desde una perspectiva LÓGICA; tenga cuidado con los posibles impactos en el rendimiento) y así puede ver lo que sucede a través de sus entradas de registro independientemente de un COMPROMISO o ROLLBACK en su transacción actual. Dicho esto, puedes hacerlo con una declaración DML masiva; tendrías que usar un bucle.
Considerar:
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;
Dado lo anterior, obtendrá una entrada de registro por cada 500 filas procesadas independientemente del éxito de la acción larga. Si necesita un duplicado exacto de los datos para ver cómo funciona, sugiero hacer una tabla duplicada y llamar a un procedimiento que duplicará los datos (el procedimiento es una transacción autónoma). Luego bombardea los datos después del hecho. (No es necesario duplicarlo).
Además, si esto es para un propósito de depuración, sugiero eliminar o reducir drásticamente la necesidad de tal registro cuando las cosas han sido probadas. Y, como siempre, pruebe, pruebe, pruebe en su propio sistema para verificar cómo funcionarán las cosas. (Vea el comentario de Niall para un buen ejemplo de cómo el registro puede afectar drásticamente el rendimiento).
(Finalmente, porque me olvidé de mencionarlo antes: tenga cuidado con las transacciones autónomas. Comprendalas completamente antes de implementarlas, y no las use "solo porque". Se pueden usar de un millón de formas incorrectas (por ejemplo, INTENTAR evitar un error de mutación en un disparador), por lo que siempre es mejor encontrar alternativas, si es posible. Si no puede, proceda con precaución. El registro durante operaciones de larga duración siempre ha sido un caso en el que es bastante seguro (ignorar problemas de rendimiento), pero no se apresure a aplicarlo a otros usos sin conocer las consecuencias).