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): http://files.e2sn.com/scripts/pmem_detail.sql http://files.e2sn.com/scripts/smem_detail.sql 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: http://blog.tanelpoder.com/2009/06/24/oracle-memory-troubleshooting-part-3-automatic-top-subheap-dumping-with-heapdump/ ) -- Tanel Poder http://tech.e2sn.com http://blog.tanelpoder.com 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. > > > > > -- > //www.freelists.org/webpage/oracle-l > > >