Re: help tracking down root of high executions.

On Jan 9, 2:44 pm, bdbafh <bdb..._at_gmail.com> wrote:
> On Jan 9, 2:34 pm, joel garry <joel-ga..._at_home.com> wrote:
>
>
>
>
>
> > On Jan 9, 6:21 am, Ben <benal..._at_yahoo.com> wrote:
>
> > > On Jan 7, 12:28 pm, Ben <benal..._at_yahoo.com> wrote:
>
> > > > On Jan 7, 11:43 am, Steve Howard <stevedhow..._at_gmail.com> wrote:
>
> > > > > On Jan 7, 11:06 am, Ben <benal..._at_yahoo.com> wrote:
>
> > > > > > 10.2.0.2 AIX 5.2 64bit.
>
> > > > > > I've got a few sql statements that are being executed once every
> > > > > > centisecond or so, according to an AWR report. I can see the type of
> > > > > > program that is executing the statement but our ERP system is setup in
> > > > > > a way that pretty much everyone gets the same database user name, so
> > > > > > it's hard to track down where or what is executing the statements.
> > > > > > With my knowledge of our ERP and our database in general I can't of
> > > > > > anything that should be executing this rapidly.
>
> > > > > > What would be a good way to attempt to find out exactly what is
> > > > > > causing this?
>
> > > > > Hi Ben,
>
> > > > > In the past, I have just selected everything from v$session where the
> > > > > sql_id = the one of interest.  If it is your ERP, it may set the
> > > > > module or action elements of the v$session structure and show you at
> > > > > least what may be causing it.  The machine in v$session may also be
> > > > > different than your ERP application servers.
>
> > > > > If it started out of the blue, I have also seen it be due to a recent
> > > > > patchset, or custom developer install, so I would check that also.
>
> > > > > HTH,
>
> > > > > Steve
>
> > > > I tried this and did find a session with the corresponding sql_id.
> > > > That user is at lunch right now though.
> > > > There are several other statements with the same kind of issues, they
> > > > look to all be originating from a few servers that are our terminal
> > > > servers for our users. The sessions all seem to be idle for some time.
> > > > every now an then when I run the select a random session shows up but
> > > > just briefly.- Hide quoted text -
>
> > > > - Show quoted text -
>
> > > Everytime I find a session that has that corresponding sql_id, the
> > > session is inactive and shows the last activity was at 1 minutes past
> > > the hour. (that is based off of last_call_et)
>
> > > The few sessions that I found to be using that sql and be active, I
> > > turned on tracing but they weren't executing the sql at an alarming
> > > rate ( maybe 10 to 20 times in 10 minutes ) which is normal. Is there
> > > a bug with AWR reporting that makes it appear that the sql is being
> > > executed every centi-second
>
> > Search the bug database on metalink for centiseconds and you might
> > wonder if anything gets them straight. :-O
>
> > jg
> > --
> > @home.com is bogus.
> > Big Brother is making money off of you:http://www.websense.com/global/en/PressRoom/PressReleases/PressReleas...
>
> Joel,
>
> ... its not like they're trying to put a lander on the surface of Mars
> or run a nuke_cue_lar pahr plant.
>
> My favorite was getting negative response times.
> That blows away just having to adjust by 3 or 6 decimal places.
>
> -bdbafh- Hide quoted text -
>
> - Show quoted text -

Little confused, are you saying that AWR doesn't report executions accurately, or that last_call_et doesn't reflect the correct centiseconds?

The execution rate for the sql that I am having issues with was based off of the # of executions during the snapshot time frame. Received on Thu Jan 10 2008 - 12:56:42 CST