Oracle 是一门博大精深的技术。玩了2年的oracle,依旧还有很多知识点不清楚。 昨天群里的朋友提到了 DEDICATED 和 SHARE 两种模式。 不清楚，默默的做点功课了。从网上搜了点知识，整理如下：
专用服务器（DEDICATED）：一个客户端连接对应一个服务器进程
共享服务器（SHARE）：多个客户端连接对应一个服务器进程，服务器端存在一个进程调度器来管理。它必须使用net services.也就是说必须配置tns。它适合用于高并发，事物量小，如果这个时候采用了共享模式，可以大大减少由于高度并发对于ORACLE服务器的资源消耗。
共享服务器体系：客户进程最终与一个调度程序连接，PMON进程注册了调度程序的位置和负荷，使监听器能够提交到负荷最小的调度程序。一个调度程序能并发地支持多重的客户连接。
专用服务器体系：每个客户进程与专用服务器进程连接。服务器进程没被任何另外的客户共享。
另：专用服务器体系结构不支持HTTP和IIOP客户，仅支持TTC客户。
一般我们以oracle默认的专用服务器方式就行了，没必要使用共享服务器模式。一个是我们是使用中间件（如：weblogic）去连oracle的，中间件本身有连接池机制，另外就是oracle的这个共享服务器方式也做的不够好了，有诸多缺点。
共享服务器具有以下一些缺点：
1)共享服务器的代码路径比专用服务器长，所以它天生就比专用服务器慢。
2)存在人为死锁的可能，因为它是串行的，只要一个连接阻塞，则该服务器进程上的所有用户都被阻塞，并且极可能死锁。
3)存在独占事务的可能，因为如果一个会话的事务运行时间过长，它独占共享资源，其它用户只能等待，而专用服务器，每个客户端是一个会话。
4)共享服务器模式限制了某些数据库特性，例如：不能单独启动和关闭实例，不能进行介质恢复，不能使用Log Miner，并且SQL_TRACE没有意义(因为是共享而不是当前会话的)。
MTS减少的内存实际上是专用服务器模式下每个用户连接到操作系统进程所需的内存，但它却使用SGA的Large_Pool来分配UGA，拆东墙补西墙，所减少的内存是很少的。如果用户会话的连接和断开很频繁，数据库进程的创建和删除的开销会非常大，这种情况最好采用共享服务器模式(否则，应该使用连接池技术)。如果客户端一次连接终身使用(会话生命周期内)，使用共享服务器模式的意义不大。因为大部分时间，一个会话就连接到一个服务器进程，无法共享服务器进程。
共享服务初始化参数的一些说明:
shared_servers ：指定了当instance 启动的时候 shared server process 启动的数量，不要将这个参数设置得太大，否者启动数据库instance 的时候 就会花更多时间,Oracle启动过后会根据负载来动态调整shared_servers。如果为0，表示数据库没有启动共享服务模式。 这个参数是配置shared server 必须的，而且只有这个参数是必须的。
修改参数： alter system set shared_servers=1;
max_shared_servers：ORACLE在同一个时刻最大能够使用的 shared server process.不要将这个参数设置小于 shared_servers,如果动态修改shared_servers大于max_shared_servers，ORACLE会覆盖max_shared_servers的值，此时你需要修改max_shared_servers.同时也不能大于processes。这个参数是为了给占用很大资源操作而设的(批处理)，为了预留一些process 给DBA任务(rman备份)，
shared_server_sesions: 指定了总共允许的的shared server session 的数量。如果设置了这个参数，那么就不要将这个值超过sessions，如果没有设置这个值，那么只要还有空闲的session,就可以被使用。设置这个值是为专有连接预留 user sessions.
dispatchers：配置 dispatcher process .如果不设置这个参数，只要设置了shared_servers ，oracle 也会自动设置一个基于tcp协议的dispatcher。还需要查看操作系统支持一个dispatcher能处理多少个connections
SQL> select * from v$dispatcher;
max_dispatchers: 设置同一时刻能够同时运行的dispatchers的数量，必须大于等于 dispatchers ，小于processes。这个参数也会被dispatchers覆盖。
circuits：指定了virtual circuits 的总数量。