Thanks for the pointer on the x$kglob. I’m with you, I don’t want to look at any dumps unless I have too. I hadn’t tried to reproduce this issue until this morning after your comment. But I didn’t have too many problems doing so. The problems for me were all related to doing the test in SQL*Plus. The first was that SQL*Plus spits out DBMS_OUTPUT calls unless you set serveroutput off (so this wiped out the prev_sql_id field in v$session). The second issue is that when the statement completes, the sql_id field in v$session is wiped out. The entries still exist in v$open_cursor and the prev_sql_id field still has the original sql_id of the statement which generated the access to the lob. So in order to see the behavior we had in production, my SQL*Plus test required that I catch the session in the act of executing the statement. I haven’t had time to look into that yet. I have captured the data and will add it to the original post as I’m not sure how the formatting would work in the comments section.

Thanks for your comments.

Kerry

It’s very interesting case even though I could not reproduce your case(SQL*Net more data from client thing).

Anyway, query on x$kglob would have shown some data like:

select * from sys.x$kglob where kglobt03 = ”;

And library cache dump would show the depedent table for the LOB LCO.

But still, hard to decode. :)

Kerry