Re: Unix Performance Issues

If you think your process is 'losing time' then the best bet is to set event 10046 at level 8 to generate a trace file that includes wait states (equivalent to v$session_wait).

There are several approaches however
a) Don't set the event, look at v$session_event

    for the relevant SID before and after the critical     code - this will give you a summary of waits for     the task

b) If you can control the process code, then issue:

    alter session set event '10046 trace name context forever, level 8'     before the code-proper starts. Make sure that the trace file size     is large before you do this.

c) If you are not in control of the process code, then

    you may have to send a message into the process     after is has started. Use svrmgrl to do this. Identify     the Unix process id of the shadow, then:

        svrmgrl
        connect internal
        oradebug setospid {unix process id}
        oradebug unlimit
        oradebug event '10046 trace name context forever, level 8'

NB - the ',' before the 'level' may be an error in one or other (or both) b and c, I can never remember which events use commas in which environment.

I doubt, by the way, if fragmentation of system tables (I assume you mean data dictionary tables) could have a significant effect on your process.

--

Jonathan Lewis
Yet another Oracle-related web site: www.jlcomp.demon.co.uk

Le Beaux wrote in message <379f5e33.192146862_at_news.primenet.com>...
>Is there a command that I can run on a UNIX machine while executing a
>SQL command via SQL*Plus that will output all table hits performed
>while this command is being executed?
>
>I think we have a problem with system tables being fragmented, and now
>I am looking for a tool that will help me prove this either wrong or
>right.
Received on Wed Jul 28 1999 - 16:39:11 CDT