Нет прямого метода; вам придется либо просматривать журналы (как уже упоминалось в другом ответе), либо использовать альтернативные методы, чтобы увидеть, что происходит в длительном процессе.
Лично я предлагаю использовать автономные транзакции для включения этой функции - не для самой транзакции, а в качестве механизма ведения журнала, позволяющего вам знать, что происходит. Например, у вас может быть PROCEDURE LONG_ACTION вызов PROCEDURE WRITE_LOG_ENTRY (определяется как автономная транзакция), который записывает VARCHAR2 в другую таблицу. Автономные транзакции НЕ мешают вашей текущей транзакции (с точки зрения логики; остерегайтесь потенциального влияния на производительность), и поэтому вы можете видеть, что происходит через ваши записи в журнале, независимо от COMMIT или ROLLBACK в вашей текущей транзакции. Тем не менее, вы можете сделать это с помощью одного массивного оператора DML; Вы должны использовать цикл.
Рассмотреть возможность:
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;
Учитывая вышесказанное, вы получите запись в журнале для каждых 500 обработанных строк независимо от успеха длинного действия. Если вам нужна точная копия данных, чтобы увидеть, как они работают, я предлагаю создать копию таблицы и вызвать процедуру, которая будет дублировать данные (процедура является автономной транзакцией). Затем постучите в ноль данных. (Нет необходимости в дублировании.)
Кроме того, если это делается для целей отладки, я предлагаю исключить или радикально уменьшить необходимость такой регистрации, когда что-то проверено. И, как всегда, тестируйте, тестируйте, тестируйте на своей собственной системе, чтобы проверить, как все будет работать. (См. Комментарий Найла для хорошего примера того, как ведение журнала может существенно повлиять на производительность.)
(Наконец, потому что я не упомянул об этом раньше: остерегайтесь автономных транзакций. Полностью поймите их перед реализацией и не используйте их «только потому, что». Они могут быть использованы миллионами способов неправильно (скажем, например, чтобы попытаться избежать ошибки изменения в триггере), поэтому всегда лучше найти альтернативы, если это возможно. Если вы не можете, тогда действуйте с осторожностью. Ведение журнала во время длительных операций всегда было одним из случаев, когда это довольно безопасно (игнорирование проблемы с производительностью), но не спешите применять его для других целей, не зная последствий.)