"Dan's Oracle7 Guide" - mts_setup (enhanced)
Date: 20 Sep 1993 06:21:00 GMT
Message-ID: <DBIKLE.93Sep19232100_at_alumni.cco.caltech.edu>
Keywords: Oracle7
mts_setup
Setting up the Multi Threaded Server is a simple two step procedure. In the example discussed below, we will describe setting up a Multi Threaded Server for TCP/IP connections. Other types of connections are possible (decnet and sockets for example). Setting up the Multi Threaded Server for them is similar to the example below. The example below assumes that the DBA has already set up and started the Listener. For a discussion about how to set up and start the Listener, read the section entitled listener_setup.
First, we set the following Init Parameters:
MTS_SERVICE MTS_SERVERS MTS_DISPATCHERS MTS_MAX_SERVERS MTS_MAX_DISPATCHERS
Descriptions and examples of the Init Parameters are displayed below:
MTS_SERVICE
This is the name of service for the dispatchers. The Dispatchers send the name of this service to the Listener when they register with the Listener. MTS_SERVICE should be a simple character string. Setting it to an ORACLE_SID makes it easy to remember.
example:
MTS_SERVICE = x7
MTS_SERVERS
This is the minimum number of server processes waiting for connections when the instance is running.
example:
MTS_SERVERS = 2 MTS_DISPATCHERS
This is the minimum number of dispatcher processes waiting for connections when the instance is running.
example:
MTS_DISPATCHERS = "tcp,2"
MTS_MAX_SERVERS
This is the maximum number of server processes waiting for connections when the instance is running.
example:
MTS_MAX_SERVERS = 5 MTS_MAX_DISPATCHERS
This is the maximum number of dispatcher processes waiting for connections when the instance is running.
example:
MTS_MAX_DISPATCHERS = 5 At this point the setup of the Multi Threaded Server is nearly complete.
After specifying the above Init Parameters in the Init file and bouncing the database, a process listing might look like the one displayed below:
USER PID %CPU %MEM SZ RSS TT STAT START TIME COMMAND o7 357 0.0 6.6 212 1424 ? S 13:28 0:00 ora_pmon_x7 o7 358 0.0 7.1 208 1544 ? S 13:28 0:00 ora_dbwr_x7 o7 359 0.0 7.4 208 1592 ? S 13:28 0:00 ora_lgwr_x7 o7 360 3.2 13.1 332 2832 ? S 13:28 0:01 ora_smon_x7 o7 361 0.0 0.0 208 0 ? IW 13:28 0:00 ora_reco_x7 o7 362 0.0 1.0 208 212 ? S 13:28 0:00 ora_s000_x7 o7 363 0.0 1.0 208 212 ? S 13:28 0:00 ora_s001_x7 o7 367 0.0 0.0 224 1588 ? IW 13:28 0:00 ora_d000_x7 o7 368 0.0 7.4 224 1588 ? I 13:28 0:00 ora_d001_x7
To some DBA's the above process listing would be enough proof that both the dispatcher and the shared server have started. Additional verification may be obtained by querying the two data dictionary views V$DISPATCHER and V$SHARED_SERVER. Canned queries for inspecting the contents of both V$DISPATCHER and V$SHARED_SERVER are displayed later.
The final step to setting up the Multi Threaded Server is setting up the tnsnames.ora file on the client side of the network.
The default location for the file on a SunOS client running "ORACLE7 Server Release 7.0.12.1.0 - Production" is $ORACLE_HOME/network/admin/tnsnames.ora. An environment variable named TNS_ADMIN (which specifies a directory path) may affect where the client executable goes to resolve the sqlnet alias. Additionally, the client executable might try to resolve the sqlnet alias by looking in the .tnsnames.ora file in the user's home directory. An example tnsnames.ora (and .tnsnames.ora) file is displayed below:
# tnsnames.ora
# alias naming convention: host_sid
ava2_x7 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP) (HOST = ava2) (PORT = 2525) )
)
(CONNECT_DATA =
(SID = x7)
)
)
# end of tnsnames.ora
Once the file tnsnames.ora has been installed on the client, the following command should connect the user to the server:
setenv TWO_TASK ava2_x7; sqlplus scott/tiger (this is another way: sqlplus scott/tiger_at_ava2_x7)
A process listing for this type connection is displayed below:
USER PID %CPU %MEM SZ RSS TT STAT START TIME COMMAND dan 484 0.0 0.0 204 0 pa IW 18:20 0:00 sqlplus o7 139 0.0 2.4 212 520 ? S 11:02 0:00 ora_pmon_x7 o7 141 0.0 2.6 208 556 ? S 11:02 0:00 ora_dbwr_x7 o7 142 0.0 2.3 208 496 ? S 11:02 0:00 ora_lgwr_x7 o7 143 0.0 0.0 332 0 ? IW 11:02 0:04 ora_smon_x7 o7 144 0.0 0.0 228 0 ? IW 11:02 0:00 ora_reco_x7 o7 145 0.0 0.0 292 0 ? IW 11:02 0:05 ora_s000_x7 o7 146 0.0 0.6 220 132 ? S 11:03 0:02 ora_s001_x7 o7 147 0.0 0.0 252 0 ? IW 11:03 0:05 ora_d000_x7 o7 148 0.0 0.0 240 0 ? IW 11:03 0:04 ora_d001_x7
Notice that no shadow process was spawned from the sqlplus process. If we complete a similar connection on a V6 database, a shadow process will appear in the process listing:
USER PID %CPU %MEM SZ RSS TT STAT START TIME COMMAND dan 331 0.0 2.0 152 424 pa S 12:25 0:00 /q/o6/bin/sqlplus o6 134 0.0 0.6 188 136 ? S 11:02 0:00 ora_pmon_x6 o6 137 0.0 1.3 320 288 ? S 11:02 0:00 ora_dbwr_x6 o6 138 0.0 1.0 236 224 ? S 11:02 0:00 ora_lgwr_x6 o6 140 0.0 0.0 300 0 ? IW 11:02 0:01 ora_smon_x6 o6 337 0.0 4.8 188 1040 ? S 12:26 0:00 oraclex6 T:I,,5
Additional information about the Oracle7 connection may be obtained by querying some of the V$ views:
Querying V$DISPATCHER
A simple query and its results are displayed below:
select
substr(NAME,1,4) NAME /* dispatcher process name */ ,substr(NETWORK,1,7) NETWORK /* network name (tcp, decnet) */ ,substr(STATUS,1,6) STATUS /* waiting, sending, ... etc */ ,ACCEPT||' ' ACCEPT /* accepting connections ? */ ,MESSAGES /* # messages processed */ ,BYTES/1024 KBYTES /* # kbytes processed */ ,BREAKS /* # breaks processed */ ,OWNED /* # circuits owned */ ,CREATED /* # circuits created */ ,IDLE/100/60 MINUTES_IDLE_TIME /* dispatcher idle time (min) */ ,BUSY/100 SECONDS_BUSY_TIME /* dispatcher busy time (sec)*/from v$dispatcher
/
Example results:
NAME NETWORK STATUS ACCEPT MESSAGES KBYTES BREAKS OWNED ---- ------- ------ ------ ---------- ---------- ---------- ----------
CREATED MINUTES_IDLE_TIME SECONDS_BUSY_TIME
---------- ----------------- ----------------- D000 tcp WAIT YES 0 0 0 0 0 233.193333 13.83 D001 tcp WAIT YES 0 0 0 0 0 233.121333 16.07
Querying V$SHARED_SERVER
A simple query and its results are displayed below:
SELECT
SUBSTR(NAME,1,4) NAME /* server process name */ ,SUBSTR(STATUS,1,12) STATUS /* executing, sending, ... etc */ ,MESSAGES /* # messages processed */ ,BYTES/1024 KBYTES /* # kbytes processed */ ,BREAKS /* # breaks processed */ ,IDLE/100/60 MINUTES_IDLE_TIME /* shared_server idle time (min) */ ,BUSY/100 SECONDS_BUSY_TIME /* shared_server busy time (sec)*/ ,REQUESTS REQUESTS /* # requests taken from request que */FROM V$SHARED_SERVER
/
Example results:
NAME STATUS MESSAGES KBYTES BREAKS MINUTES_IDLE_TIME
---- ------------ ---------- ---------- ---------- -----------------SECONDS_BUSY_TIME REQUESTS
----------------- ---------- S000 WAIT(COMMON) 324 14.1171875 0 90.6008333 7.58 162 S001 WAIT(COMMON) 48 1.79492188 0 90.683 .58 24
Querying V$QUEUE
A simple query and its results are displayed below:
select * from v$queue
/
Example results:
PADDR TYPE QUEUED WAIT TOTALQ -------- ---------- ---------- ---------- ----------
00 COMMON 0 524 624 00 OUTBOUND 0 0 0 E0013928 DISPATCHER 0 132 482 E0013AA4 DISPATCHER 0 155 348 E0013C20 DISPATCHER 0 0 0
The results displayed above make more sense when viewed after thinking about the discussion below:
A front-end process (sqlplus for example) places a request for a Dispatcher on the network. A Listener responds to the request by sending the address of a Dispatcher to the front-end process.
The front-end process uses the address to connect to the Dispatcher.
Once they are connected, the front-end process sends requests to the Dispatcher which then puts them in a single Request-queue. A server process picks requests off of the Request-queue, interacts with the buffer cache and dbs files, and then places results in one of several Response-queues. Finally, the Dispatcher pulls completed requests off of one of the Response-queues and sends them to the front-end process.
So, the discussion above clarifies the following points: The rows of type DISPATCHER correspond to the Response-queues. The row of type COMMON corresponds to the single Request-queue. What about the row of type OUTBOUND? According to the DBA guide, this queue corresponds to a single Request-queue for remote servers.
Querying V$MTS
A simple query and its results are displayed below:
SELECT /* v$mts displays #'s for instance since last startup */
MAXIMUM_CONNECTIONS /* max # connections for each dispatcher */ ,SERVERS_STARTED /* # servers automatically spawned */ ,SERVERS_TERMINATED /* # servers killed after they were not needed*/ ,SERVERS_HIGHWATER /* max # of simultaneous servers running at any */ FROM V$MTS /* moment since last startup *//
Example results obtained after pushing the dbs through a flurry of activity:
MAXIMUM_CONNECTIONS SERVERS_STARTED SERVERS_TERMINATED SERVERS_HIGHWATER
------------------- --------------- ------------------ ----------------- 29 12 9 5
A process listing was obtained from the machine during the flurry of activity to verify the above query:
% ps -aux | grep x7
o7 352 0.0 4.0 212 872 ? S 09:20 0:00 ora_pmon_x7 o7 353 0.0 4.0 208 856 ? S 09:20 0:01 ora_dbwr_x7 o7 354 0.0 3.7 208 792 ? S 09:20 0:00 ora_lgwr_x7 o7 355 0.0 0.0 332 0 ? IW 09:20 0:02 ora_smon_x7 o7 356 0.0 0.0 228 0 ? IW 09:20 0:00 ora_reco_x7 o7 357 0.0 0.6 280 132 ? S 09:20 1:03 ora_s000_x7 <- o7 358 0.0 0.6 276 132 ? S 09:20 0:52 ora_s001_x7 <- o7 455 10.3 24.1 220 5200 ? R 09:34 0:05 ora_s002_x7 <- o7 456 9.5 24.6 220 5292 ? R 09:34 0:04 ora_s003_x7 <- o7 457 9.5 23.7 220 5108 ? R 09:34 0:03 ora_s004_x7 <- o7 359 0.0 1.1 276 236 ? S 09:20 0:22 ora_d000_x7 o7 360 0.0 1.1 276 236 ? S 09:20 0:19 ora_d001_x7 o7 361 0.0 1.1 244 228 ? S 09:21 0:00 ora_d002_x7
The scripts used to generate the flurry of activity are displayed below:
#! /bin/csh -f
# mtstst.sh
# tests connections to mts
setenv ORACLE_HOME /q/o7
setenv ORACLE_SID x7
setenv TWO_TASK ava2_x7
set path = ($ORACLE_HOME/bin $path)
# run a set of scripts to make the dbs busy
$ORACLE_HOME/bin/sqlplus / _at_mtstst.sql > mtstst.1.out & $ORACLE_HOME/bin/sqlplus / _at_mtstst.sql > mtstst.2.out & $ORACLE_HOME/bin/sqlplus / _at_mtstst.sql > mtstst.3.out & $ORACLE_HOME/bin/sqlplus / _at_mtstst.sql > mtstst.4.out & $ORACLE_HOME/bin/sqlplus / _at_mtstst.sql > mtstst.5.out & $ORACLE_HOME/bin/sqlplus / _at_mtstst.sql > mtstst.6.out & $ORACLE_HOME/bin/sqlplus / _at_mtstst.sql > mtstst.7.out & $ORACLE_HOME/bin/sqlplus / _at_mtstst.sql > mtstst.8.out & $ORACLE_HOME/bin/sqlplus / _at_mtstst.sql > mtstst.9.out & $ORACLE_HOME/bin/sqlplus / _at_mtstst.sql > mtstst.10.out &
# wait a minute for the dbs to get busy
sleep 66
# obtain a process listing
ps -aux |fgrep x7 > mtstst.ps.out
# query the v$mts table; quote the $ sign so the shell doesn't
# interpret it
$ORACLE_HOME/bin/sqlplus / > qrymts.lst << endofsql
select * from v\$mts
/
endofsql
# end of mtstst.sh
####################################################
rem
rem mtstst.sql
rem
SET ECHO ON
SELECT * FROM DICT ; SELECT * FROM V$MTS ; SELECT * FROM V$CIRCUIT ; SELECT * FROM V$DISPATCHER ; SELECT * FROM V$SESSION ; SELECT * FROM V$SHARED_SERVER ; SELECT * FROM DBA_TABLES ; SELECT * FROM DBA_INDEXES ; SELECT * FROM DBA_SYNONYMS ; SELECT * FROM CAT ;
EXIT
rem end of mtstst.sql
The discussion above points out the obvious observation: V$MTS contains some of the information a DBA needs to pick a suitable value for for MTS_SERVERS. If SERVERS_STARTED and SERVERS_TERMINATED are 0 and SERVERS_HIGHWATER = MTS_SERVERS, then the instance has not been very busy since it was last started; the DBA might consider lowering the value of MTS_SERVERS if the instance has been up a long time.
Querying a Join of several of the V$ Tables
Some queries which join several of the tables are displayed below:
set echo on
spool qryckt
rem
rem qryckt.sql
rem
REM QUERIES V$CIRCUIT, V$DISPATCHER, AND V$SESSION REM V$SHARED_SERVER, V$ACCESS
SET ECHO ON SELECT
SES.OSUSER UNIXNAME ,SES.PROCESS OS_PID ,SUBSTR(SES.USERNAME,1,11) ORACLE_NAME ,D.NAME||' ' DSPTCHR ,SS.NAME SRVR ,Q.QUEUED FROM V$CIRCUIT C, V$DISPATCHER D, V$SESSION SES, V$SHARED_SERVER SS, V$QUEUE Q WHERE C.DISPATCHER = D.PADDR AND C.SADDR = SES.SADDR AND C.DISPATCHER = Q.PADDR AND C.CIRCUIT = SS.CIRCUIT (+)
/
REM HERE'S ANOTHER QUERY WHICH PROVIDES INFO ABOUT THE OBJECTS REM WHICH THE SHARED SERVER IS PROVIDING TO THE DISPATCHER SELECT
SES.OSUSER UNIXNAME ,SES.PROCESS OS_PID ,SUBSTR(SES.USERNAME,1,11) ORACLE_NAME ,D.NAME||' ' DSPTCHR ,SS.NAME SRVR ,SUBSTR(A.OWNER||'.'||A.OBJECT,1, 17) OBJECT ,SUBSTR( DECODE(A.OB_TYP, 0, 'NEXT OBJECT', 1, 'INDEX', 2, 'TABLE', 3, 'CLUSTER', 4, 'VIEW', 5, 'SYNONYM', 6, 'SEQUENCE', 7, 'PROCEDURE', 8, 'FUNCTION', 9, 'PACKAGE', 11, 'PACKAGE BODY', 12, 'TRIGGER', 'UNDEFINED'), 1,9) OB_TYPE FROM V$CIRCUIT C, V$DISPATCHER D, V$SESSION SES, V$SHARED_SERVER SS, V$ACCESS A WHERE C.DISPATCHER = D.PADDR AND C.SADDR = SES.SADDR AND SES.SID = A.SID AND C.SERVER = SS.PADDR (+)
/
EXIT rem end of qryckt.sql
Example results from the first query:
UNIXNAME OS_PID ORACLE_NAME DSPTCHR SRVR QUEUED ---------- --------- ----------- ------- ----- ----------
dan 462 OPS$DAN D000 S001 0 dan 433 SCOTT D001 S000 0
Example results from the second query:
UNIXNAME OS_PID ORACLE_NAME DSPTCHR SRVR OBJECT OB_TYPE
---------- --------- ----------- ------- ----- ----------------- --------- dan 460 OPS$DAN D000 S001 OPS$DAN.V$ACCESS NEXT OBJE dan 460 OPS$DAN D000 S001 OPS$DAN.V$CIRCUIT NEXT OBJE dan 460 OPS$DAN D000 S001 OPS$DAN.V$DISPATC NEXT OBJE dan 460 OPS$DAN D000 S001 OPS$DAN.V$SESSION NEXT OBJE dan 460 OPS$DAN D000 S001 PUBLIC.V$DISPATCH SYNONYM dan 460 OPS$DAN D000 S001 PUBLIC.V$SHARED_S SYNONYM dan 460 OPS$DAN D000 S001 SYS.V$CIRCUIT VIEW dan 460 OPS$DAN D000 S001 SYS.V$SESSION VIEW dan 460 OPS$DAN D000 S001 SYS.V_$ACCESS VIEW dan 460 OPS$DAN D000 S001 SYS.V$SHARED_SERV VIEW dan 460 OPS$DAN D000 S001 SYS.X$KMMDI TABLE dan 460 OPS$DAN D000 S001 SYS.X$KMCVC TABLE dan 460 OPS$DAN D000 S001 SYS.X$KGLOB TABLE dan 460 OPS$DAN D000 S001 SYS.X$KGLLK TABLE dan 460 OPS$DAN D000 S001 SYS.X$KGLDP TABLE dan 460 OPS$DAN D000 S001 SYS.V_$SHARED_SER VIEW dan 460 OPS$DAN D000 S001 SYS.V_$SESSION VIEW dan 460 OPS$DAN D000 S001 SYS.V_$DISPATCHER VIEW dan 460 OPS$DAN D000 S001 SYS.X$KSUSE TABLE dan 460 OPS$DAN D000 S001 SYS.X$KMMSI TABLE dan 460 OPS$DAN D000 S001 SYS.V_$CIRCUIT VIEW dan 460 OPS$DAN D000 S001 SYS.V$DISPATCHER VIEW dan 460 OPS$DAN D000 S001 SYS.V$ACCESS VIEW dan 460 OPS$DAN D000 S001 PUBLIC.V$SESSION SYNONYM dan 460 OPS$DAN D000 S001 PUBLIC.V$CIRCUIT SYNONYM dan 460 OPS$DAN D000 S001 PUBLIC.V$ACCESS SYNONYM dan 460 OPS$DAN D000 S001 OPS$DAN.V$SHARED_ NEXT OBJE dan 433 SCOTT D001 S000 PUBLIC.DICT SYNONYM dan 433 SCOTT D001 S000 SCOTT.DICT NEXT OBJE dan 433 SCOTT D001 S000 SYS.COM$ TABLE dan 433 SCOTT D001 S000 SYS.OBJ$ TABLE dan 433 SCOTT D001 S000 SYS.X$KZSPR TABLE dan 433 SCOTT D001 S000 SYS.V$ENABLEDPRIV VIEW dan 433 SCOTT D001 S000 SYS.SYN$ TABLE dan 433 SCOTT D001 S000 SYS.DICTIONARY VIEW
Summary
A quick checklist outlining the above discussion is displayed below:
-Start the Listener
-Define Init Params; bounce database: MTS_SERVICE MTS_SERVERS MTS_DISPATCHERS MTS_MAX_SERVERS MTS_MAX_DISPATCHERS -Create one of the following files: $ORACLE_HOME/network/admin/tnsnames.ora $TNS_ADMIN/tnsnames.ora ~/.tnsnames.ora -Attempt connection: setenv TWO_TASK ava2_x7; sqlplus scott/tiger -Use process listings and V$ queries to verify the connection is to the MTS rather than a dedicated server
Specifying the Pipe Driver
Many customers prefer to run in a non-client/server mode. Meaning they login to the server and run applications there. This may be accomplished by setting an environment variable named ORAPIPES to one of two values:
setenv ORAPIPES V1
The syntax above will cause a "V1" type connection to occur (whatever that means).
A process listing for this type connection is displayed below:
USER PID %CPU %MEM SZ RSS TT STAT START TIME COMMAND dan 484 0.0 0.0 204 0 pa IW 18:20 0:00 sqlplus o7 485 0.0 10.3 212 2228 ? S 18:20 0:00 oraclex7 P:4096,6,9,
The second value and it's result is displayed below:
setenv ORAPIPES V2
USER PID %CPU %MEM SZ RSS TT STAT START TIME COMMAND dan 505 0.0 5.1 224 1108 pa S 18:32 0:00 sqlplus o7 507 0.0 11.5 228 2484 ? S 18:32 0:00 oraclex7
The two types of connections above are sometimes called dedicated server connections. An obvious question might arise during this discussion, "How do I connect to the MTS using the 'Pipe Driver'?" The answer is, "Pipes can only pass information between a parent process and a child process. Since the MTS needs to communicate with many processes, it cannot use pipes to communicate with them." Pipes are only useful to a dedicated server which has been spawned by a foreground-parent process such as sqlplus.
UNIX does provide a communication mechanism called "sockets" which allows many foreground processes to communicate with a single MTS.
Using Sockets
Sockets enable us to connect a foreground process to the MTS without relying on the network. A set of values for the listener.ora, tnsnames.ora, and various Init Params are displayed below for a ORACLE V7.0.12 instance:
# listener.ora
# customized from ~network/config/samples/server/listener.ora
# The next line below is the name of the listener alias.
# The default name of the listener alias is "LISTENER".
# If you define a name other than "LISTENER", remember to
# put the name in the lsnrctl command line when you start
# the listener.
# example: lsnrctl start SOCLISTENER
#
SOCLISTENER =
(ADDRESS_LIST=(ADDRESS=(PROTOCOL=soc)(KEY=5165)))
STARTUP_WAIT_TIME_SOCLISTENER = 0
CONNECT_TIMEOUT_SOCLISTENER = 10
SID_LIST_SOCLISTENER =
(SID_LIST=(SID_DESC=(SID_NAME = x7)(oracle_home=/q/o7)))
PASSWORDS_SOCLISTENER = hellox7
## TRACE_LEVEL_SOCLISTENER = ON
TRACE_LEVEL_SOCLISTENER = OFF
# end of listener.ora
# tnsnames.ora
# alias naming convention: soc_sid
soc_x7=(DESCRIPTION=(ADDRESS=(PROTOCOL=soc)(KEY=5165))
(CONNECT_DATA=(SID=x7)))
# end of tnsnames.ora
Appropriate Init Params for the "sockets" protocol are displayed below:
MTS_LISTENER_ADDRESS = "(ADDRESS=(PROTOCOL=soc)(KEY=5165))" MTS_SERVICE = x7 MTS_SERVERS = 2 MTS_DISPATCHERS = "soc,1" MTS_MAX_SERVERS = 5 MTS_MAX_DISPATCHERS = 5
The discussion about sockets above is valid for ORACLE V7.0.12.
The socket driver for ORACLE V7.0.13 is implemented a bit differently. The name of the driver is "ipc" rather than "soc". Also, the key is alphanumeric rather than numeric.
These changes are illustrated below:
# listener.ora -- ORACLE V7.0.13
# customized from ~network/config/samples/server/listener.ora
# The next line below is the name of the listener alias.
# The default name of the listener alias is "LISTENER".
# If you define a name other than "LISTENER", remember to
# put the name in the lsnrctl command line when you start
# the listener.
# example: lsnrctl start IPCLISTENER
#
IPCLISTENER =
(ADDRESS_LIST=(ADDRESS=(PROTOCOL=ipc)(KEY=ipc_x7)))
STARTUP_WAIT_TIME_IPCLISTENER = 0
CONNECT_TIMEOUT_IPCLISTENER = 10
SID_LIST_IPCLISTENER =
(SID_LIST=(SID_DESC=(SID_NAME = x7)(oracle_home=/q/o7)))
PASSWORDS_IPCLISTENER = hellox7
## TRACE_LEVEL_IPCLISTENER = ON
TRACE_LEVEL_IPCLISTENER = OFF
# end of listener.ora
# tnsnames.ora
# alias naming convention: ipc_sid
ipc_x7=(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=ipc_x7))
(CONNECT_DATA=(SID=x7)))
# end of tnsnames.ora
Appropriate Init Params for the "sockets" protocol are displayed below:
MTS_LISTENER_ADDRESS = "(ADDRESS=(PROTOCOL=ipc)(KEY=ipc_x7))" MTS_SERVICE = x7 MTS_SERVERS = 2 MTS_DISPATCHERS = "ipc,1" MTS_MAX_SERVERS = 5 MTS_MAX_DISPATCHERS = 5 ============================================================================Received on Mon Sep 20 1993 - 08:21:00 CEST