Now I’m very confused – in your follow-up post, after I asked “are you saying this statement executes just once” you replied “this query was not executed just once, it has been executing for …”

It sounds like we’re back to something unusual – so I’d be looking at the stats that I listed in my earlier reply.

>What you meant was “why has this update statement executed 6 million times in the last 4 hours”.
Could you please point me to my words which lead to this conclusion? So if it’s my inconsistency I wouldn’t repeat it next time.

You should always take great care to ensure that you’ve presented the significant facts when describing a problem.

What you said sounded like “a single update that should be for a single row accessed by primary key has done a huge amount of work”.

What you meant was “why has this update statement executed 6 million times in the last 4 hours”.

thank you for feedback.
This query was not executed just once, it has been executing for more than 10 hours already on a customer’s test non-RAC 10.2.0.4 @ Solaris 10 environment :) The query is

update sys.snap$ set status = :1 where vname = :3 and sowner = :2 and instsite = :4

so, no CLOBs to update. A query is reported as currently being executed by an active session of a job, and it’s plan in v$sql_plan is update by UQ index. Maybe v$sql.sql_id reports wrong info – that’s possible.
Thanks again for your suggestions.

Are you saying that this update statement executes just once to update one row by unique key ? (There is no PK on sys.snaps$, by the way, just one unique key).

First I’d look in v$session to check if this really was the executing statement
Then I’d check in v$sql_plan (dbms_xplan.display_cursor) to check that the execution plan was as stated
Then I’d check in v$sql to see that it was executed just once
Then take a snapshot of x$kcbsw to see what type of logical I/O was being done, at the same time taking a snapshot of v$sesstat for that session to see if the two agreed. (And check if the figures from v$sesstat agree with the log_io from v$transaction – I’ve got one example where v$transaction over-reports).
Then I’d sit back and think for a bit.

sys.snap$ has a long column and two clob columns – so who know how nasty a single row update could get ;) (especially if your system tablespace is using ASSM and your block size is bigger than 8KB).

what would you say in case of

1) one query, UPDATE by single PK value, is executing for more than 4 hours
2) no TX contention
3) most significant wait event is ‘db file sequential read’ (more than 4 hours, ~1M total occurences in session)
4) V$TRANSACTION.LOG_IO is increasing permanently and fast (more than 20M currently)
5) V$TRANSACTION.CR_CHANGE is slightly increasing (~5K currently)
6) probably some other activities were done in this transaction, but their contribution in terms of elapsed time and used resources may be neglected
7)

SQL> select max(undoblks) from v$undostat;
 
MAX(UNDOBLKS)
-------------
         4774

8) no other active transactions are taking place
9) UPDATE operates on data dictionary table SYS.SNAP$

?

TIA.

It turned out that the possibility I had suggested in this note really was happening to the OP, so if you haven’t reviewed the OTN thread since my first comments you might want to take another look at how it developed.

Thanks, now fixed. It was the usual “less than” problem.