8. Oracle Shared Server 튜닝

- 목표
  > Oracle Shared Server 환경에서의 유저 관리 문제 식별
  > 성능 최적화를 위한 Oracle Shared Server 환경 구성
  > Oracle Shared Server 프로세스를 사용하여 성능 문제 진단 및 해결
 
- 디스패처 모니터 
  > 서버가 디스패처를 자동으로 시작하거나 정지하지 않기 때문에 디스패처 사용률을 모니터해야 한다.
  > v$shared_server_monitor
    >> 연결 및 세션 제한과 세션의 현재 사용현황을 확인할 수 있다. 
    >> sessions 가 디스패처에 대한 실제 제한보다 적게 설정되어 있으면 sessions 파라미터 값이 기본적으로 maximum_connections 의 값으로 설정된다.
  > v$dispatcher
    >> 디스패처 경합 식별
       select network Protocol, status,
              sum(owned) Client,
              sum(busy) * 100 / (sum(busy) + sum(idle)) Busy_Rate
       from v$dispatcher
       group by network, status;
  > 디스패처의 사용률이 50%를 넘으면 디스패처 수의 증가 고려
    유저는 해당 세션이 끝날 때까지 동일한 디스패처에 바인드 되므로 새로 연결할 경우에만 새 디스패처를 사용할 수 있다.
    ALTER SYSTEM SET dispatchers = 'protocol, number';
  > 유저 세션 대기 여부 조회, 평균 대기 시간은 1/100 초 단위로 나타난다.
    select decode(sum(totalq), 0, 'No Responses', sum(wait) / sum(totalq)) avg_wait_time
    from v$queue q, v$dispatcher d
    where q.type = 'DISPATCHER'
      and q.paddr = d.paddr;  
  > v$dispatcher_rate
      
- Shared Server 모니터
  > max_shared_servers 값이 현재 사용 가능한 서버 수보다 높으면 기존의 Shared Server 가 사용되고 있을 때 PMON 백그라운드 프로세스가 Oracle Shared Server 프로세스를 동적으로 시작한다.
    그리고, Shared Server 가 Idle 상태에 있을 때 Shared Server 수가 shared_servers 에 도달할 때까지 PMON 이 Shared Server 를 제거한다.
    다음 명령을 사용하여 Shared Server 를 추가하거나 제거한다.
    ALTER SYSTEM SET SHARED_SERVERS = number;
  > v$shared_server
    select name, requests,
           busy * 100 / (busy + idle), status
    from v$shared_server
    where status != 'QUIT';
  > v$queue
    select decode(totalq, 0, 'No Requests', wait/totalq || 'hundredths of seconds')
    from v$queue
    where type = 'COMMON';    
   
- 문제 해결
  > Shared Server 를 사용하면 startup 및 shutdown 과 같은 권한이 필요한 작업을 수행할 수 없다. 이 경우 Dedicated Server 를 사용해야 한다.
  > 배치 작업 등 사용률이 많은 작업은 Dedicated Server 를 사용해야 한다.   
 
- 관련 Dictionary
  > v$circuit : 데이터베이스에 대한 유저 연결 정보
  > v$dispatcher : 디스패처 프로세스에 대한 정보
  > v$dispatcher_rate : 디스패처 프로세스에 대한 비율 통계
  > v$queue : 다중 스레드 메시지 큐에 대한 정보
  > v$shared_server_monitor : Shared Server 연결을 튜닝하는데 유용한 정보
  > v$shared_server : Shared Server 프로세스에 대한 정보
  > select d.network, d.name disp, s.username oracle_user, s.sid, s.serial#,
           p.username os_user, p.terminal, s.program
    from v$dispatcher d, v$circuit c, v$session s, v$process p
    where d.paddr = c.dispatcher(+)
      and c.saddr = s.saddr(+)
      and s.paddr = p.addr(+)
    order by d.network, d.name, s.username;
    

ORACLE - Shared Server와 Dedicated Server의 접속 방식

---

 

 

• 이전에 봤던 그림이랑 다르네요. ㅡ.,ㅡ 물론, 데이터베이스 버퍼 캐시 등도 있지만,
• 설명을 하기 편하게 하기 위해, 생략 하였습니다.

• 사용자 프로세스가 Dedicated Server를 통해 접속

 

• 반면 Shared Server를 통하면 여러개의 백그라운드 프로세스를 통하여 접속 및 처리가 가능하게 됩니다.
• DO0 , DO1...은 디스패쳐입니다.
• Conn hr/hr 이 L에 돌아갔다가 오는데, 이것은 리다이렉트 방식입니다.

• 이렇게 프로세스는 적지만 다량의 작업이 가능하기 때문에, 서버에 부하가 적습니다.
• 하지만, 반환하는 시간이 Dedicated Server 보다는 조금 더 오래 걸릴 수 있습니다.
• Shared Server를 사용한다고 해서, Dedicated Server를 사용하지 못하는 것은 아닙니다.
  • Shared Server를 사용하면, 서버 프로세스들간의 Road Balance가 되어서 idle(논다)프로세스가 줄어들어서 작업에 효율을 높일 수 있습니다.

PPT 참고 설명

---

• Dedicated Server

  

  • 클라이언트가 명령문을 요청해서 처리하는 동안에만 동작하는 프로세스 입니다.

 

• Shared Server

  
  
  

  

  • 미리 정의된 프로세스들이 사용자의 접속이 없어도 이렇게 실행되어 있습니다.
  • 사용자는 Dispatcher 들을 통해서 간접적으로 접속하여 반환하게 됩니다.
    

---

# 기타 설명

• Dedicated Server에서는 공유할 필요가 없기 때문에, 각각의 명령문을 PGA에 저장되어 사용됩니다.
• 반면, Shared Server Processor 들도 PGA가 있긴 하지만, 각각의 명령문을 공유해야 하기 때문에 Stack정보를 제외하고 나머지는 SGA에 들어가면서 UGA로 명칭만 변경되어 공유가 됩니다.
• 이 UGA 는 기본적으로 Shared Pool에 들어가게 되고, 접속자가 늘어날 경우에는 이 UGA공간도 늘어납니다.
• Shared Server 구조에서는 Large Pool 사이즈를 지정하여, UGA가 들어갈 수 있도록 사용해줘야 합니다.(기본 0)
  • Shared Server 구조는 다중 시스템(프로세스가 여러개)일 때 효율적입니다.
• Shared Server를 구성할 때에는 Spfile Shared_Servers = 를 몇개이다 라고 지정해야 하며,
• Dispatchers = 역시 속성등도 구성을 해줘야 합니다.
  • 그 중에, Connection 개수를 지정해 주는데, 예로 Conn = 30 이면, 최대 90명이 접속가능 합니다.
  • 또한 Pool = on 속성을 사용할 수 있으며, 이것을 사용하면 세션 기능도 사용가능하여 Connection을 더 증가시킬 수 있습니다.
    • 예 : Dispatchers = (conn = 30)
                                (Pool = on)
                                (sess = 50)
    • 풀링기능을 활성화 시킴으로써 더 많은 사용자들을 수용할 수 있습니다.
  • Connection Manager 라는 미들티어를 구성할 수 있는데, 이것은 별도의 기기에 구성하여 서버로 사용해야 합니다.
  • 사용자는 이 미들티어를 통해서 접속하며, 미들티어는 사용자의 다중접속을 서버에게는 단일 접속으로 처리하도록 해줍니다.

    

  • ▲오라클 Connection Manager

---

 Oracle Shared Server의 이점

• Instance에 대한 Process 수를 줄인다.
• 허용되는 User수를 증가시킨다.
• 로드 밸런싱을 수행한다.
  • 서버프로세스의 로드밸런스
• 휴지 Server Process의 수를 줄인다.
• 메모리 사용량과 시스템 오버헤드를 줄인다.
  • 주로 메모리에 대한 오버헤드는 많이 줄어들지만, CPU에 대한 오버헤드는 증가합니다.

 

 Oracle Shared Server와 함께 Dedicated Server 사용

---

 

절차상의 차이점은 있지만, 둘다 리스너를 통해서 가야합니다.

또한 항상 디스패쳐당 접속수가 동일하게 유지하도록 해야 합니다.

이렇게 디스패쳐에 연결되기 위해서는 Remote와 Server의 접속방식이 동일해야 합니다.

SYSDBA가 접속할 때는 LOCAL 이던 무엇이던간에 무조건 전용서버가 할당됩니다.

• 사용자는 Request Queue를 통해 간접적으로 전하고, 반환을 받습니다.
• Response Queue는 Dispatcher당 하나씩 가지고 있습니다.

• Shared Pool 및 다른 메모리구조 : Larger Pool 입니다. Large Pool은 이러한 문제로 인해 반드시 설정해야 합니다.

---

Oracle Shared Server의 구성

• 필수 초기화 Parameter
  • DISPATCHERS
  • SHARED_SERVERS
    • 똑똑합니다. 동적으로 MAX 값까지 필요하면 늘여줍니다. 하지만, 줄이는건 동적이지 못합니다.
      
• 선택적 초기화 Parameter
  • MAX_DISPATCHERS
  • MAX_SHARED_SERVERS
    • 이 MAX 값은 Default값이 있기 때문에 선택적 값입니다.
  • CIRCUITS
    • Shared Server를 통한 경로. Response, Request를 통한....
    • 이것은 값을 튜닝해서 서버의 성능을 높이거나 하진 않지만, 값을 높여 놓으면 나중에 오라클이 인지를 하게 되고, 나중에 오라클이 Queue 사이즈를 크게 조정하거나 합니다.
    • 단, 큐를 키우게 되면 SGA의 다른 요소가 영향을 받습니다.
  • SHARED_SERVER_SESSIONS
    • Shared Server Sessions 을 모두 제한하는 파라미터 입니다.
    • 만약, 6개의 세션이 등록되었다면, 6개의 세션이 실행하고 있다는 뜻이 됩니다.
    • V$Session을 조회하면, 혼자 작업 중인데도 많은 세션이 동작중임을 볼 수 있습니다.
    • 1명이 쓰는데도 많이 접속한 것을 볼 수 있지요.
    • Shared_Server_Sessions의 값은 항상 낮게 설정해야 합니다. 그래야만, 나중에 Shared Server가 꽉 차더라도 공간을 보장해줘서 후에, Dedicated Server를 예약할 수 있도록 합니다.
      
      
      

• 지정된 프로토콜에 대해 처음에 시작된 Dispatcher 수를 지정합니다.
• \는 줄바꿈표시 ㅡ.,ㅡ
• DISPATCHERS 매개변수
  데이터베이스 관리자는 DISPATCHERS 매개변수를 사용하여 각 디스패처에 대해 다양
  한 속성을 설정합니다.
  Oracle9i는 Oracle Net 서비스에서 사용되는 구문과 유사한 이름-값 구문을 지원하여 기
  존 속성과 추가 속성의 사양을 위치 독립적이며 대소문자를 구분하지 않는 방식으로 설
  정합니다.
  예:

Oracle Database Configuration Assistant를 사용하여 이 매개변수를 구성할 수 있습니다.

Dispatchers의 파라미터

 

• PROTOCOL
• ADDRESS
• DESCRIPTION
• DISPATCHERS
• SESSIONS
• LISTENER
• CONNECTIONS

---

• 동시에 실행될 수 잇는 최대 디스패쳐 프로세스 수 지정합니다.
• 처음 시작 시보다 더 많은 디스패쳐를 지정이 가능합니다.

---

 

• 인스턴스가 시작될 때 생성할 서버 프로세스의 수를 지정합니다.
• 이것은 Alter  명령어를 이용하여 늘리거나 줄일 수 있습니다.

---

 

• 시작 가능한 최대 Shared Server수를 지정합니다.
• 직접 조정하지 않아도, 나중에 오라클서버가 자동으로 늘렺부니다.
• Request Queue의 길이에 따라 공유서버의 구성이 달라집니다.

---

 

• 수신 및 송신 네트워크 세션에 사용할 수 있는 가상 Circuit의 총 수를 지정합니다.
• 전체 SGA 크기에 영향을 줍니다.

---

• 허용되는 Oracle Shared ServerUser 세션의 총 수를 지정합니다.
• 이 파라미터를 설정하면 전용서버에 대한 사용자 세션을 예약할 수 있습니다.
• LARGE_POOL_SIZE : UGA를 사용하기 위해 라지풀을 조정한다.

---

▶ 설정 확인

• 위의 명령을 실행하여 인스턴스가 시작될 때 디스패쳐가 리스너에 등록되었는지 확인합니다.
• 단일 연결을 설정하여 공유 서버를 통해 연결한 다음 V$Circuit 뷰를 질의하여 Shared Server 연결 당 하나의 항목만 표시되는지 확인합니다.

