oracle share server

最新推荐文章于 2021-04-14 08:38:47 发布

iteye_14608

最新推荐文章于 2021-04-14 08:38:47 发布

阅读量123

点赞数

文章标签：数据库

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

这一块应该和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 serverby designand 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个服务进程，但是在共享模式，可能几十个就够了。