Kill session in shared server

I need to know what i must have into account to perform a kill session to a session in shared server. Is it different to kill a session in dedicated server?

Hi user8820906,
You must gather information of shared server from $server_server like “ name of server,status” use sql prompt “select name, status from v$shared_server”. To kill the session you need information from command select sid, serial# from v$session, then command to kill session is “ALTER SYSTEM KILL SESSION SID,SERIAL# from v$session;
The same sql command is use for both shared and dedicated server.
Regards,
Idrees

Similar Messages

Killing users Dedicated server / Shared Server

Hi,
I have a Web Applications that connects to our Oracle database and I can see a lot of users
stuck in the server and I have to manually kill these users.
To do this I´ve set a idle time to the conections , and using this script I´m able to kill these users :
sqlplus system/xxxxxx@instance <<EOF
spool $tmpfile
select p.spid from v\$process p,v\$session s
where s.paddr=p.addr
and s.status='SNIPED';
spool off
EOF
for x in `cat $tmpfile | grep "^[0123456789]"`
do
kill -9 $x
done
rm $tmpfile
I´ve also configured dead conections detection.
But unfortunatelly This machine has limited resources and the number of users will grow a lot in near future. So my only option is to change the database to shared server. In Shared server I cannot use my script anymore, because it kills all the connected users of that shared server , and dead connections detections is not working very well too ...
Anybody have a similar problem ? What could be done to clear the users that have already disconected from application and still use shared server mode ?
Whn users Log off the application it works ok, but sometimes the user closes the browser or we have blue screen in windows, etc and the conection remains forever
Thank you in advance,

Really think this should be application issues rather than database issues. Application or application server should have a way to handle idle sessions. It's not a clean way to kill session in the background like that.
In my environment, after developers changed application we don't have this problem any more.

Oracle Shared Server Session Scheduling

Hi,
We're currently evaluating the shared server architecture for production use. As far as we know, Oracle schedules N sessions across M operating system threads, dependent on the configured limits.
An essential requirement for our production system is to be able to associate a given operating system thread belonging to an Oracle shared server process with a session (more specifically the session owner) and maintain this information externally. Because a shared server thread may handle multiple sessions in random order with interruption, the assumption that a given thread and its corresponding thread identifier always processes a specific session throughout the thread lifetime is incorrect, thus we cannot directly associate a thread and session via the thread identifier.
Does Oracle provide a way to be notified (native callback) before and/or after a shared server level scheduling "session context switch" so that a thread id could be used to associate a thread with a session at any given time?
Thanks in advance for any insights!
cheers,
Horst Reiterer

You can realize if your database is working in shared mode through several ways:
1.- Looking the background process at the OS level
2.- Looking some init parameters and other methods
What is your OS ?
Joel PÃ©rez
http://otn.oracle.com/experts

How to trace a module that uses shared server sessions?

