We ended up doing a full analyze on one of the tables behind, that seemed
to have fixed the problem. I am digging around more, learning stuff.
On Thu, Sep 10, 2015 at 10:25 AM, Ram Raman <veeeraman@xxxxxxxxx> wrote:
Thanks Stefan and Jonathan, this is 10.2
On Thu, Sep 10, 2015 at 2:00 AM, Stefan Koehler <contact@xxxxxxxx> 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: @OracleSK
Ram Raman <veeeraman@xxxxxxxxx> hat am 10. September 2015 um 02:30geschrieben:
the sessionid, but when I set the trace I am not able to locate the trace
I decided to trace the query anyway, but I am not lucky there. I know
file. I cannot modify the query in the app server since that is adifferent 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 oneis 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.
--
