"Dan's Oracle7 Guide" - mts_setup (enhanced)

From: Daniel B. Bikle <dbikle_at_alumni.cco.caltech.edu>
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

Original text of this message