Não há método direto; você precisará analisar os logs (conforme mencionado em outra resposta) ou usar métodos alternativos para ver o que está acontecendo em um processo de longa execução.
Pessoalmente, sugiro o uso de transações autônomas para ativar esse recurso - não na transação em si, mas como um mecanismo de registro, permitindo que você saiba o que está acontecendo. Por exemplo, você poderia ter chamado PROCEDURE LONG_ACTION PROCEDURE WRITE_LOG_ENTRY (definido como uma transação autônoma) que gravaria um VARCHAR2 em outra tabela. As transações autônomas NÃO interferem com sua transação atual (de uma perspectiva LÓGICA; cuidado com os possíveis impactos no desempenho) e, assim, você pode ver o que está acontecendo através de suas entradas de log, independentemente de um COMMIT ou ROLLBACK em sua transação atual. Dito isto, você pode fazer isso com uma declaração DML massiva; você teria que usar um loop.
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 o exposto, você receberá uma entrada de log para cada 500 linhas processadas, independentemente do sucesso da ação longa. Se você precisar de uma duplicata exata dos dados para ver como está funcionando, sugiro criar uma tabela duplicada e chamar um procedimento que duplicará os dados (o procedimento é uma transação autônoma). Em seguida, adicione os dados após o fato. (Não há necessidade de duplicação.)
Além disso, se isso for para fins de depuração, sugiro remover ou reduzir drasticamente a necessidade desse registro quando as coisas tiverem sido testadas. E, como sempre, teste, teste, teste em seu próprio sistema para verificar como as coisas vão funcionar. (Veja o comentário de Niall para um bom exemplo de como o log pode afetar drasticamente o desempenho.)
(Finalmente, porque eu esqueci de mencioná-lo antes: cuidado com as transações autônomas. Compreenda-as completamente antes da implementação e não as use "apenas porque". Elas podem ser usadas de milhões de maneiras incorretamente (por exemplo, para tentar evitar um erro de modificação em um gatilho), por isso é sempre melhor encontrar alternativas, se possível.Se não puder, continue com cuidado.O registro durante operações de longa duração sempre foi um caso em que é razoavelmente seguro (ignorando problemas de desempenho), mas não se apresse em aplicá-lo a outros usos sem conhecer as consequências.)