oracle share server

 今天听同事做培训，提到了这一块，这里再复习下。

        这一块应该和PG的中的连接池是两种不同的概念，pgpool和pgbounce，pgbouncer是一个轻量级的连接池，小巧实用，以下是一些特性，无论以下的那种模式，pgbouncer和数据库是不会断开的。

Features

• Several levels of brutality when rotating connections:

  Session pooling

  Most polite method. When client connects, a server connection will be assigned to it for the whole duration it stays connected. When client disconnects, the server connection will be put back into pool. This mode supports all PostgeSQL features.

  Transaction pooling

  Server connection is assigned to client only during a transaction. When PgBouncer notices that transaction is over, the server will be put back into pool.

  This mode breaks few session-based features of PostgreSQL. You can use it only when application cooperates by not using features that break. See the table below for incompatible features.

  Statement pooling

  Most aggressive method. This is transaction pooling with a twist - multi-statement transactions are disallowed. This is meant to enforce "autocommit" mode on client, mostly targeted for PL/Proxy.

• Low memory requirements (2k per connection by default). This is due to the fact that PgBouncer does not need to see full packet at once.
• It is not tied to one backend server, the destination databases can reside on different hosts.
• Supports online reconfiguration for most of the settings.
• Supports online restart/upgrade without dropping client connections.
• Supports protocol V3 only, so backend version must be >= 7.4.

• feature matrix for pooling modes

  Following table list various PostgreSQL features and whether they are compatible with PgBouncer pooling modes. Note that 'transaction' pooling breaks client expectations of server by design and can be used only if application cooperates by not using non-working features.

  Supported PostgreSQL features.

  Feature	Session pooling [1]	Transaction pooling
  Startup parameters [2]	Yes	Yes
  SET/RESET	Yes	No
  LISTEN/NOTIFY	Yes	No
  WITHOUT HOLD CURSOR	Yes	Yes
  WITH HOLD CURSOR	Yes	No
  Protocol-level prepared plans	Yes	No [3]
  PREPARE / DEALLOCATE	Yes	No
  ON COMMIT DROP temp tables	Yes	Yes
  PRESERVE/DELETE ROWS temp tables	Yes	No
  Cached plan reset	Yes	Yes [1]
  LOAD statement	Yes	No
  UDFs with session state	Yes	No

  • [1] - Full transparency requires PostgreSQL 8.3 and PgBouncer 1.1+ with server_reset_query = DISCARD ALL
  • [2] - Startup parameters are: client_encoding, datestyle, timezone, standard_conforming_strings and application_name. PgBouncer can detect their changes so it can guarantee they remain consistent for client. Available from PgBouncer 1.1.
  • [3] - It is possible to add support for that into PgBouncer.
  
  
  以上摘自wiki

oracle服务器进程有两种类型，一种是专有的，一种是共享的。很好理解，专有的也就是一个服务器进程只为一个用户服务，共享的，当然就是服务器进程为大家服务了。

 

 上图是专有模式，可以看到，用户进程和服务进程是分开的，每个用户进程都有对应的服务进程来服务，几十用户进行没有相关请求，服务进程也存在，只是保持空闲状态。还有一点，没有经过listener进行监听验证客户连接的时候，只允许专有模式。

 这个是共享模式，长任务和长连接，不适合共享模式，因为长任务和长连接占有的时间更长，高并发的短事务才适合于共享模式，共享模式是用来提高服务器的效率，相对于专有模式，需要更小的内存。用户进行这里是和调度进程建立连接。而且是有PMON进程向监听程序注册调度进程的负载，使得监听程序将请求转发给占用率低的调度进程。每个调度进程可以支持多个客户的连接，每个客户机连接都使用的是一个虚拟通道，其实就是一块内存区域，请求到达时，调度进程会将这个虚拟通道放入一个公共队列，然后从这个公共队列选择该虚拟通道为其服务，这种模式就可以用少量的服务器进程来大量的客户服务。

特点：减少内存使用，实现负载均衡，减少空闲的服务器进程数，增加可服务的用户。

打个比方，有1000个用户来请求，在专有模式，那么就需要1000个服务进程，但是在共享模式，可能几十个就够了。

 以上是共享模式的请求过程：

①. 用户将请求发送给调度程序。

②. 调度程序将请求置入“系统全局区” (System Global Area, SGA) 中的请求队列（公共队列）。

③. 共享服务器从请求队列选择该请求，然后处理该请求。

④. 共享服务器将响应放入请求调度程序的响应队列。

⑤. 该响应被传送给调度程序。

⑥. 调度程序将该响应返回给用户。

请求队列：

⊙ 所有调度程序共享一个请求队列。

⊙ 共享服务器监视请求队列以查看是否有新的请求。

⊙ 请求的处理采取先进先出(FIFO) 的原则。

⊙ 共享服务器将完成的所有请求放入请求调度程序的响应队列。

⊙ 每个调度程序在SGA 中都有自己的响应队列。  ⊙ 每个调度程序都负责将完成的请求发送回相应的用户进程。  CIRCUITS ⊙ 在整个会话期间，用户始终与同一个调度程序相连。  和专有模式内存处理的区别： 专有模式，UGA是在pga中，也就是说是私有的，但是在共享模式，你的信息肯定是所有进程都要知道，所以是在SGA中。 参数： dispathers，这个可以指定监听断电的网络地址，协议类型，以及要启动的调度器的个数等等。 max_dispathers 指定同事运行的调度进程的数目，这个是用来限制调度器的个数，以防消耗太多资源，如果比较空闲，可以减少调度器的个数。 V$CIRCUIT 和V$DISPATCHER可以监视调度程序的的负载。 shared_servers指定服务进程数。 max_shared_servers指定同时允许运行的最大服务器进程数。 V$SHARED_SERVER_MONITOR可以查看最大数目。 CIRCUITS参数指定虚拟线路的总数，影响SGA使用的重要参数。 另外需要注意的就是large pool的大小，和session数。最后一张图理解下circuits