They reflect the previous wait. eg I did this
SQL> declare
2 v number;
3 begin
4 select x into v from t for update;
5 for i in 1 .. 10000000 loop
6 v := sqrt(i);
7 end loop;
8 end;
9 /
PL/SQL procedure successfully completed.
but in another session I had locked the row in table t, so it will be stuck on row 4 for a while first. Then when I committed, the plsql will burn a lot of cpu. Here's what ASH looked like:
select event, session_state, p1, p2
from v$active_session_history
where session_id = 367
order by sample_time;
EVENT SESSION P1 P2
---------------------------------------------------------------- ------- ---------- ----------
enq: TX - row lock contention WAITING 1415053318 655382
enq: TX - row lock contention WAITING 1415053318 655382
enq: TX - row lock contention WAITING 1415053318 655382
enq: TX - row lock contention WAITING 1415053318 655382
enq: TX - row lock contention WAITING 1415053318 655382
enq: TX - row lock contention WAITING 1415053318 655382
enq: TX - row lock contention WAITING 1415053318 655382
enq: TX - row lock contention WAITING 1415053318 655382
ON CPU 1415053318 655382
ON CPU 1415053318 655382
ON CPU 1415053318 655382
You can see that it went onto CPU but kept the p1/p2 info