Re: [Fwd: Re: 10046 trace - unaccounted for time]

Yes, I noticed that, but that wasn't always the case in other traces. There are strange things or at least things I'm not understanding. For example, this line:

WAIT #12: nam='db file sequential read' ela= 1385 p1=232 p2=113033 p3=1

When I get the file name from the p1 parameter, it is a different tablespace than what the query in cursor # 12 would use. P1 is the lob tablespace and QUERY #12 would use the system tablespace.

In any case, here is some background information. Before the problem, some of the LOB data was archived. We just created a database with the pre-archive data and ran the program against that data and it worked great. Running the same program against a copy of the production (post-archive) data and one row gets inserted and it hangs.

There is something doing a tremendous amount of consistent gets but we have not been able to identify what. We measured 100 million plus consistent gets by the session and it just inserted one row. We have also just found that the pre-archive lob index is 100 MB and the post-archive index is over 800 MB.

I'm wondering if the lob index is corrupt. We are looking at rebuilding the lob table and index by moving it but there are space issues.

Has anyone seen anything like this?

Keith

> The unaccounted for time appears *after* the INSERT finished inserting one
> row.
>
> EXEC #11:c=0,e=10076,p=1,cr=1,cu=7,mis=0,r=1,dep=0,og=4,tim=5188376817822
>

--
http://www.freelists.org/webpage/oracle-l