process in the gv$session when connecting from TOAD.exe to Oracle

[bill_...@yahoo.com]

Hi, there,

I am trying to understand the PROCESS column in the gv$session (or
v$session) when I am connecting to the oracle 10g RAC. Here is the
result I get: (we have 3 instances in the RAC).

select inst_id, sql_id,process from gv$session where
username='TESTUSER' machine='MYDESKTOP';

inst_id sql_id process program
-------- ---------- ------ --------
1 3uch2pddpkqt9 14402 oracle@cmc7asfm2 (PZ99)
1 3uch2pddpkqt9 4476:4204 TOAD.exe
2 3uch2pddpkqt9 13278 oracle@cmc7asfm2 (PZ99)
3 3uch2pddpkqt9 23207 oracle@cmc7asfm2 (PZ99)

In the process column, it is easy to understand the PID 14402, 13278,
23207 are the oracle_pz99_sid processes in the member side. But
regarding the 4476:4202 for the TOAD.exe, I don't know what the 4202
part is. After checking the windows processes, I know know the 4476
part in 4476:4202 is the process ID for TOAD.exe.

Anyone know why we get the output like 4476:4202 if we connecting from
windows? If we connect from unix, the output will be all single
process.

Thanks

[DA Morgan]

Windows uses threads not processes is my immediate reaction. But it may
be that someone actually knows the answer so I'll be watching too.
--
Daniel A. Morgan
University of Washington
damo...@x.washington.edu
(replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org

[John K. Hinsdale]

> bill_...@yahoo.com wrote:
> > Hi, there,
> >
> > I am trying to understand the PROCESS column in the gv$session

> > ... regarding the 4476:4202 for the TOAD.exe, I don't know what the 4202

> > part is. After checking the windows processes, I know know the 4476
> > part in 4476:4202 is the process ID for TOAD.exe.

>DA Morgan wrote:
> Windows uses threads not processes is my immediate reaction. But it may
> be that someone actually knows the answer so I'll be watching too.

Dan Morgan is exactly right: the number to the right tof the colon is
the thread ID (within the process, whose ID appears before the colon).

To verify for yourself, do the following:

- Note the value in column GV_$SESSION.PROCESS, e.g., "<pid>:<tid>"
- Go to your client Windows box, right click on the taskbar and run
Task Manager
- Select menu "View ... Select Columns" ... a dialog of checkboxes
appears
- Check the box "PID (Process Identifier) and click OK
- Locate the entry for the process of the Oracle client (toad.exe,
SQLNav5.exe, etc).
- The value in the Task Manager PID column should agree with what you
see in
the Oracle system table GV_$SESSION

To prove <tid> is the session ID, you can:
- Download and install
http://download.sysinternals.com/Files/PsTools.zip
- Run the utility "pslist" as follows:
pslist -d <pid>
where <pid> is the process ID of your Oracle client.
- You will see a number of thread IDs, one of which matches the ID to
the
right of the colon in the value in GV_$SESSSION.PROCESS

> Windows uses threads not processes is my immediate reaction.

Actually Windows (at least since Windows 95 and the Win32 model)
uses threads AND processes. It used to be Unix used ONLY processes,
but now most modern Unixes have intra-process ("user-level") threads
built in, though many many applications, including some UNIX Oracle
clients,
continue to use the old "one level" process model.

Oracle also seems to put in a lot more of its own "sessions".For your
amusement, here
is a link to $GV_SESSION in my demo database, filtered for "internal"
sessions:

http://otb.alma.com/otb.fcgi?func=btable&nfilter=1&server=orcl&user=SYS&table=GV_%24SESSION&isview=T&pagesize=100&filtcol1=PROGRAM&filtmode1=C&filtval1=oracle

Hope that helps,

John Hinsdale
h...@alma.com