I will try to answer your question – if anyone else reading this blog has a better suggestion, please offer that suggestion.

You could just query V$SESSTAT, something like this (see the documentation):

SELECT
  S.USERNAME,
  S.PROGRAM,
  S.STATUS,
  SS.SID,
  SN.NAME,
  SS.VALUE
FROM
  V$STATNAME SN,
  V$SESSTAT SS,
  V$SESSION S
WHERE
  SS.STATISTIC#=SN.STATISTIC#
  AND SN.NAME='session pga memory'
  AND SS.SID=S.SID
ORDER BY
  SS.VALUE DESC,
  SS.SID;

If you are running Oracle 10.2.0.1 or higher, you could query V$PROCESS_MEMORY, something like this:

SELECT
  P.PID,
  P.SPID,
  P.PROGRAM,
  S.PROGRAM,
  S.USERNAME,
  S.SID,
  P.PGA_USED_MEM,
  P.PGA_ALLOC_MEM,
  P.PGA_FREEABLE_MEM,
  P.PGA_MAX_MEM,
  PM.SQL_ALLOCATED,
  PM.SQL_USED,
  PM.SQL_MAX_ALLOCATED,
  PM.PLSQL_ALLOCATED,
  PM.PLSQL_USED,
  PM.PLSQL_MAX_ALLOCATED,
  PM.OLAP_ALLOCATED,
  PM.OLAP_USED,
  PM.OLAP_MAX_ALLOCATED,
  PM.JAVA_ALLOCATED,
  PM.JAVA_USED,
  PM.JAVA_MAX_ALLOCATED,
  PM.OTHER_ALLOCATED,
  PM.OTHER_USED,
  PM.OTHER_MAX_ALLOCATED,
  PM.FREEABLE_ALLOCATED
FROM
  V$PROCESS P,
  V$SESSION S,
  (SELECT
    PID,
    SERIAL#,
    MAX(DECODE(CATEGORY,'SQL',ALLOCATED,0)) SQL_ALLOCATED,
    MAX(DECODE(CATEGORY,'SQL',USED,0)) SQL_USED,
    MAX(DECODE(CATEGORY,'SQL',MAX_ALLOCATED,0)) SQL_MAX_ALLOCATED,
    MAX(DECODE(CATEGORY,'PL/SQL',ALLOCATED,0)) PLSQL_ALLOCATED,
    MAX(DECODE(CATEGORY,'PL/SQL',USED,0)) PLSQL_USED,
    MAX(DECODE(CATEGORY,'PL/SQL',MAX_ALLOCATED,0)) PLSQL_MAX_ALLOCATED,
    MAX(DECODE(CATEGORY,'OLAP',ALLOCATED,0)) OLAP_ALLOCATED,
    MAX(DECODE(CATEGORY,'OLAP',USED,0)) OLAP_USED,
    MAX(DECODE(CATEGORY,'OLAP',MAX_ALLOCATED,0)) OLAP_MAX_ALLOCATED,
    MAX(DECODE(CATEGORY,'JAVA',ALLOCATED,0)) JAVA_ALLOCATED,
    MAX(DECODE(CATEGORY,'JAVA',USED,0)) JAVA_USED,
    MAX(DECODE(CATEGORY,'JAVA',MAX_ALLOCATED,0)) JAVA_MAX_ALLOCATED,
    MAX(DECODE(CATEGORY,'Other',ALLOCATED,0)) OTHER_ALLOCATED,
    MAX(DECODE(CATEGORY,'Other',USED,0)) OTHER_USED,
    MAX(DECODE(CATEGORY,'Other',MAX_ALLOCATED,0)) OTHER_MAX_ALLOCATED,
    MAX(DECODE(CATEGORY,'Freeable',ALLOCATED,0)) FREEABLE_ALLOCATED
  FROM
    V$PROCESS_MEMORY
  GROUP BY
    PID,
    SERIAL#) PM
WHERE
  P.ADDR=S.PADDR(+)
  AND P.PID=PM.PID
  AND P.SERIAL#=PM.SERIAL#
ORDER BY
  PGA_ALLOC_MEM DESC;

The above showed that I have an inactive session that has 10,915,985 bytes of memory allocated, with 2,264,137 bytes that are in use, 720,896 bytes are freeable, and the maximum amount of memory used by the session was 53,776,529 bytes. The “Other” allocated is currently at 9,994,145 bytes (of the 10,915,985 bytes).

If the above information was not enough for me, I could turn to page 268 in the Expert Oracle Practices book (chapter 8 written by Randolf Geist and myself) and dump the PGA and UGA memory contents to a trace file, like this (in SQL*Plus, connected as SYS, 34 is the PID of the session that is inactive):

ORADEBUG SETORAPID 34
ORADEBUG UNLIMIT
ORADEBUG DUMP HEAPDUMP 5
ORADEBUG CLOSE_TRACE

More information about ORADEBUG dumps is available on Julian Dyke’s website.

Regards,
Anand

http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:580621300346132183

http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:865497961356

Anand

I believe that there is potential for double counting of shared memory segments. I suggest taking a look at the following:
Excellent Video and Documentation about Oracle Memory Usage
asktom.oracle.com Article about Oracle Memory Usage
Oracle Documentation Link about OS Tools

Regarding the query of V$OPEN_CURSOR, yes – open cursors will consume the server’s memory. I suggest also grouping on the SQL_ID so that you are able to determine if it is the same SQL statement that is open more than 600 times (opened and then abandoned), or if those 600+ entries in the count are 600+ different SQL statements caused by too large of a value for the SESSION_CACHED_CURSORS parameter.

select oc.sid, count(*) ,s.status,to_char(s.logon_time,'DD-MM-YY HH24:MI:SS')in_time,s.LAST_CALL_ET from v$open_cursor oc,
v$session s  where oc.sid=s.sid and oc.user_name='APPLICATION_SCHEMA' group by oc.sid,s.status,s.logon_time,s.LAST_CALL_ET;

Session
     ID   COUNT(*) STATUS   IN_TIME           LAST_CALL_ET
------- ---------- -------- ----------------- ------------
    235        715 INACTIVE 12-02-10 09:50:19            3
    222        662 INACTIVE 09-02-10 22:53:44          673
    260        672 INACTIVE 09-02-10 16:51:18       417235
    225        672 INACTIVE 09-02-10 22:53:44            0
    248        657 INACTIVE 09-02-10 17:02:36       445957
    237        645 INACTIVE 09-02-10 16:51:38       417235
    219        666 INACTIVE 09-02-10 22:53:44         9026
    234        678 INACTIVE 12-02-10 09:50:19         9026
    232        674 INACTIVE 09-02-10 16:50:25         9026
    230        661 INACTIVE 09-02-10 22:53:44          673
    227        677 INACTIVE 09-02-10 22:53:44           14
    243        648 INACTIVE 09-02-10 17:02:36       445957
    224        780 INACTIVE 11-02-10 21:10:00        11091
    231        667 INACTIVE 09-02-10 16:51:38         9026

Anand

You might also considering monitoring the DB time value in the same performance view to see if the session is currently stuck in a wait event, rather than consuming CPU time (in that view, DB time – DB CPU = wait event time for a single session).

How to find why the cursor is still open for a session.I have a session with a logon date on 29-JAN-2010, which is INACTIVE and has 1 open_cursor.This session is having the maximum cpu usage,though inactive.How do i go ahead for analyzing it.

Regards,
Anand