Re: Manual execution vs v$session discrepancy

On Thu, Sep 10, 2015 at 2:00 AM, Stefan Koehler <contact_at_soocs.de> wrote:

> Hi Ram,
> you can use the "new" kernel diagnostics & tracing infrastructure (>= 11g)
> to trace only that particular SQL as you know the SQL_ID (4abcc3v6tdfqj).
> It looks something like this:
>
> SQL> alter session set events 'sql_trace [sql:4abcc3v6tdfqj]
> wait=true,bind=true,plan_stat=all_executions';
> .. or globally ..
> SQL> alter system set events 'sql_trace [sql:4abcc3v6tdfqj]
> wait=true,bind=true,plan_stat=all_executions';
>
> Please make sure that "_evt_system_event_propagation" is set to TRUE, so
> that this event is pushed into the existing sessions as well.
>
> Best Regards
> Stefan Koehler
>
> Freelance Oracle performance consultant and researcher
> Homepage: http://www.soocs.de
> Twitter: _at_OracleSK
>
>
> > Ram Raman <veeeraman_at_gmail.com> hat am 10. September 2015 um 02:30
> geschrieben:
> >
> > I decided to trace the query anyway, but I am not lucky there. I know
> the sessionid, but when I set the trace I am not able to locate the trace
> > file. I cannot modify the query in the app server since that is a
> different group; I set the trace on at level 8 with dbms_system.set_ev.
> v$session
> > shows trace enabled for the session in qn, but I do not know which one
> is the trace file. I tried trcsess by giving it sid.serial#, that seems to
> > produce a file with just 4 lines and no useful info.
>

--

--
http://www.freelists.org/webpage/oracle-l