Question on SQL_TEXT from v$sqlarea

Question

Windows 2003
Oracle 9.2.0.6.0
I have a number of DML statements I want to run dynamically. I have a PLSQL proc which generates the statements and populates a tracking table with them. It then selects from the tracking table and executes each statement dynamically with a status field against each statement. a pretty simple cursor loop.
All the statements are deletes with a bitmap index hint to delete where delete_flag = Y.
delete /*+ INDEX(<bitmap index name on delete_flag>) */ table_name WHERE delete_flag = 'Y'
several hundred of these. before it runs for each statement I update the tracker table with "running" for that statement so I know which table its running against. 1 of the tables seems to be hung for a long time. hours. I would have expected the delete of this particular table to run in minutes tops. Theres maybe 1 mill rows in the table with 300k rows to be deleted.
explain plan for that statement is good, uses the index as expected with a low costing.
So I started to dig around.
Looking at the waits for this session every few seconds, it seems to be progressing through the blocks so no waits in partiuclar to worry about.
I then happen to check the SQL for that session (nothing else running on the DB while this procuedre is running)
select sesion.sid,
       sesion.username,
       optimizer_mode,
       hash_value,
       address,
       cpu_time,
       elapsed_time,
       sql_text
  from v$sqlarea sqlarea, v$session sesion
where sesion.sql_hash_value = sqlarea.hash_value
   and sesion.sql_address    = sqlarea.address
   and sesion.username is not null And the SQL_TEXT returned is not the SQL that was submitted dynamically. the table is correct but its using the primary key to delete.
DELETE FROM hung_table_name WHERE PK_FIELD = :B1
Can anyone explain why Im seeing that delete statement and not the one submitted dynamically?

Answer 1

I can understand guys saying I cant be absolutely sure nothing else is running based on the SQL, but I am sure.
its a small shop, no apps coming in, 1 other dba, 2 developers, no scheduled jobs in the database, no scheduled job on the OS, no other users on.
The tracker table that Im populating has a few hundred statements in it, dynamically generated from a cursor theyre all
step, command, status
1, delete /index hint/ from table1 where delete_flag=Y, Pre
2, commit, Pre
3, delete /index hint/ from table2 where delete_flag=Y, Pre
4, commit, Pre
5, delete /index hint/ from table3 where delete_flag=Y, Pre
and so forth....
Theres no room for anything else to get in, let alone a well constructed command to delete by the primary key.
In the PLSQL, the cursor is select command from tracker_Table order by step
for i in cur
update tracker_table set status ='running' where command = i.command
execute immediate 'i.command';
update tracker_table set status ='complete' where command = i.command
As the entire job takes 2 days (yes, Im trying to come up with a better way and I didnt write this one), this method works for tracking where the job is. At the time this particualr table is getting stuck, the status is set to 'running' for the same table that I see the 2 statements for the in sql_text.
1 which is the statement with the index hint and a non matching hash value in v$session. And 1 statement which Ive shown deletes by the PK where the hash value matches the hash value of the session thats running the delete statement.
Ive never seen that before in a view (sql area)I would have queried many times over the years.
So, unless I can see otherwise, Im going with my earlier instinct that the query is being rewritten to delete by PK based on what sybrand said about the 9i explain. Still doesnt explain for me the other SQL with the non matching hash value though.
Or better turn on sql trace in 1-st session as it was already advised and then look into trace file.see earlier post, its taking hours and not returning so cant get a good trace.