▶ 동적 뷰

• V$CIRCUITS
• V$SHARED_SERVER
• V$DISPATCHER
• V$SHARED_SERVER_MONITOR
• V$QUEUE
• V$SESSION
  

Shared Server (MTS) Diagnostics [ID 1005259.6]
		수정 날짜 29-SEP-2011     유형 BULLETIN     상태 PUBLISHED

In this Document
  Purpose
  Scope and Application
  Shared Server (MTS) Diagnostics
  References

---

Applies to:

Oracle Server - Enterprise Edition - Version: 8.1.5.0 to 10.2.0.1 - Release: 8.1.5 to 10.2
Oracle Net Services - Version: 8.1.5.0.0 to 10.2.0.1.0   [Release: 8.1.5 to 10.2]
Information in this document applies to any platform.

Purpose

Introduction

This document contains information about the Shared Server configuration of the Oracle Database software and some of the SQL scripts necessary to gather diagnostic information with guidelines for interpreting results. Prior to Oracle 9.0, Shared Server was called Multi-Threaded Server; the name was changed to reflect the extensive enhancements made.

Scope and Application

Skill level rating for this Article: Intermediate

Shared Server (MTS) Diagnostics

Architecture of the Shared Server Database Configuration

The best position to be in will always be based on understanding. The components of the Shared Server database configuration consist of the Dispatchers and the Shared Servers. These components run as separate processes in the operating system (or threads in some operating systems). They interact with each other through the use of a Common Queue (CQ - also known as the Virtual Queue, of which there could be multiple CQs) and individual Dispatcher Queues. Both queues reside in the Shared Global Area (SGA) and are sized automatically by the database itself. Another component of Shared Server is not a process but an abstraction of the user session(more of an owned pointer), called a Virtual Circuit (VC). The communication between the Dispatchers and Shared Servers is primarily done by passing ownership of a Virtual Circuit from one to another.

Fig. 1: Diagram of Shared Server Architecture

 

The stages that Shared Server goes through are quite simple. After the client sends the connection request to the Listener, it will either redirect or hand off (called warm hand-off) the connection to the Dispatcher (the Dispatcher does not necessarily need to be on the same host as the Listener). Once the client has connected to a Dispatcher it stays connected to that Dispatcher. Before the client completes the database log in, the Dispatcher associates a Virtual Circuit (VC) for that database session. There exists exactly one row in the VC view (V$CIRCUIT) for each client connection. This view also shows the current status of the client's VC. Once the VC has been associated with the database session, the client will complete the database logon by passing the username and password to the Dispatcher. This request, as part of the VC for that new session, will be placed in the Common Queue where the first available Shared Server will complete the logon. Once each phase of the logon has completed, the Shared Server will pass the VC back to the Dispatcher, which then passes the response back to the Client (this actually takes several round trips to the client, in just the same manner as if it was a Dedicated connection).

Once the logon has completed, the client starts a normal conversation with the database. When the client makes a request to the database, it is the Dispatcher that picks up this request from the operating system's network protocol. The Dispatcher then determines which client session the request came from (remember that a Dispatcher can be configured for Connection Pooling and Multiplexing: see the Net Administration Guide for more information on those configurations), tags that sessions' VC that there is a new message (there is also a pointer to that session buffer in the VC) and places the VC in the Common Queue. The CQ is serviced by the Shared Servers on a first-in-first-out basis. The next available Shared Server pulls the VC from the CQ and processes the request. Part of the VC structure is the identity of the Dispatcher that created it (and which client is connected to it). When the Shared Server is finished processing the request, it writes the output to the session buffer, changes the VC's ownership back to the Dispatcher that created it, places the VC into that Dispatcher's queue, and posts the Dispatcher it has something in its queue. The Dispatcher then checks its queue and sends what is in the session buffer through the operating system network protocol back to the Client.

In the case where there is a request for a Database Link, it is the Shared Server process that will, from the link definition, create an outbound VC and place it into the least loaded Dispatcher's queue (not necessarily the same Dispatcher the Client is connected to). This Dispatcher then logs into the remote database and passes the query to it for processing. Once the remote database responds, the Dispatcher then places the VC back into that Shared Server's ownership.

The Dispatchers are not limited to just the Oracle Net protocol. They also are able to understand FTP, HTTP(S), WebDAV, IIOP, SMTP, and TCP protocols.

 

The main views containing Shared Server information include:

V$CIRCUIT
V$DISPATCHER
V$DISPATCHER_CONFIG
V$DISPATCHER_RATE
V$QUEUE
V$SESSION
V$SHARED_SERVER
V$SHARED_SERVER_MONITOR

Dispatchers: The Number Of Dispatchers

 

The number of Dispatchers present in a Shared Server database configuration may vary from zero up to the system INIT.ORA parameter of MAX_DISPATCHERS. The initial number of Dispatchers created at instance startup is the value defined by the DISPATCHERS parameter in the system INIT.ORA and can exceed the MAX_DISPATCHERS value (as of version 10). Both parameters can be altered at runtime by ALTER SYSTEM commands (version 9.0 onwards, consult the SQL Reference manual for the particular version being run).

It is the PMON database background process that starts or stops any background processes, such as Dispatchers and Shared Servers. Dispatchers are not dynamically started or stopped, but must be manually maintained. Apart from restarting the database in order for the database to take on a new value set in the INIT.ORA, the following command may also be issued while the database is running:


Where 'string' is a valid setting for the DISPATCHERS parameter. For example:


PMON creates or destroys Dispatchers and then informs the Listener with their current state. PMON also updates the Listener about every ten seconds (depending on system load and other factors) with the current number of sessions and database load. To have PMON update the Listener with a change outside its normal cycle (as long as the LOCAL_LISTENER and REMOTE_LISTENER parameters are properly set in the system INIT.ORA) use this command:

One can then query then Listener for the new services that have been registered:

From this output we can see that there are four dispatchers, two using TCP and two using TCPS. The TCP ports that are assigned to the Dispatchers were allocated by the operating system. To specify what port to use, each Dispatcher has to be configured individually specifying the port number in the ADDRESS parameter section (see the Oracle Net Administration Guide on how to assign ports to Dispatchers).

Dispatchers can also be configured for a particular service. By default, each Dispatcher will service all SERVICE_NAMES and the DB_NAME. Dispatchers can be set up to only service a specific Service.

 The command added one Dispatcher, D003, to service the SERVICE_NAME of V10R2_DISP (specified by the SERVICE clause). To get this Dispatcher to service V10R2_DISP the INDEX clause was used (INDEX can also be used to "separate" Dispatchers from other TCP Dispatchers). This new Dispatcher gets a new INDEX:

 If the desire is to add more Dispatchers for a particular protocol, either issue the ALTER SYSTEM command specifying the full DESCRIPTION of the Dispatcher, or the Dispatcher's INDEX. For example, below are three Dispatchers configured for TCP and one configured for TCPS and there is a need to add one more TCP Dispatcher:

Dispatchers: Shutting Down Dispatchers

If the need is to shut down or reduce the number of Dispatchers by using the ALTER SYSTEM statement, the database can decide, or a specific Dispatchers can be chosen. To identify the name of the specific Dispatcher process to shut down, use the V$DISPATCHER view.

Each Dispatcher is uniquely identified by a name of the form Dnnn (where n is a number in the 0-9 range). In Unix, the Dispatcher process will have a name like ora_dnnn_sid. For Windows, the Dispatchers run as threads and are only visible using certain utilities, but the Oracle views will be the same. The Dispatchers are grouped by CONF_INDX based on the DESCRIPTION (or ADDRESS and PROTOCOL).

To shut down Dispatcher D002, issue the following statement:

 

 

The Dispatcher stops accepting new connections and will wait until all of the sessions it handles are disconnected before shutting down.

