Re: How to obtain session-specific memory dumps?

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@xxxxxxxxxxxxxxxxxxxxx
> 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

Other related posts: