Dan, 1-3 sound very reasonable to me.
4 however I don't quite follow. Tablespace/file passed in as a bind
variable?
Can't seem to quite follow the logic in 4 either. It appears that you
have a
DD managed temp tablespace, and you're seeing sorts take place as
indicated
by extent movement activity.
Is that correct?
Aren't there waits on the temp tablespace/file itself?
Can you post relevant section of the trace?
Jared
Daniel Fink <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
06/26/2003 08:35 AM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
cc:
Subject: 10046 Trace file questions
I am reviewing a 10046 trace file and have come across several questions
(actually more like hypothesis that I want to confirm).
1) The first user statement executed waits only on SQL*Net to/from client
and does not wait on any db file activity. I presume this means that the
data was found in the buffer cache and did not have to be read on disk.
2) The next user statement is preceeded by a recursive query on view$. The
user statement accesses a view, so this recursive query is part of the
object resolution phase of parsing.
3) This 3rd user statement has a substantial number of waits on db file
activities. This indicates disk access.
4) A subsequent statement has several space management (activity on fet$
and uet$) activities. The tablespace/file that is passed in as a bind
variable are associated with a 'temp' tablespace. However, the tablespace
is set up as dictionary managed. This indicates that sorting is being done
by this operation and that the sort segment space management is being
tracked in the data dictionary.
Thoughts?
daniel.fink.vcf
Description: Binary data
