Re: [Fwd: Re: 10046 trace - unaccounted for time]
- From: "Keith Moore" <kmoore@xxxxxxxxxxxx>
- To: "Rakesh Tikku" <rakesh.tikku@xxxxxxxxx>
- Date: Wed, 6 Aug 2008 17:43:30 -0500 (CDT)
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
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
