MTS详解

最新推荐文章于 2023-09-28 10:19:04 发布

ruiayLin

最新推荐文章于 2023-09-28 10:19:04 发布

阅读量1.8k

点赞数

ORACLE的连接模式有二，分别是专用服务器模式和共享服务器模式。

这两种模式很容易区分。

对于专用服务器模式，给每一个SESSION分配一个单独的SERVER PROCESS，直到用户断开连接，才会释放这一块资源。她就好比是我们的的士，在把你送到目的地之前不会为其他人服务的。

对于共享服务器模式，这就是我们的公交车了，一辆公交车是可以为多个用户服务的。

下面我来详细描述一下共享服务器模式。

上图是一个精典的MTS架构图。我们看到她接受的一用户请求之后的过程相对复杂：

1、第一步，监听将请求重定向到一个DISPATCHER

2、第二步，DISPATCHER将服务请求放到请求队列中，DISPATCHER属于一个特殊的进程，且拥有一些特殊的信息句柄。这个请求队列存在于SGA。

3、第三、四步，共享服务器进程从SGA的请求队列中获取处理这些请求

4、第五步，将结果返回到SGA中的响应队列中。（注：客户端不会永远不会直接和服务器进程进行交互）

5、第六步，响应队列返回给DISPATCHER

6、第七步，Dispatcher 进程返回响应至客户端

在MTS配置中，SGA包含特殊的内存结构。这样的结构包含两个队列：dispatcher进程存放的代表服务端请求的请求队列。响应队列包含服务器进程的响应信息。当执行成功后，请求和响应信息都将从队列中移除，用户会话数据同样保留在SGA(UGA)中。

在设计中，Dispatcher是轻量级的进程，允许客户端与服务端之间快速的信息传输。允许一个dispatcher服务多个客户端，尤其是比dedicated 连接方式开销小太多。

与MTS相关的参数较多，下面做个简单的介绍

LARGE_POOL_SIZE：每一个MTS连接占用约200K (如果需要支持10000个连接，大约需要2G的LARGE POOL)

SHARED_POOL_RESERVED_SIZE：SHARED POOL中为大内存分配所保留的大小。在使用MTS后，建议增大此保留值。

MTS_SERVICE：定义dispatcher用于注册监听的SERVICE NAME。默认就是DB_NAME。如果DB_NAME与MTS_SERVICE同名，当客户端发生请求的时候，将会获取到一个MTS连接。如果不可用，则会获取到一个DEDICATE连接。

LOCAL_LISTENER：地址和协议必须用listener.ora文件中的配置一致。如果指定将会覆盖MTS_LISTENER_ADDRESS和MTS_MULITPLE_LISTENERS。 local_listener =”(ADDRESS = (PROTOCOL=TCP)(HOST =10.253.34.19)(PORT=1521))”

SHARED_SERVERS：确定实例启动后的最小SHARED SERVER数目。它的数目取决于用户连接的并发请求。在一般情况下，一个服务器进程可以服务于10至20个用户。另外，在必要的时候，MTS_SERVERS可以自动增长到MTS_MAX_SERVERS的数目。

MAX_SHARED_SERVERS：实例中最大的SHARED SERVER数目。一般要设置为SHARED_SERVERS的2至20倍数目。

DISPATCHERS=”(ADDRESS=(PARTIAL=TRUE)(PROTOCOL=TCP)(HOST=192.168.1.10))(DISPATCHERS=2)” ，配置调度程序进程，其中可配置DISPATCHER的数目，及每个DISPATCHER支持的最大CONNECTION数目等。

MAX_DISPATCHERS：指定DISPATCHER进程的最大数目

SHARED_SERVER_SESSIONS：指定可以使用共享服务器连接的最大会话数。

SESSIONS：指定系统可以创建在最大会话数目。它的值可设置为：SHARED_SERVER_SESSIONS+专用服务器连接的最大值。

专用服务器连接的最大值如何计算呢？如果一个物理机有100G内存，操作系统+数据库等使用了50G内存。那么剩下的50G就可供专用服务器连接使用，每个专用服务器连接占用内存约8-10M，那么50G就可支持约5000个专用服务器连接。

那当我配置完成MTS后，怎么知道我们的配置是不是合理呢？我们可以做些如何的优化工作呢？我们可以通过动态性能视图来查看DIPATCHER繁忙情况、SHARED_SERVER的繁忙情况等等：

1、识别dispatcher进程的争用

set linesize 200

col protocol for a50

col “avg wait time per response” for a70

SELECT network “Protocol”,DECODE(SUM(totalq),0,’No responses’,SUM(wait)/SUM(totalq)*10||’ ms’) “avg wait time per response”

FROM v$queue q,v$dispatcher d

WHERE q.type=’DISPATCHER’

AND q.paddr=q.paddr

GROUP BY network;

以上SQL可获得dispatcher的等待时间。一般当等待时间超过1-10MS的时候，可能需要增加dispatcher的数目来提升性能。

2、测试dispatcher进程的繁忙程度

select name,(busy/(busy+idle))*100 “% of time busy” from v$dispatcher;

如果多数dispatcher进程都很忙，需要考虑是否有批任务处理，是否更适合使用dedicated连接。

3、正确分配LARGE_POOL_SIZE

SELECT SUM(value)/1024/1024||’ Mbytes’ “Total memory for all session”

FROM v$sesstat,v$statname

where name =’session uga memory’

and v$sesstat.statistic#=v$statname.statistic#;

SELECT SUM(value)/1024/1024||’ Mbytes’ “Total memory for all session”

FROM v$sesstat,v$statname

where name =’session uga memory max’

and v$sesstat.statistic#=v$statname.statistic#;

监控V$SESSTAT来决定LARGE_POO_SIZE需要设置多大。如果LARGE_POOL_SIZE没有在参数文件中被指定，那么UGA将在SHARED_POOL中为并行的共享服务进程用户分配内存空间。

4、识别SHARED SERVER进程的争用

SELECT DECODE(totalq,0,’no requests’,wait/totalq*10||’ ms’) “avg wait time per request”

from v$queue

where type=’COMMON’;

select name,requests,(busy/(busy+idle))*100 “%time busy” from v$shared_server;

如果很少量的请求而导致BUSY TIME占比很大，建议不要使用SHARED SERVER模式。宁可让大量的请求使得这些共享服务器进程繁忙起来，而如果是因为请求过大导致的繁忙，我们可以通过添加SHARED SERVER数目来提高性能。

大家在使用MTS的时候还要注意一些已知的问题：

1、如果 TNSNAMES中指定了“ADDRESS_LIST”MTS和DBLINK会阻碍shared server。BUG 300008

2、在连接池使用的情况下，MTS_DISPATCHERS不可动态修改的，如果使用 alter system set mts_dispatchers，将会导致所有存储的连接hang住。