For a more "immediate" shutdown of the Dispatcher (it is in a bad state or it won't shutdown with the above command) issue this command:

 

 

The IMMEDIATE keyword stops the Dispatcher from accepting new connections and immediately terminates all existing connections through that Dispatcher. After all sessions are cleaned up, the Dispatcher process shuts down.

When a Dispatcher is shut down, other Dispatchers will not inherit the name, so it is possible to see some Dispatchers missing. When starting up a new Dispatcher, it will obtain the next open Dispatcher name. In the case where TCPS D002 Dispatcher was shut down, and a new Dispatcher for TCP was started, the new Dispatcher will be called D002. 

Dispatchers: Monitoring Performance

In general, Dispatchers will not be very busy because their tasks are relatively quick to complete. In the example below, Dispatchers are less than 1% busy.

 The OWNED column of V$DISPATCHER view shows the number of clients currently connected to each Dispatcher. In the above example, a D000 has 26 clients connected. D000 is in the process of sending a message to a client as is shown by the SEND status. D004 has OWNED = 0 because it has just been started using the following command:

 

 

Dispatchers: Performance

One perspective for interpreting Dispatcher performance is measuring the wait times in the various queues by querying the view V$QUEUE.

 

In the above example, the WAIT column is the total amount of time all requests have waited in the particular queue. The TOTALQ column is the total number of requests in a queue since the startup of the database. The AVG WAIT denotes the average wait (in seconds) per queued request.

The row with the TYPE of COMMON represents the Common Queue. The CQ holds all client requests to be processed by the Shared Servers. Please note that V$QUEUE view is not related to the Oracle Streams Advance Queuing feature. 

Shared Servers: Setting the Quantity of Shared Servers

The quantity of Shared Server processes will vary between INIT.ORA parameters SERVERS and MAX_SERVERS. Initially, the MAX_SERVERS value should be set to some estimated maximum number. For the initial setting, it can be set to the maximum number of expected sessions on the database (this is just a suggestion as it could also be set to far less). The effect of setting this parameter to a large value only affects the size of the Common Queue. This parameter can be changed dynamically by issuing the command:

 

 

Setting the initial value for SERVERS is also estimated. It can be set to some number under the setting of MAX_SHARED_SERVERS. But once the system is running under production load, the parameter SERVERS can be changed to accommodate the load. The Oracle Database Performance Tuning Guide explains how to monitor V$QUEUE to determine if SERVERS should be increased:  

 If the system is suffering from high SYS load due to having to create and destroy many shared servers, then SERVERS might be set to one plus the number in SERVERS_HIGHWATER that is found in the V$SHARED_SERVER_MONITOR view (the name of the view is V$MTS in 8.1 and before).

Setting this parameter based on the SERVERS_HIGHWATER value will reduce the expense of process creation and match the known maximum of Shared Servers. These are just suggestions as to a starting point to configuring Shared Server. The Shared Server views should be monitored to make sure the settings are appropriate for this instance. Monitoring the instance initially to make sure the settings are correctly configured will assure a well-tuned system.

Shared Server Performance

Shared Servers are created by PMON. Upon instance startup, PMON will create them according to the value of the SHARED_SERVERS parameter. If more SHARED_SERVERS are needed, PMON will create them up to MAX_SHARED_SERVERS to meet the need. PMON will terminate idle Shared Servers until the number goes back to SHARED_SERVERS. When measuring the performance of the Shared Servers, it is normal to see the lower numbered Shared Servers to be busier then the higher numbered ones.

 

In the above example, all the Shared Servers are between 1% and 99% busy. Shared Server S008 is very busy processing a single client request and Shared Server S000 has been busy handling numerous smaller requests. In general, the S000 Shared Server will always be the busiest and could easily be 100% busy all the time. This is by design.

The reason that S003-S005 and S007 are not listed is because the SHARED_SERVER parameter was set to 3 so PMON removed those Shared Servers because they went idle long enough to be removed. The idle interval cannot be set, nor does it need to be as it is more efficient to not have to create a Shared Server. S006 and S008 are not idle so they will exist as long as there is work for them to do.

In the case where there is a gap in the %TIME BUSY, such as is illustrated above where higher numbered Shared Servers S006 and S008 are nearly 100% used. This could be due to some sessions having so much work to do that a Shared Server has been dedicated to that particular session. It is sessions like this that should be found and forced to connect with a Dedicated server processes. Such heavy sessions have enough continuous workload that the service time the Dispatcher adds may slow them down.

The STATUS column of the V$SHARED_SERVER view provides useful information about WAIT status. In particular, the WAIT(ENQ) status tells the DBA that the user is waiting for a lock resource, and in rare cases, acts as an alert for a deadlock situation.

An overview of server creation and termination and high-water mark is available from the V$SHARED_SERVER_MONITOR view.  

 

The MAXIMUM_CONNECTIONS is the value of the maximum number of Virtual Circuits in use at one time.

The MAXIMUM_SESSIONS is the highest number of Shared Server sessions in use at one time since the instance started.

The SERVERS_STARTED and SERVERS_TERMINATED columns maintain a running total of Shared Server process creation and termination by PMON (but do not include the number set in the SHARED_SERVERS parameter).

The SERVERS_HIGHWATER value holds the high-water mark for the Shared Server count since the instance startup.

These statistics are useful indicators to check if SERVERS is set too low or too high. If the SERVERS_STARTED or SERVERS_TERMINATED are zero, this is an indication that too many Shared Servers may have been configured. Similarly, if the values of SERVERS_STARTED and SERVERS_TERMINATED grow quickly, the number for SHARED_SERVERS is likely to be too low and should be set to SERVERS_HIGHWATER + 1 (the "+ 1" is for good measure and has no intrinsic meaning).

 

Virtual Circuits and Sessions

The SERVER column in the V$SESSION view shows the type of Server that is currently servicing each session.

In the above example, DEDICATED means that client is connected with a dedicated server process. Shared Server connections appear as NONE or SHARED depending on whether a task is currently being serviced by a Shared Server or not. In this case only the OS User "bill" is being serviced by a Shared Server.

The V$CIRCUIT view provides more detailed information about usage of circuits by each session.

 The DISPATCHER column identifies the Oracle process ID for the Dispatcher Associated with the session. The SERVER column provides the Oracle process ID for the Shared Server currently servicing the client session, and zero if the session is not being serviced. For the QUEUE column, NONE represents the circuit is idle, SERVER means it is currently being serviced by a Shared Server, DISPATCHER means it is being serviced by a Dispatcher, and COMMON means it is on the Common Queue waiting to be picked up by a Shared Server.

The WAITER column is the Oracle process ID of the process that is currently waiting for data to appear in the Circuit. It will contain "00" when no database operation is in progress, otherwise it will list the Oracle process id for the Dispatcher or a Shared Server. Dispatchers are very quick to complete their work, so quick that it is rare to catch a glimpse of a Dispatcher in the WAITER queue.

References

http://www.oracle.com/pls/db102/to_toc?pathname=server.102%2Fb14220%2Ftoc.htm&remark=portal+%28Books%29
http://www.oracle.com/pls/db102/to_toc?pathname=server.102%2Fb14231%2Ftoc.htm&remark=portal+%28Books%29
http://www.oracle.com/pls/db102/to_toc?pathname=server.102%2Fb14211%2Ftoc.htm&remark=portal+%28Books%29
http://www.oracle.com/pls/db102/to_toc?pathname=network.102%2Fb14212%2Ftoc.htm&remark=portal+%28Books%29
Previous versions of the above manuals

첨부 파일 Shared_Server.jpg (62.28 KB)

관련 자료 제품 Oracle Database Products > Oracle Database > Oracle Database > Oracle Server - Enterprise Edition Oracle Database Products > Oracle Database > Net Services > Oracle Net Services 키워드 DISPATCHER; DISPATCHERS; MTS; PERFORMANCE; SHARED SERVER

멀티 스레드 서버 개요

by Jeff Hunter, Sr. Database Administrator 제프 헌터, 미스터 데이터베이스 관리자에 의해

Contents 내용

1. Overview 개요
2. Benefits of MTS MTS의 장점
3. The Trade-offs 무역 오프
4. Implementing MTS 구현 MTS
5. Bottom Line: Should I use MTS? 결론 : 저는 MTS를 사용해야합니까?
6. Setting up your MTS environment 귀하의 MTS 환경 설정
   • How Many Dispatchers? 얼마나 많은 Dispatchers?
   • How Many Shared Server Processes? 얼마나 많은 공유 서버 프로세스?
   • How Much Memory? 메모리가 얼마나?
7. Changing Database Initialization Parameters 데이터베이스 초기화 매개 변수 변경
   • MTS_DISPATCHERS MTS_DISPATCHERS
   • MTS_MAX_DISPATCHERS MTS_MAX_DISPATCHERS
   • MTS_SERVERS MTS_SERVERS
   • MTS_MAX_SERVERS MTS_MAX_SERVERS
   • LOCAL_LISTENER LOCAL_LISTENER
   • LARGE_POOL LARGE_POOL
8. Forcing a Dedicated Server Connection 전용 서버 연결을 강제
9. Viewing MTS Statistics MTS 통계보기
   • Operating-System Commands 운영 체제 명령
   • Listener Control 리스너 제어
   • Dynamic Performance Views 동적 성능보기

Overview 개요

Many Oracle DBAs today are faced with the every growing number of connections to their databases. 대부분의 오라클 DBAs 오늘날들은 데이터베이스에 연결마다 증가에 직면하고 있습니다. When using the traditional method of connecting to the database (dedicated server) each client process is given a dedicated server process that runs on the database server. 데이터베이스에 연결하는 전통적인 방법을 사용하는 경우 (전용 서버) 각 클라이언트 프로세스는 데이터베이스 서버에서 실행되는 전용 서버 프로세스를 제공합니다. This server process is sometimes referred to as a "shadow process". 이 서버 프로세스는 때때로 "그림자 프로세스"라고합니다. This server process takes memory away from the system and as the number of connections increase, so does the demand for memory. 이 서버 프로세스 때문에 메모리에 대한 수요가 않으며, 시스템에서와 연결 증가의 번호로 떨어진 메모리를 소요됩니다. Not only is memory in demand for with these server processes, but so are CPU requirements. 뿐만 아니라 이러한 서버 프로세스에 대한 수요의 메모리, 근데 CPU 요구 사항이 있습니다. If you have many users connecting and disconnecting from the database server, a good amount of CPU will be required in building and destroying these dedicated server processes. 당신이 연결하고 데이터베이스 서버에서 분리 많은 사용자가있다면, CPU의 좋은 금액이 전용 ​​서버 프로세스를 구축하고 파괴해야합니다.

Oracle provides a solution that answers the above two issues called Multi-Threaded Server. 오라클은 멀티 스레드 서버라는 위의 두 가지 문제 답을 솔루션을 제공합니다. This article provides some insight into setting up Multi-Threaded Server (MTS) as well as several scripts that can be used to monitor your MTS environment. 이 문서는 멀티 스레드 서버 (MTS)뿐 아니라 MTS 환경을 모니터링하는 데 사용할 수있는 몇 가지 스크립트 설정에 몇 가지 통찰력을 제공합니다.

Benefits of MTS MTS의 장점

Think about a system in which only 4 client processes need access to the database. 겨우 4 클라이언트 프로세스가 데이터베이스에 액세스해야하는 시스템에 대해 생각합니다. With dedicated server, each client process requires one dedicated server processes. 전용 서버로, 각 클라이언트 프로세스 하나의 전용 서버 프로세스를 필요로합니다. If each server process consumes 8 megabytes of memory, you will need 32 megabytes to support this scenario. 각 서버 프로세스가 메모리 8메가바이트를 소비한다면, 당신은이 시나리오를 지원하기 위해 32메가바이트 필요합니다. Now consider 100 dedicated connections. 지금 100 전용 연결 고려하십시오. In this scenario, you would require 800 megabytes of memory! 이 시나리오에서는 메모리 800 메가가 필요 것입니다! Using MTS, you can see in Figure 1 that these same 4 client connections can be supported by only 2 shared server processes. MTS를 사용하여, 당신은에서 볼 수있는 그림 1 이 동일한 4 클라이언트 연결에만이 공유 서버 프로세스에서 지원 수 있습니다.

Figure 1: Dedicated Server vs. Shared Server 그림 1 : 전용 서버 대 공유 서버

Another thing to consider is OLTP environment where users are spending most of their time reading and editing data on their screens and very little time actively executing SQL statements against the database. 고려해야 할 또 한가지는 사용자가 적극적으로 데이터베이스에 대해 SQL 문을 실행하는 자신의 화면 데이터와 거의 시간을 읽고 편집 대부분의 시간을 소비 아르 OLTP 환경입니다. In this scenario, many of those dedicated server processes are sitting idle and needlessly consuming memory. 이 시나리오에서는 이러한 전용 서버 프로세스의 대부분은 유휴 상태 및 불필요한 소비 메모리 앉아있다. Because MTS allows the sharing of the server process between many client processes, the DBA can now make more efficient use of the server processes. MTS는 많은 클라이언트 프로세스간에 서버 프로세스의 공유를 허용하기 때문에, DBA는 이제 서버 프로세스를보다 효율적으로 사용할 수 있습니다.

Lastly, MTS can improve with environments where clients are constantly connecting and disconnecting from the database. 마지막으로, MTS는 클라이언트가 지속적으로 연결하고 데이터베이스에서 연결을 해제 아르 환경 향상시킬 수 있습니다. Since shared server processes are not tied directly to a client process, they are not built and destroyed each time a client connects or disconnects. 공유 서버 프로세스가 클라이언트 프로세스에 직접 연결되어 아니므로, 그들은 건설과 클라이언트가 연결하거나 연결을 끊으 때마다 파괴되지 않습니다. Oracle will maintain an active "pool" of shared server processes. 오라클은 공유 서버 프로세스의 적극적인 "풀"을 유지합니다. New shared server processes are only created when demand exceeds supply. 수요가 공급을 초과하면 새로운 공유 서버 프로세스는 만들어집니다. On the same note, shared server processes are only destroyed when demand drops off and those extra shared server processes are no longer needed. 같은 메모에서 수요가 떨어져 방울 때 공유 서버 프로세스는 파괴되고 그 여분의 공유 서버 프로세스는 더 이상 필요하지 않습니다.

The following list outlines the advantages of using MTS: 다음 목록은 MTS를 사용의 이점을 설명합니다 :

• Reduced Demand for Memory : Since one server process can now handle many clients, you need fewer server processes, resulting in a reduced demand for overall memory. 메모리에 대한 수요를 감소 : 하나의 서버 프로세스가 현재 많은 클라이언트를 처리할 수 있기 때문에, 당신은 전체 메모리에 대한 수요 감소 결과, 적은 수의 서버 프로세스가 필요합니다.
• More Efficiency : Since there is less idle time with each shared server process, you gain more efficiency within each server process. 더 많은 효율성 : 각 공유 서버 프로세스와 적은 유휴 시간이 있기 때문에, 당신이 각 서버 프로세스 내에서 더 많은 효율성을 습득합니다.
• Fewer CPU Resources : Server processes are no longer being built and destroyed for each client connection and disconnect. 적은 CPU 리소스 : 서버 프로세스가 구축되지 않으며 파괴 각 클라이언트 연결과 분리되고 더 이상 없습니다. Fewer resources will now be required in the building and destroying of server processes. 적은 자원 이제 건물 및 서버 프로세스의 파괴 필요합니다.
• Communicating Through a Firewall : TCP/IP port numbers can be explicitly specified for MTS dispatchers. 방화벽을 통해 통신 : TCP / IP 포트 번호는 명시적으로 MTS의 dispatchers에 대해 지정할 수 있습니다. Knowing in advance the port numbers that will be used, can sometimes help when dealing with communicating through a firewall. 방화벽을 통해 통신을 다루는 때 사용되는 포트 번호, 가끔은 도움이 사전에 알고.

The Trade-offs 무역 오프

MTS is not for everyone! MTS는 모든 사람이 아니야! Before implementing MTS in your environment, keep the following in mind: 사용자 환경에서 MTS를 구현하기 전에 다음 사항에 유의 :

• Batch Jobs vs. Quick transactions : The use of MTS is predicated on the assumption that each client will use only a small fraction of its connect time to perform any work against the database. 일괄 채용 대 빠른 거래 : MTS의 사용은 각각의 클라이언트가 데이터베이스에 대해 어떤 작업을 수행하기 위해 연결하는 시간의 작은 파편만이를 사용하는 가정에 predicated입니다. The more active your clients are, the greater the number of shared server processes you will need to respond to their requests in a timely manner. 보다 적극적인 고객, 당신​​이 적시에 자신의 요청에 응답해야합니다 공유 서버 프로세스의 큰 수입니다. You may get to a point to where MTS ceases to make sense at all. MTS 전혀 이해하기 위해 중단 어디 지점에받을 수 있습니다. Batch jobs or clients that extract large amounts of data should not connect to the database through MTS. 대용량의 데이터를 추출 일괄 작업 또는 클라이언트가 MTS를 통해 데이터베이스에 연결해서는 안됩니다.
• Latency with MTS : When clients submit SQL statements to be executed, it now has to wait until a shared server process is freed up and can take on the task of executing the statement. MTS와 지연 : 클라이언트가 실행하는 SQL 문을 제출할 때, 지금 공유 서버 프로세스가 최대 해제하고 구문을 실행할 작업에 걸릴 수있을 때까지 기다려야한다. The amount of time depends on the number of shared server processes currently running and how busy they are. 시간 금액은 공유 서버의 현재 실행중인 프로세스와 방법에 바쁜 그들의 숫자에 따라 달라집니다.
• Client's Perspective : Even though the DBA may be reducing the demand for memory and/or CPU on the server, MTS will not result in better performance from the client's perspective. 고객의 관점 : DBA가 메모리 및 / 또는 서버에서 CPU에 대한 수요를 줄일 수있다하더라도, MTS는 고객의 관점에서 더 나은 성능의 결과되지 않습니다.

Implementing MTS 구현 MTS

After deciding MTS is right for your environment, it is now time to dig into the implementation details. MTS 바로 사용자 환경을위한 결정 후, 이제 구현 세부 사항에 팔 시간입니다. The DBA will need to consider the following two issues: User Session-Specific Data (UGA) and Routing Client Requests to Shared Server Processes . DBA는 다음과 같은 두 가지 문제를 고려하셔야합니다 : 사용자 세션 관련 데이터 (UGA)와 공유 서버 프로세스로 라우팅 클라이언트 요청합니다.

User Session-Specific Data (UGA) 사용자 세션 - 특정 데이터 (UGA)
Every connection to the Oracle database has a "session-specific" memory associated with it. Oracle 데이터베이스에 대한 모든 연결은 그것과 관련 "세션별로"메모리가 있습니다. This memory is referred to as the User Global Area (UGA) and is used to hold the values of PL/SQL variables, the values of bind variables and other items specific to a session. 이 메모리는 사용자 글로벌 영역 (UGA)이라고하고 PL / SQL 변수, 세션에 특정 바인딩 변수 및 기타 항목의 값을의 값을 보유하는 데 사용됩니다. The UGA also contains that part of the sort area specified by the SORT_AREA_RETAINED_SIZE initialization parameter. UGA는 또한 SORT_AREA_RETAINED_SIZE 초기화 매개 변수에 의해 지정된 정렬 영역의 일부를 포함하고 있습니다.

With a dedicated server connection, the UGA is stored within the dedicated server process's Program Global Area (PGA). 전용 서버 연결, UGA는 전용 서버 프로세스의 프로그램 글로벌 영역 (PGA) 내에 저장됩니다. When an MTS connection is made though, the UGA is stored in either the "LARGE POOL" or the "SHARED POOL". MTS 연결이 있지만 만든 경우, UGA는 중 "대형 수영장"또는 "공유 풀"에 저장됩니다. This difference is illustrated in Figure 2 . 이 차이는에있는 그림입니다 그림 2 .

In an MTS environment, the UGA needs to be moved into a common memory structure like the large pool or shared pool since it contains "session-specific" data. MTS 환경에서 UGA는 "세션 관련"데이터가 포함되어 있으므로 대형 풀 또는 공유 풀 같은 일반적인 메모리 구조로 이동해야합니다. Keep in mind that the use of MTS does not affect the overall "amount" of memory used for session specific data. MTS의 사용 세션이 특정 데이터에 사용되는 메모리의 전반적인 "금액을"에 영향을주지 않습니다 점에 유의하십시오. It is only moved from the memory space of the individual process into a common memory structure accessible by all processes. 그것은 모든 프로세스에 의해 액세스할 수있는 공통의 메모리 구조로 각 프로세스의 메모리 공간에서 이동됩니다.

Figure 2 shows the UGA located in the large pool. 그림 2는 대형 수영장에있는 UGA를 보여줍니다. If you do not have the large pool configured, then Oracle will place the UGA in the shared pool. 당신은 대형 수영장가 설정되지 않는 경우, 오라클은 공유 수영장에서 UGA를 배치합니다. Oracle does not recommend placing the UGA in the shared pool as this will cause fragmentation. 오라클은이 조각의 원인이되므로 공유 수영장에서 UGA를 배치하지 않는 것이 좋습니다.

Figure 2: MTS changes where session-specific information is stored 그림 2 : 세션과 관련된 정보가 저장되어있는 MTS 변경

Routing Client Requests to Shared Server Processes 공유 서버 프로세스로 클라이언트 요청을 라우팅
The second major issue of MTS is setting up the dispatcher. MTS의 두 번째 주요 문제는 배차를 설정입니다. When using a dedicate server connection, the client process simply passes the SQL statements to be executed to its dedicated server process. 헌정 서버 연결을 사용하면, 클라이언트 프로세스는 단순히 전용 서버 프로세스에 실행되도록 SQL 문을 전달합니다. What happens though when in an MTS environment the client process has no dedicated server process to send the SQL to? MTS 환경에서 클라이언트 프로세스가 SQL을 보낼 전용 서버 프로세스가없는 경우 어떻게 생각됩니까? The answer is that the request gets sent to a dispatcher process. 답변 요청 배차 프로세스로 전송된다는 점이다.

In an MTS environment, the dispatcher process assumes the role of communicating with the clients and routing your request. MTS 환경에서 배차 프로세스는 클라이언트와 통신하여 요청을 라우팅의 역할을 가정합니다. The listener no longer hands the client off to a dedicated server process, but rather gives each new client to the most lightly loaded dispatcher process. 리스너는 더 이상 손떼 전용 서버 프로세스는 클라이언트, 오히려 가장 가볍게로드 배차 프로세스에 각각의 새 클라이언트를 제공합니다. For the duration of the session, the dispatcher process will handle all communication with the client. 세션의 기간 동안, 배차 프로세스는 클라이언트의 모든 통신을 처리합니다.

The dispatcher processes will then take the requests (with are often SQL statements) from the client and place them into a request queue . 배차원 프로세스는 다음 클라이언트의 요청을 (종종 SQL 문을 아르와 함께) 가지고 요청 대기열에 넣어 것입니다. The request queue is located as a memory structure within the System Global Area (SGA) and is where all incoming requests are placed. 요청 대기열은 시스템 글로벌 영역 (SGA) 내의 메모리 구조로 위치하고 들어오는 모든 요청이 위치가 어디입니다. All shared servers you have setup within your instance will monitor the request queue. 귀하의 인스턴스 내에서 설정을 모든 공유 서버 요청 대기열을 모니터링합니다. When a request is entered into the request queue, the next available shared server process will pull it out of the queue and service it. 요청이 요청 대기열에 입력하면, 다음 사용 가능한 공유 서버 프로세스는 대기열의 그것을 꺼내 그것을 서비스합니다. All requests are handled in a first-in/first-out basis. 모든 요청은 first-in/first-out 기준으로 처리됩니다. This can be seen in Figure 3 . 이것은에서 볼 수있는 그림 3 .

Figure 3: Within an MTS setup, the dispatcher is responsible for all communication to and from the client 그림 3 : MTS 설정 내에서, 배차는 클라이언트와 모든 커뮤니케이 션에 대한 책임

When the shared server process completes the task, the results are placed into a response queue . 공유 서버 프로세스가 작업을 완료하면 그 결과는 응답 대기열에 배치됩니다. Like the request queue, the response queue is a memory structure located within the SGA. 요청 대기열과 마찬가지로, 응답 대기열은 SGA 내에있는 메모리 구조입니다. Response queues are directly tied to a specific dispatcher. 응답 대기열 직접 특정 배차에 묶여있다. While each dispatcher has its own response queue, each dispatcher on the other hand will have the same request queue. 각 배차 자체 응답 대기열을 가지고 있지만, 반면에 각각의 배차는 동일한 요청 대기열을해야합니다. When a dispatcher detects a response in its response queue, it will send that response back to the client that first initiated the request. 배차는 응답 대기열에 응답을 감지하면, 먼저 요청을 시작한 클라이언트에 다시 응답을 보내드립니다.

How many dispatchers should you use in your MTS environment? 당신의 MTS 환경에서 얼마나 많은 dispatchers를 사용해야합니까? Well, for one you will need at lease one dispatcher for each network protocol that you are supporting. 음, 한 당신은 임대에서이 지원하는 각 네트워크 프로토콜에 대해 하나 배차가 필요합니다. Like shown in Figure 3 , you created one dispatcher for TCP/IP and another for SPX. 표시와 마찬가지로 그림 3 , 당신은 SPX 한 TCP에 대한 배차 / IP와 다른 만들었습니다. Aside from the number of network protocols, you also need to decide on the number of connections you are planning to support. 외에 네트워크 프로토콜의 번호에서, 당신은 또한 지원을 계획하고 연결 수를 결정합니다. There is a limit as to how many connections that each dispatcher process can handle. 각 배차 프로세스가 처리할 수있는 얼마나 많은 연결로 제한이 있습니다. (This number is operating-system specific). (이 번호는 운영 체제에만 적용됩니다.)

Bottom Line: Should I use MTS? 결론 : 저는 MTS를 사용해야합니까?

Well, this depends on your environment. 음, 이것은 환경에 따라 다릅니다. If you are supporting a large number of client connections and where those connections are mostly inactive, then MTS would be ideal here. 당신은 클라이언트 연결의 많은 지원을하고 있으며 이러한 연결은 대부분 비활성 어디면 MTS는 여기에 이​​상적인 것입니다. MTS would not be a good setup if your environment does not involve much idle time with your client connections. 환경이 클라이언트 연결과 함께 많은 유휴 시간을 포함하지 않는 경우 MTS는 잘 설치되지 않을 것입니다. (ie batch jobs). (예 : 일괄 작업). Keep in mind that you setup an environment that allows for both MTS and dedicate server processes. 당신은 MTS 모두 수있는 환경을 설치 및 서버 프로세스를 바칩니다 점을 명심하십시오. Setup user connections who only sporadically accessing the database using MTS, while batch jobs and other data intensive connections can be made using dedicated server connections. 일괄 작업 및 기타 데이터 집약적인 연결이 전용 ​​서버 연결을 사용하여 만들 수있는 동안에만 간헐적으로, MTS를 사용하여 데이터베이스를 액세스하는 설치 사용자 연결. Lastly, remember that from the client's perspective, MTS does not enhance their performance, but rather reduces the CPU and memory overhead associated with supporting many client (mostly idle) connections. 마지막으로, 클라이언트의 관점에서, MTS는 자신의 성능을 향상하지 않는 기억, 오히려 많은 클라이언트 (대부분 유휴 상태) 연결 지원과 관련된 CPU 및 메모리 오버헤드를 줄일 수 있습니다.

Setting up your MTS environment 귀하의 MTS 환경 설정

How Many Dispatchers? 얼마나 많은 Dispatchers?
As discussed above, you will need to provide at lease one dispatcher process for each protocol you plan on supporting. 위에서 설명한대로, 당신은 지원 계획이 각 프로토콜에 대해 임대 하나 배차 과정을 제공해야합니다. Another factor that will affect your decision on the number of dispatcher processes is the operating system's limit on the number of connections that can be made to a single process. 배차원 프로세스의 수를 결정에 영향을줍니다 또 다른 요인은 단일 프로세스로 만들 수있는 연결의 수를 운영 체제의 한계입니다. If for example, your operating system allows a maximum of 972 connections to one process, and you want to support 3500 TCP/IP connections using MTS, then you will need a minimum of four (4) dispatcher processes for the TCP/IP network protocol. 예를 들어 경우, 운영 체제가 하나의 처리 972 연결의 최대 허용하고 3500 TCP / MTS를 사용하여 IP 연결을 지원하려면, 다음의 TCP / IP 네트워크 프로토콜에 대한 4 배차 프로세스의 최소 필요합니다 .

Determining OS Connection Limits OS 연결 제한을 결정

Determining the connection limit for your particular operating system is fairly easy. 특정 운영 체제에 대한 연결 제한을 결정하는 것은 매우 쉽습니다. You will need to use the "SERVICES" command within the Listener Control utility. 당신은 리스너 제어 유틸리티 내에서 "서비스"명령을 사용해야합니다. Simply perform the following tasks: 간단히 다음과 같은 작업을 수행합니다 Use the MTS_DISPATCHERS initialization parameter to configure a test database for one dispatcher. 한 배차를위한 테스트 데이터베이스를 구성 MTS_DISPATCHERS 초기화 매개 변수를 사용합니다. Stop and restart your instance to read in the new value of MTS_DISPATHCERS. 중지하고 MTS_DISPATHCERS의 새로운 가치를 읽을 수 인스턴스를 다시 시작합니다. Run the Listener Control utility and issue the SERVICES command. 리스너 제어 유틸리티를 실행하고 서비스 명령을 발행하고 있습니다. The output will include a list of dispatcher processes. 출력은 배차 프로세스의 목록을 포함합니다. Now find the dispatcher process in the list of services and look at the value for max . 이제 서비스 목록에서 배차 과정을 찾아 최대의 값을보세요. This value indicates the maximum number of connections that your operating system allows for one process. 이 값은 운영 체제 하나의 프로세스에 대해 허용되는 연결의 최대 개수를 나타냅니다. Here is a small sample. 여기에 작은 샘플입니다. Note that the value for max is 972. 최대 값은 972입니다. LSNRCTL> SERVICES LSNRCTL> 서비스 Connecting to (ADDRESS=(PROTOCOL=IPC)(KEY=SOPDEV2.world)) 에 연결 (= (PROTOCOL = IPC) (KEY = SOPDEV2.world을 주소)) Services Summary... 서비스 요약 ... Service "SOPDEV2" has 2 instance(s). 서비스 "SOPDEV2는"2 인스턴스 (들)을하고 있습니다. Instance "SOPDEV2", status UNKNOWN, has 1 handler(s) for this service... 예를 들어 "SOPDEV2"상태 알 수없는이 서비스에 대해 1 처리기 (들)을했습니다 ... Handler(s): 처리기 (들) : "DEDICATED" established:0 refused:0 "전용"설립 : 0 거절 : 0 LOCAL SERVER 로컬 서버 Instance "SOPDEV2", status READY, has 2 handler(s) for this service... 예를 들어 "SOPDEV2"상태가 준비,이 서비스 2 처리기 (들)을했습니다 ... Handler(s): 처리기 (들) : "DEDICATED" established:0 refused:0 state:ready "헌신"은 설립 : 0 거부 : 0 상태 : 준비 LOCAL SERVER 로컬 서버 "D000" established:0 refused:0 current:0 max:972 state:ready "D000"은 설립 : 0 거절 : 0 현재 : 0 최대 : 972 상태 : 준비 DISPATCHER 배차원 (ADDRESS=(PROTOCOL=tcp)(HOST=appdev)(PORT=47594)) (주소 = (PROTOCOL = TCP) (HOST = appdev) (포트 = 47594)) NOTE : Do not attempt to perform the above test on a production database when users are trying to connect. 참고 : 사용자가 연결하려고하는 경우 프로덕션 데이터베이스에서 위의 테스트를 수행하지 마십시오. In fact, use a "testing" database to ensure that you will not create connection problems for people in your production environment. 사실, 당신이 프로덕션 환경에있는 사람에 대한 연결 문제를 생성하지 않도록하기 위해 "테스트"데이터베이스를 사용합니다.

Table 1: Determining OS Connection Limits 표 1 : OS 연결 제한을 결정

How Many Shared Server Processes? 얼마나 많은 공유 서버 프로세스?
Setting up the number of shared server processes requires the use of two initialization parameters: MTS_SERVERS and MTS_MAX_SERVERS. MTS_SERVERS 및 MTS_MAX_SERVERS : 공유 서버 프로세스의 수를 설정은 두 초기화 매개 변수를 사용해야합니다. They control both the minimum and maximum number of shared server processes that you want to create for your instance. 그들은 당신이 예를 들면 만들려는 공유 서버 프로세스의 모두 최소 및 최대 개수를 제어합니다.

• MTS_MAX_SERVERS: Sets an upper limit on the number of shared server processes that can be created for the instance. MTS_MAX_SERVERS :이 인스턴스에 대해 만들 수있는 공유 서버 프로세스의 숫자에 상한선을 설정합니다. Ensure to choose a value for this parameter based on the total amount of resources you are willing to dedicate to all server processes. 당신은 모든 서버 프로세스에 헌정하고자하는 자원의 총액을 기준으로이 매개 변수에 대한 값을 선택할 수 있는지 확인하십시오.
• MTS_SERVERS: Sets the number of shared servers to initially create. MTS_SERVERS이 : 처음 만들 공유 서버의 수를 설정합니다. The default value is 1. 기본값은 1입니다. You should set this value to one higher than what reflects the typical load on your system. 여러분의 시스템에 전형적인 부하를 반영하는보다 높은 하나에이 값을 설정해야합니다. Keep in mind that the goal here is to minimize the rate at which shared server processes are being built and destroyed. 여기서 목표는 공유 서버 프로세스 구축하고 파괴되는 속도를 최소화하는 것입니다 점에 유의하십시오.

How Much Memory? 메모리가 얼마나?
Before implementing MTS in your environment, you will need to decide how much shared pool or large pool memory is required for session-specific memory. 사용자 환경에서 MTS를 구현하기 전에 공유 수영장이나 대형 풀 메모리가 세션 특정 메모리가 필요합니다 어느 정도 결정이 필요합니다. An easy way to do this, is to gather the current amount of memory used by a representative session, and then extrapolate from that to cover the number of sessions you expect to have simultaneously. 이 작업을 수행하는 쉬운 방법은 대표적인 세션에 의해 사용된 메모리의 현재 금액을 모아 다음 동시에 가지고 있다고 기대 세션의 수를 커버 것과 추정하는 것입니다. Suppose I want to gather memory information from a user logged in as "JHUNTER". 난 "JHUNTER"로 로그 인한 사용자의 메모리 정보를 수집하려는 가정합시다. First you will need to get the "SID" for the "JHUNTER" user. 먼저 "JHUNTER"사용자에 대한 "SID"를 얻을해야합니다. After obtaining the proper SID, select the current "UGA memory" and "UGA memory max" from v$sesstat. 적절한 SID를 취득 후, 현재 "UGA 메모리"를 선택하고 V $ sesstat에서 "UGA 메모리 최대".

  SQL> SELECT sid FROM v$session WHERE username = 'JHUNTER'; SQL> SELECT 시드 V $ 세션에서 WHERE 이름 = 'JHUNTER';

         SID SID
  ---------- ----------
          15 15


  SQL> SELECT sn.name, ss.value SQL> SELECT sn.name, ss.value
    2 FROM v$sesstat ss, v$statname sn V $ sesstat SS, V $ statname SN에서 2
    3 WHERE ss.statistic# = sn.statistic# 3 WHERE ss.statistic # = sn.statistic #
    4 AND sn.name IN ('session uga memory', 'session uga memory max') 4 ( '세션 uga 메모리', '세션 uga 메모리 최대')에 sn.name
    5 AND ss.sid=15; 5 ss.sid = 15;

  NAME VALUE 이름 값
  ------------------------ ---------- ------------------------ ----------
  session uga memory 54364 세션 uga 메모리 54,364
  session uga memory max 57076 세션 uga 메모리 최대 57,076 

The session uga memory value represents the amount of memory that a user is currently using for session-specific information. 세션 uga 메모리 값은 사용자가 현재 세션 관련 정보를 사용하는 메모리의 양을 나타냅니다. The other value, session uga memory max represents the maximum amount of session-specific memory that has been used at any one time during the user's current session. 다른 값은 세션 uga 메모리 최대는 사용자의 현재 세션 동안 한 번에 사용되었습니다 세션 특정 메모리의 최대 크기를 나타냅니다. Lets say that the "JHUNTER" user (above) was representative of many of the other users in the database that are going to connect via MTS, and you expected 500 such connections concurrently, simply multiply both values ( session uga memory and session uga memory max ) by 500 to come up with an estimated range of 27,182,000 to 28,538,000 bytes. 하자가 "JHUNTER"사용자 (위) MTS를 통해 연결하려고하는 데이터베이스에있는 다른 사용자의 많은 대표라고 이야기하고 동시에 500과 같은 연결을 예상, 단순히 두 값 (세션 uga 메모리와 세션 uga 메모리 곱하면 최대) 500 27182000로 28,538,000 바이트의 예상 범위로 올라와 있습니다. This will be the amount of additional memory that you will need to allocate in the SGA for use by these 500 MTS sessions. 이것은 여러분이 이러한 500 MTS 세션에 의해 사용을 위해 SGA에 할당하는 번거로움이 따른다는 것을 추가 메모리의 양을 것입니다. Remember that MTS uses the shared pool for session memory, but Oracle recommends the use of the large pool. MTS는 세션 메모리 공유 풀을 사용하지만, 오라클은 대형 수영장의 사용을 권장 것을 기억하십시오. By using the large pool, you avoid fragmenting the shared pool. 큰 수영장을 사용하여 공유 수영장 fragmenting하지 마십시오. Given the above example, I would add the following to my init.ora file: 위의 예제 감안할 때, 내 init.ora 파일에 다음을 추가합니다 :

  large_pool = 32M large_pool = 32M 

The above allocates a large pool of 32 MB in size. 위의 크기는 32 MB 중 대형 수영장을 할당합니다. This is all you really have to do in order to have Oracle use it for MTS session memory. 이것은 당신이 정말로 오라클 MTS 세션 메모리를 사용할 권한을 부여하기 위해해야​​ 할 전부입니다.

Changing Database Initialization Parameters 데이터베이스 초기화 매개 변수 변경

When thinking about setting up your MTS environment, you might be tempted to think that this will require changes to your Net8 configuration files like the listener.ora. 귀하의 MTS 환경을 설정하는 방법에 대해 생각하면, 당신이이 listener.ora처럼 Net8 구성 파일의 변경 사항을 요구할 것입니다 생각하는 유혹 수도 있습니다. As you will see, this is not the case. 당신이 볼 수로서,이 사건 없습니다. All parameters for setting up your MTS environment are made to the instance and not any your Net8 config files. 귀하의 MTS 환경 설정에 대한 모든 매개 변수는 모든 사용자 Net8 설정 파일이 아닌 인스턴스로 만들어 있습니다. Remember that the dispatcher and shared processes are actually part of the instance, so it makes sense that you would configure them in the same place. 배차 및 공유 프로세스가 실제로 인스턴스의 일부하므로 그것은 당신이 같은 장소에서 그들을 구성하는 것이 의미가 있습니다.

This section of the article discusses the changes that will need to be made to the following parameters: 문서의이 섹션에는 다음과 같은 매개 변수를 만들해야합니다 변경 사항을 설명합니다 :

• MTS_DISPATCHERS MTS_DISPATCHERS
• MTS_MAX_DISPATCHERS MTS_MAX_DISPATCHERS
• MTS_SERVERS MTS_SERVERS
• MTS_MAX_SERVERS MTS_MAX_SERVERS
• LOCAL_LISTENER LOCAL_LISTENER
• LARGE_POOL LARGE_POOL

Setting up an MTS environment can be as simple as adding one or more MTS_DISPATCHERS parameters to your instance parameter file and then bouncing the database. MTS 환경을 설정하면 인스턴스 매개 변수 파일에 하나 이상의 MTS_DISPATCHERS 매개 변수를 추가하고 다음 데이터베이스를 수신 거부로 간단 수 있습니다. It's likely however, that you're going to want to tune some of the other parameters above. 그것은 당신이 위의 다른 매개 변수 중 일부를 조정하려는 거라고, 그러나 가능성이 높습니다.

MTS_DISPATCHERS MTS_DISPATCHERS

This is the key initialization parameter that needs to be set in order to implement MTS. 이것은 MTS를 구현하기 위해 설정하는 데 필요한 핵심 초기화 매개 변수입니다. The syntax here is very similar to what you would use in Net8 configuration files like the listener.ora file. 여기서 문법은 listener.ora 파일처럼 Net8 구성 파일에 사용할 것과 매우 유사합니다.

Here is an example of enabling MTS by only specifying the protocol to support. 여기에만 지원하는 프로토콜을 지정하여 MTS를 사용의 예입니다. This will accept default values for all other attributes: 이것은 다른 모든 속성에 대한 기본값을 수락합니다

  MTS_DISPATCHERS="(PROTOCOL=TCP)" MTS_DISPATCHERS = "(PROTOCOL = TCP)" 

If you want to support more than one protocol (TCP/IP and SPX for example), you would enter two MTS_DISPATCHERS parameter settings: 하나 이상의 프로토콜 (TCP / IP와 예를 들어, SPX)을 지원하려면 두 MTS_DISPATCHERS 매개 변수 설정을 입력합니다 :

  MTS_DISPATCHERS="(PROTOCOL=TCP)" MTS_DISPATCHERS = "(PROTOCOL = TCP)"
  MTS_DISPATCHERS="(PROTOCOL=SPX)" MTS_DISPATCHERS = "(프로토콜 = SPX)" 

NOTE : When declaring multiple MTS_DISPATCHERS parameters, they must be grouped together in the init.ora file. 참고 : 여러 MTS_DISPATCHERS 매개 변수를 선언하면, 그들은 init.ora 파일에 함께 그룹화해야합니다. Blank links are allowed, but do not place any other parameter settings between two MTS_DISPATCHERS settings. 빈 링크는 사용할 수 있습니다,하지만 아직 두 MTS_DISPATCHERS 설정 사이에 다른 매개 변수 설정을 올려 놓지 마십시오. Doing this will cause the instance to error when you try to start it. 이렇게하면 인스턴스가 당신이 그것을 시작하려고 할 때 오류가 발생할 것입니다.

Two other commonly used attributes in the MTS_DISPATCHERS are setting the "number of dispatchers" and maybe the "number of connections" each dispatcher is allowed to handle. MTS_DISPATCHERS에 두 기타 일반적으로 사용되는 속성은 "dispatchers의 개수"를 설정하고 아마 "연결 번호는"각 배차가 처리할 수 있습니다. The following example allocates four TCP/IP dispatchers and each of those dispatchers can handle up to 250 connections. 다음 예제에서는 네 개의 TCP / IP dispatchers 그 dispatchers 각각 최대 250 연결 처리할 수를 할당합니다.

  MTS_DISPATCHERS="(PROTOCOL=TCP)(DISPATCHERS=4)(CONNECTIONS=250)" MTS_DISPATCHERS = "(PROTOCOL = TCP) (DISPATCHERS = 4) (연결 = 250)" 

Another attribute that deserves attention for MTS_DISPATCHERS is the LISTENER attribute. MTS_DISPATCHERS에 대한 관심을받을 자격이 다른 속성은 리스너의 속성입니다. The LISTENER attribute allows you to specify the listener with which the dispatcher should register. 리스너 속성은 배차 등록해야되는 수신기를 지정할 수 있습니다. By default, the dispatcher will register with the listener that is monitoring port 1521 on the local database server. 기본적으로, 배차는 로컬 데이터베이스 서버에서 포트 1521를 감시하는 리스너로 등록합니다. Using the LISTENER attribute though, you can override this and have your dispatcher register with a listener assigned to either a different port or with a listener running on another database server. 수신기 속성을 사용하면 불구하고,이를 무시하고 배차가 다른 포트를 하나에 할당된 리스너 또는 다른 데이터베이스 서버에서 실행되는 리스너 등록을 할 수 있습니다. The following is an example of using the LISTENER attribute: 다음은 수신기 속성을 사용하는 예입니다 :

  MTS_DISPATCHERS="(PROTOCOL=TCP)(DISPATCHERS=4)(CONNECTIONS=250) \ MTS_DISPATCHERS = "(PROTOCOL = TCP) (DISPATCHERS = 4) (연결 = 250) \
                   (LISTENER=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(PORT=1526)(HOST=cartman))))" (리스너 = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (PORT = 1526) (HOST = cartman ))))" 

