If you can enable trace then they'll be in the 10046. As for dumping the uga I *think* there's an event for that, I'll look it up when I get back. If not I expect Tanel Poder has something on his site. On 8/18/09, 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. > > > -- > //www.freelists.org/webpage/oracle-l > > > -- Sent from Google Mail for mobile | mobile.google.com Niall Litchfield Oracle DBA http://www.orawin.info -- //www.freelists.org/webpage/oracle-l