> : "
> Group by is still doing sorting, and is accounted in "sorts" stats (unless
> an index scan wasn't used to get rows in desired order).
> But yes, hash joins don't increase sort stats by themselves.
> "
>
> I think you meant "was used"in sted of "wasn't used". Just like you said,
> is's all
: "
Group by is still doing sorting, and is accounted in "sorts" stats (unless
an index scan wasn't used to get rows in desired order).
But yes, hash joins don't increase sort stats by themselves.
"
I think you meant "was used"in sted of "wasn't used". Just like you said,
is's all hash joins. It'
Hi!
Group by is still doing sorting, and is accounted in "sorts" stats (unless
an index scan wasn't used to get rows in desired order).
But yes, hash joins don't increase sort stats by themselves.
You should check 10046 level 8 output, find which SQL statement is doing
direct path writes, then ge
Could it be that hash joins account for the writes to TEMP without
increasing the sort stats? Or 'group by' statements, perhaps?
In a 10 minute interval, I can see no increase in the number of sorts to
disk, but the writes and reads from v$tempstat increase by thousands.
If that's the case, the
Hi!
Either your 4 disk sorts are huge & generating lot's of IO or there direct
writes aren't because of sorting.
They could be because NOCACHE LOB access for example (also CTAS and direct
path insert). You should view 10046 level 8 output and check in which file
are the IOs occurring.
Tanel.
---
FYI
The application that is causing the wait events is a third party product
that really sucks (autocommit, no bind variables, bad data model, etc.,
etc.) We're on EMC Symmetrix. There are hardly any wait-io's measurable on
AIX; the log file sync problem is not so much of a problem; moving to r
WHO LET THE DOGS OUT!!!
on 7/29/03 11:14 AM, Kirtikumar Deshpande at [EMAIL PROTECTED]
wrote:
> But, I would like to know how this seemingly high wait for 'direct path write'
> is affecting the
> overall response time. (ResponseTime = WaitTime + ServiceTime)
>
> If the 'CPU used by this session
But, I would like to know how this seemingly high wait for 'direct path write' is
affecting the
overall response time. (ResponseTime = WaitTime + ServiceTime)
If the 'CPU used by this session' is not considered in light of these wait times,
aren't you
getting ready to bark at the wrong tree?
Hans,
Now let me guess Your disks are all RAID 5, right? And you possibly are
bottlenecking on CPU as well? It is clear from the Top 5 that writes are an
issue across the board, to TEMP (direct path write), Redo (log file sync)
and DB files (db file parallel writes). Creating a RAID 1 set of d
Hans
I did a search on Google, and found this article:
http://www.faqchest.com/prgm/oracle-l/ora-02/ora-0206/ora-020638/ora02062414
_22868.html
(you'll probably have to patch the link together)
According to this article, your biggest and second biggest wait may be
connected.
Dennis Williams
DBA
Hi Hans,
direct path write cause would be writing temporary segments when sorts are
too large to be performed in memory, direct path operations like INSERT /+
APPEND or LOB access.
It's hard to guess which one is causing your problems, so I'd suggest you
profiling the call having performance issu
Hi All,
Please help me tune this i/o related wait event. This is my 8.1.6 statspack
top-5 wait list:
Top 5 Wait Events
~ Wait %
Total
Event Waits Time (cs) Wt
Time
--
12 matches
Mail list logo
