Database Reference
In-Depth Information
We can see that we have no sessions—but we still have a process, a physical connection (using the previous
ADDR
value):
SYS@ORA12CR1> select username, program
2 from v$process
3 where addr = hextoraw( '00000000727FE9B0' );
USERNAME PROGRAM
--------------- ------------------------------------------------
oracle oracle@cs-xvm2 (TNS V1-V3)
So, here we have a connection with no sessions associated with it. We can use the also misnamed SQL*Plus
CONNECT
command to create a new session in this existing process (the
CONNECT
command might be better named
CREATE_SESSION
). Using the SQL*Plus instance we disconnected in, we'll execute the following:
EODA@ORA12CR1> connect eoda/foo
Connected.
EODA@ORA12CR1> select username, sid, serial#, server, paddr, status
2 from v$session
3 where username = USER;
USERNAME SID SERIAL# SERVER PADDR STATUS
--------------- ---------- ---------- --------- ---------------- --------
EODA 10 25 DEDICATED 00000000727FE9B0 ACTIVE
Notice that we have the same
PADDR
as before, so we are using the same physical connection, but we have
(potentially) a different SID. I say
potentially
because we could get assigned the same SID—it just depends on whether
other people logged in while we were logged out and whether the original SID we had was available.
■
On Windows or other thread-based operating systems, you might see different results—the process
address may change since you are connected to a threaded process, not just a single purpose process as you would
on UNIX/Linux.
Note
So far, these tests were performed using a dedicated server connection, so the
PADDR
was the process address of
our dedicated server process. What happens if we use a shared server?
■
to connect via a shared server, your database instance would have to have been started with the necessary
setup. Coverage of how to configure a shared server is beyond the scope of this topic but is covered in detail in the
Oracle Database Net Services Administrator's Guide
.
Note