Here the LISTENER attribute defines an ADDRESS_LIST containing one or more listener addresses. 여기 리스너 특성은 하나 이상의 리스너 주소를 포함 ADDRESS_LIST을 정의합니다. The dispatchers will then register with each of those listeners. dispatchers 그러면 그 청취자의 각 등록합니다.

NOTE : There is also a LOCAL_LISTENER initialization parameter that provides the same functionality as the MTS_DISPATCHERS parameter's LISTENER attribute. 참고 : MTS_DISPATCHERS 매개 변수의 수신기 속성과 동일한 기능을 제공 LOCAL_LISTENER 초기화 매개 변수도 있습니다. The LISTENER attribute will override the LOCAL_LISTENER parameter and is the recommended by Oracle Corp. 리스너의 속성은 LOCAL_LISTENER 매개 변수를 무시하고 오라클 주식 회사에 의해 추천

One final note to make in reference to setting the MTS_DISPATCHERS is where you have the option of specifying the network address that it will monitor. MTS_DISPATCHERS 설정에 대한 참고 자료를 만들기 위해 마지막으로 참고 당신이 모니터링 네트워크 주소를 지정하는 옵션을 가지고있는 것입니다. (Similar to how you would set the listener process to listen on port 1521). (여러분이 포트 1521에서 수신 대기하는 리스너 프로세스를 설정해야하는 방법과 유사). One of the major reasons for forcing the port number for dispatchers is get around firewall issues. dispatchers에 대한 포트 번호를 강제의 주요 이유 중 하나는 방화벽 문제를 해결할 수 있습니다.

