管理Oracle Session是后台DBMS采用Oracle的信息管理系统的一个重要工作。如果管理不当，会对系统的性能和运行的稳定性产生非常大的影响。Oracle Session是非常宝贵的资源，其数量通常都是有一个固定的设定值，对于Oracle 10g Enterprise Edition来说，如果不修改初始化参数，那么默认最大的Session数为170个，在后期系统管理员可以根据实际的需要来修改这个数值。因此系统必须非常小心的管理这些Session。本文主要就多层分布式系统中Oracle Session的管理提供解决方案。下图是本文所述的多层分布式管理系统的模型图，层与层之间的调用关系如图所示。

对于使用.NET Framework作为开发平台的系统来说，如果是Web Application或者Smart Client Application，在中间件层，应用程序服务器多采用IIS，业务逻辑组件和数据访问组件通常寄宿在IIS进程中运行。如果采用此种部署方案，那么影响Oracle Session的主要是两种因素：

1）IIS进程数；

2）连接池的设置。

一、连接池对Oracle Session的影响

     在现代的软件设计中，为了提高系统的性能，在数据访问层通常会采用连接池来改善数据库连接的效率来改善系统的性能，很多人可能不知道连接池的配置对Oracle Session的产生有着至关重要的影响。连接池对Oracle Session影响主要有两个因素：

1）对于ADO.NET来说，对于不同的连接字符串会产生不同的连接池。

2）min pool size的值。

对于使用了连接池的数据访问层来说，Oracle Session的产生机制为：minsessions=（连接池数）X（min pool size）。值得注意的是每次产生新的Oracle Session是在不同AppDomain边界产生的时候发生的，也就是说不同的进程每执行一次就会产生minsessions个oracle Session，直到这个进程结束才会释放这些session。

二、IIS进程数对Oracle Session的影响

在IIS6.0中，采用了新的进程隔离模式来响应用户的请求，管理员可以设置多个进程来满足实际的需要。IIS进程管理器（实际上是inetinfo.exe）负责调度这些进程。在IIS管理器中，我们可以这样来增加IIS进程数。

在Web 园中，我们可以设置最大工作进程数。设置完以后，打开任务管理器，如果有请求发过来，我们可以看到多了很多W3wp.exe。

上文说到Oracle Session是在不同的AppDomain边界产生的时候发生的，因此不同的请求发送到IIS以后，每一个IIS进程使Oracle产生min pool size个Sessions。按照这个推算，那么实际产生的会话数为：

Sessions = （IIS process number） X （min pool size）。

从上文的分析中我们可以得出，对于Oracle来说，安全的Sessions数应该为Sessions = （IIS process number） X （min pool size）X（连接池数）。假定连接池数为1，连接池min pool size为10，iis进程数为30，那么安全的Oracle Sessions的数量应该为300。如果不按照这个数量进行设置，那么系统运行的过程中IIS会经常报告一些莫名奇妙的错误，如认证失败。很多人可能会认为IIS已经Crash了，实际上是由于Session的数量超过了Oracle允许的数量。

当然我们还必须将由于程序异常处理不当等造成的坏死的Session的可能数量计算在内。为了保证系统的运行问题，应该在上文所说的计算方法上加一个保险值，如350。

以上内容是在实践的过程中得出的经验计算公式，不对的地方请指正。