Re: awr process memory summary section

  • From: Tanel Poder <tanel@xxxxxxxxxx>
  • To: kaygopal@xxxxxxxxx
  • Date: Thu, 1 Apr 2010 02:02:59 +0800

In addition to what K Gopal said:

Note, that the target process must also get some CPU time in order to
populate its private memory details.
If the target process is idle or waiting for something to complete (without
a timeout, like dbms_lock.sleep) then it won't populate its stats.

The V$PROCESS_MEMORY_DETAIL_PROG shows the progress - whether the target
process has populated its memory details or not (the status would change
from ENABLED to COMPETE there).

Also, if you set this event at level 0, a PGA memory detail request is sent
to all processes in the instance - but I don't recommend doing this in
production, this sends basically an oradebug request to all processes,
including LGWR and other critical procs in the instance.

Btw, I have couple of scripts for making this easier  (although I use
oradebug instead of alter session there):

The process memory detail however doesn't seem to recursively look into PGA
subheap contents, in which case you still need to resort to a
PGA/UGA/callheap dump and look into the resulting tracefile (or use heapdump
analyzer as I've done here:

Tanel Poder

On Thu, Apr 1, 2010 at 12:19 AM, K Gopalakrishnan <kaygopal@xxxxxxxxx>wrote:

> Neil,
> You need to set the event PGA_DETAIL_GET (using alter session with PID
> as level ) to populate the v$process_memory_detail view.
> -Gopal
> On Wed, Mar 31, 2010 at 10:38 AM, Neil Kodner <nkodner@xxxxxxxxx> wrote:
> > So what's the trick to getting v$process_memory_detail to populate?  I
> > haven't found much in the way of documentation.
> >
> >
> --
> //

Other related posts: