Oracle 10g Simplified Shared Server Configuration
In Oracle 10g, you no longer need to set as many initialization parameters for shared server environments. In fact, you only need to set one parameter if you are using TCP/IP as your communication protocol, and the rest of the settings are now managed internally.
Shared Server Initialization Parameters
The following initialization parameters in Oracle 10g control shared server operation:
shared_servers – This parameter specifies the initial number of shared servers to start and the minimum number of shared servers to keep. This is the only required parameter for using shared servers. Setting this to a non-zero value automatically specifies shared server.
max_shared_servers – This parameter specifies the maximum number of shared servers that can run simultaneously. Once shared server is initialized, the Oracle system will increase the number of shared servers up to this value as needed.
shared_server_sessions -- This parameter specifies the total number of shared server user sessions that can run simultaneously. Setting this parameter enables you to reserve user sessions for dedicated servers. For example, if the sessions parameter is set at 1000 and you set shared_server_sessions to 900, then 100 dedicated sessions are available, even if all 900 shared sessions are in use.
dispatchers – This parameter configures dispatcher processes in the shared server architecture. One dispatcher is always configured by default for the TCP/IP protocol, even if the parameter is not explicitly specified.
max_dispatchers – This parameter specifies the maximum number of dispatcher processes that can run simultaneously. According to the Oracle 10g manuals, this parameter can be ignored for now. It will only be useful in a future release when the number of dispatchers is auto-tuned, according to the number of concurrent connections.
circuits – This parameter specifies the total number of virtual circuits that are available for inbound and outbound network sessions.
Even though there are six initialization parameters, shared server is enabled by setting one parameter and is turned on if the shared_servers initialization parameter is set to a value greater than 0. This is all that is required. The other shared server initialization parameters do not need to be set. Because the shared server parameter requires at least one dispatcher to work, a dispatcher is brought up automatically even when no dispatcher has been configured.
Using SQL*Plus or OEM, the shared server features can be started dynamically by setting the shared_servers parameter to a nonzero value
Get the complete Oracle10g story:
The above text is an excerpt from "Oracle Database 10g New Features: Oracle10g Reference for Advanced Tuning and Administration", by Rampant TechPress. Written by top Oracle experts, this book has a complete online code deport with ready to use scripts.
The switch from dedicated server to shared server is easy. You begin by editing the init.ora file for your instance. You will need to either add in a line for dispatchers, or edit the existing line (When creating a database with DBCA on Windows, Oracle adds in a line even if you don't request dispatchers. So, be aware of the fact that you may just be changing that line).
At minimum, you will need:
dispatchers="(protocol=tcp)"
A more complete configuration would be:
dispatchers="(protocol=tcp)(dispatchers=2)(service=mydatabase)"
The (dispatchers=2) that you see tells oracle to spawn 2 dispatchers at startup.
Configuring dispatchers can get more elaborate. Unless you have experience and documentation for setting up a more advanced configuration, it is probably better to allow Oracle to give you default values for everything else. A complete list of possible dispatcher parameters is here:
dispatch_clause::= (PROTOCOL = protocol) | (ADDRESS = address) | (DESCRIPTION = description ) [options_clause] options_clause::= (DISPATCHERS = integer | SESSIONS = integer | CONNECTIONS = integer | TICKS = seconds | POOL = {1 | ON | YES | TRUE | BOTH | ({IN | OUT} = ticks) | 0 | OFF | NO | FALSE | ticks} | MULTIPLEX = {1 | ON | YES | TRUE | 0 | OFF | NO | FALSE | BOTH | IN | OUT} | LISTENER = tnsname | SERVICE = service | INDEX = integer ) There are some other parameters you will likely want to set as long as you are working on dispatchers. Here is an example: ########################################### # DISPATCHERS ########################################### dispatchers="(protocol=tcp)(dispatchers=2)(service=test)" ## shared servers on startup shared_servers=2 ## maximum shared server sessions shared_server_sessions=200 ## Maximum Shared Servers max_shared_servers=20 ## Maximum Dispatchers max_dispatchers=20Once you have changed your init.ora file and bounced your database, how can you tell if connections are going through dispatchers? There are a number of dynamic performance views that can tell you this, for example v$session, v$dispatcher, v$queue. To keep things easy, I just create my own view that gives me the data I like to see:
CREATE OR REPLACE FORCE VIEW SYSTEM.CURRENT_CONNECTIONS (SID, SERIAL#, USERNAME, OSUSER, STATUS, "SCNDS NOT ACTIVE", DISPATCHER) AS SELECT /* ©2004 by Edward Stoever, edward@database-expert.com */ s.SID, s.serial#, s.username, s.osuser, s.status, DECODE (s.username, NULL, 0, s.last_call_et) "SCNDS NOT ACTIVE", NVL (d.NAME, 'none') "DISPATCHER" FROM v$session s, v$dispatcher d WHERE s.paddr = d.paddr(+) ORDER BY status ASC, last_call_et ASC; CREATE PUBLIC SYNONYM CURRENT_CONNECTIONS FOR SYSTEM.CURRENT_CONNECTIONS; Sample output: select * from system.current_connections; SID SERIAL# USERNAME OSUSER STATUS SCNDS NOT ACTIVE DISPAT ------ ------- ------------ ------------ -------- ---------------- ------ 15 167 SYSTEM STOEVER ACTIVE 0 none 11 10 GENERAL GURJOBS_TEST ACTIVE 12535 none 1 1 @ ORACLE ACTIVE 0 none 2 1 @ ORACLE ACTIVE 0 none 3 1 @ ORACLE ACTIVE 0 none 4 1 @ ORACLE ACTIVE 0 none 5 1 @ ORACLE ACTIVE 0 none 6 1 @ ORACLE ACTIVE 0 none 7 1 @ ORACLE ACTIVE 0 none 8 1 @ ORACLE ACTIVE 0 none 18 176 WTAILOR jbautista INACTIVE 12 D000 16 191 WTAILOR jbautista INACTIVE 132 D001 10 212 WTAILOR jbautista INACTIVE 134 D001 13 119 WEB_USER SYSTEM INACTIVE 314 D000 14 20 SYSTEM vlugo INACTIVE 721 D001Now you can see who is connecting and how, either via a dispatcher or via a dedicated connection.
Does this mean that all connections from now on will be through a dispatcher? No. There are plenty of cases in which you will want or even require a connection that is dedicated. For example, to shutdown the database, a dedicated connection is required. Also, many processes are recource intensive and will perform better with a dedicated connection. To create a dedicated connection, you will need to edit the TNSNAMES.ORA file on the machine from which the connection originates. Here is an example:
### SHARED CONNECTION TO TEST DATABASE TEST_SHARED = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = alpha2)(PORT = 1521)) ) (CONNECT_DATA = (SERVER = SHARED) (SERVICE_NAME = test) ) ) ### DEDICATED CONNECTION TO TEST DATABASE TEST_DEDICATED = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = alpha2)(PORT = 1521)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = test) ) )Now, to connect via a dispatcher, try this:
SQLPLUS scott/tiger@test_sharedto connect via a dedicated server process, try this:
SQLPLUS scott/tiger@test_dedicated[출처] [펌] from dedicated to shared server|작성자 새내기
