RE: tracking down hidden SQL???
Date: Mon, 21 Oct 2013 14:56:50 +0100
Message-ID: <064e01cece65$64ce8d40$2e6ba7c0$_at_go-faster.co.uk>
Can you find this SQL_ID in your ASH data (assuming the diagnostics pack is licensed)?
If you know the SQL_PLAN_HASH_VALUE you could try to find other SQL_IDs with the same plan in DBA_HIST_SQL_PLAN.
Is this a piece of recursive SQL? Is SQL_ID the same as TOP_LEVEL_SQL_ID in the ASH data?
If the app does set a specific module/action for this SQL (again look in the ASH data) then you can enable trace just for that module/action.
regards
David Kurtz
tel: +44 (0)7771 760660
mailto:david.kurtz_at_go-faster.co.uk
-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Adric Norris
Sent: 21 October 2013 14:40
To: Chris Taylor
Cc: jonathan_at_jlcomp.demon.co.uk; oracle-l
Subject: Re: tracking down hidden SQL???
Importance: High
On Thu, Oct 17, 2013 at 9:48 AM, Chris Taylor <
christopherdtaylor1994_at_gmail.com> wrote:
> Hey, the other thing you could do, if you know some identifying
> information for these sessions, like OSUSER, machine/terminal,
> client_info etc, you could setup a LOGIN TRIGGER that enables a 10046
> trace and capture any/all SQL executed in the session.
>
> Some apps (like PeopleSoft) will populate client_info so it makes it
> easier to trace one session instead of all the connected sessions.
> Maybe you have something available to you that will enable you to
> create a limited trace on a few sessions.
>
So far there doesn't seem to be any distinguishing info for the sessions, which would make it easy to separate them from other app-related connections. If I'm able to come up with something, however, I'll certainly consider doing this.
Thanx!
-- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-lReceived on Mon Oct 21 2013 - 15:56:50 CEST