By default, whenever you specify the protocol to support, the dispatcher will decide on the address automatically. 기본적으로, 당신이 지원하는 프로토콜을 지정할 때마다 배차가 자동으로 주소를 결정합니다. You have the option though of specifying which address the dispatcher uses by replacing the PROTOCOL attribute with either the ADDRESS or DESCRIPTION attribute. 당신은 배차가 주소 또는 설명 속성 중 하나와 프로토콜 속성을 대체하여 사용하는 주소 지정지만 옵션이 있습니다. Below is an example that uses the ADDRESS attribute. 아래의 주소 속성을 사용하는 예제입니다. Also notice that in order to specify a port, that ALL dispatchers must be configured separately to ensure that no two dispatchers are sharing the same address: 또한 모든 dispatchers가 더이 dispatchers가 동일한 주소를 공유하지 않습니다 않도록 별도로 구성해야합니다 즉, 포트를 지정하기 위해서는 그 통지 :

  MTS_DISPATCHERS="(ADDRESS=(PARTIAL=TRUE)(PROTOCOL=TCP)(HOST=cartman)(PORT=1562)) \ MTS_DISPATCHERS은 = "(ADDRESS = (일부 = TRUE) (PROTOCOL = TCP) (HOST = cartman) (PORT = 1562)) \
                   (DISPATCHERS=1)(CONNECTIONS=250)" (DISPATCHERS = 1) (연결 = 250) "

  MTS_DISPATCHERS="(ADDRESS=(PARTIAL=TRUE)(PROTOCOL=TCP)(HOST=cartman)(PORT=1563)) \ MTS_DISPATCHERS은 = "(ADDRESS = (일부 = TRUE) (PROTOCOL = TCP) (HOST = cartman) (PORT = 1563)) \
                   (DISPATCHERS=1)(CONNECTIONS=250)" (DISPATCHERS = 1) (연결 = 250) "

  MTS_DISPATCHERS="(ADDRESS=(PARTIAL=TRUE)(PROTOCOL=TCP)(HOST=cartman)(PORT=1564)) \ MTS_DISPATCHERS은 = "(ADDRESS = (일부 = TRUE) (PROTOCOL = TCP) (HOST = cartman) (PORT = 1564)) \
                   (DISPATCHERS=1)(CONNECTIONS=250)" (DISPATCHERS = 1) (연결 = 250) "

  MTS_DISPATCHERS="(ADDRESS=(PARTIAL=TRUE)(PROTOCOL=TCP)(HOST=cartman)(PORT=1565)) \ MTS_DISPATCHERS은 = "(ADDRESS = (일부 = TRUE) (PROTOCOL = TCP) (HOST = cartman) (PORT = 1565)) \
                   (DISPATCHERS=1)(CONNECTIONS=250)" (DISPATCHERS = 1) (연결 = 250) " 

