Re: How to obtain session-specific memory dumps?

From: Tanel Poder <tanel_at_poderc.com>
Date: Wed, 19 Aug 2009 21:15:07 +0800
Message-ID: <4602f23c0908190615x17804940u4c813ba02c61ef9a_at_mail.gmail.com>



Read this:

http://blog.tanelpoder.com/2009/07/09/identify-the-sql-statement-causing-those-wait-x-lines-in-a-top-truncated-sql-tracefile/

In the end I have comments on both getting bind variable values with errorstack level 3 dump and also some private memory areas associated with the cursor (kxscwhp stands for cursor workheap for example etc)

Tanel.

On Tue, Aug 18, 2009 at 9:57 PM, Rich Jesse <rjoralist_at_society.servebeer.com
> wrote:

> No takers? How's about this: Can I get the bind variable values for a
> specific statement as run by a specific process? I can see the statement
> in
> an ORADEBUG DUMP PROCESSSTATE, but not sure how to go about getting the
> bind
> values for it as it was run (v$sql_bind_capture will not work as it's very
> unlikely that this process will have executed that statement last).
>
> So close...
>
> Rich
>
> > In 10.1, we have a recurring situation where a user (or users) will
> attempt
> > to pull large tables through a Websphere v5 app. The Websphere "node" (I
> > think it's called) will heapdump from the large amount of data, taking
> down
> > every user connected to that node. The dump contains no identifiable
> > information in it to tie the query back to the offending user. And since
> > the connection to Oracle uses generic DB logins and is made via
> thin-client
> > or JDBC, which lacks client information, I can't tell from the DB who the
> > user is.
> >
> > Upgrading any component is not currently possible. My hope is that
> perhaps
> > the UGA may hold some key information about the user that's not
> immediately
> > apparent nor available. For example, application login information.
> >
> > I've been experimenting with using "oradebug dump heapdump" from
> SQL*Plus,
> > but all it returns is information about the memory chunks. I'm looking
> for
> > the data stored within the chunks. There is of course little information
> on
> > the undocumented oradebug tool.
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

-- 
Tanel Poder
http://blog.tanelpoder.com

--
http://www.freelists.org/webpage/oracle-l
Received on Wed Aug 19 2009 - 08:15:07 CDT

Original text of this message