Russ,
20 seconds isn't enough time to see much of what's going on.
Give the slow SQL a chance to execute and collect some waits.
I just finished doing this on an app this morning, collected 100meg
of trace files. As long as you're doing it, set it to level 12, so you
can seen bind vars if need be.
You can use 'alter system set max_dump_file_size=unlimited' for the
duration of the collection period, then set it back to whatever it should
be.
Run tkprof on all the trace files, then look for the big time wasters.
Jared
"Brooks, Russ" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
03/11/2003 08:34 AM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
cc:
Subject: Slow running jobs
Hi,
We're having slow response on some batch jobs in our production system.
A straight SQL trace shows intermittant slow response times on selects
against a variety of tables. What is odd is:
1. the statistics are current for the tables, frequently the results of a
compute.
2. The same cursor with different bind variables will randomly vary from 200
microseconds to 3.6 seconds, randomly.
3. This occurs on multiple tables in multiple tablespaces.
What is this normally indicative of?
The other thing I did was run a 10046 level 8 trace for about 20 seconds.
I saw 22 log file sync's in that period in the trace file.
Any thoughts welcome.
Russ
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author:
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