I have an app (Esri's ArcGIS Server 9.3.1) that I want to trace. Oracle is at 11.2.0.2.0. Our OEM is is at 10.2.0.4.0.
When I initiate a trace for the module (ArcSOC.exe) in OEM, I can see a trace file start to grow larger. But it seems to be a trace file that already exists (example: <instance>s00022493.trc). To isolate activity to just the duration of time I'm interested in, I'd like to start with a fresh trace file. Is there any way to do that? Must I delete currently active trace files or would that cause a failure?
When tracing a dedicated server session, I've noticed that a new trace file will be generated with "ora" in its name. Evidently not so with shared server stuff, whether it's tracing a module or a particular session. When the shared server model is used, it seems Oracle wants to reuse existing trace files. And since trace files an get quite large, it would be difficult to open the trace file in an editor and remove the pre-existing, older activity that I don't want to work with.

See http://www.oracle-base.com/articles/10g/SQLTrace10046TrcsessAndTkprof10g.php for various ways. Delete the trace file before you begin. See http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/sqltrace.htm#i20110

Regarding Alter System Kill Session

Hi Guys,
I have to do db refresh from the build .For this I have to kill the sessions and drop the users and recreate the users with the latest build.As the application is running and there are some idle sessions, I have to kill the sessions and drop the users for that I am using a code as below
DECLARE
v_alt_stmt VARCHAR2(1000) := 'ALTER SYSTEM KILL SESSION ''';
v_kill_stmt VARCHAR2(1000);
CURSOR cur_session IS
SELECT s.type type,
s.sid sid,
s.serial# srl_no,
s.username user_name,
s.PROGRAM prog_name
FROM v$session s JOIN gv$process p ON p.addr = s.paddr and s.type='USER';
BEGIN
EXECUTE IMMEDIATE 'ALTER SYSTEM ENABLE RESTRICTED SESSION';
DBMS_OUTPUT.PUT_LINE('The Session has been put in the restricted mode');
FOR v_cur_ssn IN cur_session
LOOP
BEGIN
v_kill_stmt := v_alt_stmt || v_cur_ssn.sid || ',' || v_cur_ssn.srl_no || '''';
DBMS_OUTPUT.PUT_LINE(v_kill_stmt);
EXECUTE IMMEDIATE v_kill_stmt;
EXCEPTION
WHEN others THEN
-- DBMS_OUTPUT.PUT_LINE('The current sessions sid is ' || v_cur_ssn.sid || ' and the srl no is ' || v_cur_ssn.srl_no || ' can not be killed');
END;
END LOOP;
EXECUTE IMMEDIATE 'ALTER SYSTEM DISABLE RESTRICTED SESSION';
DBMS_OUTPUT.PUT_LINE('The restricted mode of the system has been removed');
END;
But sometimes after killing the sessions there are some os processes are going on,to avoid that I have to use 'ALTER SYSTEM DISCONNECT SESSION ''' and 'MMEDIATE' it is workig fine .
Can Any one tell me the logical difference between kill sessions and disconnect
Any information will be highly appreciated.
Thanks in advance
Prafulla

>
Can Any one tell me the logical difference between kill sessions and disconnect
>
Disconnect can be used to disconnect immediately without waiting for any ongoing transactions to complete and recovers all session resousrces.
Kill rolls back ongoing transactions and partially recovers session resources.
Kill is simiilar to SHUTDOWN IMMEDIATE while disconnect is more like SHUTDOWN ABORT.
See DISCONNECT SESSION Clause in the SQL Language doc
http://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_2013.htm
>
Use the DISCONNECT SESSION clause to disconnect the current session by destroying the dedicated server process (or virtual circuit if the connection was made by way of a Shared Sever).
•The IMMEDIATE setting disconnects the session and recovers the entire session state immediately, without waiting for ongoing transactions to complete.
>
And KILL SESSION in the same doc next section
>
The KILL SESSION clause lets you mark a session as terminated, roll back ongoing transactions, release all session locks, and partially recover session resources.
IMMEDIATE Specify IMMEDIATE to instruct Oracle Database to roll back ongoing transactions, release all session locks, recover the entire session state, and return control to you immediately.

Killed sessions & dispatcher

I killed several inactive sessions but they still exist in v$session, then I found they are all related to D001. I checked v$dispather, D001 owned by nothing. I'm just thinking... can I change MTS_SERVERS to 1 to get rid of D001 and those KILLED sessions from v$session?

>
There are 42 sessions which are KILLED but still present in the v$session view. v$Resource_limit is to keep 300 sessions. My question is: are these killed sessions count for example if v$session is showing 250 rows and out of that 50 are marked Killed. 200 sessions will be counted or 250??
>
250. There is a difference between killing a session and disconnecting a session. And did you use the IMMEDIATE clause of the KILL?
See my answer Posted: Jun 9, 2012 2:08 PM in response to: ADaniel in this thread
why DB file read is still active after the session was killed?
As I said in that thread if you really want the process terminated rather than just 'marked' for termination then use DISCONNECT SESSION with the IMMEDIATE clause
See 'DISCONNECT SESSION Clause' in the SQL Language doc
http://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_2013.htm
>
Use the DISCONNECT SESSION clause to disconnect the current session by destroying the dedicated server process (or virtual circuit if the connection was made by way of a Shared Sever).
The IMMEDIATE setting disconnects the session and recovers the entire session state immediately, without waiting for ongoing transactions to complete.
>
Post the results of using DISCONNECT

Found dead shared server

every day i found this message in the db log :
"Tue Mar 29 22:21:08 2005
found dead shared server 'S000', pid = (10, 5)
Wed Mar 30 13:51:58 2005
found dead shared server 'S000', pid = (10, 6)"
what do it means ??
it is danger for the databse ???

mrashid07 wrote:
In /bdump oracle only provide this information---
found dead shared server 'S000', pid = (17, 49)
How can I find out these processes (17, 49) which made the dead lock event??? There's no evidence from this message that the process was terminated due to a dead lock event.
Oracle also does not terminate a dead lock process - it raises a deadlock exception, allowing the process to catch this exception and re-act on it.
When Oracle does terminate a process, it will be due to some kind of fatal error. In which case there will be an ORA-0600 or similar error message in the alert log, together with a trace file reference (or cdmp ref) that contains the technical details as to what happened.
Dead shared servers are usually caused by an external process (or user) explicitly issuing a command to terminate the shared server process. E.g. killing the shared process at o/s level (using the o/s CLI), or via Oracle using the "+alter system kill session+" command.
You have not shown any evidence yet to the contrary - so the only conclusion that can be made thus far is that Oracle is not an issue here, but application code and/or users are.

"found dead shared server" in alert.log

Hi.
I am getting the following message in the alert log of 10.2.0.2 database.
Fri Feb 2 11:13:54 2007
found dead shared server 'S005', pid = (32, 3)
Fri Feb 2 11:14:24 2007
found dead shared server 'S005', pid = (32, 4)
Fri Feb 2 11:59:48 2007
found dead shared server 'S001', pid = (11, 1)
found dead shared server 'S005', pid = (32, 5)
Fri Feb 2 12:00:04 2007
found dead shared server 'S001', pid = (80, 165)
found dead shared server 'S001', pid = (80, 166)
What does it mean actaully...
will it affect(what impact) my database.
Thanks
JD

Hi,
Are you using MTS feature? If yes,
Then as given in the site:
http://searchoracle.techtarget.com/tip/0,289483,sid41_gci1018471,00.html
major issue I have seen with MTS is the dispatcher process getting abruptly killed. For some unknown reason the dispatcher process all of a sudden dies, killing the connected sessions. The following is an extract from the alert.log file for one such error:
Wed Sep 8 09:07:35 2004
Errors in file /u01/bdump/abc_d050_521.trc:
ORA-07445: exception encountered: core dump [00000001026BA2D4] [SIGSEGV] [Address
not mapped to object] [0x000000018] [] []
Wed Sep 8 09:07:45 2004
found dead dispatcher 'D050', pid = (667, 207)
The dead dispatcher process is restarted once pmon cleans the in-doubt sessions. The workaround for this issue is to turn off the DCD (dead connection detection) feature. Set SQLNET.EXPIRE_TIME = 0 in sqlnet.ora file. This issue occurred in v9.2.0.4 and v9.2.0.5 and Oracle is currently working to resolve the same.
I think you are not using MTS feature, otherwise you would have received errors
like above & trace file would have been generated & error.ORA-07445
If you are not using MTS feature,
set the initialization parameter shared_servers = 0. also make sure that the parameter dispatcher is not set (it has no default) to anything.
Message was edited by:
Seema

ALTER SYSTEM KILL SESSION

Hello Everybody,
1) Is there any difference between “ALTER SYSTEM KILL SESSION & “kill -9”? Which one is the preferred method?
2) When we do alter system kill 'sid, serial#'. Are we killing the user process or the server process?
thanks in advance