MTS_MAX_DISPATCHERS MTS_MAX_DISPATCHERS

The MTS_MAX_DISPATCHERS parameter defines an upper limit on the number of dispatchers that can be running at any one time. MTS_MAX_DISPATCHERS 매개 변수는 한 번에 실행할 수 dispatchers의 숫자에 상한선을 정의합니다. The default value for this parameter is 5. 이 매개 변수의 기본 값은 5가된다. Keep in mind that this value is subject to modification based on your values defined in MTS_DISPATCHERS. 이 값이 MTS_DISPATCHERS에 정의된 해당 값을 기준으로 변경 적용됩니다 점에 유의하십시오. Examine the following example. 다음 예제를 검사합니다.

  MTS_DISPATCHERS="(PROTOCOL=TCP)(DISPATCHERS=12)(CONNECTIONS=250)" MTS_DISPATCHERS = "(PROTOCOL = TCP) (DISPATCHERS = 12) (연결 = 250)"
  MTS_DISPATCHERS="(PROTOCOL=SPX)(DISPATCHERS=10)(CONNECTIONS=250)" MTS_DISPATCHERS = "(프로토콜 = SPX) (DISPATCHERS = 10) (연결 = 250)"
  MTS_MAX_DISPATCHERS=16 MTS_MAX_DISPATCHERS = 16 

Given the example above, the actuall value for MTS_MAX_DISPATCHERS would be adjusted upward to 22. 위의 예제 감안할 때, MTS_MAX_DISPATCHERS에 대한 actuall 값이 22 위를 조정 것입니다. (12 for TCP and 10 for SPX) (TCP 12 및 SPX에 대한 10)

MTS_SERVERS MTS_SERVERS

The MTS_SERVERS parameter controls the number of shared server processes that will be available to service MTS connections. MTS_SERVERS 매개 변수는 서비스 MTS 연결을 사용할 수 있습니다 공유 서버 프로세스의 수를 제어합니다. With this parameter, you are defining the number of shared server processes that will be created when the instance starts. 이 매개 변수를 사용하면 인스턴스가 시작될 때 생성됩니다 공유 서버 프로세스의 개수를 정의하고 있습니다. (This is also the minimum number of servers for the instance. Oracle will not reduce the number of server processes below this number). (이것은 또한 인스턴스에 대한 서버의 최소 횟수입니다. 오라클은이 번호를 아래의 서버 프로세스의 수를 감소되지 않습니다.)

MTS_MAX_SERVERS MTS_MAX_SERVERS

The MTS_MAX_SERVERS parameter puts in place an upper limit on the number of shared server processes that can be running at any given time. MTS_MAX_SERVERS 매개 변수는 장소에서 언제든지 실행할 수있는 공유 서버 프로세스의 숫자에 상한선을 저장합니다. While an instance is running, the number of shared server processes increases and decreases. 인스턴스가 실행되는 동안, 공유 서버의 수가 증가 및 감소를 처리합니다. However, the number of shared server processes will never exceed the limit placed by use of the MTS_MAX_SERVERS parameter. 그러나, 공유 서버 프로세스의 숫자는 MTS_MAX_SERVERS 매개 변수를 사용하여 배치 한도를 초과하지 않습니다.

LOCAL_LISTENER LOCAL_LISTENER

As mentioned above, the LOCAL_LISTENER parameter serves the same purpose of the LISTENER attribute of the MTS_DISPATCHERS parameter. 위에서 언급한 바와 같이, LOCAL_LISTENER 매개 변수는 MTS_DISPATCHERS 매개 변수의 수신기 속성의 동일한 목적을 제공합니다. It identifies the listener with which MTS dispatchers will register with. 그것은 MTS의 dispatchers 함께 등록됩니다있는 수신기를 나타냅니다. Below are two example of setting this parameter: 아래의이 매개 변수를 설정하는 두 가지 예를 들면 다음과 같습니다 :

  LOCAL_LISTENER="(ADDRESS_LIST= \ LOCAL_LISTENER = "(ADDRESS_LIST = \
                           (ADDRESS= \ (주소 = \
                             (PROTOCOL=TCP) \ (PROTOCOL = TCP) \
                             (HOST=cartman) \ (HOST = cartman) \
                             (PORT=1526) \ (포트 = 1526) \
                           ) \ ) \
                         )" ) " 

  LOCAL_LISTENER="(ADDRESS_LIST= \ LOCAL_LISTENER = "(ADDRESS_LIST = \
                           (ADDRESS= \ (주소 = \
                             (PROTOCOL=TCP) (PROTOCOL = TCP)
                             (HOST=localhost) (= localhost를 호스트)
                             (PORT=1521) (PORT = 1521)
                           ) )
                           (ADDRESS= (= 해결
                             (PROTOCOL=IPC) (PROTOCOL = IPC)
                             (KEY=O901DB) (KEY = O901DB)
                           ) )
                         )" ) " 

The first example specifies one listener address. 첫번째 예제 하나의 수신기의 주소를 지정합니다. Since the port for this listener is 1526, rather than the default of 1521, this is considered a non-default listener. 이 리스너에 대한 포트가 1526이기 때문에, 오히려 1521의 기본보다, 이것은 기본이 아닌이 리스너로 간주됩니다. The second example shows two addresses and also represents the default value for the LOCAL_LISTENER parameter. 두 번째 예제는 두 개의 주소를 보여줍니다 또한 LOCAL_LISTENER 매개 변수에 대해 기본값을 나타냅니다.

Consider the following when trying to decide on whether to use the LOCAL_LISTENER init.ora parameter or the LISTENER attribute of MTS_DISPATCHERS. LOCAL_LISTENER init.ora 매개 변수 또는 MTS_DISPATCHERS의 수신기 속성을 사용할지 여부를 결정하려고 할 때 다음을 고려하십시오. Using the LISTENER attribute gives you finer control; you can have different dispatchers register with different listeners. 수신기 속성을 사용하면 당신에게 미세한 제어 기능을 제공하며, 다른 dispatchers 다른 청취자가 등록을 할 수 있습니다. LOCAL_LISTENER on the other hand, provides global control. 반면에 LOCAL_LISTENER가 글로벌 제어를 제공합니다. Oracle still recommends the use of the LISTENER attributed defined in the MTS_DISPATCHERS parameter. 오라클은 여전히​​ MTS_DISPATCHERS 매개 변수에 정의된 리스너 귀속의 사용을 권장합니다.

LARGE_POOL LARGE_POOL

