5.3 Database Initialization File Changes MTS is configured in your instance parameter file ( INIT.ORA ), and not in listener.ora or any other of the Net8 configuration files. At first this may seem rather odd, but it makes some sense. The dispatcher and shared server processes are tied to the instancethey are actually considered part of the instance, so it makes sense to configure them in the same place that you configure the rest of the instance.  | The specific initialization parameters used to configure MTS have changed significantly over the past several releases of Oracle. This chapter focuses on MTS configuration for Oracle8 i . | | The following initialization parameters are the ones you need to set, or modify, when configuring an instance for MTS: - MTS_DISPATCHERS
- MTS_SERVERS
- MTS_MAX_SERVERS
- MTS_MAX_DISPATCHERS
- LOCAL_LISTENER
- LARGE_POOL
Implementing MTS can be as simple as adding one or more MTS_DISPATCHERS parameters to your instance parameter file, and then stopping and restarting your instance. It's likely, however, that you're going to want to adjust some of these other parameters as well, as described in the following sections. 5.3.1 MTS_DISPATCHERS MTS_DISPATCHERS is the key initialization parameter that you need to set in order to implement MTS. The syntax is similar to what is used in Net8 configuration files such as the listener.ora fileyou end up with a list of name /value pairs that are enclosed within parentheses. 5.3.1.1 MTS_DISPATCHERS for standard connections In a very simple case, you can enable MTS simply by specifying the protocol to support, thereby accepting default values for all the other options. You could, for example, use the following settings to support TCP/IP and SPX connections under MTS: MTS_DISPATCHERS="(PROTOCOL=TCP)" MTS_DISPATCHERS="(PROTOCOL=SPX)" More reasonably, you will want to specify the number of dispatchers that you want for each protocol and possibly place a limit on the number of connections that each dispatcher is allowed to handle. The following attribute settings would give you four TCP/IP dispatchers and one SPX dispatcher, with each dispatcher able to handle up to 100 connections: MTS_DISPATCHERS="(PROTOCOL=TCP)(DISPATCHERS=4)(CONNECTIONS=100)" MTS_DISPATCHERS="(PROTOCOL=SPX)(DISPATCHERS=1)(CONNECTIONS=100)"  | All MTS_DISPATCHERS parameter settings must be grouped together in your instance parameter file. Blank lines are okay, but do not place any other parameter settings between two MTS_DISPATCHERS settings. If you do, you'll encounter an error when you start your instance. | | You can find the complete syntax for MTS_DISPATCHERS, showing all possible attributes, in Appendix F. Some attributes are related to connection pooling and multiplexing, so those are also discussed in Chapter 9. 5.3.1.2 The MTS_DISPATCHERS LISTENER attribute The LISTENER attribute of the MTS_DISPATCHERS parameter allows you to specify the listener with which the dispatchers should register. By default, dispatchers register with the listener that is monitoring port 1521 on the local machine. If you want your dispatchers to register with a listener assigned to a different port, or a listener running on another machine, you need to use the LISTENER attribute to specify that. For example: MTS_DISPATCHERS="(PROTOCOL=TCP)(DISPATCHERS=4) \ (LISTENER=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP) \ (PORT=1523)(HOST=DONNA.GENNICK.ORG))))" The LISTENER attribute defines an ADDRESS_LIST containing one or more listener addresses. The dispatchers will then register with each of those listeners. | | There is also a LOCAL_LISTENER initialization parameter that provides the same functionality as the MTS_DISPATCHER parameter's LISTENER attribute. The LISTENER attribute overrides the LOCAL_LISTENER parameter and is recommended by Oracle. | | 5.3.1.3 MTS_DISPATCHERS for IIOP connections If you use the Internet Inter-Orb Protocol (IIOP) to support connections to Enterprise JavaBeans and CORBA objects, you need to configure MTS dispatchers to support that as well. IIOP is an implementation of the General Inter-Orb Protocol (GIOP) running over TCP/IP, and IIOP connections use a different presentation layer from standard Oracle client connections; you specify that using the PRESENTATION attribute in your MTS_DISPATCHERS setting. | | Enterprise JavaBeans and the CORBA server only support MTS connections. If you use those features, you need to configure MTS to support them. | | There are two possible values that you can use for the PRESENTATION attribute: - oracle.aurora.server.SGiopServer
-
Configures a dispatcher to handle session-based GIOP connections, and is valid with TCP/IP and TCP/IP with the Secure Socket Layer (SSL). - oracle.aurora.server.GiopServer
-
Configures a dispatcher to handle standard GIOP connections, and is valid for TCP/IP, but not for TCP/IP with SSL. Oracle's Java Virtual Machine (JVM) is session-basedeach database session effectively has its own JVM, and Oracle recommends the use of the session-based IIOP presentation. Here are a couple of sample MTS_DISPATCHERS settings that support session-based GIOP connections: MTS_DISPATCHERS="(PROTOCOL=TCP)(PRESENTATION=oracle.aurora.SGiopServer) \ (DISPATCHERS=4)" MTS_DISPATCHERS="(PROTOCOL=TCPS)(PRESENTATION=oracle.aurora.SGiopServer) \ (DISPATCHERS=4)" The first entry creates four dispatchers in support of session-based GIOP running over TCP/IP. The second entry is just like the first, except that TCP/IP with SSL is used. | | The backslash (\) is the line continuation character used in instance parameter files. It indicates that a long parameter entry has been continued to the next line. | | 5.3.1.4 Forcing an address with MTS_DISPATCHERS Just as the listener has a network address that it monitors , so do the MTS dispatchers. Normally, you can specify the protocol to support, and allow the dispatcher to decide on an address automatically. Under some circumstances, it may be necessary to manually specify all or part of the address that the dispatchers use. You can do that by replacing the PROTOCOL attribute with either an ADDRESS or a DESCRIPTION attribute. The following example uses an ADDRESS attribute and specifies the IP address for the dispatchers to use. Note the use of (PARTIAL = TRUE) in the address definition. The choice of port number is still left up to the dispatchers. MTS_DISPATCHERS="(ADDRESS=(PARTIAL=TRUE)(PROTOCOL=TCP) \ (HOST=(10.11.12.13)) \ (DISPATCHERS=4)(CONNECTIONS=100)" You can force both the address and the port number, but if you do that, you need to configure each dispatcher separately. Two dispatchers cannot share the exact same address. Here's an example: MTS_DISPATCHERS="(ADDRESS=(PARTIAL=TRUE)(PROTOCOL=TCP) \ (HOST=donna.gennick.org)(PORT=1217)) \ (DISPATCHERS=1)(CONNECTIONS=100)" MTS_DISPATCHERS="(ADDRESS=(PARTIAL=TRUE)(PROTOCOL=TCP) \ (HOST=donna.gennick.org)(PORT=1218)) \ (DISPATCHERS=1)(CONNECTIONS=100)" MTS_DISPATCHERS="(ADDRESS=(PARTIAL=TRUE)(PROTOCOL=TCP) \ (HOST=donna.gennick.org)(PORT=1219)) \ (DISPATCHERS=1)(CONNECTIONS=100)" MTS_DISPATCHERS="(ADDRESS=(PARTIAL=TRUE)(PROTOCOL=TCP) \ (HOST=donna.gennick.org)(PORT=1220)) \ (DISPATCHERS=1)(CONNECTIONS=100)" One reason to force the port number for dispatchers is to get around firewall issues. When dispatcher addresses are automatically assigned, chances are they will be assigned to a port that is blocked by the firewall. When you specify the port number manually, you can then open up that specific port in your firewall and allow outside users access to your database. In addition to the ADDRESS parameter, you can also use the DESCRIPTION parameter to specify a full or partial dispatcher address. See Appendix F for details. Obsolete MTS Parameters Oracle's implementation of MTS has evolved since it was first released. It used to be a separately installable option, but because of Oracle8 i 's JVM, MTS is now included with the base install. Releases of Oracle prior to Oracle8 i implemented several MTS parameters that are now considered obsolete: - MTS_LISTENER_ADDRESS
- MTS_MULTIPLE_LISTENERS
- MTS_RATE_LOG_SIZE
- MTS_RATE_SCALE
- MTS_SERVICE
Even though it is still used, the MTS_DISPATCHERS parameter has an obsolete syntax associated with it. That obsolete syntax, along with many of these obsolete parameters, are still supported for purposes of backward compatibility, and it's possible that you may encounter them. While not discussed in this chapter, these obsolete parameters are documented in Appendix F. | 5.3.2 MTS_SERVERS and MTS_MAX_SERVERS The MTS_SERVERS and MTS_MAX_SERVERS parameters mentioned earlier in this chapter control the number of shared server processes that will be available to service MTS connections. MTS_SERVERS specifies the number of shared server processes to create at instance startup. This also serves as a minimumOracle won't reduce the number of shared servers below this number. MTS_MAX_SERVERS places an upper limit on the number of shared servers that can be running at any given time. If you wanted an upper limit of 100 shared server processes, and you wanted to use 25 as a starting point, you would place the following two parameters in your instance parameter file: MTS_SERVERS = 25 MTS_MAX_SERVERS = 100 On Linux and Unix systems, you can use the ps command after you start your instance to see the shared server processes. The command in the following example displays all the processes running for the instance named donna. The processes with s xxx in their names , where xxx is a number, are the shared server processes: [oracle@donna oracle]$ ps -ef grep donna oracle 539 1 0 18:45 ? 00:00:00 ora_pmon_donna oracle 541 1 0 18:45 ? 00:00:00 ora_dbw0_donna oracle 543 1 0 18:45 ? 00:00:00 ora_lgwr_donna oracle 545 1 0 18:45 ? 00:00:00 ora_ckpt_donna oracle 547 1 0 18:45 ? 00:00:01 ora_smon_donna oracle 549 1 0 18:45 ? 00:00:00 ora_reco_donna oracle 551 1 0 18:45 ? 00:00:06 ora_s000_donna oracle 552 1 0 18:45 ? 00:00:06 ora_s001_donna oracle 553 1 0 18:45 ? 00:00:00 ora_d000_donna oracle 555 1 0 18:45 ? 00:00:00 ora_arc0_donna oracle 663 651 0 21:41 pts/0 00:00:00 grep donna While an instance is running, the number of shared server processes is increased and decreased as needed. However, the number of shared server processes never exceeds the limit specified by MAX_SHARED_SERVERS and will never drop below the value specified by MTS_SERVERS. The MTS_MAX_SERVERS parameter is static and cannot be changed while an instance is running. MTS_SERVERS, on the other hand, is dynamic, and can be changed using the ALTER SYSTEM command. 5.3.3 MTS_MAX_DISPATCHERS The MTS_MAX_DISPATCHERS parameter allows you to place an upper limit on the number of dispatcher processes that may be running at any one time. The default value for this parameter is 5. However, any value that you specify is subject to modification based on the total number of dispatchers that you initially configure for the instance. Take a look at the following parameter settings: MTS_DISPATCHERS="(PROTOCOL=TCP)(DISPATCHERS=8)(CONNECTIONS=100)" MTS_DISPATCHERS="(PROTOCOL=SPX)(DISPATCHERS=4)(CONNECTIONS=100)" MTS_MAX_DISPATCHERS=8 The MTS_MAX_DISPATCHERS value in this example is 8. However, that value will silently be adjusted upward to 12 because a total of 12 dispatchers (8 for TCP/IP and 4 for SPX) have been configured for the instance. Why have a limit if that limit is adjusted upwards when the instance starts? The reason for the limit is that once an instance is running, you can allocate additional dispatchers using the ALTER SYSTEM command. You can also use ALTER SYSTEM to reduce the number of dispatchers. When you start an instance, memory is going to be allocated for the number of dispatchers that you configure. You use MTS_MAX_DISPATCHERS to have the instance set aside memory for possible additional dispatchers. 5.3.4 LOCAL_LISTENER The LOCAL_LISTENER parameter serves the same purpose as the LISTENER attribute of the MTS_DISPATCHERS parameter. It identifies the listener, or listeners, with which the MTS dispatchers should register. The complete syntax is described in Appendix F, but here are a few representative examples: LOCAL_LISTENER = "(ADDRESS_LIST= \ (ADDRESS= \ (PROTOCOL=TCP) \ (HOST=donna.gennick.org) \ (PORT=1523)))" LOCAL_LISTENER = "(ADDRESS_LIST= \ (ADDRESS= \ (PROTOCOL=TCP) \ (HOST=localhost) \ (PORT=1521)) \ (ADDRESS= \ (PROTOCOL=IPC)(KEY=database_name)))" The first example specifies one listener address. Because the port number is 1523 rather than the default 1521, that address represents a non-default listener. The second example shows two addresses and also represents the default value for the LOCAL_LISTENER parameter. As you can see, the default LOCAL_LISTENER setting points directly to the port used by the default Net8 Listener. Which should you use, the LOCAL_LISTENER parameter or the MTS_DISPATCHERS LISTENER attribute? Both are valid. Using the LISTENER attribute gives you finer control, because you can have different dispatchers register with different listeners. LOCAL_LISTENER, on the other hand, applies globally. At the time that we're writing this book, Oracle is recommending the use of the LISTENER attribute because the Oracle Net8 Configuration Assistant does not allow you to set the LOCAL_LISTENER parameter. 5.3.5 LARGE_POOL While LARGE_POOL is not specifically an MTS parameter, it's something you need to look at when implementing MTS. If your instance does not have a large pool configured, then the session memory for all MTS connections is allocated from the shared pool. Having MTS use the shared pool for session memory is not what Oracle recommends, because it can lead to shared pool fragmentation, which then can lead to a drop in performance. If you configure a large pool, then MTS session-specific memory will come from that, leaving the shared pool relatively unaffected. The following LARGE_POOL parameter settings show three different ways to configure a 32-megabyte large pool: LARGE_POOL = 32M LARGE_POOL = 32768K LARGE_POOL = 33554432 For information on sizing the large pool to accommodate MTS session memory, see Section 5.2.5 earlier in this chapter.  | 