Welcome to the forum!
Whenever you post provide your 4 digit Oracle version (result of SELECT * FROM V$VERSION)
>
Hello Everybody,
1) Is there any difference between “ALTER SYSTEM KILL SESSION & “kill -9”? Which one is the preferred method?
2) When we do alter system kill 'sid, serial#'. Are we killing the user process or the server process?
>
You should only use the 'kill' from the OS as a last resort.
There are TWO Oracle options: KILL session and DISCONNECT session. Only rarely, in my experience will DISCONNECT SESSION not get the job done.
See ALTER SYSTEM in the SQL Language doc
http://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_2013.htm
>
end_session_clauses
The end_session_clauses give you several ways to end the current session.
DISCONNECT SESSION Clause
Use the DISCONNECT SESSION clause to disconnect the current session by destroying the dedicated server process (or virtual circuit if the connection was made by way of a Shared Sever). To use this clause, your instance must have the database open. You must identify the session with both of the following values from the V$SESSION view:
•For integer1, specify the value of the SID column.
•For integer2, specify the value of the SERIAL# column.
If system parameters are appropriately configured, then application failover will take effect.
•The POST_TRANSACTION setting allows ongoing transactions to complete before the session is disconnected. If the session has no ongoing transactions, then this clause has the same effect described for as KILL SESSION.
•The IMMEDIATE setting disconnects the session and recovers the entire session state immediately, without waiting for ongoing transactions to complete.
◦If you also specify POST_TRANSACTION and the session has ongoing transactions, then the IMMEDIATE keyword is ignored.
◦If you do not specify POST_TRANSACTION, or you specify POST_TRANSACTION but the session has no ongoing transactions, then this clause has the same effect as described for KILL SESSION IMMEDIATE.
See Also:
"Disconnecting a Session: Example"
KILL SESSION Clause
The KILL SESSION clause lets you mark a session as terminated, roll back ongoing transactions, release all session locks, and partially recover session resources. To use this clause, your instance must have the database open. Your session and the session to be terminated must be on the same instance unless you specify integer3.You must identify the session with the following values from the V$SESSION view:
•For integer1, specify the value of the SID column.
•For integer2, specify the value of the SERIAL# column.
•For the optional integer3, specify the ID of the instance where the target session to be killed exists. You can find the instance ID by querying the GV$ tables.
If the session is performing some activity that must be completed, such as waiting for a reply from a remote database or rolling back a transaction, then Oracle Database waits for this activity to complete, marks the session as terminated, and then returns control to you. If the waiting lasts a minute, then Oracle Database marks the session to be terminated and returns control to you with a message that the session is marked to be terminated. The PMON background process then marks the session as terminated when the activity is complete.
Whether or not the session has an ongoing transaction, Oracle Database does not recover the entire session state until the session user issues a request to the session and receives a message that the session has been terminated.
See Also:
"Terminating a Session: Example"
IMMEDIATE Specify IMMEDIATE to instruct Oracle Database to roll back ongoing transactions, release all session locks, recover the entire session state, and return control to you immediately.