We have discussed the use of the LARGE_POOL several times in this article. 우리는이 문서에 나와있는 LARGE_POOL 여러 번의 사용을 논의했습니다. Although it is not and MTS specific parameter, it is something that needs strong consideration when implementing MTS. 그것이 MTS 특정 매개 변수가 아니므로이지만, MTS를 구현할 때 강한 배려를 필요로 무언가이다. If your instance does not have a large pool defined, the session specific memory for all MTS connections will be taken from the shared pool. 인스턴스는 정의된 대형 수영장이 없다면, 모든 MTS 연결 세션 특정 메모리는 공유 수영장에서 가져온 것입니다. Have MTS take from the shared pool causes fragmentation and is not the recommended configuration from Oracle. 공유 수영장 조각을 원인과 오라클의 권장 구성하지 않습니다에서 MTS를 취할 있습니다.

Forcing a Dedicated Server Connection 전용 서버 연결을 강제

Remember that when configuring MTS requires no changes being made to your Net8 config files. MTS를 구성할 때해도 Net8 설정 파일을 만들어도되고 변경이 필요 없다는 것을 기억하십시오. MTS configuration happens at the instance level, and when configured, new connections start using it. MTS 구성 인스턴스 수준에서 발생하고 구성할 때, 새로운 연결을 사용하여 시작합니다. One thing you can control though through the use of your Net8 config files, is forcing a dedicated connection. 귀하의 Net8 설정 파일의 사용을 통해 제어할 수 있지만 한 가지는 전용 연결을 강제합니다. (Overriding the MTS configuration at the instance). (인스턴스에 MTS 구성을 우선). There are basically two ways to force a dedicated server connection: tnsnames.ora and sqlnet.ora. tnsnames.ora와 sqlnet.ora : 전용 서버 연결을 강제하는 방법은 두 가지가 기본적으로 있습니다.

tnsnames.ora tnsnames.ora
Simply add the attribute (SERVER=DEDICATED) to the list of CONNECT_DATA attributes. 간단히 CONNECT_DATA 속성 목록에 속성 (서버 = 전용)을 추가합니다.

  O901DB_DEDICATED.world = O901DB_DEDICATED.world =
  (DESCRIPTION = (DESCRIPTION =
     (ADDRESS_LIST = (ADDRESS_LIST =
         (ADDRESS = (= 해결
            (PROTOCOL = TCP) (PROTOCOL = TCP)
            (Host = cartman) (호스트 = cartman)
            (Port = 1521) (포트 = 1521)
         ) )
     ) )
     (CONNECT_DATA = (CONNECT_DATA =
         (SID = O901DB) (SID = O901DB)
         (SERVER = DEDICATED) (서버 = 전용)
     ) )
  ) ) 

sqlnet.ora sqlnet.ora
Use the USE_DEDICATED_SERVER=ON in the sqlnet.ora file to force EVERY session that you initiate from your client to use dedicated server. 당신은 전용 서버를 사용하도록 클라이언트에서 시작하는 모든 세션을 강제로 sqlnet.ora 파일에 = ON USE_DEDICATED_SERVER을 사용합니다. As you can see, this is a much less flexible approach as it does not allow for specific connections to use dedicate server. 당신이 볼 수 있듯이, 이것은 서버를 바치고 사용하는 특정 연결을 허용하지 않는 등 훨씬 덜 유연한 접근 방식이다.

Viewing MTS Statistics MTS 통계보기

Operating-System Commands 운영 체제 명령

Within UNIX and Linux, each dispatcher and shared server process is a separate operating-system process. UNIX 및 Linux, 각 배차 및 공유 서버 프로세스 내에서 별도의 운영 체제 프로세스입니다. The exact naming format varies from platform to platform, but the dispatcher process will always have the format d xxx in their name, and the shared server process will always have s xxx in their name. 정확한 명명 형식은 플랫폼에서 플랫폼으로 다양하지만, 배차 프로세스는 항상 그들의 이름에서 형식 D의 XXX가되며, 공유 서버 프로세스는 항상 자신의 이름 님의 XXX를해야합니다. In almost all cases, the xxx will be a number starting at 000. 거의 모든 경우에, XXX는 000부터 시작 번호가됩니다. This number gets incremented sequentially for each new dispatcher and/or shared server process started. 이 번호는 각각의 새로운 배차 및 / 또는 공유 서버 프로세스 시작에 대해 순차적으로 증가된옵니다.

On most UNIX system, you can make use of the ps command to generate a list of these processes. 대부분의 UNIX 시스템에서는 PS 명령의 사용이 프로세스의 목록을 생성하실 수 있습니다. You would then pipe this output into the grep command to filter out the ones that you are interested in. The following is an example: 당신은 grep 명령으로 파이프이 출력을 다음 예입니다 인치 자네가 관심이되는 것들을 걸러 다음과 같습니다

  O901DB on cartman: ps -ef | grep ora_[ds][0123456789]*_O901DB cartman에 O901DB : PS - EF | grep ora_ [DS] [0123456789] * _O901DB
  oracle 8742 1 0 Feb 06 ? 오라클 8742 1 0 2월 6일? 0:00 ora_s013_O901DB 0시 ora_s013_O901DB
  oracle 8740 1 0 Feb 06 ? 오라클 8740 1 0 2월 6일? 0:00 ora_s012_O901DB 0시 ora_s012_O901DB
  oracle 8720 1 0 Feb 06 ? 오라클 8720 1 0 2월 6일? 0:00 ora_s002_O901DB 0시 ora_s002_O901DB
  oracle 8724 1 0 Feb 06 ? 오라클 8724 1 0 2월 6일? 0:00 ora_s004_O901DB 0시 ora_s004_O901DB
  oracle 8716 1 0 Feb 06 ? 오라클 8716 1 0 2월 6일? 0:08 ora_s000_O901DB 0시 8분 ora_s000_O901DB
  oracle 8738 1 0 Feb 06 ? 오라클 8738 1 0 2월 6일? 0:00 ora_s011_O901DB 0시 ora_s011_O901DB
  oracle 8718 1 0 Feb 06 ? 오라클 8718 1 0 2월 6일? 0:06 ora_s001_O901DB 0시 6분 ora_s001_O901DB
  oracle 8728 1 0 Feb 06 ? 오라클 8728 1 0 2월 6일? 0:00 ora_s006_O901DB 0시 ora_s006_O901DB
  oracle 8736 1 0 Feb 06 ? 오라클 8736 1 0 2월 6일? 0:00 ora_s010_O901DB 0시 ora_s010_O901DB
  oracle 8722 1 0 Feb 06 ? 오라클 8722 1 0 2월 6일? 0:00 ora_s003_O901DB 0시 ora_s003_O901DB
  oracle 8744 1 0 Feb 06 ? 오라클 8744 1 0 2월 6일? 0:00 ora_s014_O901DB 0시 ora_s014_O901DB
  oracle 8726 1 0 Feb 06 ? 오라클 8726 1 0 2월 6일? 0:00 ora_s005_O901DB 0시 ora_s005_O901DB
  oracle 8730 1 0 Feb 06 ? 오라클 8730 1 0 2월 6일? 0:00 ora_s007_O901DB 0시 ora_s007_O901DB
  oracle 8734 1 0 Feb 06 ? 오라클 8734 1 0 2월 6일? 0:00 ora_s009_O901DB 0시 ora_s009_O901DB
  oracle 8732 1 0 Feb 06 ? 오라클 8732 1 0 2월 6일? 0:00 ora_s008_O901DB 0시 ora_s008_O901DB
  oracle 8746 1 0 Feb 06 ? 오라클 8746 1 0 2월 6일? 0:00 ora_s015_O901DB 0시 ora_s015_O901DB
  oracle 8748 1 0 Feb 06 ? 오라클 8748 1 0 2월 6일? 0:00 ora_s016_O901DB 0시 ora_s016_O901DB
  oracle 8750 1 0 Feb 06 ? 오라클 8750 1 0 2월 6일? 0:00 ora_s017_O901DB 0시 ora_s017_O901DB
  oracle 8752 1 0 Feb 06 ? 오라클 8752 1 0 2월 6일? 0:00 ora_s018_O901DB 0시 ora_s018_O901DB
  oracle 8754 1 0 Feb 06 ? 오라클 8754 1 0 2월 6일? 0:00 ora_s019_O901DB 0시 ora_s019_O901DB
  oracle 8756 1 0 Feb 06 ? 오라클 8756 1 0 2월 6일? 0:00 ora_s020_O901DB 0시 ora_s020_O901DB
  oracle 8758 1 0 Feb 06 ? 오라클 8758 1 0 2월 6일? 0:00 ora_s021_O901DB 0시 ora_s021_O901DB
  oracle 8760 1 0 Feb 06 ? 오라클 8760 1 0 2월 6일? 0:00 ora_s022_O901DB 0시 ora_s022_O901DB
  oracle 8762 1 0 Feb 06 ? 오라클 8762 1 0 2월 6일? 0:00 ora_s023_O901DB 0시 ora_s023_O901DB
  oracle 8764 1 0 Feb 06 ? 오라클 8764 1 0 2월 6일? 0:00 ora_s024_O901DB 0시 ora_s024_O901DB
  oracle 8766 1 0 Feb 06 ? 오라클 8766 1 0 2월 6일? 0:01 ora_d000_O901DB 0시 1분 ora_d000_O901DB
  oracle 8768 1 0 Feb 06 ? 오라클 8768 1 0 2월 6일? 0:02 ora_d001_O901DB 0시 2분 ora_d001_O901DB 

The above example shows two dispatcher processes as well as 25 shared server processes. 위 예제는 두 배차 프로세스뿐만 아니라 25 공유 서버 프로세스를 보여줍니다.

Listener Control 리스너 제어

Using the SERVICES command within the Listener Control utility, you can get a listing of the dispatchers that have been registered with the listener. 리스너 제어 유틸리티 내에서 서비스 명령을 사용하면 리스너에 등록되어있는 dispatchers의 목록을 얻을 수 있습니다. Here is a sample out of the SERVICES command: 여기 서비스 명령의 한 예제입니다 :

  LSNRCTL> SERVICES listener LSNRCTL> 서비스 청취자
  Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=cartman)(PORT=1526))) (= (ADDRESS = (PROTOCOL = TCP) (HOST = cartman) (PORT = 1526가)) 설명)은 연결
  Services Summary... 서비스 요약 ...
  Service "O901DB" has 1 instance(s). 서비스 "O901DB는"1 인스턴스 (들)을하고 있습니다.
    Instance "O901DB", status UNKNOWN, has 4 handler(s) for this service... 예를 들어 "O901DB"상태 알 수없는이 서비스에 대한 네 처리기 (들)을했습니다 ...
      Handler(s): 처리기 (들) :
        "DEDICATED" established:194 refused:0 "전용"설립 : 194 거절 : 0
           LOCAL SERVER 로컬 서버
        "DEDICATED" established:0 refused:0 state:ready "헌신"은 설립 : 0 거부 : 0 상태 : 준비
           LOCAL SERVER 로컬 서버
        "DISPATCHER" established:96 refused:23 current:38 max:250 state:ready 설립 "배차원"96 거부 : 23 현재 : 38 최대 : 250 상태 : 준비
           D000 D000 
           (ADDRESS=(PROTOCOL=tcp)(HOST=cartman)(PORT=1219)) () = (PROTOCOL = TCP) (HOST = cartman) (포트 = 1219을 주소)
  Service "PLSExtProc" has 1 instance(s). 서비스 "PLSExtProc"1 인스턴스 (들)을하고 있습니다.
    Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service... 예를 들어 "PLSExtProc"상태 알 수없는이 서비스에 대해 1 처리기 (들)을했습니다 ...
      Handler(s): 처리기 (들) :
        "DEDICATED" established:0 refused:0 "전용"설립 : 0 거절 : 0
           LOCAL SERVER 로컬 서버
  The command completed successfully 명령이 성공적으로 완료 

Figure 4 (below) gives a short overview of the different parameters in the SERVICES output command. 그림 4는 (아래) 서비스 출력 명령에 다른 매개 변수의 짧은 개요를 제공합니다.

Figure 4: Output from the Listener Control's SERVICES command 그림 4 : 리스너 제어의 서비스 명령에서 출력

Dynamic Performance Views 동적 성능보기