Procedure for Killing sessions

Hi All,
Almost everyday we have requirement to kill user sessions for dev user, I'm thinking to create a procedure for this and grant to the users so that they can kill it by themself.
Below is the what I got from Ask Tom forum, however appreciate if someone can share few information if already imlemented in there environment
<quote>
create or replace procedure kill_session( p_sid in number,
p_serial# in number)
is
ignore pls_integer;
BEGIN
select count(*) into ignore
from V$session
where username = USER
and sid = p_sid
and serial# = p_serial# ;
if ( ignore = 1 )
then
execute immediate '
alter system kill session ''' ||
to_char(p_sid,'999999')||','||
to_char(p_serial#,'999999')||'''';
else
raise_application_error( -20001,
'You do not own session ''' ||
p_sid || ',' || p_serial# ||
end if;
END;/
grant execute on kill_session to <username>
</quote>
Regards,
shaan

rp0428 wrote:
>
Instead of killing session with alter systemn kill session, better you opt for below two methods (still perform the same)
>
Please clarify what you mean. KILL and DISCONNECT do NOT perform the same.
From the SQL Language doc
http://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_2013.htm
KILL is the nice one -
>
The KILL SESSION clause lets you mark a session as terminated, roll back ongoing transactions, release all session locks, and partially recover session resources
>
While DISCONNECT is the ogre
>
Use the DISCONNECT SESSION clause to disconnect the current session by destroying the dedicated server process (or virtual circuit if the connection was made by way of a Shared Sever).
>
The difference between the two is roughly analogous to the difference between SHUTDOWN IMMEDIATE and SHUTDOWN ABORT.
I agree that, for OPs use case DISCONNECT (with IMMEDIATE or POST TRANSACTION) may be better since it gets rid of things immediately while KILL can leave things hanging around for a while.From the same link:
DISCONNECT SESSION Clause:
The POST_TRANSACTION setting allows ongoing transactions to complete before the session is disconnected. If the session has no ongoing transactions, then this clause has the same effect described for as KILL SESSION.
The IMMEDIATE setting disconnects the session and recovers the entire session state immediately, without waiting for ongoing transactions to complete.
If you also specify POST_TRANSACTION and the session has ongoing transactions, then the IMMEDIATE keyword is ignored.
If you do not specify POST_TRANSACTION, or you specify POST_TRANSACTION but the session has no ongoing transactions, then this clause has the same effect as described for KILL SESSION IMMEDIATE.
basically the difference is not between DISCONNECT and KILL SESSION, the difference exists if you allow pending/ongoing transactions to finish(IMMEDIATE vs POST_TRANSACTION)
Edited by: Keilor on Jun 25, 2012 12:57 PM
Edited by: Keilor on Jun 25, 2012 1:39 PM

Not able to get Shared Server Mode to work in XE

The server is an HP Dual CPU Xeon, 4 GB RAM. 120GB HD.
Oracle XE reports the following:
SGA 768 Target, 768MB Current.
PGA 256MB Target, 55MB current (when there are a small number of client connections)
The application and database work properly with a small number of connections, but
memory usage goes way up on PGA when I start to add more connections.
I have tried to set up the Oracle server in "Shared Server Mode" , but it appears
that I was unsuccessful.
From what I can tell, the oracle listener does not seem to be fowarding the incoming requests to the shared server dispatchers, but
instead it is deciding to kick off a dedicated server process to handle each client request.
In other words, it is working in dedicated server mode.
I am stumped as to what needs to be done next. From what
I can tell from reading documentation this should be working.
Please advice as to what else I can do to get things working.
Here is additional information:
The parameter SHARED_SERVERS is equal to 4.
parameter dispatchers=(PROTOCOL=TCP) (SERVICE=XEXDB)
max_shared_servers, max_dispatchers, shared_server_sessions have no values.
processes=150
sessions=170
Output of lnsrctl utility:
LSNRCTL> services
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC_FOR_XE)))
Services Summary...
Service "CLRExtProc" has 1 instance(s).
Instance "CLRExtProc", status UNKNOWN, has 1 handler(s) for this service...
Handler(s):
"DEDICATED" established:0 refused:0
LOCAL SERVER
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
Handler(s):
"DEDICATED" established:0 refused:0
LOCAL SERVER
Service "XEXDB" has 1 instance(s).
Instance "xe", status READY, has 1 handler(s) for this service...
Handler(s):
"D000" established:0 refused:0 current:0 max:1002 state:ready
DISPATCHER <machine: CO_DB, pid: 5844>
(ADDRESS=(PROTOCOL=tcp)(HOST=myhostname)(PORT=1771)
Service "XE_XPT" has 1 instance(s).
Instance "xe", status READY, has 1 handler(s) for this service...
Handler(s):
"DEDICATED" established:0 refused:0 state:ready
LOCAL SERVER
Service "xe" has 1 instance(s).
Instance "xe", status READY, has 1 handler(s) for this service...
Handler(s):
"DEDICATED" established:0 refused:0 state:ready
LOCAL SERVER
The command completed successfully
ILSNRCTL> status
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC_FOR_XE)))
STATUS of the LISTENER
Alias LISTENER
Version TNSLSNR for 32-bit Windows: Version 10.2.0.1.0 - Produ
ction
Start Date 18-SEP-2007 16:06:55
Uptime 0 days 0 hr. 1 min. 33 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Default Service XE
Listener Parameter File E:\oraclexe\app\oracle\product\10.2.0\server\network\a
dmin\listener.ora
Listener Log File E:\oraclexe\app\oracle\product\10.2.0\server\network\l
og\listener.log
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(PIPENAME=\\.\pipe\EXTPROC_FOR_XEipc)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=myhostname)(PORT
=1521)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=127.0.0.1)(PORT=8080))(Presentation=
HTTP)(Session=RAW))
Services Summary...
Service "CLRExtProc" has 1 instance(s).
Instance "CLRExtProc", status UNKNOWN, has 1 handler(s) for this service...
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
Service "XEXDB" has 1 instance(s).
Instance "xe", status READY, has 1 handler(s) for this service...
Service "XE_XPT" has 1 instance(s).
Instance "xe", status READY, has 1 handler(s) for this service...
Service "xe" has 1 instance(s).
Instance "xe", status READY, has 1 handler(s) for this service...
The command completed successfully
The contents of the spfile2init.ora file:
xe.__db_cache_size=104857600
xe.__java_pool_size=4194304
xe.__large_pool_size=469762048
xe.__shared_pool_size=222298112
xe.__streams_pool_size=0
*.audit_file_dest='E:\oraclexe\app\oracle\admin\XE\adump'
*.background_dump_dest='E:\oraclexe\app\oracle\admin\XE\bdump'
*.compatible='10.2.0.1.0'
*.control_files='E:\oraclexe\oradata\XE\control.dbf'
*.core_dump_dest='E:\oraclexe\app\oracle\admin\XE\cdump'
*.db_name='XE'
*.db_recovery_file_dest='f:\oracle_flash_recovery_area'
*.db_recovery_file_dest_size=42949672960
*.dispatchers='(PROTOCOL=TCP) (SERVICE=XEXDB)'
*.job_queue_processes=4
*.open_cursors=300
*.os_authent_prefix=''
*.pga_aggregate_target=268435456
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sessions=20
*.sga_target=805306368
*.shared_servers=4
*.undo_management='AUTO'
*.undo_tablespace='UNDO'
*.user_dump_dest='E:\oraclexe\app\oracle\admin\XE\udump'
The contents of listener.ora:
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = E:\oraclexe\app\oracle\product\10.2.0\server)
(PROGRAM = extproc)
(SID_DESC =
(SID_NAME = CLRExtProc)
(ORACLE_HOME = E:\oraclexe\app\oracle\product\10.2.0\server)
(PROGRAM = extproc)
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC_FOR_XE))
(ADDRESS = (PROTOCOL = TCP)(HOST = myhostname)(PORT = 1521))
DEFAULT_SERVICE_LISTENER = (XE)
The contents of tnsnames.ora
XE =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = myhostname)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = XE)
EXTPROC_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC_FOR_XE))
(CONNECT_DATA =
(SID = PLSExtProc)
(PRESENTATION = RO)
ORACLR_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC_FOR_XE))
(CONNECT_DATA =
(SID = CLRExtProc)
(PRESENTATION = RO)
The contents of sqlnet.ora:
# This file is actually generated by netca. But if customers choose to
# install "Software Only", this file wont exist and without the native
# authentication, they will not be able to connect to the database on NT.
SQLNET.AUTHENTICATION_SERVICES = (NTS)

I don't think it is supported because of XE multiple cpu usage limitations but "shared server" is not documented in the XE documentation - http://www.oracle.com/pls/xe102/ranked?word=%22shared+server%22
so you may want to follow this guide for setup and try -
http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/manproc.htm#ADMIN00502
Best Regards,
H.Tonguç YILMAZ
My Oracle blog
http://tonguc.wordpress.com
"Never believe all you read or hear! Just because it is printed or someone is more experienced doesn't mean it is TRUE.."

When we go for shared Server environment?

When we go for shared Server environment from Dedicated server mode?
When we have to choose thi shared Server mode?
Which is the optimized way?

> When we go for shared Server environment from Dedicated server mode?
You do not. It is not one or the other - it is using both correctly. You want shared server sessions to service applications (any, from web/app servers to flat clients) that are OLTP in nature. They fire off short-and-sweet SQLs that takes a second or three to execute.
A shared server pool of a few processes can service a very large number of clients.
You want to use dedicated servers to service OLAP type clients. They fire off complex SQLs that can tie up the server processes for several minutes at a time.
And that in a nutshell is how to apply the two. It is not Shared Servers versus Dedicated Server. It is about using The Right Tool For The Job. Nothing more and nothing less.
As for Windows, I will not really bother quickly with shared server connections. On Windows both shared and dedicated servers runs as threads in the main Oracle executable process image.
There is thus very little resource saving by reducing the number of threads as the footprint of a thread is tiny in comparison to a brand new process. The amount of resources saved by a reducing the number of dedicated server threads is not significant. If anything, Oracle on Windows has shown to scale better than Oracle on Linux in this regard. (refer to [url http://www.perftuning.com/pdf/Comparison_Oracle_Windows_Linux.pdf]A Comparison of Oracle Database 10gR2 Real Application Cluster Performance on Microsoft Windows 2003 Server Enterprise Edition x64 and Red Hat Enterprise Linux x86_64 from the Performance Tuning Corporation).
And this is exactly the opposite of how Oracle behaves on Unix. Each server process is a physical kernel process. This means that a servicing a 1000 concurrent sessions with a 1000 dedicated server processes, each consuming memory and resources, are expensive. Conversely, supporting a 1000 concurrent sessions with a 100 shared server processes is (almost) 90% cheaper.
This makes Shared Server a desirable option to use to scale OLTP sessions on Unix-based systems (or any platform where Oracle does not use multi-threading but multi-processing).
PS. As the Linux kernel support Posix threads (see http://en.wikipedia.org/wiki/Native_POSIX_Thread_Library), it begs the question as to when Oracle is going to support multi-threading on Linux instead of multi-processing.. or at least give us the option to choose.

How to config the server in shared server mode?

SQL> alter system set dispatchers='(protocol=tcp)(dispatchers=10)' ;
System altered.
SQL> alter system set shared_servers=5;
System altered.
then config the client connection to shared server mode thru` net manager
and try the qq user on another pc in lan.
but it failed to use shared sever mode
SQL> col username for a10
SQL> col machine for a30
SQL> col server for a10
SQL> set linesize 120
SQL> select username,server,machine from v$session where username is not null;
USERNAME SERVER MACHINE
QQ NONE WORKGROUP\HYC-PC
SYS DEDICATED rhel5
QQ user server type is NONE
RED HAT linux or windows platform are the same result

938261 wrote:
SQL> alter system set dispatchers='(protocol=tcp)(dispatchers=10)' ;
System altered.
SQL> alter system set shared_servers=5;
System altered.
then config the client connection to shared server mode thru` net manager
and try the qq user on another pc in lan.
but it failed to use shared sever mode
SQL> col username for a10
SQL> col machine for a30
SQL> col server for a10
SQL> set linesize 120
SQL> select username,server,machine from v$session where username is not null;
USERNAME SERVER MACHINE
QQ NONE WORKGROUP\HYC-PC
SYS DEDICATED rhel5
QQ user server type is NONE
RED HAT linux or windows platform are the same resultDEDICATED vs. SHARED is controlled by the client; not by DB Server

Killed sessions

Hi,
I kill a session with the commands:
select username, sid, serial#, status from v$session where username like 'RION%'
alter system kill session 'sid, serial#'
and if I give again the first select command at the status column appears KILLED. I want not to have KILLED in the status column.
Thank you,
Mihaela

hi all,
As u know you are seeing the status of at v$session view as killed, I wanna confirm that this will exists in two senario.
When a Session is in inactive state and a kill command on that session is issued then the "status" column of v$session will be updated as killed as to indicate/mark as it is killed, and the "server " column will be updated as psuedo. when the user again try to connect to the session user will receive 0ra-00028 error and the entry will be removed from v$session.
Another senario is that the transaction is at its half way, either in commiting or at the roleback stage for that partucular session then also you can find that the v$table is updated as above.
more information, go through the documentation, at the Server Process handling section.
i hope it cleared your confussion,

Shared server config issues

Dear experts,
Below is my environment details:
DB: Oracle 10gR1 Base (10.2.0.1)
OS: RHEL 5
I have configured shared servers as shown below:
1) Set the following parameters
dispatchers='(protocol=tcp)(dispatchers=2)'
max_dispatchers=10
shared_servers=4
max_shared_servers=10
circuits (not configured)
2) Changed TNS parameter as below
I modified SERVER=DEDICATED to SERVER=SHARED
3) lsnrctl services
the output of this command shows dispatchers ready
Now coming to the issue, when i connect to the database using new tns alias, i see "NONE" displayed under "SERVER" column of the V$SESSION view. It should have been SHARED.
Appreciate your help in this regard.
Thanks
P

In Shared Server configuration when we see value 'NONE' , it means there is no task being processed by shared server for that session. The server column will infact show status of 'SHARED' if there is some task being processed at that particular time by the shared server process for that session. Hence to check the status, fire some big query and then check the server status .
you can check the shared server as
select server from v$session where machine='XXXX' ;--neeraj

Kill session in shared server

Similar Messages

Maybe you are looking for