Dynamic Performance View relevant to MTS MTS와 관련된 동적 성능보기
View name 이름보기	Description 설명
V$CIRCUIT V $ 회로	Returns one row to the instance for each MTS connection. 각각의 MTS 연결 인스턴스에 행 하나를 반환합니다. A circuit is a connection through a specific dispatcher and shared server process. 회로는 특정 배차 및 공유 서버 프로세스를 통해 연결됩니다. Columns in this view relate each MTS circuit to a specific dispatcher, shared server process and session. 이보기에서 열은 특정 배차, 공유 서버 프로세스와 세션에 각각의 MTS 회로 관련.
V$DISPATCHER V $의 배차	Returns one row for each dispatcher process associated with the instance. 인스턴스와 연관된 각 배차 프로세스를 하나의 행을 반환합니다. This view returns information such as the dispatcher's name, network address, process address and status. 이보기에는 배차의 이름, 네트워크 주소, 프로세스 주소 및 상태 등의 정보를 제공합니다.
V$DISPATCHER_RATE V $ DISPATCHER_RATE	Returns one row for each dispatcher process, and returns rate statistics for each dispatcher. 각 배차원 공정 한 행을 반환하고, 각각의 배차에 대한 비율 통계를 반환합니다.
V$MTS V $ MTS	Returns only one row. 하나의 행을 반환합니다. This view provides some statistics that you can use to determine whether or not you have the MTS_SERVERS parameter set to a reasonable value. 이보기는 당신이 적당한 값으로 MTS_SERVERS 매개 변수 집합이 있는지 여부를 확인하는 데 사용할 수있는 몇 가지 통계를 제공합니다.
V$QUEUE V $ 대기열	Returns one row for MTS queue in the instance. 인스턴스에 MTS 대기열에 대해 행 하나를 반환합니다. Each dispatcher will have one response queue associated with it, and their will always be one common request queue for the instance. 각 배차원는과 관련된 한 응답 대기열을 것입니다, 그들은 항상 인스턴스에 대해 하나 일반적인 요청 대기열 것입니다. The number of rows returned by V$QUEUE is always equal to the number of dispatchers plus one. V $ 대기열에 의해 반환된 행 수를 항상 dispatchers 더하기 하나의 숫자와 동일한 것입니다.
V$SHARED_SERVER V $ SHARED_SERVER	Returns one row for each shared server process that is currently running as part of the instance. 현재 인스턴스의 일부로 실행되는 각 공유 서버 프로세스에 대해 행 하나를 반환합니다. This view returns the process name, process address, status and other useful statistics. 이보기는 프로세스 이름, 프로세스 주소, 상태 및 기타 유용한 통계를 반환합니다.

Table 2: Dynamic Performance View relevant to MTS 표 2 : MTS와 관련된 동적 성능보기

Dispatcher Process Status 배차원 프로세스 상태

  SQL> SELECT name, status, accept, created, conf_indx, network SQL> SELECT 이름, 상태, 수락, 만든, conf_indx, 네트워크
    2 FROM v$dispatcher; V $ 배차원에서 2;

  NAME STATUS ACCEPT CREATED CONF_INDX NETWORK NAME 상태 만든 CON​​F_INDX 네트워크에 동의
  ---- ------ ------ ------- --------- -------------------------------------------------- ---- ------ ------ ------- --------- ------------------ --------------------------------
  D000 WAIT YES 56 0 (ADDRESS=(PROTOCOL=tcp)(HOST=cartman)(PORT=38793)) D000은 예 56 0 (= (PROTOCOL = TCP) (HOST = cartman) (포트 = 38793을 주소)) 기다려요
  D001 WAIT YES 78 1 (ADDRESS=(PROTOCOL=tcp)(HOST=cartman)(PORT=38794)) D001은 (주소 = (PROTOCOL = TCP) (HOST = cartman) (포트 = 38794)) YES 78 일 잠깐 

• NAME : Returns the dispatcher's name. 이름 : 배차의 이름을 반환합니다. This forms part of the operating system process name. 이것은 운영 체제 프로세스 이름의 일부를 형성합니다.

• NAME : Returns the dispatcher's current status. 이름 : 배차의 현재 상태를 반환합니다. Valid values are: 유효한 값은 다음과 같습니다
  • WAIT : The dispatcher is idle and waiting for work. WAIT : 배차원는 유휴 상태이고 일을 기다리고 있습니다.
  • SEND : The dispatcher is sending a message. 보내기 : 배차원는 메시지를 보내는 것입니다.
  • RECEIVE : The dispatcher is receiving a message. 수신 : 배차원는 메시지를 받고 있습니다.
  • CONNECT : The dispatcher is establishing a new connection from a client. 연결 : 배차원는 클라이언트에서 새 연결을 설정합니다.
  • DISCONNECT : A client is disconnecting from the dispatcher. 분리 : 클라이언트는 배차에서 분리됩니다.
  • BREAK : The dispatcher is handling a break. BREAK : 배차원는 휴식을 처리합니다.
  • OUTBOUND : The dispatcher is establishing an outbound connection. 아웃 바운드 : 배차원는 아웃 바운드 연결을 설정합니다.

• ACCEPT : Tells you whether or not the dispatcher is accepting new connections. 동의 : 배차가 새로운 연결을 수락할지 여부를 알려줍니다. Valid values are YES and NO. 유효한 값은 그렇기도하고 아니기도하지 않습니다.

• CREATED : Returns the number of virtual circuits currently associated with this dispatcher. 만든 : 현재이 배차와 관련된 가상 회로의 개수를 반환합니다.

• CONFIG IDX : Indicates the specific MTS_DISPATCHERS initialization parameter on which this dispatcher is based. CONFIG IDX :이 배차의 기반이되는 특정 MTS_DISPATCHERS 초기화 매개 변수를 나타냅니다. Dispatchers created from the first MTS_DISPATCHERS parameter in your instance's parameter file will have a CONF_INDX value of 0. 인스턴스의 매개 변수 파일의 첫 번째 MTS_DISPATCHERS 매개 변수에서 생성된 Dispatchers 0의 CONF_INDX 값이됩니다. Dispatcher's created from the second MTS_DISPATCHERS parameter will have a value of 1, and so on. 배차는 두 번째 MTS_DISPATCHERS 매개 변수에서 이렇게 1의 값을 가지고 있고, 만들어지는 것입니다.

• NETWORK : Returns the dispatcher's network address. 네트워크 : 배차의 네트워크 주소를 반환합니다.

Dispatcher Process Utilization 배차원 프로세스 활용

  SQL> SELECT name, busy / (busy + idle) * 100 SQL> SELECT 이름, (바쁜 + 유휴) / 바쁜 * 100
    2 FROM v$dispatcher; V $ 배차원에서 2;

  NAME BUSY/(BUSY+IDLE)*100 이름 (바쁜 + 유휴) / 바쁜 * 100
  ---- -------------------- ---- --------------------
  D000 .000359889 D000 0.000359889
  D001 .000405469 D001 0.000405469 

Doesn't look like these dispatchers are very busy! 이러한 dispatchers 매우 바쁘다처럼 보이지 않는다! Keep in mind that the BUSY and IDLE values are reported in hundredths of a second. 바쁜와 유휴 값이 두 번째의 hundredths에서보고 있음을 유념하시기 바랍니다. If the BUSY value for a dispatcher is 100, that means the dispatcher had been busy for 1 second. 배차에 대한 약속 값이 100면, 그것은 배차 1 초 동안 바쁜 있었다는 것이죠.

If dispatcher utilization is very high, you should consider creating more dispatcher processes. 배차 사용률이 매우 높은 경우 더 배차 프로세스를 만드는 것이 좋습니다. If dispatcher utilization is very low, you should consider deleting some dispatcher processes. 배차 사용률이 매우 낮은 경우, 일부 배차 프로세스를 삭제 고려해야합니다. In the above example, I would consider only running one dispatcher process to support this instance. 위의 예제에서, 난 단지이 인스턴스를 지원하는 하나의 배차 프로세스를 실행이라고 생각한다.

Queue Size and Wait Time 대기열 크기와 대기 시간

  SQL> SELECT paddr, type, queued, DECODE(totalq,0,0,wait/totalq) SQL> SELECT paddr, 종류, 대기열, 디코딩 (totalq, 0,0, 잠깐 만요 / totalq)
    2 FROM v$queue; V $ 대기열에서 2;

  PADDR TYPE QUEUED DECODE(TOTALQ,0,0,WAIT/TOTALQ) PADDR 종류 대기열 해독 (TOTALQ, 0,0, 기다려 / TOTALQ)
  -------- ---------- -------- ------------------------------ -------- ---------- -------- ------------------------ ------
  00 COMMON 0 .009878904 00 공통 0 0.009878904
  8008AC54 DISPATCHER 0 3.38482683 8008AC54 배차원 0 3.38482683
  8008AF70 DISPATCHER 0 .009591116 8008AF70 배차원 0 0.009591116 

You can get an idea of how well work is flowing through the request and response queues by using v$queue. 이 작품은 V $ 대기열을 사용하여 요청 및 응답 대기열을 통해 흐르는 얼마나 잘의 아이디어를 얻을 수 있습니다.

The DECODE in the query handles the case where the TOTALQ column, which is the divisor, happens to be zero. 검색어에 디코딩은 제수입니다 TOTALQ 열에, 제로에서 일어나는 사건을 처리합니다. The average wait time is reported in hundredths of a second. 평균 대기 시간은 초 hundredths에보고됩니다. (ie If the average wait time of a dispatcher is 37, works out to 0.37 seconds.) (즉 배차의 평균 대기 시간은 37 경우 0.37 초로 사용할 수 있습니다.)

The COMMON queue is where requests are placed so that they can be picked up and executed by a shared server process. 요청들이 데리러와 공유 서버 프로세스에 의해 실행될 수 있도록 배치 어디 공통 대기열입니다. If you average wait time is high, you might be able to lower it by creating more shared server processes. 기다리는 시간 높은 평균되면 더 많은 공유 서버 프로세스를 생성하여 그것을 낮출 수 있습니다.

Users and Dispatchers 사용자 및 Dispatchers

  SQL> SELECT d.name, s.username, c.status, c.queue SQL> SELECT d.name, s.username, c.status, c.queue
    2 FROM v$circuit c, v$dispatcher d, v$session s
    3 WHERE c.dispatcher = d.paddr AND c.saddr = s.saddr;

  NAME USERNAME STATUS QUEUE
  ---- ------------------ ---------------- ----------------
  D000 JHUNTER NORMAL NONE
  D001 AHUNTER NORMAL NONE 

• NAME : Returns the dispatcher's name. This forms part of the operating system process name.

• USERNAME : Oracle username.

• STATUS : Reports the status of the circuit, and may take one of the following values:
  • BREAK : The circuit had been interrupted due to a break.
  • EOF : The connection is terminating, and teh circuit is about to be deleted.
  • OUTBOUND : The circuit represents an outbound connection to another database.
  • NORMAL : The circuit represents a normal client connection.

• QUEUE : Reports on the work currently being done. One the following values will be returned:
  • COMMON : A request has been placed into the common request queue, and the circuit is waiting for it to be picked up be a shared server process.
  • DISPATCHER : Results from a request are being returned to the client by the dispatcher.
  • SERVER : A request is currently being acted upon by a shared server process.
  • NONE : A circuit (or connection) is idle. Nothing is happening.

Shared Server Utilization

 SQL> SELECT name, busy / (busy + idle) * 100
    2 FROM v$shared_server;

  NAME BUSY/(BUSY+IDLE)*100
  ---- -------------------- ---- --------------------
  S000 .00155527
  S001 .000669656
  S002 .000012313
  S003 0
  S004 0
  S005 0
  S006 0
  S007 0
  S008 0
  S009 0
  S010 0
  S011 0
  S012 0
  S013 0
  S014 0
  S015 0
  S016 0
  S017 0
  S018 0
  S019 0
  S020 0
  S021 0
  S022 0
  S023 0
  S024 0 

Other Shared Server Statistics

The v$mts view is useful when trying to tune both the MTS_SERVERS and MTS_MAX_SERVERS initialization parameters. Here is an example output from v$mts:

 SQL> SELECT servers_started, servers_terminated, servers_highwater
    2 FROM v$mts;

  SERVERS_STARTED SERVERS_TERMINATED SERVERS_HIGHWATER
  --------------- ------------------ -----------------
               94 18 25 

• SERVERS_STARTED : The number of shared server processes started as the instance adjusts the number of shared processes up and down from the initial value specified by the MTS_SERVERS parameter. When the instance starts, and after the initial number of shared server processes specified by MTS_SERVERS has been started, this value is set to 0. From that point on, this value is incremented whenever a new shared server process is started.

• SERVERS_TERMINATED : A count of the total number of shared server processes that have been terminated since the instance was started.

• NOTES : If the SERVERS_HIGHWATER value matches, the instance's MTS_MAX_SERVERS value, then you might realize a performance benefit from increasing MTS_MAX_SERVERS. If the counts for SERVERS_STARTED and SERVERS_TERMINATED keep climbing, then you should consider raising MTS_SERVERS. Raising the minimum number of shared server processes should reduce the number that are deleted only to be recreated later.